It should be possible to run Bevy Apps on Android
I'm working on this issue now, can I get it assigned to me to help head off accidental parallel implementations?
absolutely! thanks for picking it up. this will be huge :heart:
haha just noticed @karroffel already beat me to it
@PrototypeNM1 could you please share your progress and what's left to be done? I have some time on weekends that I could dedicate to adding Android support to Bevy. Last weekend I added Android support to cpal, which was one of the major blockers. There are still some issues on android-ndk-rs side. I could look into that, but it would be nice if you broke this issue into subitems and clarify what is done and what isn't.
To my knowledge there are 4 main blockers for Android support.
cpal (wip) (thanks for tacking this!)Rodio or winit.cargo apk is broken for how Bevy structures Cargo.toml (PR)bevy-glsl-to-spirv requires a rewrite or replacement.I'm working on 4. glsl-to-spirv as written depends on a bundled glslangValidator executable. This can't work on Android without hackery. Luckily glslangValidator has a recently added a C API.
@endragor since you started investigating cpal/oboe issues, I recommend figuring out why cargo apk had issues with including multiple shared libraries, doing so is helpful both for the Rust Android ecosystem and Bevy.
@PrototypeNM1 FYI over at https://github.com/bevyengine/bevy/issues/87 I put up https://github.com/bevyengine/bevy/pull/324 where currently uses shaderc-rs instead of glsl-to-spirv for iOS. Feel free to give it a try.
I too have now run into the missing touch support... I might hack something in just so I can play with it, not exactly sure what the correct API is.
Hey all! I was able to run Bevy 3d example on my Android phone.
Proof and repo:

Current issues are next:
This is the current status. Any feedback and advice are highly appreciated.
Fantastic! This is a big step :smile:
- Shaders still not working in runtime (so I did it in compile-time). As they precompiled - we can't use macros so that shadows are weird on the screenshot.
Yeah as we discussed elsewhere I think we'll want to solve this by adding pre-compiled shader support with the various permutations available. We'll want a system like that anyway to improve startup times in release builds. Alternatively we can try adding dynamic compilation support by (1) waiting for Naga or (2) somehow making shaderc compile on android
- Bgra was not worked with Vulkan on my phone so I replaced them with Rgba. Probably we can just replace them with Rgba everywhere in Bevy but this should be tested on other platforms.
Yeah thats a bit annoying, but it seems like we can work around it by selecting formats according to the platform. Alternatively, it might be worth checking with the wgpu folks to see if its something they can fix on their end.
- I couldn't make assets work at all on Android. It's pretty weird but with the newest version of android-ndk-rs - there are no assets when I trying to get them from asset_manager.
Hmm maybe we need to add them to some sort of asset manifest? I haven't worked with android for awhile, but i vaguely remember something like that.
@enfipy Awesome! Referencing your changes for TextureFormat I got runtime shader generation working on Android.

After about 10 hours of unsuccessful tries to make @PrototypeNM1 example with bevy-glsl-to-spirv work on my Mac (and Windows) - I added shaderc-rs support for Android (but it's still shitty) and was able to make shaders work in runtime.
Status update:
Naga will land soon). (Screenshot_1)Things need to be resolved:
jni call to this in a couple of days.This is all I remembered.
Screenshots:
Screenshot_1:

Screenshot_2:

Very nice progress! I just merged the asset system changes. I'm making a few more changes to AssetIo to re-add wasm compatibility. It should also make integrating the android AssetIo backend slightly easier (as I'm boxing AssetIo)
I'd like to just say, I'm not working on this issue, but am wildly excited to see its progress. Huge thanks to everyone working on it and know that the community is ecstatic to see this moving forward!!
@enfipy @cart Given Enfipy has more time to work on and organize this issue, I think we should transfer this issue to them.
I think this is a big enough issue / problem space that I don't think anyone needs to own it.
Added support for runtime spirv generation using a rewrite of glsl-to-spirv.
We're still waiting for a fix in cargo-apk's dependencies to land. The alternative of removing glob imports for bevy's workspaces is still a viable alternative if we wanted this working asap.
Would like to bring attention to proper implementation of winit events Event::Suspended and Event::Resumed at https://github.com/bevyengine/bevy/blob/master/crates/bevy_winit/src/lib.rs#L170 so it can proper release and reload resources
Would there be any interest in using cargo-mobile to help with building, generating Android Studio projects, running on device, etc?
Medium-to-long term I might be interested in adopting higher level abstractions. Short term I'd rather keep it simple, encourage people to become familiar with the "native" mobile tooling, and maintain control over "official" templates. We will likely create an official bevy_template repo in the near future.
A minor note on the current cargo-mobile bevy template: bevy has its own answer to #[mobile_entry_point] called #[bevy_main]. I'd prefer it if you used that instead (to support future non-mobile scenarios). Although thats only available on the master branch right now.
Most helpful comment
I'm working on this issue now, can I get it assigned to me to help head off accidental parallel implementations?