Android 6 and up will start stripping unused apps’ permissions
Google is coming for your unused Android crapware. The company announced Friday that it will backport an Android 11 privacy feature—auto-resetting app permissions—to Android 6.
Auto-resetting app permissions were introduced in Android 11 as part of a continually expanding Android feature set aiming to automatically limit apps you don’t use. When you don’t use an app for a set period of time, Android will automatically strip the app of any permissions it has been granted, limiting it from tracking you in the background or accessing data. It’s a nice feature for less tech-savvy people who aren’t interested in manually organizing the inner workings of their phones. If you open the app again, it can ask for all of those permissions again.
Like most new Android features, auto-resetting permissions were exclusive to Android 11 when it came out last year—making up a very small number of Android’s 3 billion active devices. Google’s official Android Studio stats have Android 11 at 0 percent market share, but that chart hasn’t been updated since Android 11 came out (update your chart, Google!). The last update we got said OEMs were pushing out Android 11 about as quickly as they rolled out Android 10, so today, version 11 might be cracking 10 percent of Android devices.
Releasing the feature to Android 6 and up means that it will reach billions of users. Even Google’s 18-month-old chart shows Android 6 at 84.9 percent of devices. Users will get the feature starting this December via a Google Play Services update, with the rollout finishing sometime in Q1 2022. Play Services is Google’s system-level mega app that ships with every Google Play device, so just visit the Play Store sometime in the next few months, and the update will automatically download. Once you have the update, “the system will start to automatically reset the permissions of unused apps a few weeks after the feature launches on a device,” Google says.
Google’s app-limiting features
Google’s first swing at this idea came in Android 6 with Doze and App Standby, which both limited app background-processing access based on usage. Android 11’s permission revocation was an extension of this idea, and Google is getting really serious in Android 12, where it’s adding “App hibernation.” A hibernated app will be optimized for storage size rather than speed, so its cache will be deleted. The app will get zero background access, even when the phone is plugged in (App Standby only applies to on-battery usage), and it won’t be able to receive any push notifications at all.
“Usage” for all of Google’s app-killing features means opening an app, tapping on an app notification (meaning anything other than dismissing it), or interacting with a widget. If a user doesn’t do any of these things for a set period of time, the app-limiting features kick in. If a user performs any of the “usage” interactions with a limited app, all the app limitations will be seamlessly lifted, and the app will start working normally again. Users can also manually flag apps for immunity against the app-limiting features, even if they don’t get used. This is great for apps you expect to run only in the background, like companion apps for smartwatches 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-limiting features work automatically and will intelligently direct hardware resources toward apps you use, even for people with next to no knowledge about how their phones work. For someone without a lot of know-how or desire to organize—and a phone with a ton of crapware—this feature should help clean things up quite a bit. The nuclear option would be to completely disable an unused app, but that would remove it from the app drawer, and you wouldn’t be able to seamlessly recover from that action.
All of Google’s app-limiting 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 say which version of Android they are compatible with, allowing a developer to specify that the app has been tested against a certain Android feature set, and any features or restrictions from newer versions of Android usually won’t be applied to the app.
Even when the auto-resetting permissions feature is rolled out to Android 6 and up, it will still only reset the permissions of apps targeting Android 11 and up. Google doesn’t want to automatically break anything, but the blog post notes that less-cautious users will be able to flip a switch and let permission resetting happen to any app targeting Android 6 and higher.
Apps could theoretically target a very old version of Android and be free of many restrictions (sideloaded malware does this), but Google has a number of carrots and sticks to get developers to target newer versions of Android. The biggest inducement is that the Play Store has a rolling minimum API level for apps, which usually demands that developers ship an API level from the previous year or two in order to be listed on the store.
Android 12 is about to come out, and new apps being uploaded to the Play Store must target Android 11. In order for existing apps to ship an app update, developers currently need to target Android 10, but in November, the minimum for updating apps will jump to Android 11. So in November, a developer’s options will be “target Android 11 or become abandonware,” and around this time next year, Android 12 will be the required target.
Next year: Android 12’s app hibernation hits Android 6 and up?
Let’s make a bold prediction: Google will probably roll out Android 12’s app-hibernation feature to older devices next year. All the app-limiting features—App Standy from Android 6, permissions reset from Android 11, and app hibernation from Android 12—are just more aggressive versions of the same idea and work via the same “usage” mechanisms. If you’re backporting one feature, it makes sense to backport the other at some point.
As part of today’s announcement, Google is shipping new APIs that will let apps display an opt-out box for the auto-resetting permissions feature. Because auto-resetting permissions will work on Android 6 and up, these APIs are part of a “Jetpack” library that developers can include in their app, so the feature is not tied to a specific version. Google helpfully notes that this new opt-out library is “also compatible with app hibernation introduced by Android 12.” Google could just be vaguely planning for a future on Android 12, but to me, that sounds like a hint of more future backporting, where Android 12’s app hibernation will start to work on older versions of the operating system.
The Android Team takes a very cautious approach to its app platform and never wants to break anything, so it’s very on-brand for the group to not release all the app-limiting features at the same time. Once the Android Team sees how this permission-revoking rollout works on older versions, though, it would not surprise me to see the group take the next step with an app hibernation release. With the Play store’s rolling API minimums, nearly all apps will have declared compatibility with app hibernation by next year anyway, so why not take advantage of that?
https://arstechnica.com/?p=1796167