ヘルプ
英语（美国） | English (US) 日本語 | Japanese 中文 | Chinese (Simplified)

1899876_ja-JP

キャンセル
提案をオンにする
自動提案では、入力時に可能な一致が提案されるので検索結果を素早く絞り込むことができます。
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

1899876_ja-JP

1899876_ja-JP

i.MX AndroidクロスバージョンOTAに関する注意事項

本書について

i.MX Androidでは、新しいAndroidバージョンで直接OTAパッケージをビルドし、それを旧バージョンのAndroidが動作しているデバイスに適用することは、実現できない場合があります。たとえば、i.MX Android-13.0.0_2.0.0リリースでビルドされたevk_8mm向けOTAパッケージは、i.MX Android-11.0.0_1.0.0でビルドされたイメージが動作しているevk_8mmボードには直接適用できません。

この記事では、まず、i.MX AndroidでクロスバージョンOTAが直接実行できない理由について説明します。次に、クロスバージョンOTAの前に考慮すべき点および実施すべき内容について説明します。


Googleがデバイスのシステムを更新する方法

Googleが初めてデバイスをリリースすると、そのデバイスは「ローンチデバイス」と呼ばれます。ローンチデバイスには以下があります：

  • コードネーム。Pixel 3a XLを例に挙げると、コードネームはbonitoです
  • Androidバージョン。Pixel 3a XLの場合、Android 9.0です
  • カーネルバージョン。Pixel 3a XLの場合、4.9です
  • PRODUCT_SHIPPING_API_LEVEL。Pixel 3a XLの場合、そのAndroidバージョンのSDKバージョンと同じ28に設定されています。
  • FCMターゲットレベル。Pixel 3a XL の場合は 3 です

システムコードが新しいバージョンに更新された後、Pixel 3a XL向けにaosp_bonito-userまたはaosp_bonito-userdebugのランチターゲットを使用してOTAパッケージをビルドできます。このように更新されたデバイスを「レトロフィットデバイス」と呼ぶことにします。

  • コードネームは変更されていません。そのデバイス構成は、引き続き「device/google/bonito/」にあります。
  • Androidバージョン。OTAで更新されたバージョンです。Android 9、10、11、12の4つのバージョンがサポートされています。つまり、Pixel 3a XLは最大でAndroid 12までアップグレード可能です。「device/google/bonito/」はAndroid 9で導入され、Android 13で削除されました。
  • カーネルバージョン。OTA適用後も変更されません
  • PRODUCT_SHIPPING_API_LEVEL。OTA では変更されないため、OTA 後、プロパティ「ro.product.first_api_level」の値は SDK バージョンと異なります。
  • FCMターゲットレベル。OTA適用後も変更されません。

FCMターゲットレベルはデバイスのmanifest.xmlに定義されており、特定のバージョンのsystem compatibility.matrix.xmlに対応しています。したがって、FCMターゲットレベルが変更されない場合、このデバイスによって提供されるHALに大きな変更を加える必要はありません。

これは、Google が自社のデバイスのシステムを維持する方法です。これは、i.MX Android デバイスが維持される方法ではありません。

保守対象デバイスに対するi.MX Androidのシステム更新方法

保守対象のi.MXデバイスに対してコードが新しいバージョンに更新されると、すべてのデバイスは「ローンチデバイス」として扱われます。そのため、以前のバージョンと比較して、新しいシステムでは以下のような変更があります：

  • カーネルバージョンが変更されました
  • PRODUCT_SHIPPING_API_LEVELが変更されました
  • FCM のターゲットレベルが変更されました。
  • 物理パーティションが変更される場合もあります。

FCMターゲットレベルが変更される場合、このデバイスが提供するHALに大きな変更が加わる可能性があります。

PRODUCT_SHIPPING_API_LEVELが変更されると、プロパティ「ro.product.first_api_level」に基づく多くのコードロジックが異なる処理フローで実行されることになります。

