Compatibility Definition
2f44OdUf0
2f44OdUf0
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
skipped or omitted.<br />
Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since<br />
many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier<br />
on builds that differ only in trivial ways. Specifically, device implementations that differ from an<br />
implementation that has passed the CTS Verifier only by the set of included locales, branding, etc.<br />
MAY omit the CTS Verifier test.<br />
11. Updatable Software<br />
Device implementations MUST include a mechanism to replace the entirety of the system software.<br />
The mechanism need not perform “live” upgrades—that is, a device restart MAY be required.<br />
Any method can be used, provided that it can replace the entirety of the software preinstalled on the<br />
device. For instance, any of the following approaches will satisfy this requirement:<br />
“Over-the-air (OTA)” downloads with offline update via reboot<br />
“Tethered” updates over USB from a host PC<br />
“Offline” updates via a reboot and update from a file on removable storage<br />
However, if the device implementation includes support for an unmetered data connection such as<br />
802.11 or Bluetooth PAN (Personal Area Network) profile:<br />
Android Automotive implementations SHOULD support OTA downloads with offline update<br />
via reboot.<br />
All other device implementations MUST support OTA downloads with offline update via<br />
reboot.<br />
The update mechanism used MUST support updates without wiping user data. That is, the update<br />
mechanism MUST preserve application private data and application shared data. Note that the<br />
upstream Android software includes an update mechanism that satisfies this requirement.<br />
For device implementations that are launching with Android 6.0 and later, the update mechanism<br />
SHOULD support verifying that the system image is binary identical to expected result following an<br />
OTA. The block-based OTA implementation in the upstream Android Open Source Project, added<br />
since Android 5.1, satisfies this requirement.<br />
If an error is found in a device implementation after it has been released but within its reasonable<br />
product lifetime that is determined in consultation with the Android <strong>Compatibility</strong> Team to affect the<br />
compatibility of third-party applications, the device implementer MUST correct the error via a software<br />
update available that can be applied per the mechanism just described.<br />
Android includes features that allow the Device Owner app (if present) to control the installation of<br />
system updates. To facilitate this, the system update subsystem for devices that report<br />
android.software.device_admin MUST implement the behavior described in the SystemUpdatePolicy<br />
class [ Resources, 138].<br />
12. Document Changelog<br />
The following table contains a summary of the changes to the <strong>Compatibility</strong> <strong>Definition</strong> in this release.<br />
Various<br />
Section<br />
Summary of changes<br />
Replaced instances of the "encouraged" term with "RECOMMENDED"<br />
2. Device Types Update for Android Automotive implementations<br />
3.2.2. Build Parameters Additions for the hardware serial number and for the security patch level of<br />
a build<br />
Page 67 of 74
Change language