新しいテスト モジュールごとに、モジュール メタデータ、コンパイル時の依存関係、パッケージ化手順をビルドシステムに指示するための構成ファイルが必要です。Android では Soong ビルドシステムを使用してより簡単にテストを構成できるようになりました。
Soong では、ブループリント（.bp）ファイルが使用されます。これは、ビルドするモジュールに関する JSON に似た形式の単純な宣言的記述です。この形式は、以前のリリースで使用されていた Make ベースのシステムに代わるものです。詳細については、継続的インテグレーション ダッシュボードの Soong リファレンス ファイルをご覧ください。
カスタムテストを調整する場合、または Android 互換性テストスイート（CTS）を使用する場合は、複雑なテスト構成を使用します。
例
以下の説明では、ブループリント構成ファイルのサンプル（/platform_testing/tests/example/instrumentation/Android.bp）を使用します。
説明のため、スナップショットを以下に示します。
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
最初の android_test 宣言は、これがテストであることを示します。
代わりに android_app とすると、ビルド パッケージであることを示します。
設定
次の設定は説明を要します。
name: "HelloWorldTests",
android_test モジュール タイプが指定されている場合、name 設定が（ブロックの先頭に）必要です。この設定がモジュール名になり、生成される APK は同じ名前で接尾辞 .apk が付きます。この場合、生成されるテスト apk の名前は HelloWorldTests.apk です。また、モジュールの make ターゲット名も定義します。これにより、make [options]
<HelloWorldTests> を使用してテスト モジュールとすべての依存関係をビルドできます。
static_libs: ["androidx.test.runner"],
static_libs 設定は、指定されたモジュールのコンテンツを現在のモジュールで生成される apk に組み込むようビルドシステムに指示します。つまり、各名前付きモジュールは .jar ファイルを生成します。そのコンテンツはコンパイル時に classpath 参照の解決に使用され、生成される apk に組み込まれます。
androidx.test.runner モジュールは AndroidX テストランナー ライブラリ用に事前にビルドされています。これには、テストランナー AndroidJUnitRunner が含まれています。AndroidJUnitRunner は JUnit4 のテスト フレームワークをサポートしており、Android 10 の InstrumentationTestRunner に代わるものです。Android アプリのテストについて詳しくは、Android でアプリをテストするをご覧ください。
新しいインストルメンテーション モジュールを作成する場合、まずテストランナーとして androidx.test.runner ライブラリを使用する必要があります。プラットフォーム ソースツリーには、ub-uiautomator、mockito-target、easymock などの他の有用なテスト フレームワークも含まれています。
certificate: "platform",
certificate 設定は、コア プラットフォームと同じ証明書で apk に署名するようビルドシステムに指示します。これは、署名で保護された権限または API をテストで使用する場合に必要です。プラットフォームの継続的なテストには適していますが、CTS テスト モジュールでは使用しないでください。この例で証明書を設定しているのは説明のためにすぎません。この例のテストコードでテスト apk を特別なプラットフォーム証明書で署名する必要はありません。
システム サーバーの外部に存在するインストルメンテーションを作成する場合（通常のアプリ apk と同じようにパッケージ化されている場合）、システム イメージに組み込まれて特権アプリの可能性があることを除けば、インストルメンテーションがコンポーネントのアプリ パッケージ（マニフェストに関する以下のセクションを参照）をターゲットにしている可能性があります。この場合、アプリケーションの makefile には独自の certificate 設定があり、インストルメンテーション モジュールには同じ設定を保持する必要があります。これは、テスト対象アプリでインストルメンテーションをターゲットにするためであり、テスト apk とアプリ apk に同じ証明書で署名する必要があります。
それ以外の場合、この設定は必要ありません。ビルドシステムはビルド バリアントに基づいてデフォルトの組み込み証明書で署名するだけです。通常は dev-keys と呼ばれます。
test_suites: ["device-tests"],
test_suites 設定により、Trade Federation テストハーネスでテストを簡単に検出できるようになります。このテストを共有できるように、CTS などの他のスイートをここに追加できます。
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
詳細設定
次の詳細設定は説明を要します。
test_config: "path/to/hello_world_test.xml"
test_config 設定は、ビルドシステムに対して、テスト ターゲットに特定の設定が必要であることを通知します。デフォルトでは、Android.bp と同じディレクトリにある AndroidTest.xml がその設定に関連付けられています。
auto_gen_config: true
auto_gen_config 設定は、テスト設定を自動的に作成するかどうかを示します。Android.bp と同じディレクトリに AndroidTest.xml が存在しない場合、この属性を明示的に true に設定する必要はありません。
require_root: true
require_root 設定は、ビルドシステムに対して、自動生成されたテスト設定に RootTargetPreparer を追加するよう指示します。これにより、root 権限でテストが実行されます。
test_min_api_level: 29
test_min_api_level 設定は、ビルドシステムに対して、自動生成されたテスト設定に MinApiLevelModuleController を追加するよう指示します。Trade Federation がテスト構成を実行するとき、ro.product.first_api_level というデバイス プロパティが test_min_api_level よりも小さいと、テストはスキップされます。