Starting March 27, 2025, we recommend using android-latest-release
instead of aosp-main
to build and contribute to AOSP. For more information, see Changes to AOSP.
Device Scheduling
Stay organized with collections
Save and categorize content based on your preferences.
The Device Scheduling module contains logic that detects whether or not the
device is in an idle state, and may be rebooted without user disruption.
This module improves the uptake rate of software updates by
providing a reliable signal of reboot readiness to installers. A reliable reboot
readiness signal enables installers to reboot the device to apply an update,
with the knowledge that the user hasn't been disrupted by the update.
Automatically rebooting devices in an unused state allows for faster updates,
compared to waiting for the device to be organically rebooted. By reducing the
time taken for an update to be applied, users receive critical fixes quicker
which improves the overall health of their device. A quicker uptake rate
also enables regressions to be found sooner.
This logic is updatable since determining the reboot readiness of a device
involves the consideration of multiple criteria. These criteria may evolve over
time, so being able to update this logic ensures that the reboot readiness
signal remains valid.
Module boundary
In Android 12, this module contains code in the
following new directory:
packages/modules/Scheduling
The Device Scheduling module (com.android.scheduling
) ships as an APEX
package.
The module contains two JAR files:
framework-scheduling.jar:
Contains the API surface that an installer
interacts with. This is a part of the bootclasspath
.
service-scheduling.jar
: Contains a new system service,
RebootReadinessManagerService
. Loaded by the system server process.
Dependencies
This module has no external dependencies.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-12 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-12 UTC."],[],[],null,["# Device Scheduling\n\nThe Device Scheduling module contains logic that detects whether or not the\ndevice is in an idle state, and may be rebooted without user disruption.\n\nThis module improves the uptake rate of software updates by\nproviding a reliable signal of reboot readiness to installers. A reliable reboot\nreadiness signal enables installers to reboot the device to apply an update,\nwith the knowledge that the user hasn't been disrupted by the update.\n\nAutomatically rebooting devices in an unused state allows for faster updates,\ncompared to waiting for the device to be organically rebooted. By reducing the\ntime taken for an update to be applied, users receive critical fixes quicker\nwhich improves the overall health of their device. A quicker uptake rate\nalso enables regressions to be found sooner.\n\nThis logic is updatable since determining the reboot readiness of a device\ninvolves the consideration of multiple criteria. These criteria may evolve over\ntime, so being able to update this logic ensures that the reboot readiness\nsignal remains valid.\n\nModule boundary\n---------------\n\nIn Android 12, this module contains code in the\nfollowing new directory:\n\n- `packages/modules/Scheduling`\n\nPackage format\n--------------\n\nThe Device Scheduling module (`com.android.scheduling`) ships as an APEX\npackage.\n\nThe module contains two JAR files:\n\n- `framework-scheduling.jar:` Contains the API surface that an installer\n interacts with. This is a part of the `bootclasspath`.\n\n- `service-scheduling.jar`: Contains a new system service,\n `RebootReadinessManagerService`. Loaded by the system server process.\n\nDependencies\n------------\n\nThis module has no external dependencies."]]