従来のOTA方式と比較して、A / Bシステムの主な変更点は次のとおりです。
- システムパーティションの設定
従来の方法では、パーティション
A / Bのセットは1つだけです。システムには、スロットAとスロットBと呼ばれる2つのパーティションセットがあります。 - ブートローダーとの通信方法
従来のブートローダーは、その他のパーティション情報を読み取ることにより、Androidメインシステムとリカバリシステム
A / Bシステムのどちらに入るかを決定します。A/ Bシステムのブートローダーは、スロットAとスロットのどちらから起動するかを決定します。 B特定のパーティション情報を介して。 - システムのコンパイルプロセス
従来の方法では、コンパイル中にboot.imgとrecovery.imgが生成されます。Androidメインシステムとリカバリシステムで使用されるramdisk
A / Bシステムには、個別のrecovery.imgを生成する代わりに、それぞれboot.imgがあります。 - OTAアップデートパッケージの生成方法
A / Bシステムは従来の方法と同じOTAパッケージツールとコマンドを生成しますが、生成されるコンテンツの形式が異なります
従来のパーティションとA / Bシステムパーティションの比較：
A / Bシステムパーティションの属性
A / BシステムのスロットAおよびスロットBパーティションには、次の3つの属性があります。
| 属性 | 名前 | 特徴 |
|---|---|---|
| アクティブ | システムのアクティブパーティションID | これは排他的な属性です。アクティブな属性に設定できるのはシステムの1つのパーティションのみです。起動時に、ブートローダーはアクティブに設定されたパーティションを選択して開始します。 |
| 起動可能 | パーティションの起動可能なロゴ | パーティションに完全な起動可能なシステムが含まれていることを示します |
| 成功 | パーティション実行フラグ | 前回の起動時または現在の起動時にパーティションが正しく実行できることを示します |
A / Bシステムの典型的なシナリオ
4つの典型的なアプリケーションシナリオがあります（現在Bパーティションから起動されていると仮定）。
図では：
現在実行中のシステム（現在）は緑色のボックスで表され、現在使用されていないシステム（未使用）は灰色のボックスで表されます。
属性IDは赤で、対応する属性がこの状態に設定されていることを示し、識別は灰色で、属性がこの状態に設定されていないか、次のような反対の属性に設定されていることを示します。
”active” 表示已经设置active属性，当前为活动分区；”active” 表示没有设置active属性
“bootable” 表示已经设置bootable属性；”bootable” 表示设置为unbootable或没有设置bootable属性
“successful” 表示已经设置successful属性，”successful” 表示没有设置successful属性
各シーンの詳細は次のとおりです。
- 通常の場合（通常の場合）
最も一般的なシナリオは、たとえば、デバイスが工場出荷時に、パーティションAとパーティションBが正常に起動して正しく実行できるため、両方のパーティションが起動可能で正常に設定されますが、パーティションBから起動されるため、パーティションBのみが起動されます。アクティブに設定されています。
- 更新中
パーティションBは、パーティションAのアップグレードデータとアップグレードを検出します。この時点で、パーティションAは起動不可としてマークされ、成功したマークはクリアされます。パーティションBは引き続きアクティブで、起動可能で、成功しています。
- 更新が完了し、再起動を待ちます（更新が適用され、再起動が保留中）
BパーティションがAパーティションを正常に更新した後、Aパーティションは起動可能としてマークされます。さらに、再起動後にパーティションAから起動する必要があるため、パーティションAもアクティブに設定する必要がありますが、パーティションAが正常に実行されることが確認されていないため、正常に設定されません。パーティションBのステータスは起動可能になり、成功しましたが、アクティブではありません。
- 新しいシステムから正常に起動しました（システムは新しいアップデートで再起動しました）
デバイスが再起動した後、ブートローダーはAパーティションがアクティブであることを検出するため、Aパーティションシステムをロードします。Aシステムに入った後に正しく実行できる場合は、Aパーティションを成功としてマークする必要があります。最初の一般的なシナリオと比較すると、AシステムとBシステムの両方が起動可能で成功するように設定されていますが、アクティブはBパーティションからAパーティションに切り替えられます。この時点で、パーティションBは正常に更新され、パーティションAに切り替えられ、デバイスは通常のシーンに戻ります。
A / Bシステム関連のMakefile変数
これらの変数には、主に3つのタイプがあります。
- A / Bシステムが定義しなければならない変数
AB_OTA_UPDATER := true
AB_OTA_PARTITIONS := boot system vendor
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
TARGET_NO_RECOVERY := true
BOARD_USES_RECOVERY_AS_BOOT := true
PRODUCT_PACKAGES += update_engine update_verifier
- A / Bシステムでオプションで定義できる変数
PRODUCT_PACKAGES_DEBUG += update_engine_client
- A / Bシステムで定義できない変数
BOARD_RECOVERYIMAGE_PARTITION_SIZE
BOARD_CACHEIMAGE_PARTITION_SIZE
BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
これらの変数については、以下で詳しく説明します。
1.必须定义的变量
AB_OTA_UPDATER := true
設定後のA / Bシステムの主なスイッチ変数：
recovery系统内不再具有操作cache分区的功能，bootable\recovery\device.cpp；
recovery系统使用不同的方式来解析升级文件，bootable\recovery\install.cpp
A / Bシステム関連のMETAファイルを生成します
AB_OTA_PARTITIONS := boot system vendor
A / Bシステムのアップグレード可能なパーティションをファイル$（zip_root）/META/ab_partitions.txtに書き込みます
BOARD_BUILD_SYSTEM_ROOT_IMAGE := true
ブートRAMディスクをシステムパーティションに配置します
TARGET_NO_RECOVERY := true
Recovery.imgイメージを生成しなくなりました
BOARD_USES_RECOVERY_AS_BOOT := true
リカバリRAMディスクをboot.imgファイルに入れます
PRODUCT_PACKAGES += update_engine update_verifier
update_engineモジュールとupdate_verifierモジュールをコンパイルし、対応するアプリケーションをインストールします
2.オプションの変数
PRODUCT_PACKAGES_DEBUG += update_engine_client
システムにはupdate_engine_clientアプリケーションが付属しており、必要に応じてコンパイルしてインストールするかどうかを選択できます
3.定義できない変数
BOARD_RECOVERYIMAGE_PARTITION_SIZE
システムにはリカバリパーティションがないため、リカバリパーティションのサイズを設定する必要はありません。
BOARD_CACHEIMAGE_PARTITION_SIZE
システムにはキャッシュパーティションがないため、キャッシュパーティションのサイズを設定する必要はありません。
BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE
システムにはキャッシュパーティションがなく、キャッシュパーティションのタイプを設定する必要はありません。