新しいデバイスの追加

このページの情報を使用して、デバイスと製品のメイクファイルを作成してください。

注:この情報は、新しいデバイス タイプの作成にのみ適用され、特に会社のビルドおよび製品チームを対象としています。

新しい各 Android モジュールには、ビルド システムにモジュール メタデータ、コンパイル時の依存関係、およびパッケージ化手順を指示するための構成ファイルが必要です。 Android はSoong ビルド システムを使用します。 Android ビルド システムの詳細については、 Androidのビルドを参照してください。

ビルドレイヤーについて

ビルド階層には、デバイスの物理的な構成に対応する抽象化レイヤーが含まれています。これらのレイヤーについては、次の表で説明します。各レイヤーは、1 対多の関係でその上のレイヤーに関連付けられます。たとえば、アーキテクチャには複数のボードを含めることができ、各ボードには複数の製品を含めることができます。特定のレイヤー内の要素を、同じレイヤー内の要素の特殊化として定義できます。これにより、コピーが不要になり、メンテナンスが簡素化されます。

層	例	説明
製品	myProduct、myProduct_eu、myProduct_eu_fr、j2、sdk	製品レイヤーは、ビルドするモジュール、サポートされるロケール、さまざまなロケールの構成など、出荷製品の機能仕様を定義します。つまり、これは製品全体の名前です。製品固有の変数は、製品定義 makefile で定義されます。製品は他の製品定義から継承できるため、保守が簡単になります。一般的な方法は、すべての製品に適用される機能を含む基本製品を作成してから、その基本製品に基づいて製品バリエーションを作成することです。たとえば、無線 (CDMA と GSM) のみが異なる 2 つの製品は、無線を定義しない同じ基本製品から継承できます。
ボード/デバイス	カジキ、ブルーライン、コーラル	ボード/デバイス層は、デバイス上のプラスチックの物理層 (つまり、デバイスの工業デザイン) を表します。このレイヤーは、製品の裸の回路図も表します。これらには、ボード上の周辺機器とその構成が含まれます。使用されている名前は、異なるボード/デバイス構成の単なるコードです。
アーチ	アーム, x86, arm64, x86_64	アーキテクチャ層は、ボード上で実行されているプロセッサ構成とアプリケーション バイナリ インターフェイス (ABI) を記述します。

ビルド バリアントの使用

特定の製品用にビルドする場合、最終リリース ビルドにマイナー バリエーションを持たせると便利です。モジュール定義では、モジュールはLOCAL_MODULE_TAGSでタグを指定できます。これは、 optional (デフォルト)、 debug 、およびengの 1 つ以上の値にすることができます。

モジュールが ( LOCAL_MODULE_TAGSによって) タグを指定しない場合、そのタグはデフォルトでoptionalになります。オプションのモジュールは、 PRODUCT_PACKAGESを使用した製品構成で必要な場合にのみインストールされます。

これらは、現在定義されているビルド バリアントです。

変異体	説明
eng	これがデフォルトのフレーバーです。 engまたはdebugでタグ付けされたモジュールをインストールします。 タグ付けされたモジュールに加えて、製品定義ファイルに従ってモジュールをインストールします。 ro.secure=0 ro.debuggable=1 ro.kernel.android.checkjni=1 adbはデフォルトで有効になっています。
user	亜種は、最終リリース ビットを意図したものです。 userでタグ付けされたモジュールをインストールします。 タグ付けされたモジュールに加えて、製品定義ファイルに従ってモジュールをインストールします。 ro.secure=1 ro.debuggable=0 adbはデフォルトで無効になっています。
userdebug	次の例外を除いて、 userと同じです。 debugでタグ付けされたモジュールもインストールします。 ro.debuggable=1 adbはデフォルトで有効になっています。

userdebug のガイドライン

