新しいデバイスの追加

デバイスやサービス用の makefile を作成する場合に、このページの情報を参照してください。

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

ビルドレイヤについて

ビルド階層には、デバイスの物理的な構成に対応する抽象レイヤが含まれます。これらのレイヤについて、以下の表で説明します。各レイヤは 1 対多の関係で上位のレイヤに関連付けられます。たとえば、アーキテクチャは複数のボードを持つことができ、各ボードは複数のプロダクトを持つことができます。特定のレイヤ内の要素を、同じレイヤ内で要素を分化させたものとして定義することもできます。そうすることで、コピー操作が不要になり、維持管理が簡単になります。

レイヤ 説明
プロダクト myProduct、myProduct_eu、myProduct_eu_fr、j2、sdk プロダクト レイヤでは、ビルドするモジュール、サポートされているロケール、さまざまなロケールの構成など、リリースするプロダクトの機能仕様を定義します。つまり、これがプロダクト全体を示す名称になります。プロダクト固有の変数は、プロダクト定義の makefile で定義されます。プロダクトは他のプロダクト定義から継承できるため、維持管理を簡略化できます。すべてのプロダクトに適用する機能を含むベース プロダクトを作成し、そのベース プロダクトに基づいてプロダクトのバリアントを作成するというのが一般的な方法です。たとえば、無線通信方式がそれぞれ CDMA と GSM であることだけが異なる 2 つのプロダクトは、無線通信方式が定義されていない同じベース プロダクトから継承できます。
ボード / デバイス marlin、blueline、coral ボード / デバイスレイヤは、デバイスの物理的な形成に関するレイヤ(デバイスの工業デザイン)を表します。また、プロダクトの最低限の概要についても示し、ボード上の周辺機器とその構成が含まれます。使用される名称は、ボード / デバイスの各種構成を表すコードです。
アーキテクチャ arm、x86、arm64、x86_64 アーキテクチャ レイヤは、ボード上で実行されるプロセッサ構成とアプリケーション バイナリ インターフェース(ABI)を表します。

ビルド バリアントを使用する

特定のプロダクトを対象としてビルドを実行する場合、最終的なリリースビルドに小さな変更を加えたバリアントを用意しておくと便利です。モジュールの定義では、LOCAL_MODULE_TAGS でタグを指定できます。この値には、optional(デフォルト)、debugeng のうちの 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 は、ルートアクセスが有効なユーザービルドとして定義されます。ただし、以下を除きます。
    • ユーザーがオンデマンドでのみ実行する userdebug 専用アプリ
    • 充電中やフル充電時のアイドル状態のメンテナンス中にのみ実行される操作(バックグラウンド コンパイルでの dex2oatddex2oat の使用など)
  • ビルドタイプに基づいてデフォルトで有効 / 無効になっている機能は含めないでください。デバッグログやヒープダンプなど、電池寿命に影響するロギングは使用しないことをおすすめします。
  • 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/config.xml
    

config.xml オーバーレイ ファイル内の文字列または文字列配列で、元のファイルの内容が置き換えられます。

プロダクトをビルドする

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

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

プロダクトの makefile を作成する

次の手順で、プロダクトの makefile を設定する方法について説明します(Pixel でも同様の方法が使用されています)。

  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. プロダクトの makefile を指す AndroidProducts.mk ファイルを作成します。例では、プロダクト定義 makefile のみが必要です。下の例では、device/google/marlin/AndroidProducts.mk になります(Pixel の marlin と Pixel XL の sailfish の両方が含まれており、ほとんどの構成が共有されています)。
        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. vendorsetup.sh ファイルを作成し、ビルド バリアントをダッシュで区切って、プロダクト(lunch combo)をビルドに追加します。例:
        add_lunch_combo <product-name>-userdebug
        
  7. ここまでの手順で、同じデバイスを基にした複数のプロダクト バリアントを作成できます。

プロダクト定義変数を設定する

プロダクト固有の変数は、プロダクトの makefile で定義されます。次の表に、プロダクト定義ファイルで管理される変数の一部を示します。

