- Android 16 now supports cloud compilation, a new feature that could speed up new app installs.
- The goal of cloud compilation is to avoid running the dex2oat tool during app installations by offloading compilation to the cloud.
- Dex2oat takes an APK file and generates app artifact files that the Android Runtime loads. Depending on the device and the amount of code to compile, this could take some time.
It looks like the ART (Android Runtime) JIT is playing an increasingly less important role with time.
Friendly reminder that the cloud is just someone else’s computer.
Without actually reading anything other than the title of the article, which I should prolly do, I’m gonna make this comment anyway.
What apps are you installing that take more than 30 secs?
I quite regularly see installation stall on older and cheaper phones. One single app install is fine, but when five or ten apps update all at once the phone becomes sluggish for minutes.
With Android consisting mostly of what, four instruction sets, this problem should’ve been prevented years ago in my opinion. Precompile for the most common platforms, leave the current slow processes for instruction sets nobody uses in practice, like MIPS and RISC-V.
Well that’s a issue, for sure.
I absolutely NEVER allow Google Play to just update my apps when it wants to. That’s insane. That would be constantly updating all day everyday. There is no need for daily software updates. There is no need for weekly updates. It’s borderline ridiculous.
One can argue “but muh security” all they like and go right ahead and do it if you need that validation in your life but when 10 apps are in que for an update 24/7 around the clock it’s almost suspicious.
You should’ve read the article. In an ideal world every device phone gets this process done in seconds. But, we don’t and not everyone can afford to buy a decently powerful enough phone.
For those people, downloading the optimized odex files could be faster than creating them on device. Thanks to availability of super fast internet.
Underpowered device or not, one thing that remains a constant is they will download a simple app very quickly, as long as the internet is there for it to do so.
So it really has nothing to do with the device but rather the internet speed.
Next time they’ll “invent” using a compiled language in the first place
You can compile Java and Kotlin to native if you want. That’s not the issue here. Like OP responded to you, it’s not a property of the language but the implementation.
Compiled isn’t a property of a language but it describes the implementation. You can compile Python for example to native code using Cython, but it will need a Python runtime that is not much less work than running the code through the interpreter. There are C interpreters. Further, Java is compiled to native code and is being used in this fashion right now. You can also ship native C, C++, or Go binaries by using the Android Native Development Kit and that’s exactly what most Android games do for performance.
Should Android not have started with Java? Even looking back, it’s hard to say. Java helped Android get started quickly using a language many developers already knew how to use. We might have been discussing something other than Android if that wasn’t the case. I cannot know.
I can’t believe it took them this long lol. There’s like millions of whatever latest Samsung Galaxy phone, running that compilation locally millions of times is just a waste of global compute power and everyone’s time, run it once in the cloud and cache it.
There are CPU and Android version differences, but it’s not that hard a problem to solve. On-device bytecode->native compilation long struck me as a bit of a silly hack. Surely Google can cache build products.
Or we could give up on native apps and just use a browser for everything. In a lot of ways I wish we would.
That’s not going to work too well when you’re offline
