Surprised to discover my Qt app Android build also works on an x86 device. How???

[timday]

I have an app compiled for Android with Qt 5.7 (stuck on the old version for licensing reasons). We also use Qt's multiplatform goodness to build iOS, OSX, Windows and Linux builds, but this is about Android. Note that I don't know that much more about Android than is needed to build a Qt (mix of QML & C++ & OpenGL) app into an apk and install it on a device via adb!

Trying to get a feel for device compatibility, I'd been trying out the android .apk on various AWS "device farm" devices, mostly quite successfully.

Subsequently looking over the device specs I'd actually tested on, I was amazed to discover that one of them - the Dell Venue 8 7840 - is (according to data here https://www.gsmarena.com/dell_venue_8_7000-6714.php ) an Intel Atom Z3580. And looking more closely at the device logs from the test run, I saw that there was indeed a large number of mentions of x86.

This surprised me enormously as I was under the impression it was actually necessary to explicitly build for x86 and you'd have a different x86 apk for such devices, and that the default is to build for ARM.

So what's going on behind the scenes for my apk to be able to run on an x86 Android device besides all the ARM devices it works on? If my app was entirely Java I wouldn't be surprised if it worked on both... but it's not, there's quite a lot of native C++ & OpenGL to it too.

Do apks actually contain both ARM and x86 binaries? Do x86 devices do some JIT translation of ARM code? Or is some other intermediate code representation (Java byte code?) actually used and both platforms compile to native from that? This is one of those cases where I suddenly realize I have no idea what is actually going on... if anyone can enlighten me, thanks!

[timday]

Hmmm a bit of googling around finds me a 2015 review of the Dell device https://techreport.com/review/27790/dells-venue-8-7000-tablet-reviewed/ containing:

---

The other important item of note is the x86 instruction set, which differs from the ARM ISA that dominates the mobile world.

Intel and Google have been collaborating on x86 Android optimizations since 2011, so the ISA shouldn’t pose a problem with modern software. Android’s Dalvik VM can generate the appropriate instructions, and binaries compiled with the Native Developer Kit can target x86 specifically. In cases where ARM-specific code is the only option, binary translation software serves as an interpreter. There’s some unavoidable overhead associated with translating ARM instructions to x86, but Intel contends that the impact is minimal. Any potential ISA issues may ultimately be rendered moot by Lollipop, which features a new runtime environment with a cross-platform compiler.

---

so it does indeed seem to be code translation. Is this pretty standard for x86 Android devices these days, or an unusual exceptional case?

(A bit more research suggests x86-Android is a complete dead end with no new devices in years... so probably not something it's worth worrying about).