パーティションの変更がある場合、更新後のコードで直接ビルドされたOTAパッケージは、適用できないことがよくあります。たとえば、新しいパーティション用のイメージは、旧システムが動作しているボードには適用できません。旧システムにはそのイメージ用のパーティションが存在しないためです。

OTA中に変更できない項目

クロスバージョンOTAが直接実行できない理由を明確にするためには、OTA中に変更できない項目があることを理解しておく必要があります。

1.OTA中は物理パーティションを変更することはできません。

関連する機能は以下のとおりです。

*動的パーティション

* gki

* ブートヘッダーバージョン

2.userdata パーティションのユーザーデータは変更しないでください。変更すると、OTA中にデータが失われる可能性があります。

関連する機能は以下のとおりです。

* 暗号化オプション

新しいバージョンのAndroidが、古いバージョンのAndroidで暗号化されたデータを認識できるようにするため、暗号化オプションは変更するべきではありません。

一部のfs_mgr暗号化オプションでは、product_shipping_api_levelがカーネルに渡される最終的な暗号化パラメータに影響を与えます。次のコードをご覧ください。同じfs_mgr暗号化オプションでも、first_api_levelが異なると、Androidバージョンごとに最終的な暗号化パラメータが異なります。

android10    system/extras/libfscrypt/fscrypt.cpp
    if (filenames_encryption_mode == FS_ENCRYPTION_MODE_AES_256_CTS) {
        // Use legacy padding with our original filenames encryption mode.
        return FS_POLICY_FLAGS_PAD_4;
    } else if (filenames_encryption_mode == FS_ENCRYPTION_MODE_ADIANTUM) {
        // ...snip...
        return (FS_POLICY_FLAGS_PAD_16 | FS_POLICY_FLAG_DIRECT_KEY);
    }
    // ...snip...
    return FS_POLICY_FLAGS_PAD_16;
 
android11    system/extras/libfscrypt/fscrypt.cpp
    if (!is_gki && options->version == 1 && options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) {
        options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4;
    } else {
        options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16;
    }
 
android12  system/extras/libfscrypt/fscrypt.cpp
    if (first_api_level <= __ANDROID_API_Q__ && options->version == 1 &&
        options->filenames_mode == FSCRYPT_MODE_AES_256_CTS) {
        options->flags |= FSCRYPT_POLICY_FLAGS_PAD_4;
    } else {
        options->flags |= FSCRYPT_POLICY_FLAGS_PAD_16;
    }

fscryptのバージョンも結果に影響します。指定されていない場合、「product_shipping_api_level <= 29」であれば、デフォルトの「version」は「v1」になり、それ以外の場合は「v2」になります。
「casefold」や「project id」などの一部の fscrypt 機能は fscrypt「v2」に依存します。これらの機能は、「device/nxp」に「$(call inherit-product, $(SRC_TARGET_DIR)/product/emulated_storage.mk)」を含めることで有効になります。fscrypt「v1」を使用する場合は、「emulated_storage.mk」を含めないでください。

* userdataパーティションのファイルシステムタイプ

ext4（i.MX Android 13.0.0 より前で使用）

f2fs（i.mx android 13.0.0から使用）

* userdata パーティション上のエミュレーテッドストレージのファイルシステム

sdcardfs

ヒューズ

3. miscパーティション内のブート制御情報は、OTAの前後で認識される必要があります。

関連する機能は次のとおりです。

*ブートコントロールHAL

4。U-Bootがカーネルに渡すブート引数は、ブートローダーが更新されない限り変更できません

関連する機能は次のとおりです。

* bootconfig は、Android 12.0.0_1.0.0以降でブート引数を渡すために使用されます。vendor boot header v4とともに使用されます。

 

デュアルブートローダーまたはpostinstallが使用されている場合、ブートローダーの更新が可能であることを理解しておく必要があります。


これらの関連機能について、Googleは「レトロフィットデバイス」向けには実装や変更を行っておらず、「ローンチデバイス」向けの機能変更のみに対応しています。これにより、ローンチデバイスではクロスバージョンOTAの直接適用が可能になります。これは、OTA中に変更できない項目が Androidバージョン間で共通であるためです。

