Google comes in for their unused Android crapware. The company announced on Friday that it will back a privacy feature from Android 11 (automatic reset app permissions) to Android 6.
Self-resetting app permissions were introduced in Android 11 as part of an ever-expanding Android feature set that aims to automatically limit the apps you don’t use. When you don’t use an app for a specified period of time, Android will automatically remove any permissions granted to the app, preventing you from tracking it in the background or accessing data. It’s a nice feature for less tech-savvy folks who aren’t interested in manually organizing the inner workings of their phones. If you reopen the app, you can reapply for all those permissions.
Like most new Android features, the soft reset permissions were unique to Android 11 when it came out last year, representing a very small number of Android’s 3 billion active devices. Google’s Android Studio official stats have Android 11 on 0 percent market share, but that chart hasn’t been updated since Android 11 came out (update your chart, Google!). The latest update we received said that OEMs were rolling out Android 11 as fast as they did with Android 10, so today, version 11 could be breaking 10 percent of Android devices.
Releasing the feature to Android 6 and later means it will reach billions of users. Even Google’s 18-month chart shows Android 6 on 84.9 percent of devices. Users will get the feature starting in December via a Google Play Services update, with the rollout ending sometime in the first quarter of 2022. Play Services is Google’s mega system-level app that ships with all Google Play devices, so just visit the Play Store sometime in the next few months and the update will download automatically. Once you have the update, “the system will automatically begin to reset permissions for unused apps a few weeks after the feature is released on a device,” Google says.
Google app limiting features
Google’s first twist on this idea came on Android 6 with the Doze and App Standby, which limited access to the app’s background processing based on usage. Android 11’s permission revocation was an extension of this idea, and Google is getting really serious on Android 12, where it’s adding “App Hibernate.” A hibernated application will optimize for storage size rather than speed, thus clearing its cache. The application will not have access in the background, even when the phone is plugged in (the application’s standby mode only applies to battery use), and you will not be able to receive any automatic notifications.
“Usage” for all Google app removal features means opening an app, touching an app notification (that is, anything other than dismissing it), or interacting with a widget. If a user doesn’t do any of these things for a specified period of time, the app’s throttling features kick in. If a user makes any of the “use” interactions with a limited application, all limitations of the application will be removed without issue. and the application will start working normally again. Users can also manually flag apps for immunity against app-limiting features, even if they don’t get used to it. This is ideal for applications that you expect to run only in the background, such as companion apps for smart watches or data syncing apps.
If you never use an app, the best course of action is to uninstall it, but that requires user interaction, a desire for organization, and a certain amount of tech savvy. Google’s app throttling features work automatically and will intelligently direct hardware resources to the apps you use, even for people with little or no understanding of how their phones work. For someone without much technical knowledge or not wanting to get organized, and a phone with a lot of garbage, this feature should help to clean things up quite a bit. The core option would be to completely disable an unused app, but that would remove it from the app drawer and it couldn’t smoothly recover from that action.
All of Google’s app throttling features are tied to apps that “target” a certain version of Android (called “API levels,” one for each version of Android). For backward compatibility purposes, apps on Android can tell which version of Android they are compatible with, allowing a developer to specify that the app has been tested with a certain set of Android features, and that any features or restrictions of the newer versions of Android generally wins. it will not apply to the application.
Even when the automatic reset permissions feature is implemented in Android 6 and later versions, it will only reset the permissions of the apps destined for Android 11 and later versions. Google doesn’t want to break anything automatically, but the blog post notes that less- Cautious users will be able to flip a switch and allow permission to be reset on any app that targets Android 6 and later.
Theoretically, the apps could target a very old version of Android and be free of many restrictions (side-loading malware does this), but Google has a number of carrots and sticks for developers to target newer versions of Android. . The biggest attraction is that the Play Store has a mobile minimum API level for apps, which generally requires developers to submit an API level from the previous year or two in order to appear in the store.
Android 12 is about to come out, and new apps that are uploaded to the Play Store must target Android 11. For existing apps to submit an app update, developers currently need to target Android 10, but in November, the The minimum to update apps will jump to Android 11. So in November, a developer’s options will be to “target Android 11 or go abandonware,” and by this time next year, Android 12 will be the required target.
Next year: Android 12 app hibernation coming to Android 6 onwards?
Let’s make a bold prediction: Google will likely roll out Android 12’s app hibernate feature on older devices next year. All of the app limiting features (Android 6 Standy App, Android 11 Permission Reset, and Android 12 App Hibernate) are more aggressive versions of the same idea and work through the same “usage” mechanisms. If you are supporting one feature, it makes sense to back the other at some point.
As part of today’s announcement, Google is shipping new APIs that will allow apps to display an opt-out box for the automatic reset permissions feature. Because the automatic reset permissions will work on Android 6 and later, these APIs are part of a “Jetpack” library that developers can include in their application, so the feature is not tied to a specific version. Google kindly notes that this new opt-out library “also supports application hibernation introduced by Android 12.” Google might be vaguely planning a future in Android 12, but to me, that sounds like a hint of more future backporting, where Android 12 app hibernation will start working on older versions of the OS.
The Android team takes a very cautious approach to their app platform and never wants to break anything, so it’s very wise that the group doesn’t release all app-limiting features at the same time. However, once the Android team sees how this permission revocation implementation works in previous versions, I wouldn’t be surprised to see the group take the next step with a hibernate version of the app. With the Play Store’s mobile API minima, almost every app will have declared app hibernation support for next year anyway, so why not take advantage of that?