4d ago

Android 16 has a new trick to speed up app installation

www.androidauthority.com

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.

18 comments

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.

It's an interesting trick because it makes me ponder: why would google do this?
Pre-compiling on the server means spending compute resources that are not free on something that was free before. In other words: cost. Why would google incur a cost on something that is non-user marketable or even perceptible? Were there really that many users complaining about how long it took to install x random app? Would google do this out of the kindness of their hearts?
So here's my best theory of why they're doing this: **Automatic installing of apps / ads on the background. **
here's why I think that:
Google has a history of trying this in-between state of app/website with "instant apps". Instant apps were never really "instant" though and they never really took off.
There are already several full screen ads for dopaming-hacking games that are partially interactive. It wouldn't take much to jump into a "pass the first level to skip the ad" kind of mechanic instead of "watch 20 seconds of this video to skip the ad" The limiting factor is how quickly does the ad install on your device.
Xiaomi and other Chinese companies have demonstrated how lucrative auto-installed crapware is. If one assumes that the concept generates revenue, imagine the following pitch:
For $20 we'll highlight your app on the play store
For $200 we'll show 20 full screen ads on 1000 users
For $2000 we'll pre-install the app on 1000 users from May 1st to June 1st

Next time they’ll “invent” using a compiled language in the first place
- 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.
- 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.

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
  
  Oh no? We've had browser storage and cached web apps for twenty years now. The technology exists and could be improved, if we stopped forcing everything to be a native app.
  I mean, honestly, most "native" apps are webviews displaying cached content. Clearly we can make it happen, it just needs to be more discoverable and have smoother integration.

18 comments