テストスイート
テストが VTS の一部である場合は、Android.bp で次の設定を行う必要があります。
test_suites: ["vts"],
さらに、テストスイート general-tests にテストを追加すると、テストが presubmit チェックで使用されるテスト マッピング スイートの一部として構成されます。
テスト構成
ほとんどの場合、テスト構成（VTS テストを実行するために Trade Federation が使用する XML ファイル）がビルド中に自動生成されます。ただし、テスト構成はカスタマイズできます。
カスタマイズされたテスト構成ファイルを作成する
新しいテスト XML ファイルを一から作成するのは、テストハーネスの動作や各テストランナーの相違について理解する必要があることから、手順が複雑になる可能性があります。自動生成されるテスト構成ファイルは、このプロセスを容易にすることを目的としたものです。
テスト XML ファイルをカスタマイズする必要がある場合は、自動生成されるファイルから一連の手順を開始できます。
自動生成されたテスト構成ファイルを確認するには、まず、以下に示すように make コマンドを実行して構成をビルドします。
$ m VtsHalUsbV1_1TargetTest
以下のように、ビルド ディレクトリでモジュール名に基づいて構成ファイルを検索できます。
$ find out/ -name VtsHalUsbV1_1TargetTest.config
ファイルのコピーは複数作成でき、作成したファイルのうち任意のファイルを使用できます。.config ファイルを Android.bp ファイルがあるディレクトリにコピーします。
Android.bp ファイルに格納されているテスト モジュールが 1 つのみである場合は、XML ファイルの名前を AndroidTest.xml に変更します。ビルドシステムは、自動的にこのファイルをテスト モジュールの構成ファイルとして使用します。このように処理しない場合は、以下の例に示すように、モジュールに test_config 属性を追加します。
test_config: "VtsHalUsbV1_1TargetTest.xml",
これで、カスタマイズを実装するために処理するテスト構成ファイルが用意できました。
テストが adb root で実行されるように設定する
ほとんどの VTS テストを実行するには、root 権限が必要です。テスト構成ファイルが自動生成されている場合は、次の属性を Android.bp に追加できます。
require_root: true,
テスト構成ファイルがカスタマイズされている場合は、テスト XML ファイルに次のコマンドを追加します。
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
テスト中にフレームワークを停止する
多くの VTS テストでは Android フレームワークの実行を必要としません。また、フレームワークの停止状態でテストを実行することによって、デバイスの不安定な状態に影響を受けることなく、テストを安定的に実行できます。テスト構成ファイルが自動生成されている場合は、次の属性を Android.bp に追加できます。
disable_framework: true,
テスト構成ファイルがカスタマイズされている場合は、テスト XML ファイルに次のコマンドを追加します。
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
その他のテスト引数を追加する
一部の gtest テストは実行に時間を要する場合があります。そのような場合には、XML ファイルにテストランナー オプションを追加できます。
たとえば、次のエントリの native-test-timeout 設定では、デフォルトの 1 分ではなく 3 分間のタイムアウトでテストを実行できます。
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
最小 API レベルを必須にする
一部の VTS テストは、最小 API レベルの要件を満たすデバイスでのみ実行できます。テスト構成ファイルが自動生成されている場合は、次の属性を Android.bp に追加できます。
min_shipping_api_level: 29,
または
vsr_min_shipping_api_level: 202404,
テスト構成ファイルがカスタマイズされている場合は、テスト XML ファイルに次のコマンドを追加します。
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
または
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
<option name="vsr-min-api-level" value="202404" />
</object>
API レベル プロパティ
Android 12 では、ro.board.first_api_level プロパティと ro.board.api_level プロパティが定義されています。これにより、これらのデバイスのベンダー イメージの API レベルが示されます。これらのプロパティを ro.product.first_api_level と組み合わせることで、テストスイートはデバイスに適したテストケースを選択します。
Android 13 では、ro.product.first_api_level、ro.board.first_api_level、ro.board.api_level プロパティを使用して必要なベンダー API レベルを計算することにより自動的に設定される ro.vendor.api_level が定義されています。
詳細は、ベンダー API レベルをご覧ください。
ro.board.first_api_level
ro.board.first_api_level プロパティは、このプロパティでベンダー フリーズの対象となる SoC のベンダー イメージが最初にリリースされたときの API レベルです。デバイスのリリース時の API レベルには依存せず、この値を定義する SoC の最初の API レベルにのみ依存します。この値は、SoC の耐用期間中は永続的に使用されます。
ro.board.first_api_level を設定するには、デバイス メーカーが device.mk ファイルで BOARD_SHIPPING_API_LEVEL を定義します。次に例を示します。
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
これにより、デバイスの ro.board.first_api_level プロパティが vendor/build.prop に自動的に定義されます。このプロパティは、ベンダーの init プロセスによって設定されます。
ro.board.api_level
ro.board.api_level プロパティはベンダー イメージの現在のベンダー API レベルで、ベンダー API のフリーズ時の YYYYMM 形式が含まれます。これはビルドシステムで自動的に設定されます。
ro.vendor.api_level
ro.vendor.api_level プロパティは、ベンダー イメージがサポートする必要がある API レベルを示すために Android 13 で導入されました。これは ro.product.first_api_level に自動的に設定されます。または、ro.board.first_api_level が存在し、ro.board.api_level が ro.product.first_api_level よりも前の API レベルに設定されている場合は ro.board.api_level に設定されます。バージョンが ro.product.first_api_level の 35 以上のバージョンに設定されている場合は、対応するベンダー API レベルに置き換えられます。ベンダー イメージのアップグレードを必要とするベンダー実装のテストは、このプロパティを参照することで、SoC のベンダー要件から除外される場合があります。
VTS を使用したシャーディング プロセス
Android バージョン 10 以降の場合は、以下に示す手順に沿って VTS と CTS-on-GSI の両方のプランでテストしながら、複数のデバイスでシャーディング プロセスを実行できます。
run vts --shard-count <number of devices> -s <device serial> ...
このコマンドは、VTS プランをシャードに分割し、複数のデバイスで実行します。
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
このコマンドは、CTS-on-GSI プランを分割し、複数のデバイスで実行します。