aboutsummaryrefslogtreecommitdiff
path: root/en/devices/tech/ota/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'en/devices/tech/ota/index.html')
-rw-r--r--en/devices/tech/ota/index.html162
1 files changed, 33 insertions, 129 deletions
diff --git a/en/devices/tech/ota/index.html b/en/devices/tech/ota/index.html
index 234ff2de..58737b5c 100644
--- a/en/devices/tech/ota/index.html
+++ b/en/devices/tech/ota/index.html
@@ -23,138 +23,42 @@
-<p>Android devices in the field can receive and install over-the-air (OTA)
-updates to the system and application software. Devices have a special
-recovery partition with the software needed to unpack a downloaded update
-package and apply it to the rest of the system.</p>
-<p>This section describes the structure of these packages and the tools
-provided to build them. It is intended for developers who want to
-make the OTA update system work on new Android devices and those who are
-building update packages for use with released devices. OTA updates are
-designed to upgrade the underlying operating system and the read-only apps
-installed on the system partition; these updates do <i>not</i> affect
-applications installed by the user from Google Play.
-</p>
-<p>This section describes the OTA system as of the Android 5.x release. For
-help porting OTA-related code from older releases, see <a href="#migrating">
-Migrating from previous releases</a>.
-</p>
+ <p>
+ Android devices in the field can receive and install over-the-air (OTA)
+ updates to the system and application software. This section describes
+ the structure of the update packages and the tools provided to build
+ them. It is intended for developers who want to make the OTA update
+ system work on new Android devices and those who are building update
+ packages for use with released devices. OTA updates are designed to
+ upgrade the underlying operating system and the read-only apps installed
+ on the system partition; these updates do <em>not</em> affect
+ applications installed by the user from Google Play.
+ </p>
-<h2 id="android-device-layout">Android device layout</h2>
-<p>The flash space on an Android device typically contains the following
-partitions.</p>
+ <h2 id="ab_updates">A/B updates</h2>
-<dl>
-<dt>boot</dt>
-<dd>Contains the Linux kernel and a minimal root filesystem (loaded into a RAM
-disk). It mounts system and other partitions and starts the runtime located on
-the system partition.</dd>
-<dt>system</dt>
-<dd>Contains system applications and libraries that have source code available
-on Android Open Source Project (AOSP). During normal operation, this partition
-is mounted read-only; its contents change only during an OTA update.</dd>
-<dt>vendor</dt>
-<dd>Contains system applications and libraries that do <em>not</em> have
-source code available on Android Open Source Project (AOSP). During normal
-operation, this partition is mounted read-only; its contents change only
-during an OTA update.</dd>
-<dt>userdata</dt>
-<dd>Stores the data saved by applications installed by the user, etc. This
-partition is not normally touched by the OTA update process.</dd>
-<dt>cache</dt>
-<dd>Temporary holding area used by a few applications (accessing this
-partition requires special app permissions) and for storage of downloaded OTA
-update packages. Other programs use this space with the expectation that files
-can disappear at any time. Some OTA package installations may result in this
-partition being wiped completely.</dd>
-<dt>recovery</dt>
-<dd>Contains a second complete Linux system, including a kernel and the
-special recovery binary that reads a package and uses its contents to update
-the other partitions.</dd>
-<dt>misc</dt>
-<dd>Tiny partition used by recovery to stash some information away about what
-it's doing in case the device is restarted while the OTA package is being
-applied.</dd></dl>
+ <p>
+ Modern A/B devices have two copies of each partition, A and B. Devices
+ apply the update to the currently unused partition while the system is
+ running but idle. A/B devices do not need space to download the update
+ package because they can apply the update as they read it from the
+ network. This is called <em>streaming A/B</em>. A/B updates are also
+ know as <em>seamless updates</em>. For more information about OTA
+ updates for A/B devices, see
+ <a href="/devices/tech/ota/ab_updates.html">A/B (Seamless) System
+ Update
+ </a>.
+ </p>
-<h2 id="life-ota-update">Life of an OTA update</h2>
-<p>A typical OTA update contains the following steps:</p>
-<ol>
-<li>Device performs regular check in with OTA servers and is notified of the
-availability of an update, including the URL of the update package and a
-description string to show the user.</li>
-<li>Update downloads to a cache or data partition, and its cryptographic
-signature is verified against the certificates in
-<code>/system/etc/security/otacerts.zip</code>. User is prompted to install the
-update.</li>
-<li>Device reboots into recovery mode, in which the kernel and system in the
-recovery partition are booted instead of the kernel in the boot partition.</li>
-<li>Recovery binary is started by init. It finds command-line arguments in
-<code>/cache/recovery/command</code> that point it to the downloaded package.
-</li>
-<li>Recovery verifies the cryptographic signature of the package against the
-public keys in <code>/res/keys</code> (part of the RAM disk contained in the
-recovery partition).</li>
-<li>Data is pulled from the package and used to update the boot, system,
-and/or vendor partitions as necessary. One of the new files left on the system
-partition contains the contents of the new recovery partition.</li>
-<li>Device reboots normally. <ol style="list-style-type:lower-alpha">
-<li>The newly updated boot partition is loaded, and it mounts and starts
-executing binaries in the newly updated system partition.</li>
-<li>As part of normal startup, the system checks the contents of the recovery
-partition against the desired contents (which were previously stored as a file
-in <code>/system</code>). They are different, so the recovery partition is
-reflashed with the desired contents. (On subsequent boots, the recovery
-partition already contains the new contents, so no reflash is necessary.)</li>
-</ol></li>
-</ol>
-<p>The system update is complete!</p>
+ <h2 id="nonab_updates">Non-A/B updates</h2>
-<h2 id="migrating">Migrating from previous releases</h2>
-
-<p>When migrating from Android 2.3/3.0/4.0 release, the major change is the
-conversion of all the device-specific functionality from a set of C functions
-with predefined names to C++ objects. The following table lists the old
-functions and the new methods that serve a roughly equivalent purpose:</p>
-
-<table>
-<tbody>
-<tr>
-<th>C function</th>
-<th>C++ method</th>
-</tr>
-<tr>
-<td>device_recovery_start()</td>
-<td>Device::RecoveryStart()</td>
-</tr>
-<tr>
-<td>device_toggle_display()<br>
-device_reboot_now()<br>
-</td>
-<td>RecoveryUI::CheckKey()<br>
-(also RecoveryUI::IsKeyPressed())<br>
-</td>
-</tr>
-<tr>
-<td>device_handle_key()</td>
-<td>Device::HandleMenuKey()</td>
-</tr>
-<tr>
-<td>device_perform_action()</td>
-<td>Device::InvokeMenuItem()</td>
-</tr>
-<tr>
-<td>device_wipe_data()</td>
-<td>Device::WipeData()</td>
-</tr>
-<tr>
-<td>device_ui_init()</td>
-<td>ScreenRecoveryUI::Init()</td>
-</tr>
-</tbody>
-</table>
-
-<p>Conversion of old functions to new methods should be reasonably
-straightforward. Don't forget to add the new <code>make_device()</code>
-function to create and return an instance of your new Device subclass.</p>
+ <p>
+ Older devices have a special recovery partition containing the software
+ needed to unpack a downloaded update package and apply the update to
+ the other partitions. For more information, see
+ <a href="/devices/tech/ota/nonab_updates.html">Non-A/B System Updates
+ </a>.
+ </p>
+
</body>
</html>