モジュール構成の全体的な構造は、通常のTradefed XML構成と同様のパターンに従いますが、スイートの一部として実行されるため、いくつかの制限があります。
許可されたタグのリスト
AndroidTest.xmlまたはより広義のモジュール構成には、 target_preparer 、 multi_target_preparer 、 test 、 metrics_collectorのXMLタグのみを含めることができます。
このリストには制限があるように見えますが、テストモジュールのセットアップのニーズと実行するテストを正確に定義できます。
注：さまざまなタグの復習が必要な場合は、 TradefedXML構成を参照してください。
build_providerやresult_reporterなどのオブジェクトをモジュール構成内から実行しようとすると、 ConfigurationExceptionが発生します。これは、これらのオブジェクトがモジュール内から実際に何らかのタスクを実行することを期待しないようにするためのものです。
モジュール構成の例
<configuration description="Config for CTS Gesture test cases">
<option name="test-suite-tag" value="cts" />
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsGestureTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.gesture.cts" />
<option name="runtime-hint" value="10m50s" />
</test>
</configuration>
この構成では、 CtsGestureTestCases.apkをインストールする必要があり、 android.gesture.ctsパッケージに対してインストルメンテーションを実行するテストについて説明します。
「metrics_collector」タグの特殊なケース
metrics_collectorは許可されていますが、モジュール用にプルおよびログに記録される特定のファイルまたはディレクトリーを指定するために、 FilePullerLogCollectorクラスに制限されています。これは、ログを特定の場所に残し、それらを自動的に回復したい場合に役立ちます。
構成例：
<configuration description="Config for CTS UI Rendering test cases">
<target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
<option name="cleanup-apks" value="true" />
<option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
</target_preparer>
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="android.uirendering.cts" />
<option name="runtime-hint" value="11m55s" />
<option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
<option name="isolated-storage" value="false" />
</test>
<!-- Collect the files in the dump directory for debugging -->
<metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
<option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
<option name="collect-on-run-ended-only" value="true" />
</metrics_collector>
</configuration>
ビルド情報やダウンロードはどうですか？
許可されたタグの定義は、モジュールがビルド情報を取得しないという誤った印象を与える可能性があります。これは真実ではありません。
ビルド情報はスイートレベルのセットアップから提供され、スイートのすべてのモジュールで共有されます。これにより、スイートのすべてのモジュール部分を実行するために、スイートの単一のトップレベルセットアップが可能になります。
たとえば、各互換性テストスイート（CTS）モジュールがデバイス情報やタイプなどを個別にクエリする代わりに、CTSスイートレベルのセットアップ（ cts.xml ）が1回実行し、各モジュールが要求した場合にその情報を受け取ります。
モジュール内のオブジェクトがビルド情報を受信するには、通常のTradefed構成の場合と同じように実行する必要がありますIBuildReceiverインターフェイスを実装してIBuildInfoを受信します。詳細については、デバイスを使用したテストを参照してください。
メタデータフィールド
多数のテストモジュールには、それぞれに固有の目標を持ついくつかのmetadata仕様が含まれています。
例：
<option name="config-descriptor:metadata" key="component" value="framework" />
<option name="config-descriptor:metadata" key="parameter" value="instant_app" />
<option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
<option name="config-descriptor:metadata" key="parameter" value="secondary_user" />
成分
componentのメタデータは、モジュールがテストする予定の一般的なAndroidコンポーネントを記述します。テストの実行に直接的な影響はありません。これは主に組織的な目的で使用されます。
CTSで許可されているコンポーネントの最新リストは、 CtsConfigLoadingTestで入手できます。存在しないコンポーネントがCTSモジュールに追加された場合、このテストは事前送信で失敗します。
module-metadata-include-filterおよびmodule-metadata-exclude-filterを使用して、コンポーネントに基づいてスイートの実行をフィルタリングできます。
例：
--module-metadata-include-filter component framework
この例では、 frameworkコンポーネントで注釈が付けられたテストモジュールのみを実行します。
パラメータ
parameterメタデータは情報提供であり、テストの実行に影響を与えます。テストモジュールが適用されるAndroidモードを指定します。この場合、モードは、 instant apps 、 secondary users 、 different abisなどの高レベルのAndroidモードに制限されます。
スイートの実行中に、モードがテストに適用される場合、モードに基づいてテストモジュールのいくつかのバリエーションが作成されます。各バリエーションは同様のテストを実行しますが、モードは異なります。
-
instant_app：APKをインスタントアプリとしてインストールするテストのバリエーションを作成します。 -
multi_abi：デバイスでサポートされているABIごとにテストのバリエーションを作成します。 -
secondary_user：APKをインストールし、セカンダリユーザーとしてテストを実行するテストのバリエーションを作成します。