iOS's advantage in this is that the hardware range is small. It's feasible to do full AOT away from the end user's device.
With Android there are hundreds or thousands of combinations of various bits of hardware and drivers, with various levels of compatibility. Device manufacturers have a terrific advantage in being able to produce hardware that is more specialised for the purpose, but there are trade-offs. Compiling all possible variations AOT away from the end device is going to be difficult.
Not really. Practically all Android devices support ARMv7 binaries. They have to, in order to work with applications that use the NDK. If what you say about Android were true, then AOT compilation for Windows on x86 wouldn't be feasible either.
This comment reminds me, there are actually a bunch of Android tablets that shipped with Intel Atom x86 processors. Intel worked some magic with libhoudini that allowed them to run ARM binaries surprisingly fast. If you're an app maker who actually cares about those devices (like my employer) then you end up building all your native code for x86 too. I recall the ARM binaries running at more than 50% of the native x86 ones, running optimized threaded and vectorized image processing code. I wish Intel would talk more about that library. I'd love to know what techniques it used.
It's done on-device to handle the problem of linking. All calls from the app into framework have to be linked when you do AOT, and Google can't do that without having device images of every android device and compiling on-demand for whatever device is requesting the install.
And then you'd still have to fall back to on-device compilation if Play Store doesn't know what the device is anyway (aka, all custom ROMs), or when you take an OTA (otherwise you'd need to re-download all installed apps for the new OTA image).
Plus, the dex bytecode is considerably smaller than the AOT result, so wire transmission costs are cheaper doing on-device compilation - call it a form of compression.
In fairness, they managed to do it only for the highest of high end users. Apple institutionally doesn't care about anyone in places like China, India or Africa where data is expensive. That's why Android completely dominates the global smartphone market share.
I guess nothing would stop the Play Store from AOT compiling binaries just for users with fast connections though.
WP 8 and 8.1 use MDIL, Machine Dependent Intermediate Language, basically machine code with jump targets kept as symbolic links, replaced at installation time.
WP 10 uses .NET Native.
I can gladly point out the respective Microsoft documentation, BUILD and Channel 9 presentations.
With Android there are hundreds or thousands of combinations of various bits of hardware and drivers, with various levels of compatibility. Device manufacturers have a terrific advantage in being able to produce hardware that is more specialised for the purpose, but there are trade-offs. Compiling all possible variations AOT away from the end device is going to be difficult.