テストで userdebug ビルドを実行すると、デバイス開発者が開発中のリリースのパフォーマンスと能力を理解するのに役立ちます。ユーザー ビルドとユーザーデバッグ ビルドの間の一貫性を維持し、デバッグに使用されるビルドで信頼できる指標を実現するには、デバイス デベロッパーは次のガイドラインに従う必要があります。

• userdebug は、ルート アクセスが有効になっているユーザー ビルドとして定義されます。ただし、次の場合を除きます。
  • ユーザーがオンデマンドでのみ実行する userdebug 専用アプリ
  • バックグラウンド コンパイルにdex2oatdとdex2oatを使用するなど、アイドル メンテナンス中 (充電器/フル充電時) にのみ実行される操作
• ビルド タイプに基づいてデフォルトで有効/無効になる機能は含めないでください。開発者は、デバッグ ログやヒープ ダンプなど、バッテリ寿命に影響を与える形式のログを使用しないことをお勧めします。
• userdebug でデフォルトで有効になっているデバッグ機能は、明確に定義し、プロジェクトに取り組んでいるすべての開発者と共有する必要があります。デバッグしようとしている問題が解決されるまで、限られた時間でのみデバッグ機能を有効にする必要があります。

リソース オーバーレイを使用したビルドのカスタマイズ

Android ビルド システムは、ビルド時にリソース オーバーレイを使用して製品をカスタマイズします。リソース オーバーレイは、デフォルトの上に適用されるリソース ファイルを指定します。リソース オーバーレイを使用するには、プロジェクトのビルドファイルを変更して、 PRODUCT_PACKAGE_OVERLAYSを最上位ディレクトリからの相対パスに設定します。そのパスは、ビルド システムがリソースを検索するときに、現在のルートと共に検索されるシャドウ ルートになります。

最も一般的にカスタマイズされた設定は、ファイルFrameworks/base/core/res/res/values/config.xmlに含まれています。

このファイルにリソース オーバーレイを設定するには、次のいずれかを使用してプロジェクト ビルドファイルにオーバーレイ ディレクトリを追加します。

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

また

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

次に、オーバーレイ ファイルをディレクトリに追加します。次に例を示します。

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

オーバーレイconfig.xmlファイルで見つかった文字列または文字列配列は、元のファイルで見つかったものを置き換えます。

製品の構築

デバイスのソース ファイルは、さまざまな方法で整理できます。ここでは、Pixel の実装を編成する 1 つの方法について簡単に説明します。

Pixel は、 marlinという名前のメイン デバイス構成で実装されます。このデバイス構成から、名前やモデルなどのデバイスに関する製品固有の情報を宣言する製品定義 makefile を使用して製品が作成されます。 device/google/marlinディレクトリを表示して、これらすべてがどのように設定されているかを確認できます。

製品メイクファイルの作成

次の手順では、Pixel 製品ラインと同様の方法で製品の Makefile を設定する方法について説明します。

1. 製品のdevice/ <company-name> / <device-name>ディレクトリを作成します。たとえば、 device/google/marlinです。このディレクトリには、デバイスのソース コードとそれらをビルドするための makefile が含まれます。
2. デバイスに必要なファイルとモジュールを宣言するdevice.mk makefile を作成します。例については、 device/google/marlin/device-marlin.mkを参照してください。
3. 製品定義 makefile を作成して、デバイスに基づいて特定の製品を作成します。次の makefile は、例としてdevice/google/marlin/aosp_marlin.mkから取得されます。製品は、makefile を通じてdevice/google/marlin/device-marlin.mkおよびvendor/google/marlin/device-vendor-marlin.mkファイルを継承すると同時に、名前、ブランド、とモデル。

   # Inherit from the common Open Source product configuration
   $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
   $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)
   
   PRODUCT_NAME := aosp_marlin
   PRODUCT_DEVICE := marlin
   PRODUCT_BRAND := Android
   PRODUCT_MODEL := AOSP on msm8996
   PRODUCT_MANUFACTURER := Google
   PRODUCT_RESTRICT_VENDOR_FILES := true
   
   PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin
   
   $(call inherit-product, device/google/marlin/device-marlin.mk)
   $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)
   
   PRODUCT_PACKAGES += \
       Launcher3QuickStep \
       WallpaperPicker
   

   makefile に追加できるその他の製品固有の変数については、製品定義変数の設定を参照してください。

