1# 11\. Updatable Software 2 3* [C-0-1] Device implementations MUST include a mechanism to replace the 4entirety of the system software. The mechanism need not perform “live” 5upgrades—that is, a device restart MAY be required. 6Any method can be used, provided that it can replace the entirety of the 7software preinstalled on the device. For instance, any of the following 8approaches will satisfy this requirement: 9 10 * “Over-the-air (OTA)” downloads with offline update via reboot. 11 * “Tethered” updates over USB from a host PC. 12 * “Offline” updates via a reboot and update from a file on removable storage. 13 14* [C-0-2] The update mechanism used MUST support updates without wiping user 15data. That is, the update mechanism MUST preserve application private data and 16application shared data. Note that the upstream Android software includes an 17update mechanism that satisfies this requirement. 18 19* [C-0-3] The entire update MUST be signed and the on-device update mechanism 20 MUST verify the update and signature against a public key stored on device. 21* [C-SR] The signing mechanism is STRONGLY RECOMMENDED to hash the update 22 with SHA-256 and validate the hash against the public key using ECDSA NIST 23 P-256. 24 25If the device implementations includes support for an unmetered data 26connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, 27then, they: 28 29* [C-1-1] MUST support OTA downloads with offline update via reboot. 30 31For device implementations that are launching with Android 6.0 and 32later, the update mechanism SHOULD support verifying that the system image is 33binary identical to expected result following an OTA. The block-based OTA 34implementation in the upstream Android Open Source Project, added since Android 355.1, satisfies this requirement. 36 37Also, device implementations SHOULD support [A/B system updates](https://source.android.com/devices/tech/ota/ab_updates.html). 38The AOSP implements this feature using the boot control HAL. 39 40If an error is found in a device implementation after it has been released but 41within its reasonable product lifetime that is determined in consultation with 42the Android Compatibility Team to affect the compatibility of third-party 43applications, then: 44 45* [C-2-1] The device implementer MUST correct the error via a software 46update available that can be applied per the mechanism just described. 47 48Android includes features that allow the Device Owner app (if present) to 49control the installation of system updates. If the system update subsystem 50for devices report android.software.device_admin then, they: 51 52* [C-3-1] MUST implement the behavior described in the [SystemUpdatePolicy](http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html) 53 class. 54