Android 5.x OTA Update官方文档（一，关于OTA 升级）
写在前面：
若能直译，不会意译，意译不成，为了选择不误导他人也会漏译无伤大雅的部分，英语是硬伤，如果有误译，请路过的朋友帮忙指正，以免误导更多的朋友。
Android设备可以接受和安装基于系统和应用的更新。在设备中有一个特殊recovery分区，在这个分区中有一套特殊的恢复系统可以将下载的更新包进行解压并应用到系统中去。
本节主要描述了更新包的组织架构，并且概述了如何使用更新包打包工具制作系统升级的更新包。OTA 的存在是用来对潜在系统的升级，或者在系统分区安装只读（不可卸载）的应用程序，因此在升级过程中不会影响到用于已经安装到系统中的 应用程序。
本节的内容主要基于Android5.x版本。
一、Android设备布局的设计
通常，在Android设备中的flash常常包含下面一些分区：
boot
boot分区中包含了Linux内核和一个很小的根文件系统（会被加载到RAM中去），用来挂在系统等分区，而且boot分区还被用来启动system分区中的运行环境。
system
system分区中包含了系统级的应用如通话、音视频等，此外还有一些库文件。而这些应用程序和库文件往往是开源的，我们可以在AOSP中去查看相关的实现。正常情况下（非root）这些基础的应用程序为只读不可进行卸载。而且只有在OTA 时才会发生变化。
vendor
vendor分区中也有一些应用程序和库文件，但这些是由第三方提供，至于开源与否，不好说，至少在aosp中是看不到源码的。当然非root情况下也是无法进行卸载的，是出厂时预置的只读的应用程序。
userdata
userdata分区是用户的天堂，用户在使用应用程序时所产生的一些数据都保存在这里，比如保存的常用联系人，短信息等。
cache
cache分区是极少数应用程序才能访问到的一个分区（需要一些特定的权限），通常被用来保存OTA包，还有一些在升级过程中所产生的日志文件如last_log等。
recovery
recovery是一个特殊的分区，在recovery分区中有一套完整的linux系统，被用来读取更新包和对其他分区进行升级。
misc
misc是一个很小的分区，常常被recover分区用来保存一些ota 相关的信息。
二、OTA 升级流程
标准的OTA升级流程包含以下几步：
1.Android设备首先会与OTA服务器进行交互，如果有更新会推送给客户。推送的信息常常会包含OTA更新包的下载地址和一些版本信息。
2.Update程序会将更新包下载到cache分区下，并提醒用户安装更新。
3.设备会重启进入recovery模式，同时启动recovery分区下运行环境，不再启动boot分区下的运行环境。
4.recovery运行环境初始化时会启动recovery二进制程序并根据/cache/recovery/command中的命令对更新包进行下一步操作。
5.Recovery运行环境对更新包中/res/key的签名进行校验，如果校验失败会中断升级。
6.Recovery二进制程序会对更新包中的数据进行解压同时根据解压出的数据对boot、system、和vender分区进行相应的更新。对system分区的更新也同时包含了新的recovery分区的更新。
7.重启设备
a.载入新的boot分区，并执行升级后的system分区中的二进制文件。
b.系统启动时会同时校验recovery分区，如果recovery与升级时保存在system分区下的信息不一致会对recovery进行更新。
8.系统更新完成。
三、Android5.x与Android4.0/3.0/2.3不同之处。
从Android2.3/3.0/4.0到Android5.x的迁移过程中有很多函数特定的函数发生了变化，主要是一些C函数被重新用C++进行定义。下面的表格中列出了一些新旧函数的交替。
| C function |
C++ method |
| device_recovery_start() |
Device::RecoveryStart() |
| device_toggle_display() |
RecoveryUI::CheckKey() |
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
下面为原文：http://source.android.com/devices/tech/ota/index.html#android-device-layout
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.
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 not affect applications installed by the user from Google Play.
This section describes the OTA system as of the Android 5.x release. For help porting OTA-related code from older releases, see Migrating from previous releases.
Android device layout
The flash space on an Android device typically contains the following partitions.
- boot
- 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.
- system
- 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.
- vendor
- Contains system applications and libraries that do not 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.
- userdata
- Stores the data saved by applications installed by the user, etc. This partition is not normally touched by the OTA update process.
- cache
- 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.
- recovery
- 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.
- misc
- 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.
Life of an OTA update
A typical OTA update contains the following steps:
- 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.
- Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in
/system/etc/security/otacerts.zip. User is prompted to install the update. - 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.
- Recovery binary is started by init. It finds command-line arguments in
/cache/recovery/commandthat point it to the downloaded package. - Recovery verifies the cryptographic signature of the package against the public keys in
/res/keys(part of the RAM disk contained in the recovery partition). - 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.
- Device reboots normally.
- The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.
- 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
/system). 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.)
The system update is complete!
Migrating from Previous Releases
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:
| C function | C++ method |
|---|---|
| device_recovery_start() | Device::RecoveryStart() |
| device_toggle_display() device_reboot_now() |
RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |
| device_handle_key() | Device::HandleMenuKey() |
| device_perform_action() | Device::InvokeMenuItem() |
| device_wipe_data() | Device::WipeData() |
| device_ui_init() | ScreenRecoveryUI::Init() |
Conversion of old functions to new methods should be reasonably straightforward. Don't forget to add the newmake_device() function to create and return an instance of your new Device subclass.