4. 製品のメイクファイルを指すAndroidProducts.mkファイルを作成します。この例では、製品定義 makefile のみが必要です。以下の例は、 device/google/marlin/AndroidProducts.mkからのものです (これには、ほとんどの構成を共有する、Pixel である marlin と Pixel XL であるセイルフィッシュの両方が含まれています):

   PRODUCT_MAKEFILES := \
   	$(LOCAL_DIR)/aosp_marlin.mk \
   	$(LOCAL_DIR)/aosp_sailfish.mk
   
   COMMON_LUNCH_CHOICES := \
   	aosp_marlin-userdebug \
   	aosp_sailfish-userdebug
   

5. ボード固有の構成を含むBoardConfig.mk makefile を作成します。例については、 device/google/marlin/BoardConfig.mkを参照してください。
6. Android 9 以前の場合のみ、 vendorsetup.shファイルを作成して、ダッシュで区切られたビルド バリアントと共に製品 (「ランチ コンボ」) をビルドに追加します。例:

   add_lunch_combo <product-name>-userdebug
   

7. この時点で、同じデバイスに基づいてさらに多くの製品バリエーションを作成できます。

製品定義変数の設定

製品固有の変数は、製品のメイクファイルで定義されています。次の表は、製品定義ファイルで維持される変数の一部を示しています。

変数	説明	例
PRODUCT_AAPT_CONFIG	パッケージの作成時に使用するaapt構成。
PRODUCT_BRAND	ソフトウェアがカスタマイズされているブランド (キャリアなど)。
PRODUCT_CHARACTERISTICS	バリアント固有のリソースをパッケージに追加できるaapt特性。	tablet 、 nosdcard
PRODUCT_COPY_FILES	source_path:destination_pathのような単語のリスト。この製品をビルドするときに、ソース パスのファイルを宛先パスにコピーする必要があります。コピー手順のルールはconfig/makefileで定義されています。
PRODUCT_DEVICE	工業デザインの名前。これはボード名でもあり、ビルド システムはこれを使用してBoardConfig.mkを見つけます。	tuna
PRODUCT_LOCALES	2 文字の言語コードと 2 文字の国コードのペアをスペースで区切ったリストで、UI 言語、時刻、日付、通貨の書式設定など、ユーザーの設定を記述します。 PRODUCT_LOCALESにリストされている最初のロケールは、製品のデフォルトのロケールとして使用されます。	en_GB 、 de_DE 、 es_ES 、 fr_CA
PRODUCT_MANUFACTURER	メーカーの名前。	acme
PRODUCT_MODEL	最終製品のエンドユーザーに表示される名前。
PRODUCT_NAME	製品全体のエンドユーザーに表示される名前。 [設定] > [バージョン情報]画面に表示されます。
PRODUCT_OTA_PUBLIC_KEYS	製品の無線 (OTA) 公開鍵のリスト。
PRODUCT_PACKAGES	インストールする APK とモジュールのリスト。	カレンダーの連絡先
PRODUCT_PACKAGE_OVERLAYS	デフォルトのリソースを使用するか、製品固有のオーバーレイを追加するかを示します。	vendor/acme/overlay
PRODUCT_SYSTEM_PROPERTIES	システム パーティションの"key=value"形式のシステム プロパティ割り当てのリスト。他のパーティションのシステム プロパティは、ベンダー パーティションのPRODUCT_VENDOR_PROPERTIESと同様に、 PRODUCT_<PARTITION>_PROPERTIESを介して設定できます。サポートされているパーティション名: SYSTEM 、 VENDOR 、 ODM 、 SYSTEM_EXT 、およびPRODUCT 。

