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