Is the Android target with the native renderer currently under active development?

[atty303]

On the current main branch, the WebView renderer starts successfully, but dx serve --android --renderer native fails with the following error.

I wanted to try the native renderer because the device uses an old Android 7 System WebView based on Chromium 52, which is too old to run the interpreter.

I understand that the native renderer is experimental. I would like to confirm whether Android support for the native renderer is currently under active development, or whether Android is not supported yet.

09:02:27 [cargo] error[E0583]: file not found for module `activity_impl`
   --> /Users/a13400/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/android-activity-0.6.1/src/lib.rs:381:1
    |
381 | pub(crate) mod activity_impl;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: to create the module `activity_impl`, create file "/Users/a13400/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/android-activity-0.6.1/src/activity_impl.rs" or "/Users/a13400/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/android-activity-0.6.1/src/activity_impl/mod.rs"
    = note: if there is a `mod activity_impl` elsewhere in the crate already, import it with `use crate::...` instead

09:02:27 [cargo] error: Either "game-activity" or "native-activity" must be enabled as features

If you have set one of these features then this error indicates that Cargo is trying to link together multiple implementations of android-activity (with incompatible versions) which is not supported.

Since android-activity is responsible for the android_main entrypoint of your application then there can only be a single implementation of android-activity linked with your application.

You can use cargo tree (e.g. via cargo ndk -t arm64-v8a tree) to identify why multiple versions have been resolved.

You may need to add a [patch] into your Cargo.toml to ensure a specific version of android-activity is used across all of your application's crates.
   --> /Users/a13400/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/android-activity-0.6.1/src/lib.rs:352:1
    |
352 | / compile_error!(
353 | |     r#"Either "game-activity" or "native-activity" must be enabled as features
...
366 | | android-activity is used across all of your application's crates."#
367 | | );
    | |_^

[BLCCoreStudio]

The native renderer is definitely still being worked on, but Android support looks like it’s still in the experimental/bleeding-edge stage rather than something fully supported through dx yet.
Blitz itself is under active development and already has Android builds, so I wouldn’t read this error as the Android native renderer being abandoned. It looks more like the Dioxus/Android integration path isn’t complete yet.

[AlakhiarovSalekh]

It looks like Android native rendering is actively being worked on, but I would still treat it as experimental rather than production-supported.

The current Dioxus README describes the WGPU/native renderer as experimental, while the normal mobile path is still the WebView renderer. There were also Android/native-related changes around the same time as this question, including Android-specific desktop/native fixes and native shell work.

The android-activity error itself is a feature/version wiring problem:

Either "game-activity" or "native-activity" must be enabled

and only one compatible android-activity implementation can end up in the final dependency graph.

I would check:

cargo tree -i android-activity

and verify that the native renderer path resolves one compatible android-activity version with exactly the required activity feature enabled.

So I would summarize the current state as:

• Android itself is supported by Dioxus.
• The WebView renderer is the stable/default mobile path.
• The native WGPU/Blitz path exists and is being developed, but is still experimental and may break on current main/release combinations.
• Your error does not look like "Android native renderer is intentionally unsupported"; it looks like dependency/feature integration that still needs stabilization.

For an Android 7 device with an unusably old WebView, the native renderer is a very reasonable thing to experiment with, but I would expect to track latest native-renderer fixes rather than rely on it as a stable target yet.