Making permissions auto-reset available to billions more devices

Posted by Peter Visontay, Software program Engineer; Bessie Jiang, Software program Engineer

Contributors: Inara Ramji, Software program Engineer; Rodrigo Farell, Interplay Designer; James Kelly, Product Supervisor; Henry Chin, Program Supervisor.

Most customers spend a whole lot of time on their smartphones. Whether or not working, enjoying video games, or connecting with mates, individuals usually use apps as the first gateway for his or her digital lives. With a view to work, apps usually must request sure permissions, however with dozens of apps on any given gadget, it may be robust to maintain up with the permissions you’ve beforehand granted – particularly should you haven’t used an app for an prolonged time frame.

In Android 11, we launched the permission auto-reset function. This function helps defend consumer privateness by mechanically resetting an app’s runtime permissions – that are permissions that show a immediate to the consumer when requested – if the app isn’t used for a number of months. Beginning in December 2021, we’re increasing this to billions extra gadgets. This function will mechanically be enabled on gadgets with Google Play providers which might be operating Android 6.0 (API stage 23) or greater.

The function can be enabled by default for apps concentrating on Android 11 (API stage 30) or greater. Nevertheless, customers can allow permission auto-reset manually for apps concentrating on API ranges 23 to 29.

So what does this imply for builders?

Exceptions

Some apps and permissions are mechanically exempted from revocation, like lively Machine Administrator apps utilized by enterprises, and permissions fastened by enterprise coverage.

Request consumer to disable auto-reset

If wanted, builders can ask the consumer to stop the system from resetting their app’s permissions. That is helpful in conditions the place customers count on the app to work primarily within the background, even with out interacting with it. The principle use circumstances are listed right here.

Evaluating present and new habits

Present habits	New habits
Permissions are mechanically reset on Android 11 (API stage 30) and better gadgets.	Permissions are mechanically reset on the next gadgets: Units with Google Play providers which might be operating a model between Android 6.0 (API stage 23) and Android 10 (API stage 29), inclusive. All gadgets operating Android 11 (API stage 30) and better gadgets.
Permissions are reset by default for apps concentrating on Android 11 or later. The consumer can manually allow auto-reset for apps concentrating on Android 6.0 (API stage 23) or later.	No change from the present habits.
Apps can request the consumer to disable auto-reset for the app.	No change from the present habits.

Obligatory code modifications

If an app targets at the least API 30, and asks the consumer to disable permission auto-reset, then builders might want to make a number of easy code modifications. If the app doesn’t disable auto-reset, then no code modifications are required.

Notice: this API is simply meant for apps whose targetSDK is API 30 or greater, as a result of permission auto-reset solely applies to those apps by default. Builders don’t want to alter something if the app‘s targetSDK is API 29 or decrease.

The desk under summarizes the brand new, cross-platform API (in comparison with the API revealed in Android 11):

Motion	Android 11 API (works solely on Android 11 and later gadgets)	New, cross-platform API (works on Android 6.0 and later gadgets, together with Android 11 and later gadgets)
Examine if permission auto-reset is enabled on the gadget	Examine if Construct.VERSION.SDK_INT >= Construct.VERSION_CODES.R	Name androidx.core.content material.PackageManagerCompat.getUnusedAppRestrictionsStatus()
Examine if auto-reset is disabled on your app	Name PackageManager. isAutoRevokeWhitelisted()	Name androidx.core.content material. PackageManagerCompat. getUnusedAppRestrictionsStatus()
Request that the consumer disable auto-reset on your app	Ship an intent with motion Intent.ACTION_AUTO_REVOKE_PERMISSIONS	Ship an intent created with androidx.core.content material. IntentCompat. createManageUnusedAppRestrictionsIntent()

This cross-platform API is a part of the Jetpack Core library, and can be out there in Jetpack Core v1.7.0. This API is now out there in beta.

Pattern logic for an app that wants the consumer to disable auto-reset:

val future: ListenableFuture<Int> =
    PackageManagerCompat.getUnusedAppRestrictionsStatus(context)
future.addListener(
  { onResult(future.get()) },
   ContextCompat.getMainExecutor(context)
)

enjoyable onResult(appRestrictionsStatus: Int) {
  when (appRestrictionsStatus) {
    // Standing couldn't be fetched. Examine logs for particulars.
    ERROR -> { }

    // Restrictions don't apply to your app on this gadget.
    FEATURE_NOT_AVAILABLE -> { }
    // Restrictions have been disabled by the consumer on your app.
    DISABLED -> { }

    // If the consumer does not begin your app for months, its permissions 
    // can be revoked and/or it is going to be hibernated. 
    // See the API_* constants for particulars.
    API_30_BACKPORT, API_30, API_31 -> 
      handleRestrictions(appRestrictionsStatus)
  }
}

enjoyable handleRestrictions(appRestrictionsStatus: Int) {
  // In case your app works primarily within the background, you'll be able to ask the consumer
  // to disable these restrictions. Examine you probably have already requested the
  // consumer to disable these restrictions. If not, you'll be able to present a message to 
  // the consumer explaining why permission auto-reset and Hibernation needs to be 
  // disabled. Inform them that they'll now be redirected to a web page the place 
  // they'll disable these options.

  Intent intent = IntentCompat.createManageUnusedAppRestrictionsIntent
    (context, packageName)

  // Should use startActivityForResult(), not startActivity(), even when 
  // you do not use the consequence code returned in onActivityResult().
  startActivityForResult(intent, REQUEST_CODE)
}

The above logic will work on Android 6.0 – Android 10 and in addition Android 11+ gadgets. It is sufficient to use simply the brand new APIs; you gained’t must name the Android 11 auto-reset APIs anymore.

Compatibility with App Hibernation in Android 12

The brand new APIs are additionally appropriate with app hibernation launched by Android 12 (API stage 31). Hibernation is a brand new restriction utilized to unused apps. This function will not be out there on OS variations earlier than Android 12.

The getUnusedAppRestrictionsStatus() API will return API_31 if each permission auto-reset and app hibernation apply to an app.

Launch Timeline

• September 15, 2021 – The cross-platform auto-reset APIs are actually in beta (Jetpack Core 1.7.0 beta library), so builders can begin utilizing these APIs right now. Their use is secure even on gadgets that don’t help permission auto-reset (the API will return FEATURE_NOT_AVAILABLE on these gadgets).
• October 2021 – The cross-platform auto-reset APIs grow to be out there as steady APIs (Jetpack Core 1.7.0).
• December 2021 – The permission auto-reset function will start a gradual rollout throughout gadgets powered by Google Play Providers that run a model between Android 6.0 and Android 10. On these gadgets, customers can now go to the auto-reset settings web page and allow/disable auto-reset for particular apps. The system will begin to mechanically reset the permissions of unused apps a number of weeks after the function launches on a tool.
• Q1 2022 – The permission auto-reset function will attain all gadgets operating a model between Android 6.0 and Android 10.