変数 説明
PRODUCT_AAPT_CONFIG パッケージの作成時に使用する aapt 構成
PRODUCT_BRAND ソフトウェアでカスタマイズ対象となる携帯通信会社などのブランド(該当する場合)
PRODUCT_CHARACTERISTICS aapt 特性。パッケージへのバリアント固有のリソースの追加を許可します。 tabletnosdcard
PRODUCT_COPY_FILES source_path:destination_path などのリスト。ソースパスにあるファイルは、プロダクトをビルドする際に保存先のパスにコピーする必要があります。コピーの手順に関するルールは config/makefile で定義されています。
PRODUCT_DEVICE 工業デザインの名称。ボード名でもあり、ビルドシステムが BoardConfig.mk を検索する際に使用します。 tuna
PRODUCT_LOCALES 2 文字の言語コードと 2 文字の国コードのペアをスペースで区切ったリスト。UI 言語や、時刻、日付、通貨の形式など、ユーザー向けの複数の設定について記述します。PRODUCT_LOCALES に記載された最初のロケールが、プロダクトのデフォルトのロケールとして使用されます。 en_GBde_DEes_ESfr_CA
PRODUCT_MANUFACTURER メーカー名。 acme
PRODUCT_MODEL エンドユーザーに表示される完成品の名称。
PRODUCT_NAME エンドユーザーに表示されるプロダクト全体の名称。[設定] > [デバイス情報] の画面に表示されます。
PRODUCT_OTA_PUBLIC_KEYS プロダクトの無線(OTA)用の公開鍵のリスト。
PRODUCT_PACKAGES インストールする APK とモジュールのリスト。 カレンダーの連絡先
PRODUCT_PACKAGE_OVERLAYS デフォルトのリソースを使用するか、プロダクト固有のオーバーレイを追加するかを指定します。 vendor/acme/overlay
PRODUCT_PROPERTY_OVERRIDES "key=value" 形式でのシステム プロパティの割り当てのリスト。

ANDROID_VENDOR_KEYS を設定して USB 経由で接続する

デバイス メーカーは ANDROID_VENDOR_KEYS 環境変数を使用することで、adb を介して実稼働ビルドにアクセスできます。リリースごとにすべてのデバイスで承認される鍵を生成し、内部(vendor/oem-name/security/adb/ など)にその鍵を保存してから、ANDROID_VENDOR_KEYS を使用して、ランダムな鍵ではなくこれらの正規の鍵を使用するように adb に指示します。

ANDROID_VENDOR_KEYS 環境変数を使用し、暗号化用に生成された adb の公開鍵と秘密鍵を格納するディレクトリを指すように設定します。秘密鍵は file に、公開鍵は file.pub に格納します。ANDROID_VENDOR_KEYS 環境変数では、生成された鍵ペアが格納されるファイルまたはディレクトリを指定します。

ANDROID_VENDOR_KEYS 変数は、adb keygen file コマンドを使用して生成された 2048 ビットの RSA 認証鍵ペアを格納するファイルまたはディレクトリに設定されます。これらの鍵ペアは、adb サーバーが生成した RSA 鍵ペアとは別に生成されます。RSA 鍵ペアは、adb を使用して USB 経由で最初に接続する際に必要になります。

デバイスに adb アクセス権限を明示的に付与するには、ホスト コンピュータの RSA 鍵を受け入れる必要があります。デフォルトでは、adb サーバーによって生成された鍵ペアは、adbkey(秘密鍵)と adbkey.pub(公開鍵)として次のキーストア ディレクトリに格納されます。

Mac OS では、通常、ファイルの場所は $HOME/.android になります。Windows では %USERPROFILE%\.android で、Linux では $home\.android になります。Windows では、RSA 認証鍵が C:\Windows\System32\config\systemprofile\.android に格納される場合もあります。

adb サーバーは鍵が必要な場合、最初に adb サーバーのキーストア ディレクトリを検索します。鍵が見つからない場合は、次に ANDROID_VENDOR_KEYS 環境変数を確認します。それでもキーが見つからない場合、ローカル adb サーバーが新しいキーペアを生成して、adb サーバーのキーストア ディレクトリに保存します。