there’s just this vague recommendation to “turn it off in settings.” no link, no toggle, nothing.
had to hunt for the relevant setting in the app(even their settings menu is down under in the list when you tap on your avatar.
image transcription:
a screenshot of Google play store which has a popup that can only be disabled by pressing OK button at the bottom.
the popup contains the following text:
Google is optimising app installs with your help
Google Play makes apps faster to install, open and run based on what people are using most.
The first time that you open an app after installing, Google notes which parts of the app you use. When enough people do this, your apps will install faster.
App install optimisation is automatically turned on, but you can turn it off in settings. Learn more
Silly question, I’m a software dev but not as mobile dev so could be barking up the wrong tree here. Could Google play not cache precompiled versions for the most popular architectures and just download them precompiled? Sure some rarer configurations would still need to do the slower local process but the more popular configurations representing the vast majority of systems would be covered.
It’s not impossible, but there are limitations to that alternative approach. For example, ARM processors are really heterogeneous with respect to exactly which extensions are supported. If you compile on the server, you might not be able to take advantage of features that only exist on a few phones like the latest flagships. It also requires the device to trust that the pre-compiled code is actually consistent and won’t cause bad memory access for example that can lead to a crash. If the device compiles the code, it knows there’s a true one-to-one correspondence with the actual Java byte code, closing an opportunity for inconsistency. The device knows the size of the CPU caches and might make different instruction scheduling decisions in the actual binary. Generally, it’s easier to be more efficient when you have all the information about the target processor available on device. But, you could have done it a different way that’s true. Google decided not to do that.
We should also think about what’s to be gained by moving it all to the server? On the server, you still don’t know the actual user patterns. It’s not space efficient to compile the entire application even if the compile time is free on the server. You would have to download unnecessary native code that may only be used by an extremely small fraction of users, wasting storage space on user devices. What if I don’t use that whole area in the application? What if most users don’t use it? Why should we have to download an optimized version of it onto every device? Perhaps, the best optimization is to not ship any native code for the feature nobody uses.
If you want the best balance of high performance on the user device while not wasting extra space for binary code that isn’t frequently used, I think this design makes more sense. You’re never getting away from having a full compiler on every device because Google can’t assume that you aren’t using other app stores, and it’s perfectly valid for Android apps to generate code dynamically at runtime that can never be compiled in advance.
I want to appreciate the effort you put in this response. Respect, dear sir.
I feel you’re brushing over the privacy implications regarding how apps are used.
Sure, you could say: “Oh, but it’s inefficient to compile the entire application, and what if there are features that barely anyone uses.”
But you can also say: “Compiling the entire application ensures we don’t need to collect usage data and it ensures everyone gets the best experience, even the people that use features that are otherwise hardly used.”
Now, of course, to go with the second option, you need to care about user privacy and not gain any benefits from usage data beyond the benefits for compiling it.
You’re right. That is a perfectly valid solution with different trade offs. Perhaps in a perfect world users could select which they prefer.
Yes, it’s why I said most popular configurations as well as architecture, not just CPU architecture. So that’s specific CPU/SoC components (GPU etc). Compiling for the most popular configurations (thinking Google Pixel, Samsung Sxx, whatever Motorola’s flagship is. Probably also the mid-range units that sell well too) you would cover a large %age with maybe 10-15 configurations, which isn’t THAT hard to do if you’re google.
This is the kind of approach that Apple takes by building multiple versions of the application for different devices. It’s a perfectly serviceable solution that also works.
I don’t have a great answer for why they don’t do it this way.