i.MX Androidでは、すべての保守対象デバイスに新機能を実装するため、Androidの新しいバージョンへの更新時に、OTA中に変更可能な項目が変更されることがよくあります。これにより、クロスバージョンOTAの直接適用は実現できなくなります。

 

参照用として、以下に主な機能変更の履歴を記載します。

* 物理パーティションの変更履歴
bootloader_a/b 4MB 4MB 4MB 4MB 4MB 16MB 16MB 16MB
dtbo_a/b 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB
boot_a/b 48MB 48MB 64MB 64MB 64MB 64MB 64MB 64MB
init_boot_a/b - -   -   - 8MB 8MB
vendor_boot_a/b - -   64MB 64MB 64MB 64MB 64MB
misc 4MB 4MB 4MB 4MB 4MB 4MB 4MB 4MB
metadata 2MB 2MB 2MB 2MB 16MB 16MB 64MB 64MB
presistdata 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB
素晴らしい - - 7168MB 3584MB 4096MB 4096MB 4096MB 4096MB
fbmisc 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB
vbmeta_a/b 1MB 1MB 1MB 1MB 1MB 1MB 1MB 1MB
system_a/b 2560MB 1536MB - -   - - -
vendor_a/b 256MB 512MB - -   - - -
product_a/b - 1792MB - -   - - -

 

boot_a/b：48MB → 64MB（デバッグオプションの有効化によりイメージサイズが増加）

vendor_boot_a/b：boot header v3。GKI機能を有効にするには、vendor bootおよびboot header v3が必須です。

init_boot_a/b：ramdisk内のinitバイナリがboot.imgからinit_boot.imgに移動されました。GoogleからのGKIイメージを書き込んでも、initに対するベンダーの変更には影響しません。

 

metadataパーティションについて：

2MB → 16MB（VTSの要件：「-m vts_gsi_boot_test -t MetadataPartition#MinimumSize」）

16MB → 64MB（パーティションをF2FSとしてフォーマットするには32MBでは足りないため、64MBが使用されます。）

metadataパーティションは、ユーザーデータチェックポイント機能を有効にした際にAndroid 11で初めてマウントされました。

* GKI機能の変更履歴

Android 11で初めて導入されました。一部のコードはモジュールとしてビルドされ、vendor_boot_a/bパーティションに配置されます。vendor_boot_a/bパーティションもAndroid 11で初めて導入されました。

GKIのプリビルドバイナリはAndroid 12から統合されました。

 

i.MX AndroidのクロスバージョンOTA処理方法

