デバイス マニフェストの開発

ベンダーは、新しいデバイスを開発してリリースする際に、デバイス マニフェスト(DM)でターゲット FCM バージョンを定義および宣言できます。古いデバイスのベンダー イメージをアップグレードする場合、ベンダーは新しい HAL バージョンを実装するかターゲット FCM バージョンをインクリメントするかを選択できます。

新しいデバイスを開発する

新しいデバイスのターゲット FCM バージョンを定義するには:

  1. DEVICE_MANIFEST_FILEPRODUCT_ENFORCE_VINTF_MANIFEST を未定義のままにします。
  2. ターゲット FCM バージョン用の HAL を実装します。
  3. 適切なデバイス マニフェスト ファイルを作成します。
  4. ターゲット FCM バージョンをデバイス マニフェスト ファイルに記述します。
  5. DEVICE_MANIFEST_FILE を設定します。
  6. PRODUCT_ENFORCE_VINTF_MANIFESTtrue に設定します。

新しいデバイスをリリースする

新しいデバイスをリリースする際は、そのデバイスの初回ターゲット FCM バージョンを決定し、デバイス マニフェストで最上位の <manifest> 要素の「target-level」属性として宣言する必要があります。

たとえば、Android 9 でリリースするデバイスの場合、ターゲット FCM バージョンは 3(現時点で利用可能な最大バージョン)でなければなりません。デバイス マニフェストでこれを宣言するには、次のように記述します。

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

ベンダー イメージをアップグレードする

古いデバイスのベンダー イメージをアップグレードする場合、ベンダーは新しい HAL バージョンを実装するかターゲット FCM バージョンをインクリメントするかを選択できます。

HAL をアップグレードする

ベンダー イメージをアップグレードする際、HAL 名、インターフェース名、インスタンス名が同じであれば、ベンダーは新しい HAL バージョンを実装できます。たとえば、以下の場合です。

  • ターゲット FCM バージョン 2 でリリースされた Google Pixel 2 / Pixel 2 XL デバイスでは、必須の Audio 2.0 HAL である android.hardware.audio@2.0::IDeviceFactory/default が実装されます。
  • Android 9 でリリースされた Audio 4.0 HAL については、フル OTA を使用して Google Pixel 2 / Pixel 2 XL デバイスを 4.0 HAL にアップグレードできます。これにより android.hardware.audio@4.0::IDeviceFactory/default が実装されます。
  • compatibility_matrix.2.xml では Audio 2.0 のみが規定されていますが、ターゲット FCM バージョン 2 のベンダー イメージに対する要件は緩和されました。これは、Android 9 フレームワーク(FCM バージョン 3)では、機能面から Audio 4.0 が Audio 2.0 HAL の代わりになると見なされるためです。

compatibility_matrix.2.xml には Audio 2.0 が必要で、compatibility_matrix.3.xml には Audio 4.0 が必要であることから、要件をまとめると次のようになります。

FCM バージョン(システム) ターゲット FCM バージョン(ベンダー) 要件
2(8.1) 2(8.1) Audio 2.0
3(9) 2(8.1) Audio 2.0 または 4.0
3(9) 3(9) Audio 4.0

ターゲット FCM バージョンをアップグレードする

ベンダー イメージをアップグレードする際、ベンダーはターゲット FCM バージョンをインクリメントして、アップグレードされたベンダー イメージが利用できるターゲット FCM バージョンを指定することもできます。デバイスのターゲット FCM バージョンを上げるには、ベンダーは以下の作業を行う必要があります。

  1. ターゲット FCM バージョンに対して新たに必要になる HAL バージョンをすべて実装する。
  2. デバイス マニフェスト ファイルの HAL バージョンを変更する。
  3. デバイス マニフェスト ファイルのターゲット FCM バージョンを変更する。
  4. サポートが終了した HAL バージョンを削除する。

たとえば、Android 7.0 でリリースする Google Pixel / Pixel XL デバイスの場合、ターゲット FCM バージョンは以前のバージョン以上にする必要があります。一方、ベンダー イメージは compatibility_matrix.2.xml に準拠するようにアップデートされているため、デバイス マニフェストでは、次のようにしてターゲット FCM バージョン 2 を宣言します。

<manifest version="1.0" type="device" target-level="2">

ベンダーが新たに必要になった HAL バージョンをすべて実装していない場合、またはサポートが終了した HAL バージョンを削除していない場合、ターゲット FCM バージョンをアップグレードすることはできません。

たとえば、Google Pixel 2 / Pixel 2 XL デバイスのターゲット FCM バージョンが 2 であるとします。また、compatibility_matrix.3.xml で要求される一部の HAL(Audio 4.0 や Health 2.0 など)は実装されているが、FCM バージョン 3(Android 9)でサポートが終了した android.hardware.radio.deprecated@1.0 が削除されていないとします。この場合、これらのデバイスでターゲット FCM バージョンを 3 にアップグレードすることはできません。

OTA 時にカーネル要件を必須にする

Android 9 以下のデバイスをアップグレードする

Android 9 以下のデバイスでは、必要に応じて次の CL を cherry-pick してください。

この変更により、ビルドフラグ PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS が導入され、Android 9 以下でリリースするデバイスではフラグは未設定のままになります。

  • Android 10 にアップデートする場合、Android 9 以下を搭載しているデバイス上の OTA クライアントは、OTA パッケージのカーネル要件を正しくチェックしません。上記の変更は、生成される OTA パッケージからカーネル要件を取り除くために必要です。
  • Android 11 にアップデートする場合、必要に応じて PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS ビルドフラグを設定して、アップデート パッケージの生成時に VINTF の互換性をチェックできます。

このビルドフラグの詳細については、Android 10 のデバイスをアップデートするをご覧ください。

Android 10 のデバイスをアップデートする

Android 10 では、新しいビルドフラグ PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS が導入されています。Android 10 でリリースするデバイスでは、このフラグは自動的に true に設定されます。このフラグが true に設定されている場合、スクリプトはインストールされたカーネル イメージからカーネル バージョンとカーネル構成を抽出します。

  • Android 10 にアップデートする場合、OTA アップデート パッケージにカーネルのバージョンと構成が含まれます。Android 10 を搭載したデバイス上の OTA クライアントは、この情報を読み取って互換性をチェックします。
  • Android 11 にアップデートする場合、OTA パッケージ生成スクリプトはカーネルのバージョンと構成を読み取り、互換性をチェックします。

スクリプトがカーネル イメージから上記の情報を抽出できない場合は、次のいずれかを行ってください。

  • カーネル形式をサポートするようにスクリプトを変更し、AOSP に提供します。
  • BOARD_KERNEL_VERSION をカーネル バージョンに設定し、BOARD_KERNEL_CONFIG_FILE をビルド済みカーネル構成ファイル .config のパスに設定します。カーネル イメージがアップデートされたときは、これらの変数を両方とも更新する必要があります。
  • または、PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTSfalse に設定して、カーネル要件のチェックをスキップします。非互換性は非表示であり、アップデート後に VTS テストを実行したときにのみ検出されるため、この方法はおすすめしません。

カーネル情報抽出スクリプトのソースコードは、extract_kernel.py で確認できます。