App hibernation

An average Android user installs 50+ apps on their devices (the number increases as the RAM-tier of devices increases). However, a significant number of these apps go unused by the user for a long period of time.

App hibernation hibernates apps that the user doesn't use for a few months, similar to permission auto-revocation. This force-stops the app and puts it into a state where we optimize for storage rather than performance. Permission auto-revoke is also bundled with this state and they share the same exemption setting in Settings. A force stopped app doesn't run jobs or alerts in the background and isn't able to send push notifications. When the user uses the app again, the app exits hibernation and jobs/alerts/notifications run again as usual. Any jobs/alerts/notifications that were scheduled before the app went into hibernation need to be rescheduled.

OEMs modifying the platform may conflict with the app hibernation implementation. For example

  • Modifying the app usage definition or introducing ways of waking up an app that aren't in AOSP may interrupt app hibernation's accuracy
  • An OEM’s proprietary restriction mechanism similar to app hibernation may perform a similar purpose. While both can exist, there may be some overlap.

CDD outlines a new set of requirements for changes that are based on app usage, similar to the existing 3.5.1 requirement. App hibernation follows these requirements.

The framework code lives in:

The policy logic lives in:

  • repo: platform/packages/modules/Permission
  • directory: PermissionController/src/com/android/permissioncontroller/hibernation

High-level architecture

The app hibernation system service optimizes a user's infrequently used apps for storage and prevents those apps from running in the background. To achieve these results, when we hibernate an app, we specifically:

  • Auto-revoke permissions
  • Force-Stop the app
  • Delete the ODEX and VDEX files
  • Delete the app cache

Our goal is to implement hibernation as a reversible action so that the app is still available to the user through Launcher and other surfaces with app data intact. Upon launching the app, we will restore it back from the force-stop state and continue with the ODEX and VDEX file creation as usual.

The planned design centers around two main parts:

  • Determining when a package should hibernate
  • Optimizing the hibernating package

A new system service, AppHibernationService, and a job service, AppHibernationJobService, inPermissionController is the glue that controls the overall decision making and logic.

Determining when a package should hibernate is primarily powered by UsageStatsService and managed by AppHibernationJobServicein PermissionController. This policy logic lives in PermissionControllerto allow us to dynamically update through Mainline. In addition, we plan on adding a new signal, component usage, to capture usage of the package's components (for example, services, content providers) as a new metric in UsageStatsService.

Optimizing a package is where all the actual savings and optimizations happen. AppHibernationService communicates with various parts of the system to stop the package, delete cache data, delete ART artifacts, and so on. Permission revocation is directly initiated from AppHibernationJobService to retain auto-revoke functionality on Android 11 and lower devices.

User experience

The user is provided with both information and controls over which apps can be hibernated.

Similar to auto-revoke, the user gets a notification about which apps are hibernated and has the option to go to the Settings directly from the notification to either open the app and bring it out of hibernation or delete the unused app if required.

We continue to support the developer's intent of asking the user for an exemption from hibernation with the existing permissions auto-revoke exemption intent.

Backward compatibility

Hibernation-specific features are available starting in Android 12. This feature couldn't function on earlier versions since the platform components (such as. the new system service) aren't present. Auto-revoke continues to function as implemented for the earlier OS versions.

Starting in Android 12, to ensure backward compatibility, a hibernation toggle is added on the app's page under Apps & notifications in Settings while keeping the original auto-revoke toggle within the Permissions sub-menu. This toggle controls the overall app hibernation system exemption for the app.

Customization

Some of the implementation is part of modular system component, so partners are discouraged from modifying the feature. Partners can instead implement similar features or functionality as long as they follow the CDD requirements.

App hibernation should default to ON for all apps targeting Android 11 or higher. This is the same as permissions auto-revoke. While the setting itself may be ON, the app hibernation implementation may differ between apps targeting Android 11 versus Android 12. More specifically, app hibernation only works for apps targeting Android 11 whereas it is essentially just auto-revoke for apps targeting Android 12.

Additionally, OEMs may be implementing a similar feature. However, those features are targeted on a much shorter timescale for battery optimizations which can be OEM specific. Any similar app restriction features developed by OEMs can co-exist with the app hibernation system as long as they meet the existing criteria defined in CDD.

Testing

App hibernation has CTS and unit tests to ensure it is working correctly.