2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
非 A/B システム アップデート
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
非 AB アップデートは、古い Android デバイス（Android 6 以前）で使用されていた廃止された OTA 手法です。これらのデバイスには専用のリカバリ パーティションがあり、ダウンロードしたアップデート パッケージを解凍して他のパーティションにアップデートを適用するために必要なソフトウェアがそこに含まれています。
A/B パーティションのない古い Android デバイスでは、通常、フラッシュ領域に次のパーティションが含まれます。
- boot
-
Linux カーネルと最小限のルート ファイル システム（RAM ディスクに読み込まれる）が格納されています。system パーティションとその他のパーティションをマウントし、system パーティション上でランタイムを開始します。
- system
-
Android オープンソース プロジェクト（AOSP）で利用できるソースコードを含むシステム アプリケーションとライブラリが格納されています。通常のオペレーションでは、このパーティションは読み取り専用としてマウントされ、そのコンテンツは OTA アップデート中にのみ変更されます。
- vendor
-
Android オープンソース プロジェクト（AOSP）で利用できるソースコードを含まない、システム アプリケーションとライブラリが格納されています。通常のオペレーションでは、このパーティションは読み取り専用としてマウントされ、そのコンテンツは OTA アップデート中にのみ変更されます。
- userdata
-
ユーザーがインストールしたアプリによって保存されたデータが格納されています。通常、このパーティションは OTA アップデート プロセスでは処理されません。
- cache
-
一部のアプリケーションにより、ダウンロードされた OTA アップデート パッケージの保存に使用される一時保留領域です。このパーティションへのアクセスには特別なアプリ権限が必要です。他のプログラムがこの領域を使用する場合は、ファイルがすぐに消えてしまうことを想定します。一部の OTA パッケージのインストールにより、このパーティションが完全にワイプされることがあります。この cache には、OTA アップデートのアップデート ログも格納されます。
- recovery
-
予備の Linux システム完全版が格納されています。このシステムには、カーネル、パッケージを読み取ってそのコンテンツを使用して他のパーティションを更新する特殊なリカバリ バイナリが含まれます。
- misc
-
OTA パッケージを適用している間にデバイスが再起動された場合に、リカバリが、その時点で行われていたオペレーションに関する情報を保管できる小さなパーティションです。
OTA アップデートのライフサイクル
一般的な OTA アップデートには、次の手順が含まれます。
- デバイスにより OTA サーバーが定期的にチェックされます。アップデート パッケージの URL とユーザーに表示する説明文などとともに、更新の可否が通知されます。
-
アップデートは cashe パーティションまたはデータ パーティションにダウンロードされ、その暗号署名を
/system/etc/security/otacerts.zip にある証明書を使用して検証します。ユーザーはアップデートをインストールするよう求められます。
-
デバイスがリカバリモードで再起動し、起動パーティションのカーネルではなく、リカバリ パーティションのカーネルとシステムが起動します。
-
リカバリ バイナリは init によって開始され、ダウンロードされたパッケージにそれをポイントするコマンドライン引数を、
/cache/recovery/command 内で検出します。
-
リカバリでは、パッケージの暗号署名が
/res/keys（recovery パーティションに含まれる RAM ディスクの一部）にある公開鍵と照合されます。
-
データはパッケージから取得され、必要に応じて boot、system、vendor パーティションの更新に使用されます。system パーティションに残っている新しいファイルの 1 つに、新しい recovery パーティションのコンテンツが格納されます。
-
デバイスは通常どおり再起動します。
-
新たに更新された boot パーティションが読み込まれ、新たに更新された system パーティション内のバイナリをマウントして開始します。
-
通常の起動時に、システムは recovery パーティションのコンテンツを、以前
/system 内にファイルとして保存されていたコンテンツと照合します。これらは異なるため、recovery パーティションは必要なコンテンツで再読み込みされます。次の起動時には、recovery パーティションにはすでに新しいコンテンツが含まれているため、再読み込みは必要ありません。
システム アップデートが完了しました。アップデート ログは /cache/recovery/last_log.# にあります。
アップデート パッケージ
アップデート パッケージは実行可能なバイナリ META-INF/com/google/android/update-binary を含む .zip ファイルです。パッケージの署名を確認したら、recovery はこのバイナリを /tmp に抽出してバイナリを実行し、次の引数を渡します。
-
アップデート バイナリ API のバージョン番号。引数がアップデート バイナリの変更に渡された場合、この数値が増えます。
-
コマンドパイプのファイル記述子。アップデート プログラムはこのパイプを使用して、リカバリ バイナリにコマンドを返信できます。多くの場合はユーザーに進行状況を知らせるなどの UI の変更についてです。
- アップデート パッケージの
.zip ファイルのファイル名。
アップデート パッケージは、静的にリンクされたバイナリをアップデート バイナリとして使用できます。OTA パッケージ構築ツールでは、多数のインストール作業を実行できる簡単なスクリプト言語を提供するアップデータ プログラム（bootable/recovery/updater）を使用します。デバイス上で動作している他のバイナリに置き換えることができます。
アップデータ バイナリ、edify 構文、組み込み関数の詳細については、OTA パッケージの詳細を参照してください。
以前のリリースからの移行
Android 2.3 / 3.0 / 4.0 リリースからの移行での大きな変更点は、デバイス固有のすべての機能を C 関数のセットから C++ オブジェクトに変換したことです。次の表に、ほぼ同じ目的に使用する古い関数と新しいメソッドを示します。
| C 関数 |
C++ メソッド |
| device_recovery_start() |
Device::RecoveryStart() |
device_toggle_display()
device_reboot_now()
|
RecoveryUI::CheckKey()
（RecoveryUI::IsKeyPressed() も同様）
|
| device_handle_key() |
Device::HandleMenuKey() |
| device_perform_action() |
Device::InvokeMenuItem() |
| device_wipe_data() |
Device::WipeData() |
| device_ui_init() |
ScreenRecoveryUI::Init() |
古い関数を新しいメソッドに変換するのは簡単です。新しい make_device() 関数を追加して、新しいデバイスのサブクラスにインスタンスを作成して返すことを忘れないでください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. 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.\n2. 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.\n3. 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.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. 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).\n6. 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.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. 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.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
