Make android-activity dependency optional

[ardocrat]

This allows Android-targeting builds to use not only native-activity, but game-activity and avoids using a specific version of android-activity because Egui doesn't directly use the android-activity API.

[podusowski]

How do you select which type of the activity you app uses after this merge? By explicitly adding android-activity to your app?

[ardocrat]

How do you select which type of the activity you app uses after this merge? By explicitly adding android-activity to your app?

I simply use android-activity = { version = "0.4", features = ["game-activity"] } at my dependencies.

[rib]

Applications that are based on Winit should use the android-native-activity and android-game-activity features from Winit.

These features will result in Winit adding the required dependency on android-activity and it will also mean that egui or your application crate doesn't need to specify any version for depending on android-activity. (Potentially leading to a conflict in the future if Winit bumps the version of android-activity that it uses)

I think egui-winit should probably do the same as Winit here and provide android-native-activity and android-game-activity features that just map to the Winit features.

This way egui-winit never directly depends on android-activity unless it needs to directly use the android-activity API in the future.

CI can then hopefully just pick one of these features to use.

[emilk]

cargo check --features wgpu --target aarch64-linux-android fails

[rib]

I've opened up an alternative PR #2863 to hopefully address this issue by exposing features for the different backends (even though that may seem awkward; please see the PR for an explanation of why I think that's the appropriate solution here)

How do you select which type of the activity you app uses after this merge? By explicitly adding android-activity to your app?

I simply use android-activity = { version = "0.4", features = ["game-activity"] } at my dependencies.

If possible, I would generally recommend aiming to avoid adding a direct dependency on android-activity to your app if you don't make any significant use of the android-activity API.

Instead try to use the API re-exported from winit, e.g. like:

#[cfg(target_os = "android")]
use winit::platform::android::activity::AndroidApp;

By minimizing the number of crates that explicitly depend on the android-activity crate then it should be less painful to manage semver bumps for the android-activity crate if needed in the future (in situations where you're relying on some middleware crate like Winit to generally deal with the android-activity API).

The problem with adding a direct dependency is that Winit is much more likely to be opinionated about what version of android-activity it depends on and due to the runtime nature of the android-activity crate you will end up with a link-time build failure in the future if your app crate depends on a version that's not semver compatible with the version that Winit depends on.

[ardocrat]

Better fix: #2863