从 2025 年 3 月 27 日起，我们建议使用 android-latest-release 而不是 aosp-main 来构建 AOSP 并为其做贡献。如需了解详情，请参阅AOSP 变更。

测试设置
使用合集保持井井有条根据您的偏好保存内容并进行分类。

测试套件

为了让测试成为 VTS 的一部分，它必须在 Android.bp 中具有以下设置。

test_suites: ["vts"],

此外，将测试添加到套件 general-tests 可使其成为预提交检查中使用的测试映射套件的一部分。

测试配置

在大多数情况下，测试配置（即 Trade Federation 用于运行 VTS 测试的 XML 文件）在 build 期间自动生成。但是，您可以自定义测试配置。

创建自定义的测试配置文件

从头开始创建新的测试 XML 文件可能很复杂，因为它涉及到理解测试框架的工作原理，以及每个测试运行程序之间的差异。自动生成的测试配置文件旨在简化此流程。

如果您必须自定义测试 XML 文件，可以使用自动生成的文件作为起点。

要找到自动生成的测试配置文件，请先运行 make 命令来构建配置，如下所示。

$ m VtsHalUsbV1_1TargetTest

在您的 build 输出目录中，您可以根据模块名称搜索配置文件，如下所示。

$ find out/ -name VtsHalUsbV1_1TargetTest.config

该文件可能存在多个副本，您可以使用任意副本。将 .config 文件复制到 Android.bp 文件所在的目录。

如果 Android.bp 文件中只有一个测试模块，您可以将 XML 文件重命名为 AndroidTest.xml，build 系统会自动将其用作测试模块的配置文件。否则，请向模块添加 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 设置允许测试以 3 分钟的超时时间运行，而不是默认的 1 分钟。

   <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.vendor.api_level，它通过使用 ro.product.first_api_level、ro.board.first_api_level 和 ro.board.api_level 属性计算所需的供应商 API 级别来自动设置。

有关更多详细信息，请参阅供应商 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

它将在设备上的 vendor/build.prop 中自动定义 ro.board.first_api_level 属性。该属性由供应商 init 进程设置。

ro.board.api_level

ro.board.api_level 属性是供应商映像的当前供应商 API 级别，其格式为 YYYYMM，表示供应商 API 冻结的时间。它由构建系统自动设置。

ro.vendor.api_level

ro.vendor.api_level 属性在 Android 13 中引入，用于显示供应商映像需要支持的 API 级别。如果 ro.board.first_api_level 存在且 ro.board.api_level 设置为早于 ro.product.first_api_level 的 API 级别，则此属性会自动设置为 ro.product.first_api_level 或 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 ...

测试设置 使用合集保持井井有条 根据您的偏好保存内容并进行分类。