- 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.
I have a lot of apps on my phone. Several government and banking apps require to be updated at least weekly or they’re locked out for security reasons. Sure I could interrupt my 2FA login flow to update the app (assuming I have fast Internet available) but why bother? Google Play should be updating those things in the background while the phone charges. Same with F-Droid, though that’s buggy and gets stuck all the time.
My Android devices are nothing compared to my Linux installs, anyway.
Sure, banking and work related apps. Set those for auto-update.
The rest, I’d manually do it monthly.
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.
So you’re just reimplementing the current model but with the extra layer of a browser in between. Installing a PWA is the same as installing a native app, except instead of running it directly you also have to have a browser installed to run it. It’s adding a significant amount of complexity for no good reason. Browsers are huge attack targets.
So you’re just reimplementing the current model but with the extra layer of a browser in between.
No, I’m removing the layer of the native code that launches whatever flavor of Electron they’re running under the hood in favor of the browser and webview that’s already installed on your device (or whatever other one you’re interested in switching to).
Installing a PWA is the same as installing a native app, except instead of running it directly you also have to have a browser installed to run it.
…which literally every single mobile device already has. Seriously, you can’t uninstall webview if you wanted to.
Plus, you only have to install one browser for the entire system, Come on. You can’t honestly believe that the dozens of reproduced copies of the same codebases that live on your phone right now are a good use of your phone’s storage or memory.
It’s adding a significant amount of complexity […]
I don’t know what complexity you think it’s adding. It’s removing a bunch of native code, and replacing it with web-standard code that (in the case of most apps) was already written for the native app anyway, or at least was written for the web app.
[…] for no good reason.
Ever wanted to mod an app? If it was a web app running in a browser, you could. Would you like to use ad blockers on the YouTube app? Or use a userscript to hide stories about a particular person? Or automate the function of one of your apps? With native code you can’t. With web apps you can. Web apps are more accessible, they adhere to published standards, they’re not as heavy on your operating system, they’re more resistant to privacy-siphoning attacks and surveillance, they’re more easily able to share code…and, to be honest, they’re also easier to develop. The only reason for corpos not to do this is because it gives the user power that they would rather be able to sell to the user instead.
Browsers are huge attack targets.
Security is not improved by forcing users to switch to native apps. For one thing, most companies’ apps already are web apps; if they’re not already hardened, wrapping them in native code and putting them in the Play Store or App Store won’t magically make them more secure, because decompiling native apps and sniffing API endpoints is still a thing. Also, it could be argued that browsers are more resistant to security issues, since you can patch them once and mitigate certain vulnerabilities in every app without waiting for developers to ship a fix.