手順は以下のとおりです

  • OTAベースコードとOTAターゲットコードのパーティションを一致させます
    • 製品が開発段階にあり、OTAベースコードの修正が可能な場合：
      • OTAベースコードでパーティションを予約します。たとえば、Android 10から11へのOTAを行う場合、vendor_boot.imgがなくても、Android 10のパーティションテーブルでvendor_bootパーティションを予約しておきます。このパーティションを更新できるように、update_engineに対する SELinux ルールを変更します。
      • OTAターゲットコードと同様に、OTAベースコード内の一部のパーティションを拡張します。たとえば、Android 13ではブートローダーパーティションが16MBです。Android 12 から Android 13 への OTA を行う際、Android 12 のコードを修正できる場合は、ブートローダーパーティションを 16MB に拡張してください。
      • OTA中にuserdataおよびmetadataパーティションのデータは変更されないため、OTAターゲットコードでのuserdataおよびmetadataパーティションのマウントオプションは、OTAベースコードと同一にしてください。
    • 製品パーティションがすでに出荷されている場合、修正できるのは OTAターゲットコードのみです。
      • OTA中にuserdataおよびmetadataパーティションのデータは変更されないため、OTAターゲットコードでのuserdataおよびmetadataパーティションのマウントオプションは、OTAベースコードと同一にしてください。
      • OTAベースコードに合わせてパーティションサイズを変更してください。
      • vendor_bootやinit_bootなどのパーティションは、削除が必要になる場合があります。
      • 削除または変更されたパーティションに関連する機能を削除または変更する
  • デュアルブートローダーを使用しない場合：
    • 最近のAndroidバージョン更新では、vendor_bootおよびinit_bootパーティションが追加されており、これはブートイメージヘッダーのバージョンに関連しています。これらのパーティション内のイメージはU-Bootによって読み込まれ、検証されます。そのため、デュアルブートローダーを使用しない場合、これらに関連するU-Bootコードを変更する必要があります。U-Boot内の「struct boot_img_hdr」に関連するコードを確認してください。
    • OTAベースコードとOTAターゲットコードの間で、A/Bスロットメタデータのフォーマットが変更されている可能性があります。この A/Bスロットメタデータには、Androidのbootctrl HALとU-Bootの両方がアクセスします。デュアルブートローダーが使用されていないためU-Bootは更新されず、更新されたAndroidのbootctrl HALも同じフォーマットでファイルにアクセスする必要があります。
    • ポストインストールメカニズムを使用して uboot イメージを更新することができますが、更新に失敗した場合のフォールバックがないため、リスクを評価する必要があります。
  • OTAパッケージが適用可能かどうか、および更新後のシステムが起動できるかどうかを確認してください。
    • 失敗例：Android 10からAndroid 12へのOTAにおいて、PRODUCT_SHIPPING_API_LEVEL (ro.product.first_api_level) が原因でシステムが起動に失敗しました。値の違いにより、userdataパーティションに異なる暗号化オプションが使用されます。そのため、PRODUCT_SHIPPING_API_LEVELの値は、OTAベースコードと同じ値に変更する必要があります。
    • PRODUCT_SHIPPING_API_LEVELを変更すると、device manifest.xmlおよびcompatibility_matrix.xmlの変更を含め、FCMターゲットバージョンおよび関連するHALの変更も必要になる場合があります。FCMターゲットバージョンの変更に伴い、どのような変更が加えられたかを確認するため、コミット履歴をチェックする必要があります。

 

動的パーティションに関して、注意すべき点があります。

  1. 動的パーティションを使用していないイメージから、動的パーティションを使用するイメージへのOTA：
    1. Android 10.0.0_2.0.0のコードを参照すると、10.0.0_1.0.0から10.0.0_2.0.0 のアップデート手順が示されています。0.0.0_1.0.0では、動的パーティションは有効化されていません。変数「TARGET_USE_RETROFIT_DYNAMIC_PARTITION」および関連する設定を確認してください。
  2. 動的パーティションから仮想A/BへのOTA（例：Android 10からAndroid 11へのOTA）
    1. 「build/make/target/product/virtual_ab_ota_retrofit.mk 」を継承します。
      1. Android 10からAndroid 11に初めてOTA アップデートを行う際には、「build/make/target/product/virtual_ab_ota_retrofit.mk」を継承し、動的パーティションが使用されるようにBOARD_NXP_DYNAMIC_PARTITIONS_SIZEが設定されます。
      2. 2回目のOTAでは、デバイスがVirtual A/Bレトロフィット機能付きのAndroid 11を実行しています。今回はクロスバージョンではないOTAとなり、「build/make/target/product/virtual_ab_ota.mk」を継承します。代わりに、仮想A/B機能が使用される場合、BOARD_NXP_DYNAMIC_PARTITIONS_SIZEを設定できます。
    2. 動的パーティションにアップグレードされたデバイスは、仮想 A/B を後付けすることができません。
  3. OTAターゲットコードにvendor_dlkmなどの新しい動的パーティションがある場合、追加の変更は必要ありません。

次に、お客様側で、品質を保証するために xTS のフルテストを実施する必要があります。

 
タグ(1)
0 件の賞賛
この記事は役に立ちましたか? はい いいえ
評価なし
バージョン履歴
最終更新日:
‎01-05-2026 12:22 AM
更新者: