I’ve been working on an Android cloud-gaming platform and have been using ReDroid extensively:
https://github.com/maddox05/android-cloud-gaming
I’ve been running into limitations getting ReDroid to work outside of ARM hosts, and I was hoping to get your perspective given your experience with redroid-script, libndk / Houdini experiments, and Android container tooling in general.
Background / What I’m Trying to Do
- Use case: Run many Android “phones” concurrently for cloud gaming
- Android versions: Mostly 12 and 13
- Apps: Primarily ARM-only games
- Hosts available:
- ARM machines → works reliably, but no GPUs (cant get OSS nvidia drivers to work on g5g amazon instance, if you can help here LMK!!)
- x86 machines (AMD CPUs + AMD GPUs) → where I’m currently blocked
My long-term goal is to run the same Android containers across mixed infrastructure (ARM + x86) while still having GPU acceleration available.
Questions I’d Love Your Insight On
1. GPUs with ReDroid
- Have you personally had GPU acceleration working with ReDroid?
- If so:
- What host architecture (ARM vs x86)?
- What GPU vendor (AMD / NVIDIA / integrated)?
- What Android versions?
I’m especially curious whether AMD GPUs on x86 are fundamentally problematic, or if it’s more about current tooling maturity.
2. ARM translation layers (libndk / Houdini)
- Were you ever able to get ARM translation working reliably with ReDroid?
- If yes:
- Which Android versions (11 vs 12/13)?
- What setup or approach worked?
- If not:
- Do you see this as an AOSP 12+ limitation, or more of a container / native-bridge issue?
I noticed prior discussion around libndk / Houdini being difficult or broken on newer Android versions, so I’d love to know what your real-world conclusion was.
3. Single Docker image across x86 + ARM
- In your opinion, is it realistically possible to:
- Use one Android Docker image for both ARM and x86 hosts?
- Or is the practical reality today:
- Separate images per architecture?
- Or ARM-only if you want full ARM app compatibility?
If you’ve tried multi-arch images (or decided they’re not worth it), I’d love to understand why.
Why I’m Asking
For cloud gaming, ARM-only apps are the norm, and GPU access is critical. I want to make sure I’m not fighting fundamental limitations of the Android runtime or container model before committing to a long-term architecture.
Even high-level guidance or confirmations like “this isn’t viable today” would be extremely helpful.
Thanks a ton for your work on redroid-script and for any insight you’re willing to share 🙏
Maddox
I’ve been working on an Android cloud-gaming platform and have been using ReDroid extensively:
https://github.com/maddox05/android-cloud-gaming
I’ve been running into limitations getting ReDroid to work outside of ARM hosts, and I was hoping to get your perspective given your experience with redroid-script, libndk / Houdini experiments, and Android container tooling in general.
Background / What I’m Trying to Do
My long-term goal is to run the same Android containers across mixed infrastructure (ARM + x86) while still having GPU acceleration available.
Questions I’d Love Your Insight On
1. GPUs with ReDroid
I’m especially curious whether AMD GPUs on x86 are fundamentally problematic, or if it’s more about current tooling maturity.
2. ARM translation layers (libndk / Houdini)
I noticed prior discussion around libndk / Houdini being difficult or broken on newer Android versions, so I’d love to know what your real-world conclusion was.
3. Single Docker image across x86 + ARM
If you’ve tried multi-arch images (or decided they’re not worth it), I’d love to understand why.
Why I’m Asking
For cloud gaming, ARM-only apps are the norm, and GPU access is critical. I want to make sure I’m not fighting fundamental limitations of the Android runtime or container model before committing to a long-term architecture.
Even high-level guidance or confirmations like “this isn’t viable today” would be extremely helpful.
Thanks a ton for your work on redroid-script and for any insight you’re willing to share 🙏
Maddox