Note: This answer covers other apps than Pokémon Go, as Pokémon Go has been updated to work with x86 processors
Apps contain multiple architecture dependent and architecture independent parts:
Independent:
- Dalvik code
- Android resources
- the Manifest
Dependent:
- Libraries
- Special assembly code in the Dalvik executable (rare but possible)
The major things are the libraries.
Those are shared objects (.so
files) much like DLLs on Windows that contain bytecode.
They are compiled using the Android NDK (Native Development Kit) and are compiled for a specific architecture (like compiling Linux applications using a cross-compiler, ie. compile ARM code on an x86 machine).
In our example, this library can only be used in an ARM environment were the ARM bytecode is understood.
Some Android x86 devices (commercial phones/tablets, not the emulators) come with a special ARM Translation toolkit, aka. libhoudini
. It basically translates ARM instructions to x86 instructions.
Those instructions however, are not optimized to run on x86 hardware and thus result in poor performance and high battery usage (the latter of those is one reason x86 is not primarily used in mobile processors).
The real problems are the developers:
Either:
They do not compile their libraries (often containing proprietary code) for any other architecture, for some reason.
They use specialized bytecode, only available on ARM so that any ARM Translator or libhoudini fails.
Luckily Pokémon Go received an update, allowing users of x86 devices to run the app, but other apps (mostly games) do require a real ARM device.