デフォルトのシステム言語とロケール フィルターの構成

この情報を使用して、既定の言語とシステム ロケール フィルターを構成し、新しいデバイス タイプのロケール フィルターを有効にします。

プロパティ

専用のシステム プロパティを使用して、既定の言語とシステム ロケール フィルターの両方を構成します。

• ro.product.locale : デフォルトのロケールを設定します。これは、最初はPRODUCT_LOCALES変数の最初のロケールに設定されています。その値をオーバーライドできます。 (詳細については、製品定義変数の設定の表を参照してください。)
• ro.localization.locale_filter : ロケール名に適用される正規表現を使用して、ロケール フィルターを設定します。例えば：
  • 包括的フィルター: ^(de-AT|de-DE|en|uk).* - ドイツ語 (オーストリアとドイツのバリアント)、英語のすべての英語のバリアント、およびウクライナ語のみを許可します。
  • 排他的フィルター: ^(?!de-IT|es).* - ドイツ語 (イタリアのバリアント)、およびスペイン語のすべてのバリアントを除外します。

ロケール フィルターの有効化

フィルターを有効にするには、 ro.localization.locale_filterシステム プロパティの文字列値を設定します。

工場でのキャリブレーション中にoem/oem.propを介してフィルター プロパティ値とデフォルト言語を設定することにより、システム イメージにフィルターを焼き付けずに制限を構成できます。以下に示すように、これらのプロパティをPRODUCT_OEM_PROPERTIES変数に追加することで、これらのプロパティが OEM パーティションから確実に取得されるようにします。

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

次に、本番環境では、実際の値がoem/oem.propに書き込まれ、ターゲット要件が反映されます。このアプローチでは、工場出荷時設定へのリセット中にデフォルト値が保持されるため、初期設定はユーザーにとって最初のセットアップとまったく同じように見えます。

USB経由で接続するようにADB_VENDOR_KEYSを設定する

ADB_VENDOR_KEYS環境変数を使用すると、デバイス メーカーは、手動の承認なしで adb 経由でデバッグ可能なビルド (-userdebug および -eng、ただし -user は除く) にアクセスできます。通常、adb はクライアント コンピューターごとに一意の RSA 認証キーを生成し、接続されているデバイスに送信します。これは、adb 認証ダイアログに表示される RSA キーです。別の方法として、既知のキーをシステム イメージに組み込み、それらを adb クライアントと共有することもできます。これは、adb 認証ダイアログを手動で操作する必要がなくなるため、OS 開発、特にテストに役立ちます。

ベンダー キーを作成するには、1 人 (通常はリリース マネージャー) が次のことを行う必要があります。

1. adb keygenを使用して鍵ペアを生成します。 Google デバイスの場合、Google は新しい OS バージョンごとに新しいキー ペアを生成します。
2. ソース ツリーのどこかにキー ペアをチェックインします。たとえば、Google はそれらをvendor/google/security/adb/に保存します。
3. ビルド変数PRODUCT_ADB_KEYSがキー ディレクトリを指すように設定します。 Google は、 PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pubというキー ディレクトリにAndroid.mkファイルを追加することでこれを行います。これにより、OS バージョンごとに新しいキー ペアを生成することを忘れないようにすることができます。

Google が各リリースのチェックイン キー ペアを保存するディレクトリで使用する makefile は次のとおりです。

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

これらのベンダー キーを使用するには、エンジニアはADB_VENDOR_KEYS環境変数を、キー ペアが格納されているディレクトリを指すように設定するだけです。これにより、手動認証が必要な生成されたホスト キーにフォールバックする前に、これらの正規キーを最初に試すようadbに指示されます。 adbが許可されていないデバイスに接続できない場合、 ADB_VENDOR_KEYSがまだ設定されていない場合は設定するようエラー メッセージが表示されます。