this post was submitted on 10 Dec 2023
26 points (93.3% liked)

AssholeDesign

7645 readers
1 users here now

This is a community for designs specifically crafted to make the experience worse for the user. This can be due to greed, apathy, laziness or just downright scumbaggery.

founded 2 years ago
MODERATORS
[email protected]
26
automatically turning on new (creepy)feature with no single click to disable them (discuss.tchncs.de)
submitted 1 year ago by [email protected] to c/[email protected]
31 comments fedilink hide all child comments
 

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

all 35 comments
sorted by: hot top controversial new old
[–] [email protected] 16 points 1 year ago (3 children)

Nobody here seems to understand the real technical purpose of this feature, so let me try to explain what's really happening.

Android applications and much of the system are written in Java. In the beginning, this decision was made because it provides portability at least in theory and the language was familiar to developers, but this decision wasn't without its disadvantages. This extra layer of the Java virtual machine led to laggy user experiences and increased memory use in the very first versions of Android.

The first attempt to fix this problem was the Dalvik runtime. This first solution incorporates a tracing style just in time compiler that translates Java into native code as it runs. An Android Kitkat, ART or Android runtime was introduced as a developer option and later became the default which offers full compilation to native code at install time. This led to a really long system update process and some complex apps took forever to install, so in Nougat Android moved to a hybrid design that only pre-compiles the most important parts of the application. This saves install time and system update time while still getting good performance by pre-compiling to native, and we fall back to JIT if unexpected code becomes a performance bottleneck when the user is actually using the app.

But which parts do we pre-compile? How do you know what code actually matters to the user experience?

This dialogue in Play is about sharing runtime information about which code was actually executed. Google aggregates this information so that when users install an app they also receive a file describing which parts are most commonly used and actually matter to performance so the system can focus on pre-compiling only this specific subset. Namely, this data is which classes and methods are expected to be hot, with special attention paid to the ones required to initialize the application.

From a technical perspective, I don't really see how this places private user information at risk, and I agree that it needs to be the default for this design to work because most users aren't savvy enough to understand what it actually does. Google tried to simplify it is much as possible in this dialogue, but it's led to a lot of confusion especially for more technical users.

[–] [email protected] 7 points 1 year ago

The detailed breakdown is appreciated.

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 5 points 1 year ago* (last edited 1 year ago) (4 children)

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.

[–] [email protected] 2 points 1 year ago

I want to appreciate the effort you put in this response. Respect, dear sir.

[–] [email protected] 0 points 1 year ago (1 children)

While not all ARMs are the same, I'm pretty sure there are certain configurations that are more common. Why not just provide binaries for those?

[–] [email protected] 1 points 1 year ago

You can, but that could be to the detriment of less common configurations. That's a valid solution that strikes a different balance.

You may also wish to consider that Android apps can generate and execute code at runtime. It's perfectly valid to download or generate more Java bytecode after the app was installed. You would still need a compiler on the device to handle apps that do this efficiently.

I also left out some more specific information to prevent my reply from being even longer, but the binary code your device generates actually adapts to your specific usage as well as the general usage. The profile you get from Play is just a starting point. Shipped binary code isn't generally very flexible. If you like to use an app in a way that makes us runtime compile code that we thought wasn't important before, your device actually just adds this information to the profile and recompiles when the device isn't being used. That means you get a personal level of performance optimization depending on your personal usage.

It's not wrong to ship a slightly less optimal, fully compiled binary. I just don't think that would work as well. It would be a lot simpler though.

[–] [email protected] -1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

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.

[–] [email protected] -1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

You're right. That is a perfectly valid solution with different trade offs. Perhaps in a perfect world users could select which they prefer.

[–] [email protected] -1 points 1 year ago (1 children)

I knew it had something to do with art but didn't know you could pre-compile only certain segments. I thought the best you could do was to have a bundle for certain architecture (split apks). thanks for the explanation!

now I have another question:
can't Google just get that data by running the app itself (which it does anyway) on the servers? or do they trust real hardware more than emulators?

[–] [email protected] 2 points 1 year ago

Google cannot do this because the code that matters to performance depends on all the inputs which includes the user's actual behavior. For example, I could write an app that contains a big feature that users overwhelmingly care nothing about, wasting time in compiling it and resources in storing the translated code for this unused feature.

Building on the server means giving up access to user behavior, which is important to what code really runs. It's tough to strike a good balance between not storing code that won't be used, install times, and runtime performance.

[–] [email protected] 2 points 1 year ago (1 children)

@pokedoku You're right, that popup is vague and unhelpful.

[–] [email protected] 1 points 8 months ago

You forgot to degoogle.

[–] [email protected] 0 points 1 year ago (1 children)

Seems like a cool idea but it would be good if it was opt-in and done by not-google

[–] [email protected] -1 points 1 year ago* (last edited 1 year ago)

If they do that people won't turn it on. They rely on people to not read things.

I wish someone (EU) would step in and force companies to make data collection settings be opt in rather than opt out.

[–] [email protected] -1 points 1 year ago (2 children)

I could neither find any such setting nor did I ever get such a notification. Could you tell me where you found the relevant setting?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Not all devices are supported. Building a list of what code is actually run is going to be device dependent, so it only handles popular configurations.

Or, it could be that you're running an older version of the play store, or maybe there's some other reason that it's not using this feature that I don't know about.

[–] [email protected] -1 points 1 year ago (1 children)

I remember seeing this popup but cant find anything in settings

[–] [email protected] 1 points 1 year ago (2 children)

It's in Settings > General > App install optimisation. The last item in the list.

[–] [email protected] 0 points 1 year ago* (last edited 1 year ago) (1 children)

There is no such option for me. I guess its not aviliable

[–] [email protected] 0 points 1 year ago (1 children)

Here's where it appears in mine.

https://i.imgur.com/9PGQHP9.png

[–] [email protected] 2 points 1 year ago (1 children)

Yeah there is no such option for me. This might be some feature not released yet for everyone idk

[–] [email protected] 0 points 1 year ago (1 children)

It's in the settings of the Play Store app itself, not a setting in Android. That threw me off at first.

Turns out I already had it disabled, thankfully.

[–] [email protected] 1 points 1 year ago

I know... But still that option wasnt there for me

[–] [email protected] -1 points 1 year ago

Found it and turned it off. Thanks

[–] [email protected] -2 points 1 year ago (1 children)

"Apps will install faster."

Look. I'm using a 4 year old phone, and apps seem to install in seconds. Downloading them takes longer than the install, and even that's a few seconds...

What problem is Google really trying to solve here?

[–] [email protected] -2 points 1 year ago

They're trying to solve their money problems, we all know such a small company like Google must be struggling