egui-winit: Remove android-activity dependency + add Activity backend features
#2863
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of depending on android-activity directly, this exposes the android-native-activity and android-game-activity features from Winit. This ensures that applications can choose what android-backend they use while also relying on Winit to decide what version of android-activity to use - without increasing the risk of a version conflict by having a direct dependency. _(NB: Egui doesn't currently use the android-activity API itself)_ Since android-activity provides the `android_main()` entry point for Android applications it's not possible to link in multiple version of the android-activity crate and so it's particularly important to avoid unnecessary direct dependencies that could cause a version conflict in the future. To help avoid the need for applications to directly depend on android-activity the Winit crate re-exports the android-activity API and exposes features to configure the backend so that application crates can instead rely on Winit to pull in a compatible version of android-activity. (This way version bumps for android-activity only need to be synchronized with the Winit crate). CI now enables the `android-native-activity` feature for testing. Fixes: emilk#2829 Fixes: emilk#2720 Closes: emilk#2834
TicClick
pushed a commit
to TicClick/egui
that referenced
this pull request
Apr 18, 2023
Instead of depending on android-activity directly, this exposes the android-native-activity and android-game-activity features from Winit. This ensures that applications can choose what android-backend they use while also relying on Winit to decide what version of android-activity to use - without increasing the risk of a version conflict by having a direct dependency. _(NB: Egui doesn't currently use the android-activity API itself)_ Since android-activity provides the `android_main()` entry point for Android applications it's not possible to link in multiple version of the android-activity crate and so it's particularly important to avoid unnecessary direct dependencies that could cause a version conflict in the future. To help avoid the need for applications to directly depend on android-activity the Winit crate re-exports the android-activity API and exposes features to configure the backend so that application crates can instead rely on Winit to pull in a compatible version of android-activity. (This way version bumps for android-activity only need to be synchronized with the Winit crate). CI now enables the `android-native-activity` feature for testing. Fixes: emilk#2829 Fixes: emilk#2720 Closes: emilk#2834
emilk
added
eframe
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of depending on
android-activitydirectly, this exposes theandroid-native-activityandandroid-game-activityfeatures from Winit (viaegui-winitandeframe).The overall issue here is that Android applications will very likely need to implement a subclass of
Activityin Java or Kotlin and when usingandroid-activitythat means they will have to choose to subclassNativeActivityorGameActivity. Since there are significant pros and cons to each one it isn't really appropriate for Egui to force a choice here.Conceptually the
android-activitycrate is the lowest-level, runtime crate for a native Android application written in Rust and then middleware like Winit and Egui sit on top of this. With the way Cargo features work then if we want make the low-level crate configurable for applications then we don't really have any choice but to expose equivalent features via middleware frameworks (such as Egui) that applications depend on.This ensures that applications can choose what
android-activitybackend they use while also relying on Winit to decide what version ofandroid-activityto use - without increasing the risk of a version conflict by having a direct dependency.(NB: Egui doesn't currently use the android-activity API itself)
Since
android-activityprovides theandroid_main()entry point for Android applications it's not possible to link in multiple versions of the android-activity crate and so it's particularly important to avoid unnecessary direct dependencies that could cause a version conflict in the future.To help avoid the need for applications to directly depend on
android-activitythe Winit crate re-exports theandroid-activityAPI and exposes features to configure the backend so that application crates can instead rely on Winit to pull in a compatible version ofandroid-activity. (This way version bumps forandroid-activityonly need to be synchronized with the Winit crate).CI now enables the
android-native-activityfeature for testing.Fixes: #2829
Fixes: #2720
Closes: #2834
Cc: @ardocrat