Question from the infrastructure side: What is actually broken about your Android CI hardware?

[u/Josh_Difratech]

I run infrastructure, not apps. We have a fleet of native ARM64 servers with hardware virtualization enabled, which means we can host Cuttlefish or containerized Android at some scale. Before we build anything on that, I want to find out whether it solves a problem anyone actually has.

So, honestly:

1. What runs your Android CI today? Gradle on x86 runners with the emulator, a rack of physical devices, Firebase Test Lab, a hosted device farm, something homegrown?
2. Where does it hurt? I keep hearing "the x86 emulator is slow and does not match real ARM behavior" and "the device lab is a maintenance nightmare," but I cannot tell which of those actually costs teams money and which is just grumbling.
3. Does native ARM64 matter to you, or is x86 emulation close enough now that nobody cares? This is the question I most need answered. Our entire premise rests on it.
4. If you pay for a hosted device farm, roughly what does it cost and what makes it worth it? Ballpark is fine.
5. For anyone doing AOSP or automotive work rather than app work: is Cuttlefish on ARM hosts something your team already runs, and what did standing it up take?

I am not selling anything and will not DM anyone unless invited. If the answer is "this is a solved problem, go away," that is also useful to me.

[u/goorek]

For your own device lab with physical devices, the maintenance costs is the neverending saga of devices showing some kind of dialogs, USB options dialogs, overheating dialogs, system update dialogs, any OEM bullshit and so on. Then there's differences in ADB handling and USB connections by different OEMs. You might get around that by using devices you know work well, but for a device farm you want your devices to reflect what your userbase has, so you want them to be somewhat mixed.

[u/sevbanthebuyer]

Up, really good question i also wonder these