非 A/B システム アップデート

A/B パーティションのない古い Android デバイスでは、通常、フラッシュ領域に次のパーティションが含まれます。

boot

Linux カーネルと最小限のルート ファイル システムを含み、RAM ディスクに格納されます。system パーティションとその他のパーティションをマウントし、system パーティション上でランタイムを開始します。

system

Android オープンソース プロジェクト（AOSP）で利用できるソースコードを含んだシステム アプリケーションとライブラリが含まれています。通常のオペレーションでは、このパーティションは読み取り専用としてマウントされ、その内容は OTA アップデート中にのみ変更されます。

vendor

Android オープンソース プロジェクト（AOSP）で利用できるソースコードを含まない、システム アプリケーションとライブラリが含まれています。通常のオペレーションでは、このパーティションは読み取り専用としてマウントされ、その内容は OTA アップデート中にのみ変更されます。

userdata

ユーザーがインストールしたアプリによって保存されたデータを格納します。通常、このパーティションは OTA アップデート プロセスでは処理されません。

cache

一部のアプリケーションにより、ダウンロードされた OTA アップデート パッケージの保存に使用される一時保留領域です。このパーティションへのアクセスには特別なアプリ権限が必要です。他のプログラムがこの領域を使用する場合は、ファイルがすぐに消えてしまうことを想定します。一部の OTA パッケージのインストールにより、このパーティションが完全にワイプされることがあります。キャッシュには、OTA アップデートのアップデート ログも含まれます。

recovery

完全な第 2 版 Linux システムを含み、カーネルと、パッケージを読み取ってその内容を使用して他のパーティションを更新する特殊なリカバリ バイナリを含んでいます。

misc

OTA パッケージの適用中にデバイスが再起動された場合に、リカバリが何をしていたかの情報を保管するために使用する小さなパーティションです。

OTA アップデートのライフサイクル

一般的な OTA アップデートには、次の手順が含まれます。

1. デバイスは、OTA サーバーで定期的にチェックインし、アップデート パッケージの URL とユーザーに表示する説明文字列を含む更新の可否について通知を受けます。
2. アップデートは cashe パーティションまたはデータ パーティションにダウンロードされ、その暗号署名を /system/etc/security/otacerts.zip にある証明書を使用して検証します。ユーザーはアップデートをインストールするよう求められます。
3. デバイスがリカバリモードで再起動し、起動パーティションのカーネルではなく、リカバリ パーティションのカーネルとシステムが起動されます。
4. リカバリ バイナリは init によって開始されます。リカバリ バイナリは /cache/recovery/command 内でコマンドライン引数を検出し、ダウンロードされたパッケージに指定します。
5. リカバリでは、パッケージの暗号署名が /res/keys（recovery パーティションに含まれる RAM ディスクの一部）にある公開鍵と照合されます。
6. データはパッケージから取得され、必要に応じて boot、system、vendor のパーティションの更新に使用されます。system パーティションに残っている新しいファイルの 1 つに、新しい recovery パーティションの内容が含まれています。
7. デバイスは通常どおり再起動します。
   1. 新たに更新された boot パーティションが読み込まれ、新たに更新された system パーティション内のバイナリをマウントして開始します。
   2. 通常の起動時に、システムは 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() 関数を追加して、新しいデバイスのサブクラスにインスタンスを作成して返すことを忘れないでください。