[C-0-1] Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform “live” upgrades—that is, a device restart MAY be required. Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:
[C-0-2] The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.
[C-0-3] The entire update MUST be signed and the on-device update mechanism MUST verify the update and signature against a public key stored on device.
[C-SR] The signing mechanism is STRONGLY RECOMMENDED to hash the update with SHA-256 and validate the hash against the public key using ECDSA NIST P-256.
If the device implementations includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, then, they:
For device implementations that are launching with Android 6.0 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.1, satisfies this requirement.
Also, device implementations SHOULD support A/B system updates. The AOSP implements this feature using the boot control HAL.
If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, then:
Android includes features that allow the Device Owner app (if present) to control the installation of system updates. If the system update subsystem for devices report android.software.device_admin then, they: