兼容性测试套件 (CTS) 是一个免费的商业级测试套件,可在此处下载。CTS 代表兼容性的“机制”。
CTS 可在桌面设备上运行,并直接在所连接的设备或模拟器上执行测试用例。CTS 是一套单元测试,可以集成到工程师构建设备的日常工作流程(例如通过连续构建系统)。其目的是尽早发现不兼容性,并确保软件在整个开发过程中保持兼容性。
CTS 是一个自动化测试套件,它使用两个主要软件组件:
CTS 验证程序是一款手动测试工具,包含以下软件组件:
在 DUT 上执行并收集结果的 CTS 验证程序应用。
在桌面设备上执行,以便为 CTS 验证程序应用中的某些测试用例提供数据或额外控制的可执行文件或脚本。
上图总结了 CTS 工作流程。有关详细说明,请参阅本部分从设置开始的子页面。
CTS 包含以下类型的测试用例:
CTS 的未来版本将包含以下类型的测试用例:
单元测试用例涵盖以下领域,以确保兼容性:
领域 | 说明 |
---|---|
签名测试 | 每个 Android 版本中都包含一个 XML 文件,用于描述该版本中包含的所有公共 API 的签名。CTS 包含一个实用工具,用于根据设备上可用的 API 检查这些 API 签名。签名检查的结果会记录在测试结果 XML 文件中。 |
平台 API 测试 | 按照 SDK 类索引所述内容来测试平台(核心库和 Android 应用框架)的 API,以确保 API 的正确性,包括正确的类、属性、方法签名以及正确的方法行为;此外还需进行负面测试,以确保不正确的参数处理产生预期行为。 |
Dalvik 测试 | 这类测试侧重于测试 Dalvik 可执行格式的文件。 |
平台数据模型 | CTS 会测试通过内容提供程序(如 SDK android.provider 软件包中所述)提供给应用开发者的核心平台数据模型:联系人、浏览器、设置等。 |
平台 Intent | CTS 会测试核心平台 Intent(如 SDK 可用 Intent 中所述)。 |
平台权限 | CTS 会测试核心平台权限(如 SDK 可用权限中所述)。 |
平台资源 | CTS 会测试核心平台资源类型(如 SDK 可用资源类型中所述)的处理是否正确。这包括对以下资源的测试:简单值、可绘制资源、九宫格、动画、布局、样式和主题背景,以及加载备用资源。 |
如果被测设备 (DUT) 支持蓝牙 LE 功能,为了对 DUT 进行蓝牙 LE 扫描测试,应在距离 DUT 不超过五米的范围内放置至少三个蓝牙 LE 信标。可以放置任何类型且不需要进行配置或发射任何特定信号的信标,这些信标可以是 iBeacon、Eddystone 或者模拟 BLE 信标的设备。
在运行相机 CTS 时,建议您使用正常光照条件,并且测试图案图表(例如棋盘图案)不要与镜头靠得太近(具体距离取决于设备的最小焦距)。
如果 DUT 支持外部相机(如 USB 网络摄像头),则在运行 CTS 时必须将外部相机接上电源,否则 CTS 测试将失败。
如果 DUT 支持全球定位系统 (GPS)/全球导航卫星系统 (GNSS) 功能,则应该以合适的信号电平向 DUT 提供 GPS/GNSS 信号(GPS 部分符合 ICD-GPS-200C 标准),以便其接收到相应信号并计算 GPS 位置。GPS/GNSS 信号源的种类不限(可以是卫星模拟器,也可以是室外 GPS/GNSS 信号中继器),只需将 DUT 放在距离窗口足够近的位置以使其可以直接接收到足够强的 GPS/GNSS 信号即可。
请注意:在进行 GPS 测试时,请确保互联网连接设置未屏蔽 supl.google.com 的 7276 端口的连接。该端口将用于下载 GPS 辅助数据,以便在本地设备上测试位置计算。
CTS 测试需要满足以下要求的 WLAN 网络:支持 IPv6,可以将被测设备 (DUT) 视为隔离客户端,并可以连接到互联网。隔离客户端是一种配置,可使 DUT 无法接收子网络上的广播/多网消息;这种配置可通过 WLAN AP 配置或通过在未连接其他设备的隔离子网络上运行 DUT 来实现。
如果您无法访问原生 IPv6 网络、IPv6 运营商网络或 IPv6 VPN,以致无法通过基于 IPv6 的一些测试,则可以改为使用 WLAN 接入点和 IPv6 隧道。请参阅维基百科 IPv6 隧道代理列表。
Android 9 针对 WLAN RTT 功能增加了一个 API,此 API 允许设备测量自身与接入点之间的距离(误差幅度在 1 到 2 米内),可以显著提高室内位置信息精确度。下面推荐两款支持 WLAN RTT 的设备:Google Wifi 和 Compulab 的 Filet2 接入点 (带宽为 40MHz,频段为 5GHz)。
接入点应接通电源,但无需连接到任何网络。接入点无需紧挨着测试设备,但建议放置在距离 DUT 40 英尺的范围内。通常情况下,一个接入点就足够了。
注意:CTS 目前支持 64 位 Linux 和 Mac OS 主机。CTS 无法在 Windows 操作系统上运行。
运行 CTS 之前,请确保已安装最新版本的 Android 调试桥 (adb) 和 Android 资源打包工具 (AAPT),并已将这两个工具的位置添加到计算机的系统路径中。
要安装 ADB,请下载适用于您的操作系统的 Android SDK 工具包,打开它,然后按照附带的 README 文件中的说明进行操作。要了解问题排查相关信息,请参阅安装独立 SDK 工具。
确保 adb
和 aapt
位于您的系统路径下。以下命令假定您已在主目录中打开了软件包归档文件:
export PATH=$PATH:$HOME/android-sdk-linux/build-tools/<version>
注意:请确保起始路径和目录名称均准确无误。
安装正确版本的 Java 开发套件 (JDK)。对于 Android 7.0 -
如需了解详情,请参阅 JDK 要求。
下载并打开与您设备的 Android 版本以及您的设备支持的所有应用二进制接口 (ABI) 相匹配的 CTS 包。
下载并打开最新版本的 CTS 媒体文件。
请按照相应的步骤设置您的系统以检测设备,例如为 Ubuntu Linux 创建 udev
规则文件。
兼容的设备被定义为具有 user/release-key 签名版本的设备,因此您的设备应运行基于代号、标签和版本号中已知兼容的用户版本(Android 4.0 及更高版本)的系统映像。
注意:使用 CTS 确认最终系统映像的 Android 兼容性时,您必须在具有用户版本的设备上执行 CTS。
某些 CTS 要求取决于设备最初搭载的版本。例如,如果设备最初搭载的是较低的版本,则不一定需要遵循适用于搭载较高版本的设备的系统要求。
为了保证 CTS 可读取到这些信息,设备制造商可以定义编译时属性:ro.product.first_api_level
。该属性的值是对该设备进行商业化发布时所采用的初始 API 级别。
如果选择在现有产品中重复使用常用的底层实现,设备制造商可以将新产品作为同一设备组中现有产品的升级版来发布。设备制造商可以选择将现有产品的 API 级别设置为 ro.product.first_api_level
,以对 CTS 和 Treble/VTS 应用升级要求。
设备制造商可以将 PRODUCT_PROPERTY_OVERRIDES
添加到其 device.mk 文件中以设置此属性,具体如以下示例所示:
#ro.product.first_api_level indicates the first api level that the device has
been commercially launched on.
PRODUCT_PROPERTY_OVERRIDES +=\
ro.product.first_api_level=21
Android 9 及更高版本的初始 API 级别
如果设备搭载的是 Android 9 或更高版本,请将属性 ro.product.first_api_level
设置为代号、标记和细分版本号上提供的有效值。
Android 8.x 及更低版本的初始 API 级别
对于搭载 Android 8.x 或更低版本的设备,请为产品的第一个版本取消设置(移除)属性 ro.product.first_api_level
。对于所有后续版本,请将 ro.product.first_api_level
设置为正确的 API 级别值。这样一来,该属性便可以正确标识新产品,关于产品初始 API 级别的信息也将得以保留。如果标记处于未设置状态,则 Android 会将 Build.VERSION.SDK_INT
分配给 ro.product.first_api_level
。
Android 7.0 包含以下预编译的应用(根据此处的源代码编译),这些应用不包含除清单以外的任何代码:
/system/app/CtsShimPrebuilt.apk
。/system/priv-app/CtsShimPrivPrebuilt.apk
。CTS 会使用这些应用来测试特权和权限。要通过测试,您必须将应用预加载到系统映像上的相应目录下,但不能对它们重新签名。
Android 9 中引入了 Open Mobile API。如果设备计划基于多个安全元件生成报告,为了验证 Open Mobile API 的行为,CTS 会添加相应的测试用例。使用这些测试用例时,需要在被测设备 (DUT) 的嵌入式安全元件 (eSE) 或 DUT 所使用的 SIM 卡中安装一次示例小程序。可以在 AOSP 存储库中找到 eSE 示例小程序和 SIM 示例小程序。
要详细了解 Open Mobile API 测试用例和访问控制测试用例,请参阅安全元件的 CTS 测试。
CTS 媒体压力测试要求将视频剪辑存放在外部存储设备 (/sdcard) 上。大部分剪辑来自 Big Buck Bunny,剪辑版权归 Blender Foundation 所有并采用知识共享署名 3.0 许可。
所需空间取决于设备支持的最高视频播放分辨率(要查看所需分辨率的平台版本,请参阅兼容性定义文档中的第 5 部分)。请注意,被测设备的视频播放功能将通过 android.media.CamcorderProfile
API(针对早期 Android 版本)和 android.media.MediaCodecInfo.CodecCapabilities
API(针对 Android 5.0 及更高版本)进行检测。
以下是按最大视频播放分辨率列出的存储空间要求:
任何没有嵌入式屏幕的设备一律需要连接到屏幕。
如果设备具有存储卡插槽,请插入空的 SD 卡。请使用支持超高速 (UHS) 总线且具有 SDHC 或 SDXC 容量的 SD 卡,或使用至少具有 Class 10 速度的 SD 卡,以确保设备能够通过 CTS。
警告:CTS 可能会修改/清空插入设备的 SD 卡上的数据。
如果设备具有 SIM 卡插槽,请将激活的 SIM 卡插入每个插槽。如果设备支持短信,则应填充每个 SIM 卡的号码字段。
为了执行 CTS 运营商 API 测试,该设备需要使用运营商授权的 SIM 卡。请参阅准备 UICC。
将设备恢复出厂设置:设置 > 备份和重置 > 恢复出厂设置
警告:这将清空设备中的所有用户数据。
将设备的语言设置为英语(美国):设置 > 语言和输入法 > 语言
如果设备具有 GPS 或 WLAN/移动网络功能,则打开位置信息设置:设置 > 位置信息 > 开启
连接到满足以下要求的 WLAN 网络:支持 IPv6、可以将被测设备 (DUT) 视为隔离客户端(请参阅上文的物理环境部分),并可连接到互联网。连接网络的具体操作方法为:设置 > WLAN
确保设备上未设置锁定图案或密码:设置 > 安全 > 屏幕锁定 > 无
在设备上启用 USB 调试:设置 > 开发者选项 > USB 调试。
注意:在 Android 4.2 及更高版本中,默认情况下会隐藏开发者选项。要显示这些选项,请依次转到设置 > 关于手机,然后点按版本号七次。返回上一屏幕以查找开发者选项。要查看其他详细信息,请参阅启用设备上的开发者选项。
确保将时间设置为 12 小时格式:设置 > 日期和时间 > 使用 24 小时制 > 关闭
依次选择:设置 > 开发者选项 > 不锁定屏幕 > 开启
依次选择:设置 > 开发者选项 > 允许模拟位置 > 开启
注意:此模拟位置设置仅适用于 Android 5.x 和 4.4.x。
依次选择:设置 > 开发者选项 > 通过 USB 验证应用 > 关闭
注意:此验证应用步骤在 Android 4.2 中为必需步骤。
启动浏览器并关闭任何启动/设置屏幕。
使用 USB 数据线连接用于测试设备的台式机
注意:将运行 Android 4.2.2 或更高版本的设备连接到计算机时,系统会显示一个对话框,询问您是否接受允许通过此计算机进行调试的 RSA 密钥。选择“允许 USB 调试”。
在设备上安装和配置帮助程序应用。
注意:对于 CTS 2.1 R2 - 4.2 R4 的版本,请通过以下命令设置您的设备(或模拟器),以便执行无障碍测试:
adb install -r android-cts/repository/testcases/CtsDelegatingAccessibilityService.apk
在设备上,依次启用:设置 > 无障碍 > 无障碍 > Delegating Accessibility Service
注意:对于 7.0 之前的 CTS 版本,请在声明 android.software.device_admin 的设备上设置您的设备,以使用以下命令执行设备管理测试:
adb install -r android-cts/repository/testcases/CtsDeviceAdmin.apk
依次点击“设置”>“安全”>“选择设备管理器”,然后启用两个 android.deviceadmin.cts.CtsDeviceAdminReceiver*
设备管理器。确保 android.deviceadmin.cts.CtsDeviceAdminDeactivatedReceiver
和任何其他预加载的设备管理器均保持停用状态。
将 CTS 媒体文件复制到设备上,如下所示:
注意:对于 CTS 2.3 R12 及更高版本,如果设备支持视频编解码器,则必须将 CTS 媒体文件复制到设备上。
chmod u+x copy_media.sh
copy_media.sh
:
./copy_media.sh 720x480
./copy_media.sh all
,以便复制所有文件。./copy_media.sh 720x480 -s 1234567
您可以参阅 Trade Federation 概述,了解有关 Trade Federation(简称 tradefed 或 TF)持续测试框架的说明。
运行测试计划的操作如下:
至少连接一个设备。
在开始运行 CTS 时,按主屏幕按钮将设备设置为显示主屏幕。
当设备在运行测试时,不能执行任何其他任务,并且必须保持静止状态(以免触发传感器活动),同时要让相机指向某个可以聚焦的对象。
在运行 CTS 时,不要按设备上的任何键。按测试设备上的键或触摸其屏幕会干扰正在运行的测试,并且可能导致测试失败。
通过运行解压缩 CTS 包所得文件夹中的 cts-tradefed 脚本(例如 $ ./android-cts/tools/cts-tradefed
)启动 CTS 控制台。
通过附加以下命令启动默认测试计划(包含所有测试包):run cts --plan CTS
。这将启动测试兼容性所需的所有 CTS 测试。
或者,您也可以使用以下命令,从命令行中运行所选的 CTS 计划:cts-tradefed run cts --plan
注意:您可以通过使用 run cts-dev 命令(而非 run cts)来缩减在 Android 7.0 (Nougat) 及更高版本中的运行时间。此命令会跳过前提条件、设备信息收集和所有系统状态检查工具。它还仅在单个 ABI 上运行测试。对于设备验证,请忽略此优化操作并添加所有前提条件和检查。
查看控制台中报告的测试进度和结果。
如果您的设备搭载的是 Android 5.0 或更高版本,并且声明支持 ARM 和 x86 ABI,则 ARM 和 x86 CTS 包都应运行。
(可选)利用套件重试功能重新运行测试的以前会话:
使用以下命令查看以前的会话:
cts-tf > l r
确定您需要的会话编号,并将其代入以下命令中:
cts-tradefed run retry --retry <session-number>
若要详细了解如何实现重试功能,请参阅 Trade Federation 的套件重试页面。
对于 Android 7.0 或更高版本,您将使用 CTS v2。
您可以选择以下测试计划:
其他可用配置如下:
所有这些计划和配置都可以使用 run cts 命令执行。
对于 Android 6.0 或更早版本,您将使用 CTS v1。
我们在CTS中添加了可以使媒体测试模块通过以下方式运行的功能:
将内容加载到被测设备(DUT)SD卡上。
将媒体文件托管在CTS的本地服务器上。
将媒体文件托管在用于执行测试套件的主机上。
CTS可以连接到合作伙伴,本地或第三方服务器。 CTS无法连接到Google服务器。
下载文件如下所示。
CtsMediaTestCases模块支持SD卡方法和本地服务器托管方法。
将文件复制到设备SD卡上,然后使用以下命令运行模块。
$adb push CtsMediaTestCases /sdcard/
将android-cts-media-1.5文件夹移至主机的/ tmp /文件夹中。
单模块运行
$run cts -m CtsMediaTestCases --dynamic-config-url
https://storage.googleapis.com/cts_media/DynamicConfig_local.json --shard-count 6
这将从dl.google.com
上的images
文件夹下载文件。如果要使用android-cts-media-1.5.zip
的本地images
文件夹,请使用以下命令:
$run cts -m CtsMediaTestCases --module-arg
CtsMediaTestCases:config-url: https://storage.googleapis.com/cts_media/DynamicConfig_local.json --
module-arg CtsMediaTestCases:local-media-path:/tmp/android-cts-media -1.5 --shard-count 6
完整的CTS运行(SD卡上的CtsMediaTestCases)
$run cts --module-arg CtsMediaTestCases:config-url:
https://storage.googleapis.com/cts_media/DynamicConfig_local.json --module-arg CtsMediaTestCases:
local-media-path:/tmp/android-cts-media-1.5 --shard-count 6
您可以使用自定义本地服务器路径替换默认的JSON配置路径。
单模块运行
$run cts -m CtsMediaTestCases --dynamic-config-url
https://storage.googleapis.com/cts_media/DynamicConfig.json
这将从dl.google.com上的images文件夹下载文件。如果要使用android-cts-media-1.5.zip的本地images文件夹,请使用以下命令:
$run cts -m CtsMediaTestCases --module-arg CtsMediaTestCases:
config-url: https://storage.googleapis.com/cts_media/DynamicConfig.json --module-arg
CtsMediaTestCases:local-media-path:/tmp/android-cts-media-1.5 --shard-count 6
完整的CTS运行(SD卡上的CtsMediaTestCases)
$run cts --module-arg CtsMediaTestCases:config-url:
https://storage.googleapis.com/cts_media/DynamicConfig.json --module-arg CtsMediaTestCases:
local-media-path:/tmp/android-cts-media-1.5 --shard-count 6
您可以对主机上的所有三个模块运行CTS媒体测试。
单独或一起运行模块
注意:这不能运行完整的CTS。
运行以下命令以分别运行模块。
$run cts -m CtsMediaTestCases
--module-arg CtsMediaTestCases:
local-media-path:/tmp/android-cts-media-1.5 --shard-count 6
运行以下命令以同时运行所有模块。
$run cts --include-filter CtsMediaTestCases --module-arg CtsMediaTestCases:local-media-path:
/tmp/android-cts-media-1.5 --include-filter CtsMediaStressTestCases --module-arg
CtsMediaStressTestCases:local-media-path:/tmp/android-cts-media-1.5 --include-filter
CtsMediaBitstreamsTestCases --module-arg CtsMediaBitstreamsTestCases:local-media-path:
/tmp/android-cts-media-1.5 --shard-count 6
全面运行CTS(带有单独的模块参数)
$run cts --module-arg CtsMediaTestCases:local-media-path:
/tmp/android-cts-media-1.5 --module-arg CtsMediaStressTestCases:local-media-path:
/tmp/android-cts-media-1.5 --module-arg CtsMediaBitstreamsTestCases:local-media-path:
/tmp/android-cts-media-1.5 --shard-count 6
注意:对于Android 6.0或更低版本,请参阅CTS v1命令控制台。
对于Android 7.0或更高版本,请使用CTS v2。
可用的测试计划包括以下内容:
其他可用配置包括:
所有这些计划和配置都可以通过run cts命令执行。
对于 Android 6.0 及更低版本,请使用 CTS v1。
您可以选择以下测试计划:
您可以使用 run cts
命令执行这些测试。
免安装应用是 Android 10 的一项重要功能,因此必须确保这些应用能够正常运行。免安装应用是隐式安装的,因此它们具有的功能有限,并需要在限制更多的安全沙盒中运行。由于这些限制普遍存在,因此系统的任何部分都存在无法正常运行免安装应用的风险。为此,我们创建了一个 CTS 测试子集来确保免安装应用允许的行为正常运作。核心理念就是,尽可能少隔离要移植的测试组,从而最大限度地限制 CTS 大小的增长。在免安装应用模式下运行 CTS,意味着将测试 APK 作为免安装应用进行安装并运行测试。
免安装应用并非由用户安装,因此它们需要在受限沙盒中运行,并受到以下限制:
此外,免安装应用还必须选择允许新的安全沙盒添加更多限制。免安装应用的这类特殊行为广泛存在于整个平台上,因此需要一种方法来验证免安装应用是否能在生态系统中的所有设备上按预期运行。
并非所有 CTS 模块都包含适用于免安装应用的测试。如果模块所测试的功能需要和系统服务器进行交互,则这些测试应在免安装应用模式下运行。例如,OpenGL 测试不会和系统服务器进行交互,因此无需在免安装应用模式下运行,而无障碍功能测试需要和系统服务器进行交互,因此需要在免安装应用模式下运行。
用户除了需要确定哪些模块适用之外,还需要确定这些模块中的哪些测试适用。例如,测试可插拔架构(例如 AccessibilityService)的服务特定行为不适用于免安装应用模式,因为免安装应用无法向其他应用(包括平台)公开服务,而验证应用端行为的测试则适用于免安装应用模式。再比如,如果某个免安装应用无法拥有某项权限,则可通过测试来验证此权限背后的行为是否可在免安装应用模式下运行。有一组仅适用于免安装应用的测试,可用于验证与此类应用的行为方式(例如,不公开服务或看不到其他应用)有关的规则。通常,这些测试已经编写好,且不需要移植。
如果测试因验证免安装应用无法访问的功能而失败,则表示该测试不适用于免安装应用模式。您可以使用 @AppModeFull 注释测试,将其标记为仅可在完整应用模式下运行。您可以在类级别应用此注释,以排除该类中的所有测试。
如果测试因免安装应用可以访问的某项功能被破坏而失败,请提交错误。
如果您的测试失败并且系统显示“Failed to install MyCtsModule.apk on DEVICE. Reason: ‘-116’”消息,请在 logcat 上查找 PackageManager 消息。例如,如果系统显示“Can’t replace Full App with Instant App: your_app”消息,则 adb 会先卸载您的应用。
Android 兼容性测试套件验证程序(CTS 验证程序)是对兼容性测试套件 (CTS) 的补充。CTS 能够对那些可进行自动化测试的 API 和功能进行测试,而 CTS 验证程序则可以针对必须依赖于手动操作才能在固定设备上进行测试的 API 和功能(例如音频质量、触摸屏、加速度计、相机等)提供测试。
在运行 CTS 验证程序之前,请确保您具有以下设备:
要设置 CTS 验证程序测试环境,请执行以下操作:
adb install -r -g CtsVerifier.apk
点按 DUT 上的 CTS 图标,启动 CTS 验证程序应用: 图 1. CTS 验证程序图标
该应用会显示适用于手动验证的多个测试集: 图 2. CTS 验证程序测试菜单。
每项测试均包含一组共同元素(信息、通过、失败):图 3. 测试元素。
注意:在某些测试中,系统会自动确认测试结果为通过/失败。
一些测试(例如 USB 配件模式和相机校准测试)需要额外的测试设置和说明(详见以下各部分)。
为了运行 USB 配件测试,您需要一台 Linux 计算机来运行 USB 台式机(主机)程序。
将 DUT 连接到 Linux 计算机。
在计算机上执行 cts-usb-accessory
程序(存放在 CTS 验证程序包中):
./cts-usb-accessory
转到 CTS 验证程序应用中的 USB 配件测试。
在计算机上,查看控制台的输出。输出示例:
CTS USB Accessory Tester
Found possible Android device (413c:2106) - attempting to switch to accessory
mode...
Failed to read protocol version
Found Android device in accessory mode (18d1:2d01)...
[RECV] Message from Android device #0
[SENT] Message from Android accessory #0
[RECV] Message from Android device #1
[SENT] Message from Android accessory #1
[RECV] Message from Android device #2
[SENT] Message from Android accessory #2
[RECV] Message from Android device #3
[SENT] Message from Android accessory #3
[RECV] Message from Android device #4
[SENT] Message from Android accessory #4
[RECV] Message from Android device #5
[SENT] Message from Android accessory #5
[RECV] Message from Android device #6
[SENT] Message from Android accessory #6
[RECV] Message from Android device #7
[SENT] Message from Android accessory #7
[RECV] Message from Android device #8
[SENT] Message from Android accessory #8
[RECV] Message from Android device #9
[SENT] Message from Android accessory #9
[RECV] Message from Android device #10
[SENT] Message from Android accessory #10
使用视野校准程序以适中的精确度快速确定设备的视野。
设置测试环境:
设置目标宽度:
检查设备和目标是否均放在图中所示的位置,以及是否在设置对话框中输入了正确的距离。在预览中,图片上会叠加显示一条垂直线;该垂直线应与目标图案的中心线对齐。透明网格可与其他垂直线配合使用,以确保光轴与目标正交。
运行校准测试:
导出结果
完成所有测试后,您可以将结果另存为报告并下载到计算机上。报告名称会自动加上时间戳(基于 DUT 系统时间)。
点按**保存(磁盘)**图标。图 6. CTS 验证程序保存图标。
注意:Android 7.0 及更高版本不包含预览功能。
等待弹出消息显示报告保存的路径(例如 /sdcard/verifierReports/ctsVerifierReport-date-time.zip)
,然后记录该路径。图 7. CTS 验证程序报告保存的路径。
将 DUT 连接到 Linux 计算机。
通过在 Linux 计算机上安装的 Android SDK,使用 adb pull CTSVerifierReportPath
在已连接的设备中下载报告。
对于 Android 7.x 及更高版本,请使用以下命令下载所有报告:
adb pull /sdcard/verifierReports
对于 Android 6.0 及更早版本,请使用以下命令下载所有报告:
adb pull /mnt/sdcard/ctsVerifierReports/
要清除通过/失败结果,请在 CTS 验证程序应用中选择这些结果,然后依次选择“菜单”>“清除”。
这套新测试需要人为干预,并会用到一些外部硬件,包括音频环回加密狗、USB 参照麦克风和外部扬声器。对于没有 3.5 毫米 (⅛") 耳机接口的设备,用户可以跳过相应测试并将其标记为成功。有关详情,请参阅以下部分。
音频的往返延迟是指录制、处理并回放音频信号所需的时间。
要使用 CTS 验证程序测量往返延迟,请将环回插头插入 3.5 mm (⅛") 耳机接口。(如果您没有环回插头,可以按照音频环回适配器中的说明轻松制作一个)。
此测试使用环回插头来测试左/右音频线路的输出情况,然后使用来自环回插头的麦克风反馈来截取音频,并计算每个通道的频率响应。
对于每个通道,我们会针对每个频段(四个中的一个)设置一个简单的最低能量标准。
此测试使用外部 USB 参照麦克风捕获的信号来评估左路(和右路,如果存在)扬声器的频率响应。
参照麦克风是指频响平缓、自然的麦克风,通常用于分析和测量设备。
市面上有一些价格便宜的 USB 参照麦克风(例如,miniDSP USB 测量校准麦克风、Dayton 音频 UMM-6 USB 测量麦克风),主要供家庭影院爱好者用于校准其设置。
推荐的最低参照麦克风规格:
介于 100 Hz - 20 kHz 之间的平缓频响:+/- 2 dB
信噪比为 70 dB(A 加权)
频率为 1000 Hz,声压级为 127 dB 时,总谐波畸变率小于 1%
CTS 扬声器音频频响测试 | |
显示说明摘要 | |
USB 参照麦克风(请参阅扬声器音频频响测试) 按 USB REFERENCE MICROPHONE READY |
|
静的房间内设置 DUT(被测设备), | |
TEST | |
几秒钟,直到频响测试完成 | |
结束后,屏幕上会显示结果 | |
过按钮(仅在测试通过时才可用)或失败按钮来记录结果。 |
该测试涉及的硬件比前面的测试多。该测试需要使用以下两种硬件:用作白噪声声源的外部扬声器,以及用作声音参照的 USB 参照麦克风。尽管该测试涉及的硬件更多,但可以使用经济实惠、易于获得的硬件来执行。
距设备 40 厘米处的外部扬声器用于提供白噪声声源。这些扬声器不需要具有“平缓”频率响应,但需要能够支持最低 100Hz 到最高 20Khz 的频率范围。通常便携式或中等尺寸的有源扬声器(例如 Sony SRS -X5 便携式扬声器)就可以满足要求。
这里的关键在于使用 USB 参照麦克风执行校准步骤,以估算扬声器的实际频率响应,从而提供可靠的参照来和内置麦克风做比较。
对于该测试,除 USB 参照麦克风和外部扬声器之外,还需要使用声压级电平表(SPL 表)。
另外值得一提的是,在本测试中,每个测试的播放和测试部分都有自己的按钮。这样做是为了帮助测试不具备简便的播放功能但仍然可以测试未处理录音源的设备。
本文档包含执行近超声(以前称为高保真超声)麦克风和扬声器测试的步骤。请参阅音频部分,了解常规音频实施说明。
旋转矢量 CV 交叉检验
图 1. 测试图案的缩略图。请下载上面给出链接的完整分辨率图片。
本页面讲述了对旋转矢量传感器实现的兼容性进行正确测试的步骤。如果设备声明具有 TYPE_ROTATION_VECTOR 复合传感器功能,则应该运行该测试。要了解更多详情,请观看此视频教程。
在接受测试的 Android 设备上安装 OpenCV Manager。
从 SourceForge.net 下载 OpenCV-3.0.0-android-sdk.zip
软件包。
从下载内容中的 apk 文件夹中查找相关 APK。有关从计算机中将 APK 加载到 Android 设备的命令,请参阅安装应用。
如果存在登录到 Google Play 的有效帐号,则同时在 Google Play 中找到 OpenCV Manager,并在上下文菜单(“…”按钮触发的弹出菜单)中停用自动更新。
图 2. 在 Google Play 中停用自动更新。
打印链接的测试图案,并在打印时停用任何缩放选项。横向的 US Letter 纸张应该可以完整打印出该图案,您也可以使用更大尺寸的纸张打印。
注意:上面正文中的图片分辨率较低,仅用于说明。请勿直接将其作为图案进行打印。
将该图案放在水平面上。
在 CTS 验证程序应用中开始旋转矢量 CV 交叉检验。按照下面的指南开启飞行模式,关闭自动屏幕旋转,并调整自动调节亮度和位置信息(如果尚未进行这些更改)。
图 3. 启动测试。
当视频预览出现时,将手机放置在图案上方三英尺(或一米)处,使主摄像头朝向图案且屏幕上的黄色标记与图案上的黄色标记在同一角落对齐。
图 4. 放置测试图案。
使图案一直完全位于摄像头的取景范围内,同时围绕图案以三个不同的方向旋转 Android 被测设备 (DUT):按照旋转范围指示图的提示,逐个方向进行旋转(1、2,然后是 3,如下图所示)。请保持平稳移动,以达到最佳效果。
图 5. 操控被测设备。
拍照后,摄像头预览将消失,且分析过程将开始。耐心等待分析完成;该过程通常需要一到五分钟,具体取决于手机的性能。分析完成后,手机会发出提示音并振动。如果分析成功,屏幕上会出现数值结果。
图 6. 完成测试。
按照以下提示进行操作以获得最佳效果:
这是一个比较复杂的手动测试,因此您可能需要尝试多次以获得最佳效果。
测试之前,应对加速度计、陀螺仪和磁力计进行校准,以获得良好效果。
要了解更多详情,请观看此视频教程。
如果上述步骤无法解决问题,请务必按照以下反馈步骤报告您的问题。
请在报告错误时收集以下信息:
/sdcard/RVCVRecData/
中的内容。该文件夹包含视频文件,因此如果已进行多次测试,则可能会非常大。清空该文件夹并再次执行测试将有助于减小大小。检查其中的视频文件,找出录制方面的明显问题。虽然大多数 CTS 测试活动都会在测试开始时自动进行,但 Android 10 CTS 验证程序中的 MIDI 测试功能需要人为干预,以将适当的外设连接到被测设备。
CTS 验证程序 MIDI 测试可使用 USB MIDI 接口、蓝牙 MIDI 接口和虚拟 MIDI 设备路径测试 MIDI 功能。此外,对于测试的蓝牙接口部分,USB MIDI 接口用于实现从蓝牙接口输出回到其输入的环回。因此,CTS 验证程序 MIDI 测试需要一个 USB MIDI 接口设备和一个指定的外设。
可接受的 USB MIDI 外设需满足以下要求:可由被测设备识别,并且具有标准的圆形 5 针 DIN MIDI 插孔。某些 USB MIDI 接口设计为可使用 MIDI 线直接连接到 MIDI 仪表。这些设备有一对插头,因此无法通过标准 MIDI 线实现环回。
对于蓝牙 MIDI 接口,推荐的外设包括:
注意:所有指定的 USB 音频接口外设均需满足此测试的要求。
图 1.带 MIDI 的典型 USB 音频接口(前视图)
图 2.带 MIDI 的典型 USB 音频接口(后视图),带 MIDI I/O 插孔
图 3.带 MIDI I/O 插头的蓝牙 MIDI 适配器
所有环回测试都会通过测试外设发送一组 MIDI 消息,环回该数据,然后监视该设备的输入,以确保收到的数据与发送的数据相符。
该测试会通过 USB MIDI 接口测试 MIDI 功能。在本例中,环回机制是将一条标准 MIDI 线同时连接到该接口上的输入和输出插孔。
图 4.标准 MIDI 线
图 5.连接到 USB MIDI 接口的 MIDI 线
当 USB MIDI 接口连接到被测设备时,USB Input 和 USB Output 标签会显示该接口的名称,并且会启用 Test USB MIDI Interface 按钮。
点按 Test USB MIDI Interface,Status 标签会显示测试结果。
图 6.USB MIDI 环回测试已准备就绪
注意:如果测试失败并显示 Timeout @0 说明,则表示环回 MIDI 线可能已断开连接或连接不正确。
如果测试失败并显示 Timeout @,则表示发送的数据没有全部收到。
虚拟 MIDI 环回测试会测试虚拟 MIDI 设备 API。该测试会实现一个简单的虚拟 MIDI 设备,将输入直接环回到输出。由于此软件模块完全包含在测试代码本身中,因此该测试不需要额外的硬件,并且始终处于启用状态。
该测试会通过蓝牙 MIDI 接口测试 MIDI 功能。在本例中,环回机制是 USB MIDI 接口。
运行蓝牙 MIDI 环回测试之前,您必须通过 MIDI BLE Connect 应用连接到蓝牙 MIDI 适配器,该应用可在 Play 商店中免费下载。
将蓝牙 MIDI 接口连接到 USB MIDI 接口,注意将蓝牙 MIDI 接口的输出插头连接到 USB MIDI 接口的输入插孔,将蓝牙 MIDI 接口的输入插头连接到 USB MIDI 接口的输出插孔。
图 7.蓝牙 MIDI 接口已正确连接到 USB MIDI 接口
应用识别出蓝牙接口后,点按该蓝牙接口的名称。蓝牙接口现已连接并可供被测设备使用。
切换回 CTS 验证程序应用/MIDI 测试。
图 10.MIDI 测试
此时,界面上会显示蓝牙接口的名称并启用 Test Bluetooth MIDI Interface。点按 Test Bluetooth MIDI Interface,Status 标签会显示测试结果。
注意:如果测试失败并显示 Timeout @0 说明,则表示蓝牙 MIDI 接口的物理连接可能存在问题。
如果测试失败并显示 Timeout @ non-zero value,则表示发送的数据没有全部收到。
这三项环回测试都成功后,点按 以表明合规。
针对 Android USB 音频的几项 Android 兼容性测试套件 (CTS) 测试要求以物理方式连接 USB 音频外设。我们为此实现了额外的 CTS 验证程序测试。
在本文档中,所用的术语“设备”和“外设”具有非常明确的指代含义:
为了使 USB 音频 CTS 验证程序测试了解它们正在验证的属性和功能,您需要指定一组已知的外设作为测试依据。有鉴于此,下面指定了一些具体的外设品牌和类型。有些测试需要使用具体指定的外设。还有些测试则只需要使用满足具体测试要求的 USB 音频外设。请注意,USB 音频外设属性测试的所有指定外设也会符合播放测试和录制测试的要求。
请使用以下任一外设进行 USB 音频外设属性测试。同时,这些外设也适用于播放测试和录制测试。
请注意,制造商已停止销售这两个外设,在未来版本的 CTS 验证程序中将弃用它们。
USB 音频接口 (PreSonus AudioBox 22VSL)。
CTS 验证程序 USB 音频按钮测试不需要使用特定的 USB 耳机外设。该测试可以使用以下任一类型的耳机外设。
请注意,无论使用上述哪一类耳机外设,对于三个必需的按钮(音量调高、音量调低、播放/暂停),对应的按钮都必须能生成虚拟按键代码,测试才能成功。有关虚拟按键代码的说明,请参阅 Android USB 耳机配件规范中的“软件映射”部分。
USB 耳机。
跳线(用作回环)2 条 ¼" 阳头接 ¼" 阳头的短跳线,用来连接 USB 的输出端和输入端
USB 外设数据线
此数据线(通常外设产品会随附)可将 USB 音频外设连接到主机设备。
USB On The Go (OTG) 适配器
需要使用 USB On The Go (OTG) 适配器才能将外设连接到 Android 设备,并向 Android 设备指明它应该承担“主机”的角色。
模拟耳机用于在播放测试中监测 USB 音频接口的输出。
在每项测试中,如果测试成功,请点击 test pass(对勾标记)按钮来表示该结果。反之,如果测试失败,请点击 test fail(感叹号)按钮来表示该结果。
概要
此测试会验证相关属性(支持的采样率、声道配置、采样格式等)是否与设备的已知先验属性集相匹配。
流程
从主菜单中调用此测试后,请连接 USB 音频外设。如果这些属性与已知先验属性相匹配,则系统将启用 test pass(对勾标记)按钮。
概要
此测试可验证音频播放是否正常。为实现此目的,它会生成 1KHz 测试音调,然后使用立体声(双声道)将其传送到 USB 音频外设。
流程
从主菜单中调用此测试后,将 USB 音频接口(包括模拟耳机)连接到监测接口上的耳机输出插孔。
按 PLAY(播放)按钮。如果在耳机的两个声道中都能听到测试音调,请通过点击 test pass(对勾标记)按钮来表示测试通过。如果其中任一声道无法播放音调,或者两个声道都无法播放,请通过点击 test fail(感叹号)按钮来表示测试失败。
备注
选择“USB Audio Peripheral Buttons Test”
显示的说明摘要。
建立连接前的屏幕。
将 USB 音频外设连接到 Android 设备。
耳机已连接到用于监测的 USB 音频接口上的耳机输出插孔。
概要
此测试可验证录音功能是否正常。为实现此目的,这项测试会在 USB 音频接口的输出端生成音调,然后通过跳线将该音调传送到 USB 音频外设的输入端。
流程
从主菜单中调用此测试后,连接 USB 音频接口。使用跳线将模拟输出端连接到模拟输入端。按 **RECORD LOOPBACK(录制回环)**按钮。如果所录制测试音调的两个声道都显示在下面的视图中,请通过点击 **test pass(对勾标记)**按钮来表示测试通过。如果其中任一声道未显示,或者两个声道都未显示,请通过点击 **test fail(感叹号)**按钮来表示测试失败。
备注
请务必使用正接法同时连接外设上的输入插孔和输出插孔。为确保正确显示录制的信号,将需要调整输入等级。
选择“USB Audio Peripheral Record Test”
显示的说明摘要。
建立连接前的屏幕。
USB 音频接口已通过回环连接到 Android 设备
USB 音频接口背面的连接
USB 音频接口正面的连接
建立连接后的屏幕
建立连接后的屏幕,
概要
此测试可验证是否已正确识别所推荐耳机上的 media/transport 按钮。
流程
从主菜单中调用此测试后,连接 USB 耳机外设。按耳机上的每个 media/transport(播放、暂停、音量调高和音量调低)按钮。系统每识别出一个按钮,便会在测试面板中标识出该按钮。在识别出所有按钮后,系统将启用 test pass(对勾标记)按钮。点击 test pass 按钮即可表示测试成功。如果无法识别全部按钮,请通过点击 test fail(感叹号)按钮来表示测试失败。
备注
USB 耳机外设已连接到 Android 设备。
请留意 OTG 适配器。
选择“USB Audio Peripheral Buttons Test”
显示的说明摘要。
已连接外设,但尚未识别出任何按钮。
请注意,预期应识别出的按钮(设备配置文件所知的按钮)以白色文本显示;不属于测试外设的按钮以灰色文本显示。
Android 10及更高版本包括针对Pro Audio合规性的CTS Verifier测试,该测试可测试往返音频延迟。与许多自动运行的CTS Verifier测试不同,Pro Audio测试需要人工干预才能选择适当的外围设备并将其连接到被测设备(DUT)。
注意: Android 11不推荐使用Dr. Rick O’Rang回送应用程序。
适当的外围设备应具有足够的回放和记录功能,并且可以直接连接到DUT以准确测量通过音频路径的往返延迟。由于模拟,数字和蓝牙耳机无法直接连接到设备的输出和输入,因此这些外围设备不是合适的外围设备,不能用于Pro Audio测试。
可接受的外围设备包括:
要运行CTS Verifier Pro音频测试:
CTS Verifier for Instant Apps通过使用CTS Verifier测试由于OEM特定的UI(例如系统UI)而无法完全自动化的功能,从而增加了Instant Apps的Android兼容性测试范围。
在运行CTS Verifier for Instant Apps之前,请确保您具有以下设备:
CtsVerifierInstantApp.apk和CTS
验证程序包含在android-cts-verifier.zip
,可通过登录Q-EAP仪表板找到。
合作伙伴可以手动构建CTS验证程序以构建CTS以合并或测试新的修补程序。手动构建CtsVerifierInstantApp.apk
。在主机上发出以下命令:
make CtsVerifierInstantApp
要安装CtsVerifierInstantApp.apk
,请在主机上发出以下命令。
adb install -r --instant CtsVerifierInstantApp.apk
adb install -r --instant /path/to/CtsVerifierInstantApp.apk
这三个系统UI测试显示在主屏幕上的Instant Apps测试类别下。
图2.主屏幕
当您点击Instant Apps测试类别下的测试时,将打开该测试的测试屏幕。测试屏幕包含以下内容:
轻按“开始测试”按钮将启动示例Instant App。
首次单击Start Test时,将打开一个警告对话框,其中包含有关安装示例Instant App的说明(图4)。如果已经安装了示例即时应用程序,则其他即时应用程序测试不会显示此对话框。
图4.安装说明对话框
点击“帮助”按钮将打开一个弹出对话框,其中包含测试说明。
本文档列出了可用于评估 Android 相机硬件抽象层 (HAL) 的所有测试。本文档专供原始设备制造商 (OEM) 和应用处理器 (AP) 供应商参考,以帮助他们确保正确实现相机 HAL,并最大限度地减少问题。尽管这是 Android 兼容性测试套件 (CTS) 的自愿性补充测试,但它显著扩大了相机测试覆盖范围,并且确实能够发现一些潜在错误。
原始设备制造商 (OEM) 可以通过执行这些测试来检验是否已正确集成 Android 相机硬件抽象层 (HAL) 3 接口。当满足核对清单中的所有要求时,即认为设备实现完全符合 Android 相机 HAL 接口规范。这反过来又会使设备能够正确支持构建相机应用所依赖的 android.hardware.camera2 软件包。
Android 相机 HAL3 规范具体说明了设备必须满足的各项要求,可视为权威信息来源进行参考。本页提供了所有测试的摘要,可用作核对清单。相机 HAL 实现方(例如 AP 供应商)应仔细阅读相机 HAL3 规范,确保自己的设备符合规范要求。
要了解最新的 HAL 规范,请参阅 Android 5.0 及更高版本的通用 Android 平台开发套件 (PDK) 中的以下文件:
以下是适用于最新 Android 相机的主要测试类型以及相关说明:
README
文件和 tutorial.py
pdk/apps/TestingCamera/
中的源代码运行pdk/apps/TestingCamera2/
中的源代码运行下面详细介绍所有这些测试类型。我们按照 OEM 执行这些测试时所遵循的先后顺序进行介绍。
例如,如果设备未通过原生测试,那么也一定无法通过后续的兼容性测试套件 (CTS) 测试。如果设备未通过 CTS 测试,也就没有必要继续进行图像测试套件 (ITS) 测试。我们建议先解决每种测试中出现的问题,然后再继续进行下一组测试。
Android 供应商测试套件 (VTS) 是在 HIDL 接口级运行的测试套件。要详细了解如何使用 VTS,请参阅供应商测试套件。
相机 Android 兼容性测试套件 (CTS) 测试重点测试设备的兼容性。要了解如何设置测试环境,请参阅设置 CTS。
相机 CTS 测试的起始路径为:platform/cts
。
在针对支持外部相机(如 USB 网络摄像头)的设备运行相机 CTS 时,必须插入外部相机设备,否则测试会自动失败。外部相机示例:Logitech HD Pro Webcam C920 和 Microsoft LifeCam HD-3000。
有关运行 CTS 的一般说明,请参阅 CTS 简介及其子页面。
这些相机测试位于 cts/tests/tests/ 中的以下位置:
hardware/src/android/hardware/cts/CameraTest.java
hardware/src/android/hardware/cts/CameraGLTest.java
hardware/src/android/hardware/cts/Camera_SizeTest.java
permission/src/android/permission/cts/CameraPermissionTest.java
这些相机测试位于 cts/tests/tests/
中的以下位置:
hardware/src/android/hardware/camera2/cts/*
permission/src/android/permission/cts/Camera2PermissionTest.java
这些相机测试位于以下位置:cts/apps/CtsVerifier/src/com/android/cts/verifier/camera/*
注意:由于相机 HAL1 已被弃用,因此对于搭载 Android 9 或更高版本的设备,强烈建议您使用相机 HAL3。另外,这样还可以顺利地逐步停用已弃用的 Camera API。
相机图像测试套件 (ITS) 测试重点测试图像的正确性。要执行这类测试,请在工作站上对通过 USB 连接的 Android 设备运行 Python 脚本。
相机 ITS 的基础架构和测试的相关文件位于 cts/apps/CameraITS 目录下。每个测试都位于一个单独的 tests/scene#
子目录中。
要设置测试环境,请运行:
extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip
cd android-cts-verifier
adb install -r CtsVerifier.apk
cd CameraITS
source build/envsetup.sh
注意 :由于 ITS 是 CTS 验证程序的子测试,因此应该先启动 CTS 验证程序和 ITS 子测试,然后再运行 Python 脚本,以便这些脚本具有可与之通信的进程。
要详细了解如何设置和运行测试,请参阅 cts/apps/CameraITS
中的 CameraITS
PDF 文件。要查看有关如何使用这些脚本的指南,请参阅 tests 子目录中的 tutorial.py。
ITS 静态测试(场景 0-5)可以在任何满足相关 Python 2.7 环境要求的操作系统中运行。但是,采用传感器融合盒的 sensor_fusion
测试必须在 Linux 操作系统中运行。
相机盒装 ITS 中介绍了场景 0-4 的推荐设置。传感器融合盒快速入门指南中介绍了 sensor_fusion 场景的推荐设置。
要手动运行 ITS,请准备一个具有可重复使用的特定测试用具的简单物理环境,比如白色墙面、灰色卡片和台灯。将 Android 设备安装在三脚架上,然后运行脚本来测试相机功能。大多数测试只会提示通过或失败,但有些测试会提供一些指标。
这些脚本用于测试在 CTS 中没有测试的场景,是 HAL 3.2 测试计划的重要组成部分。
ITS 测试结果可能为通过或失败。设备必须通过每个场景文件夹中的所有强制性测试。对于非强制性测试,即使结果为失败,在 CtsVerifier 中仍算作通过。
这些场景代表了 ITS 测试的主要部分,它们以 PDF 文件的形式包含在 scene 文件夹中。要自动执行这些测试,请使用相机盒装 ITS 系统。
在场景 5 测试中,需要在相机上方放置灯光漫射器。
在传感器融合测试中,将分别针对 AR 和 VR 应用,测试相机和陀螺仪之间的时间戳差异,因此需要按特定轨迹移动相机。如果没有陀螺仪或未启用 REALTIME
参数,则会跳过此测试。sensor_fusion
测试可以通过传感器融合盒来自动执行。
应通过 MediaFrameworkTest 中的所有与相机相关的媒体测试。请注意,运行这些测试需要在 Android 设备上安装 mediaframeworktest.apk。您需要 make mediaframeworktest
,然后使用 adb 来安装生成的.apk。下面提供了一些命令示例。
与相机相关的媒体框架测试的起始路径为:platform/frameworks/base
这类测试的源代码位于以下目录:frameworks/base/media/tests/MediaFrameworkTest
设置这类测试的命令如下:
make mediaframeworktest
adb install out/target/product/name/data/app/mediaframeworktest.apk
其中,name 变量表示包含供应商产品的目录。
可在以下目录或其子目录中找到所有这些测试:
frameworks/base/media/tests/MediaFrameworkTest/src/com/android/mediaframeworktest
每个子目录都代表一个测试类:
functional/
integration/
prformance/
power/
stress/
unit/
查看所有可用测试的命令如下:
adb shell pm list instrumentation
这将会产生类似如下的结果:
instrumentation:com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner
(target=com.android.mediaframeworktest)
instrumentation:com.android.mediaframeworktest/.MediaRecorderStressTestRunner
(target=com.android.mediaframeworktest)
instrumentation:com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner
(target=com.android.mediaframeworktest)
instrumentation:com.android.mediaframeworktest/.MediaFrameworkPowerTestRunner
(target=com.android.mediaframeworktest)
从每个测试行中识别并提取组件(在 instrumentation:
和 (target=com.android.mediaframeworktest)
之间)。组件的名称包含目标软件包名称(com.android.mediaframeworktest)
和测试运行程序名称 (MediaFrameworkTestRunner)
。
例如:
com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner
com.android.mediaframeworktest/.MediaRecorderStressTestRunner
com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner
com.android.mediaframeworktest/.MediaFrameworkPowerTestRunner
然后,您可以将每个组件传递到 db shell am instrument
,如下所示:
adb shell am instrument -w component.name
其中,component.name
即为上面提取的值。例如:
adb shell am instrument -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner
请注意,虽然类路径是 Java 软件包加类名称,但插桩软件包不一定与 Java 软件包相同。连接组件名称时,请确保您使用的是 AndroidManifest.xml 软件包,而不是测试运行程序类所在的 Java 软件包。
若要运行单个类所包含的测试,请传递 -e 类参数,如下所示:
adb shell am instrument -e class com.android.mediaframeworktest.integration.CameraBinderTest -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner
如果只想运行某个测试类中的单个方法,请将井号 (#) 和方法名称(本例中为 testConnectPro
)附加到类名称,如下所示:
adb shell am instrument -e class 'com.android.mediaframeworktest.integration.CameraBinderTest#testConnectPro' -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner
下面是运行功能测试的一个示例。该测试验证不同相机设置(包括闪光灯、曝光、白平衡、场景、照片大小和地理标记)组合的基本功能。
运行以下测试命令:
adb shell am instrument -w -r -e delay_msec 15 -e log true -e class com.android.mediaframeworktest.functional.camera.CameraPairwiseTest com.android.mediaframeworktest/com.android.mediaframeworktest.CameraStressTestRunner
下面是运行集成测试的一个示例,本例中采用了 mediaframeworktest/integration/CameraBinderTest.java 和 mediaframeworktest/CameraStressTestRunner.java:
adb shell am instrument -e class \ 'com.android.mediaframeworktest.integration.CameraBinderTest' -w \ 'com.android.mediaframeworktest/.CameraStressTestRunner'
如果测试顺利通过,则会输出类似如下的结果:
-----
com.android.mediaframeworktest.integration.CameraBinderTest:...........
Test results for CameraStressTestRunner=...........
Time: 3.328
OK (11 tests)
-----
此预览内存测试将打开和关闭相机预览 200 次。系统会每进行 20 次迭代记录一次 ps mediaserver 的快照,并且会在 200 次迭代后比较内存使用量的差异。如果差异大于 150kM,测试就会失败。
运行以下测试命令:
adb shell am instrument -w -r -e class com.android.mediaframeworktest.performance.MediaPlayerPerformance#testCameraPreviewMemoryUsage com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner
更详细的输出信息可在以下文件中找到:/sdcard/mediaMemOutput.txt
用于运行单元测试的命令都很相似。例如,对于 CameraMetadataTest.java,命令如下:
adb shell am instrument -e class 'com.android.mediaframeworktest.unit.CameraMetadataTest' -w 'com.android.mediaframeworktest/.CameraStressTestRunner'
该测试用于对相机进行拍照压力测试和视频录制压力测试。
运行以下测试命令:
adb shell am instrument -w com.google.android.camera.tests/com.android.camera.stress.CameraStressTestRunner
您必须确保通过所有测试。
您必须手动运行 TestingCam 应用并执行以下检查。TestingCam 的源代码位于以下位置:pdk/apps/TestingCamera/
启动 TestingCam,打开预览,并确保将自动对焦模式设置为无限远。使用拍照按钮,以水平、向上(接近垂直)和向下(接近垂直)三种角度,拍摄远处(至少 10 米远)的物体的照片。例如,向上拍摄可以是站在树下仰拍树高处的树叶或树枝,而向下拍摄则可以是从建筑物的屋顶俯拍下面的街道。在所有情况下,远处的物体都必须成像清晰且对焦准确。在图库视图中保存和查看照片,以便您可以放大照片,从而更轻松地检查清晰度。
请注意,对于采用 VCM 致动器的相机,要通过此测试,将需要使用闭环自动对焦控制系统,或者需要使用加速度计数据来确定相机方向,并据此进行一些软件校正。此外,还需要对镜头的无限远位置进行可靠的出厂校准。
您必须手动运行 TestingCam2 应用并执行以下检查。TestingCam2 的源代码位于以下位置:pdk/apps/TestingCamera2/
Android 相机图像测试套件 (ITS) 是 Android 兼容性测试套件 (CTS) 验证程序的一部分,其中包含用于验证图像内容的测试。CTS 验证程序支持使用相机盒装 ITS 来自动执行 ITS 测试;支持对所有类型的 Android 设备进行手动测试。
盒装 ITS 具有以下优势:
自动化。在测试期间不需要人为干预。
缩短测试时间。可以同时测试前置/后置摄像头,使测试周期时间缩短 50%。
可以轻松排查问题。测试环境的一致性可以减少设置错误并提高问题可重现性。
高效。能够针对单个相机/场景进行重试,提高测试执行效率。
盒装 ITS 由一个根据计算机辅助设计 (CAD) 图纸激光切割而成的塑料盒、一部图表平板电脑和一部被测设备 (DUT) 组成。您可以使用宽视野 (WFoV) 盒装 ITS,也可以使用常规视野 (RFoV) 盒装 ITS。宽视野 (WFoV) 盒装 ITS 既能测试 WFoV (FoV > 90°) 相机,也能测试 RFoV (FoV < 90°) 相机。
如需开始使用相机盒装 ITS,请执行以下操作:
本部分详细介绍如何设置平板电脑,以用于 CameraITS 目录中的 相机 ITS 测试。这里以 Pixel C 平板电脑为例进行说明。如需了解有关平板电脑的要求和建议,请参阅平板电脑要求。
注意:相机 ITS Python 脚本会自动在平板电脑上为您设置以下选项:
设置 > 显示 > 休眠 > 无操作 30 分钟后
自动调节亮度 > 关闭
启用选项 |
|
---|---|
停用选项 |
|
$ adb devices
列出可用设备来确定 DUT ID 和图表 ID。如需确定 device_id
和 chart_id
,请插上再拔下设备并观察连接和断开连接的设备。将平板电脑正面朝上放在桌子上(不要将平板电脑安装到盒子的后板)。
运行以下命令:
python tools/run_all_tests.py device=$device_id camera=0 chart=$chart_id scenes=2,3
场景 2 和 3 要求平板电脑显示图像,因此平板电脑会提示您“是否允许云端硬盘访问您设备上的照片、媒体和文件?”。按允许以清除此提示(并防止以后再次显示提示)。
再次运行该命令。平板电脑会提示您“是否保留此文件的副本?”,并建议保存到 Google 云端硬盘。按“云端硬盘”图标,然后按取消来拒绝上传到云端硬盘,以此清除此提示(并防止以后再次显示提示)。
最后,运行 tools/run_all_tests.py
并确认当前场景会随着脚本循环自动变换为其他场景。虽然大多数测试都会失败(因为未将相机对准图表),但您可以验证平板电脑是否能正确地循环播放场景,而不会在屏幕上显示任何提示或其他弹出内容。
在运行盒装 ITS 之前,请确保您的测试设置包含以下硬件和软件:
一 (1) 个盒装 ITS
一 (1) 台用于显示场景的高分辨率 10 英寸平板电脑,序列号:5811000011
一 (1) 部安装了 CTS 验证程序 7.0_8+ 应用的 DUT。DUT 示例:
一 (1) 部用于测试后置摄像头 (0) 的 Pixel NOF26W,序列号:FA6BM0305016。如需安装 CTS 验证程序应用,请解压缩 android-cts-verifier.zip
,然后运行
adb -s FA6BM0305016 install -r android-cts-verifier/CtsVerifier.apk
针对后置摄像头运行场景 0-4:
cd android-cts-verifier/CameraITS
. build/envsetup.sh
python tools/run_all_tests.py device=FA6BM0305016 camera=0 chart=5811000011
您可以针对单个摄像头重新运行场景:
针对单个摄像头重新运行场景:
python tools/run_all_tests.py device=FA6BM0305016 chart=5811000011 camera=0 scenes=3,4
场景 5 需要进行特殊的设置以满足特定的照明要求。如需了解详情,请参阅 CTS 验证程序中的 CameraITS.pdf
,您可以在兼容性测试套件下载页面下载该文档。您可以单独运行场景 5(在盒子外部)。
图 2. 相机场景 5
针对单台设备的前置和后置摄像头运行场景 5:
python tools/run_all_tests.py device=FA6BM0305016 camera=0 scenes=5
python tools/run_all_tests.py device=FA6BM0305016 camera=1 scenes=5
您可以在测试期间查看结果,并将完成的结果另存为报告。
平板电脑的显示屏尺寸必须为 10 英寸左右,并且屏幕分辨率必须大于 2000 x 1500 像素。必须根据平板电脑型号在 CameraITS/tools/wake_up_screen.py
中设置 DISPLAY_LEVEL
值。下表列出了建议用于 ITS 测试的平板电脑。
设备 | 屏幕尺寸 (英寸) |
分辨率 (像素) |
平板电脑尺寸 (英寸) |
显示级别 | 操作系统 |
---|---|---|---|---|---|
Asus ZenPad 3 | 9.7 | 2048 x 1536 | 9.47 x 6.44 x 0.28 | 192 | Android 6.0 |
Huawei MediaPad m5 | 10.8 | 2560 x 1600 | 10.18 x 6.76 x 0.29 | 192 | Android 8.0 |
Pixel C | 10.2 | 2560 x 1800 | 9.53 x 7.05 x 0.28 | 96 | Android 8.0 |
Samsung S3 | 9.7 | 2048 x 1536 | 10.76 x 6.65 x 0.24 | 192 | Android 7.0 |
Sony Xperia Z4 | 10.1 | 2560 x 1600 | 10 x 6.57 x 0.24 | 192 | Android 7.0 |
RFoV 盒装 ITS 修订版 1 用于测试 RFoV 相机,可以运行 CameraITS/tests 目录下的场景 0-4 测试。RFoV 的定义为:60° < FoV < 90°。对于 FoV 更大的相机,图像中可能会出现光线,或者图表覆盖的 FoV 区域太小,因而会影响测试结果。
WFoV 盒装 ITS 修订版 2 用于测试 WFoV 相机,可以运行 CameraITS/tests 目录下的场景 0-4 测试。WFoV 的定义为:FoV >= 90°。它的功能与修订版 1 相同,但视野更大。修订版 2 测试装置可用于测试 Android 9 及更高版本中的 RFoV 和 WFoV 相机。
传感器融合盒可以通过 scenes=sensor_fusion
中的测试来测试相机/陀螺仪的定时偏差以及多摄像头系统的帧同步。REALTIME
功能标记和 VR/AR 应用要求相机/陀螺仪的定时偏差小于 1 毫秒。
如果相机具有 REALTIME 功能标记,则可以通过用于静态 ITS 测试的单个装置以及传感器融合装置来测试多摄像头设备。
下表提供了一组配置示例。
示例 | 相机 FoV | 是否具有 REALTIME? | 推荐装置 | 备注 |
---|---|---|---|---|
1 | 75° | 否 | 修订版 1 | Android 7.0 或更高版本 |
2 | 75° | 是 | 修订版 1 + 传感器融合 | Android 9 或更高版本 |
3 | 75° + 95° | 是 | 修订版 2 + 传感器融合 | Android 9 或更高版本 |
图表缩放适用于 Android 9 或更高版本。确保图表距离输入对于测试装置的版本而言正确无误。
WFoV 盒装 ITS 修订版 2
python tools/run_all_tests.py ... chart=# dist=22
RFoV 盒装 ITS 修订版 1(dist=31
为默认值)
python tools/run_all_tests.py ... chart=#
默认情况下,平板电脑亮度设置为 96。如需更改搭载 Android 7.0 到 Android 9 的平板电脑的亮度,请运行以下命令:
edit tools/wake_up_screen.py
DISPLAY_LEVEL=96 → DISPLAY_LEVEL=192
如需更改搭载 Android 10 或更高版本的平板电脑的亮度,可以在命令行中通过添加 brightness
标记来更改亮度:
python tools/run_all_tests.py device=# camera=# chart=# brightness=192
可以出于调试的目单独运行各个测试,但是只有运行整体场景时,系统才会将测试结果报告给 CtsVerifier.apk
。运行 tools/run_all_tests.p
y 时,系统会将结果输出到本地屏幕,并将图像保存到本地目录(而不是生成的/tmp/tmp###
目录)中。
如需运行单个场景,请执行以下操作:
通过在 tools/run_all_tests.py
中添加 scenes
标记来加载场景:
python tools/run_all_tests.py device=# camera=# chart=# scenes=#
在场景被记录为已加载到 stdout
后,按 Ctrl+C 停止测试。
如果屏幕上已经显示正确场景,请唤醒屏幕:
python tools/wake_up_screen.py screen=#
运行单个测试。
python tests/scene#/test_*.py device=# camera=#
然后,系统会在本地目录下生成图片,并将 stdout 和 stderr 输出到屏幕上。
如需了解有关调试的详细信息,请将 print 语句添加到脚本中。如需增加用于调试的测试输出,请添加 debug=True 标记。
python tests/scene#/test_*.py device=# camera=# debug=True
可以出于调试的目单独运行各个测试,但是只有运行整体场景时,系统才会将测试结果报告给 CtsVerifier.apk
。
相机 ITS 确保第三方应用具有兼容的摄像头接口。与单元测试类似,每个测试侧重于相机的一项规范。为了捕获不可靠的行为,这些测试应在一个整体场景测试中全部通过。例如,虽然在重新运行整体场景时单个不可靠测试可能会通过,但多个不可靠测试却很难通过。
以一种极端情况为例,假设某个场景中有 10 个测试,每个测试都有 50% 的概率返回 PASS。如果单独运行每个测试,则操作人员使相机通过相机 ITS 测试的概率会很高。但是,如果将这些测试作为一个场景整体运行,则整个场景通过测试的概率只有 0.1%。
默认情况下,脚本tools/run_all_tests.py
按顺序运行所有场景。但是,也可以单独运行各个场景或按指定顺序运行场景,并将结果报告给 CtsVerifier.apk
。
如需运行单个场景(例如场景 2),请运行以下命令:
python tools/run_all_tests.py device=# camera=# chart=# scenes=2
如需按特定顺序运行多个场景,请运行以下命令:
python tools/run_all_tests.py device=# camera=# chart=# scenes=3,2
确保平板电脑和测试环境符合以下规范。
平板电脑规范
确保平板电脑符合以下规格要求:
如需了解更多详情,请参阅平板电脑要求。
平板电脑亮度
如果平板电脑显示屏亮度过低,测试可能会无法获得正确的结果。
如需了解详情,请参阅如何控制平板电脑亮度?
盒子的光照强度(需要照度计)
确保平板电脑开口处的目标勒克斯值介于 100 到 300 之间。
如果勒克斯值过高,scene1/test_param_flash_mode.py
会返回 FAIL。如果勒克斯值过低,多个测试会失败。
确保您位于 dialout 组中。
groups | egrep ‘dialout'
确定 Microchip Technology 是否连接到 USB 端口,以此来确保传感器融合控制器已连接。
lsusb
…
Bus 003 Device 004: ID 04d8:fc73 Microchip Technology, Inc.
…
使用以下命令多次运行测试,以获得测试尝试的分布情况:
python tools/run_sensor_fusion_box.py device=A camera=0 num_runs=10 rotator=default
运行输出将存储在 sensor_fusion_#
文件夹下的/tmp/tmp###
文件夹中,其中#
是指运行编号。常见的失败原因如下:
FAIL
有效,必须纠正相机和陀螺仪之间的定时偏差。报告测试错误时,请提供为测试生成的文件和图片。
tools/run_all_tests.py
运行测试,请将压缩后的/tmp/tmp###
目录附加到错误信息中。此外,还应提供错误报告。相关测试失败后,请运行以下命令来生成错误报告,并将生成的 zip 文件附加到错误信息中。
adb -s device_id bugreport
常规视野 (RFoV) 盒装 ITS(修订版 1a)由一个根据计算机辅助设计 (CAD) 图纸激光切割而成的塑料盒、一部图表平板电脑和一部被测设备 (DUT) 组成,用于测试视野 (FoV) 小于 90 度 (RFoV) 的设备。您可以购买盒装 ITS,也可以自行组装。
注意:宽视野 (WFoV) 盒装 ITS(修订版 2)可用于测试 WFoV(视野大于 90 度)设备和 RFoV 设备。如需了解详情,请参阅宽视野盒装 ITS。
建议您通过以下任一合格供应商购买 RFoV 盒装 ITS(修订版 1a)。
Rahi Systems Inc.
48303 Fremont Blvd, Fremont CA 94538, USA
rahisystems.com/products/android-device-testing-equipment/
[email protected]
+1-510-319-3802
MYWAY Design
台湾新北市新庄区福营路 163 号 4 楼
twmyway.com
[email protected]
+886-2-29089060
除了购买,您也可以自行组装 RFoV 盒装 ITS。本节将详细介绍相关的组装步骤。
盒装 ITS 包含一部 DUT、一台图表平板电脑、一个内部照明系统和一个根据计算机辅助设计 (CAD) 图纸激光切割而成的塑料盒(如图 1 所示)。
首先,下载最新的盒装 ITS 机械图纸。
购买物料清单 (BOM) 中列出的材料。切割塑料和乙烯基元件。
准备好以下工具:
将有色乙烯基膜贴在丙烯腈-丁二烯-苯乙烯树脂 (ABS) 的光滑面上,并剪出必要的开口(如图 2 和图 3 所示)。在盒子安装平板电脑的一面贴上带有大矩形开口的白色乙烯基膜,在盒子安装移动设备的一面贴上带有圆形开口的黑色乙烯基膜。在侧板上贴上灰色乙烯基膜(如图 3 所示)并在底板的四个角上粘贴支脚(如图 4 所示)。 如需了解详情,请参阅 wikiHow。
图 2. 在前板上贴上了黑色乙烯基膜(左),在后板上贴上了白色乙烯基膜(右)
图 4.在底板的四个角上粘贴了支脚
组装盒装 ITS 的照明组件:
收集齐照明组件的材料并放在一起,如图 5 所示。
图 5.灯配件
组装配件包括:LED 灯条、塑料挡光板、塑料灯座、LED 照明套件中包含的塑料或金属灯夹,以及四个 6-32 螺钉和盖形螺母。
用螺栓将灯夹固定在塑料挡光板上,如图 6 所示。 在挡光板的另一面,使用盖形螺母固定灯夹。
如需组装灯,请使用灯夹将塑料挡光板连接到 LED 灯条的背面。
图 7. 灯条(灯朝下,螺钉拧进灯夹)
组装照明组件时,应使 LED 灯条朝下,并使塑料挡光板覆盖 LED 灯条背面闪亮的反光表面。
组装手机托架:
两个金属手机托架、两个柱塞、两个橡皮帽、四个 8-32 平头螺钉以及相应的螺母。
组装前孔板:
收集齐前孔板配件并放在一起,如图 11 所示。
图 11.前孔板配件
组装配件包括:组装好的手机托架、手机托架板、四个较短的尼龙螺钉和四个尼龙螺母(螺母的作用是防止螺钉从塑料板的背面伸出)。
使用螺钉和螺母将组装好的手机托架固定到手机托架板上。确保手机托架的方向正确,如图 12 所示。
图 12.组装好的前孔板
要组装平板电脑托架,请执行以下操作:
收集齐平板电脑托架的组装配件并放在一起,如图 13 所示。
图 13.平板电脑托架配件
组装配件包括:后板、平板电脑托架、一个柱塞、一个像皮帽、两个 8-32 平头螺钉、两个较短的尼龙螺钉以及相应的螺母。
使用平头螺钉组装平板电脑托架,从而将柱塞装置固定在金属托架上。确保使用相应的螺母拧紧螺钉。
使用螺钉和螺母将组装好的平板电脑托架固定到后板上。确保手机托架的方向正确,如图 14 所示。
图 14.组装好的平板电脑托架
如需安装灯,请执行以下操作:
将销钉插入从顶板和底板插槽处伸出的矩形卡舌上的小孔来固定挡光板,如图 16 所示。
图 16.插入盒子外侧的 LED 灯安装卡舌中的销钉特写
如需固定销钉,请轻轻按压销钉,直到销钉插入到位,您感觉到塑料片上有一点压力为止。
图 17.用于安装销钉的钳子
按照图 18 所示的正确方向组装前板和侧板,然后从外部用胶带将它们粘在一起。
图 18.灯的放置方向
将电源线连接到灯条电源,如图 19 所示。
图 19.照明电源线
将电源线穿过左侧板上的孔。电源线两端有两个不同的连接器:较窄的连接器连接到 LED 灯条,较大的连接器连接到电源适配器。
图 20.电源线从测试装置的左侧穿出
用电缆将顶部的灯和底部的灯连接起来,并将电缆固定到左侧板上。
图 21.固定在左侧板上的灯线
如需使用螺钉组装盒装 ITS 的侧板、平板电脑托架和手柄,请执行以下操作:
把各侧面板组装起来,然后用胶带将它们粘在一起,如图 22 所示。
图 22. 用胶带粘在一起进行组装的盒装 ITS
用电钻根据现有的孔钻定位孔。确保定位孔足够穿过 4-40 螺钉,从而确保在插入螺钉时不会使 ABS 塑料破裂。
图 23.钻出能够插入 4-40 螺钉的定位孔
使用 4-40 自攻螺钉将所有面板组装在一起。
图 24.用于组装面板的 4-40 螺钉
收集齐手柄配件并放在一起,如图 25 所示。
图 25.手柄配件
组装配件包括:4 个矩形塑料件和 4 个 6-32 螺钉。
组装手柄,如图 26 所示。
图 26.组装好的手柄
进行盒装 ITS 的最终组装:
将平板电脑托架安装到后板上,然后根据平板电脑尺寸调整高度。
图 27.放在盒子后板上的平板电脑托架中的平板电脑
使用 4-40 螺钉将不带手机托架的方形孔板安装到盒子的前板上,如图 28 所示。
图 28.组装好的手机前板
插入 10x10 厘米的鳄鱼孔板以适配 DUT 的摄像头开孔。
图 29.安装了鳄鱼孔板的盒装 ITS
安装手机,使摄像头与开孔对准。通过平板电脑开口检查对准情况。
图 30.安装了一部手机的盒装 ITS
为摄像头开孔。您可以开一个孔(用于测试一部手机)或两个孔(用于测试两部手机)。Pixel 和 Pixel XL 前置摄像头和后置摄像头的开孔如图 31 所示:由于没有闪光灯或激光器,前置摄像头的开孔是圆形孔;而为了不挡住闪光灯和激光器,后置摄像头的开孔为矩形孔。
图 31.前置摄像头和后置摄像头的开孔示例
图 32.安装了两部手机的盒装 ITS
使用数字照度计测试 LED 灯的照度。本例中使用的是 Contempo Views 的 YF-1065。
图 33.Contempo Views 的 YF-1065
将照度计放置在平板电脑一侧,然后将其调到 2000 勒克斯,以测量光照度。照度应在 100 到 300 勒克斯之间。对于该测试而言,如果照度值明显低于此范围,就说明太暗了,可能会导致测试失败。
图 34.用照度计测量安装了平板电脑托架的后板上的光照强度
根据测得的照度值,执行相应的步骤:
下面列出了一些常见的组装错误,这些错误会导致测试易出故障。
安装平板电脑的后板上有刺穿孔。这会导致 find_circle 测试失败,因为螺钉孔会产生额外的圆圈。
图 35.有刺穿孔的后板
缺少固定销。这会导致挡光板在运输过程中松脱。
图 36.挡光板上缺少固定销
非 UL 认证电源。使用 UL 认证电源可确保电源不会断电。
图 37.UL 认证电源示例
下面介绍了 RFoV 盒装 ITS 的修订历史记录。
修订版 1a
CTS 测试结果位于以下文件中:
$CTS_ROOT/android-cts/repository/results/<start_time>.zip
如果您自行编译了 CTS,则 $CTS_ROOT 将类似于路径 out/host/linux-x86/cts(但会因平台而异)。该路径取决于您解压缩从此网站下载的预编译官方 CTS 文件时所在的路径。
在 zip 压缩包中,testResult.xml 文件会包含实际的结果。在任何网络浏览器(推荐使用与 HTML 5 技术兼容的浏览器)中打开此文件,即可查看测试结果。
使用 Chrome 浏览器时,如果 testResult.xml 显示空白页,请更改浏览器配置,以启用 --allow-file-access-from-files 命令行标记。
测试结果的详细信息取决于您目前使用的 CTS 版本:
注意:所提供的结果旨在帮助您确保软件在整个开发过程中始终兼容,并且可作为通用格式向其他方说明您的设备的兼容性状态。
设备信息
在 CTS v6.0 及更早版本中,选择“Device Information”(“Test Summary”上方的链接)可查看关于设备、固件(品牌、型号、固件版本号、平台)和设备硬件(屏幕分辨率、键盘、屏幕类型)的详细信息(CTS v7.0 不显示设备信息)。
测试摘要
“Test Summary”部分可提供已执行的测试计划的详细信息,例如 CTS 计划名称以及执行开始时间和结束时间。该部分还会提供通过、失败、超时或无法执行的测试数量的汇总摘要。
测试报告
下一部分为 CTS 测试报告,它会按文件包显示已通过的测试的摘要。
接下来是所执行的实际测试的详细信息。该报告会列出测试包、测试套件、测试用例和执行的测试。它会显示测试执行结果:通过、失败、超时或未执行。如果测试失败,则该报告会提供详细信息以供诊断原因。
此外,为了确保简洁性,失败的测试的堆栈跟踪信息会包含在 XML 文件中,但不会包含在报告中;使用文本编辑器查看 XML 文件可了解有关测试失败的详细信息(搜索与失败的测试对应的 标记,并在其中查找 标记)。
要确定某个测试会话中的未完成模块数量,请运行命令“list results”。系统会列出之前每个会话的“已完成模块数量”和“模块总数量”。要确定哪些模块已完成,哪些模块未完成,请打开 test_result.xml 文件,并读取结果报告中每个模块的“done”属性的值。“done”值为“false”表示模块尚未运行完毕。
按照下载源代码中的说明进行操作,以获取并编译 Android 源代码,但在发出 repo init
命令时,请指定具体的 CTS 分支名称,例如 -b android-5.0_r2
。这样可以确保在下一个及后续 CTS 版本中包含您的 CTS 更改。
执行以下命令构建 CTS 并启动交互式 CTS 控制台:
注意:您可以提供 aosp_x86_64 以替代 aosp_arm64。
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
在 CTS 控制台中,输入以下命令:
tf> run cts --plan CTS
CTS 测试使用 JUnit 和 Android 测试 API。请查看测试应用教程,并仔细查看 cts/tests
目录下的现有测试。您会发现 CTS 测试大部分情况下都遵循其他 Android 测试中使用的相同规范。
CTS 可在多种正式版设备上运行,因此测试必须遵循以下规则:
大多数 CTS 测试用例都针对 Android API 中的特定类进行测试。这些测试具有以 cts 为后缀的 Java 软件包名称和以 Test
为后缀的类名称。每个测试用例包含多个测试,其中每个测试通常会执行被测类的某个特定方法。这些测试按目录结构进行组织并被划分为不同的类别,例如“微件”和“视图”。
例如,Java 软件包 android.widget.TextView
的 CTS 测试为 android.widget.cts.TextViewTest
,其 Java 软件包名称为 android.widget.cts
,其类名称为 TextViewTest
。
具体的目录结构和代码示例取决于您使用的是 CTS v1 还是 CTS v2。
CTS v1
对于 Android 6.0 及更低版本,请使用 CTS v1。对于 CTS v1,代码示例位于 cts/tests/tests/example
下。
CTS v1 测试中的目录结构如下所示:
cts/
tests/
tests/
package-name/
Android.mk
AndroidManifest.xml
src/
android/
package-name/
SampleDeviceActivity.java
cts/
SampleDeviceTest.java
CTS v2
对于 Android 7.0 及更高版本,请使用 CTS v2。有关详情,请参阅 AOSP 中的测试示例。
CTS v2 目录结构如下所示:
cts/
tests/
module-name/
Android.mk
AndroidManifest.xml
src/
android/
package-name/
SampleDeviceActivity.java
cts/
SampleDeviceTest.java
添加新测试时,可能没有现成的目录放置测试。在这种情况下,您需要创建目录并复制相应的示例文件。
CTS v1
您如果使用的是 CTS v1,请参照 cts/tests/tests/example
下的示例创建一个新目录。此外,请确保将位于相应 Android.mk
的新软件包模块名称添加到 cts/CtsTestCaseList.mk
中的 CTS_COVERAGE_TEST_CASE_LIST
。build/core/tasks/cts.mk
将使用该 Makefile 将所有测试组合起来,以创建最终的 CTS 软件包。
CTS v2
参照测试示例 /cts/tests/sample/,按照以下步骤快速开始构建新的测试模块:
运行以下命令创建测试目录并将示例文件复制到该目录中:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
转到 cts/tests/module-name
,然后按照上文建议的命名惯例替换所有出现的“[Ss]ample”。
更新 SampleDeviceActivity
以运行您需要测试的功能。
更新 SampleDeviceTest
以确保该 Activity 成功或记录其错
误。
其他目录
此外,您还可以添加其他 Android 目录,如 assets
、jni
、libs
和 res
。如需添加 JNI 代码,请在项目根目录下的 src
旁创建一个目录,并将原生代码和 Android.mk
Makefile 放入该目录中。
Makefile 通常包含以下设置:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libCtsSample_jni
# don't include this package in any target
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := list of source code files
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
# Tag this module as a cts test artifact
LOCAL_COMPATIBILITY_SUITE := cts
LOCAL_SHARED_LIBRARIES := libnativehelper
LOCAL_SDK_VERSION := current
include $(BUILD_SHARED_LIBRARY)
Android.mk 文件
最后,按如下所示修改项目根目录下的 Android.mk 文件,以编译原生代码并依赖于该代码:
# All tests should include android.test.runner.
LOCAL_JAVA_LIBRARIES := android.test.runner
# Includes the jni code as a shared library
LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni
# Include for InstrumentationCtsTestRunner
LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner...
LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE)
#Tells make to look in subdirectories for more make files to include
include $(call all-makefiles-under,$(LOCAL_PATH))
除添加新测试之外,您还可以修复或移除带有“BrokenTest”或“KnownFailure”注释的测试。
在 AOSP 中提交 CTS 或 VTS 补丁程序时,请根据补丁程序适用的 API 级别选择您的开发分支。
按照提交补丁程序工作流程向 CTS 提交更改。我们会为您的更改指定审核人员,并会尽快完成审核。
CTS 的发布遵循以下时间表。
发布过程中的重要日期
我们对 CTS 开发分支做了相应的设置,使提交到每个分支的更改自动合并到更高的分支中。
对于提交到即将发布的 Android 版本的更改,自动合并路径为:
aosp/master
>
对于直接提交到 AOSP 分支的更改,自动合并路径为:
nougat-cts-dev
> nougat-mr1-cts-dev
> oreo-cts-dev
> oreo-mr1-cts-dev
> pie-cts-dev
> android10-tests-dev
如果变更列表 (CL) 未能正确合并,CL 的作者会收到一封说明如何解决冲突的电子邮件。在大多数情况下,CL 作者可以按照这些说明跳过冲突的 CL 的自动合并。
此外,如果较旧的分支需要相关的更改,就需要从较新的分支中挑选 CL。
感谢您对 Android 兼容性计划的关注!您可以通过以下链接访问关于该计划的重要文档和信息。随着 CTS 的更新,此网页上会陆续添加新的版本。CTS 版本在链接名称中以 R 加数字表示。
Android 10 是代号为 Q 的开发里程碑版本。以下测试(包括针对免安装应用的测试)的源代码可以与开源树中的“android-cts-10.0_r3”标记同步。
Android 10 R3 兼容性测试套件 (CTS) - ARM
Android 10 R3 兼容性测试套件 (CTS) - x86
Android 10 R3 CTS 验证程序 - ARM
Android 10 R3 CTS 验证程序 - x86
Android 9 是代号为 P 的开发里程碑版本。以下测试(包括针对免安装应用的测试)的源代码可以与开源树中的“android-cts-9.0_r11”标记同步。
Android 9.0 R11 兼容性测试套件 (CTS) - ARM
Android 9.0 R11 兼容性测试套件 (CTS) - x86
Android 9.0 R11 CTS 验证程序 - ARM
Android 9.0 R11 CTS 验证程序 - x86
Android 9.0 R11 CTS(适用于免安装应用)- ARM
Android 9.0 R11 CTS(适用于免安装应用)- x86
Android 8.1 是代号为 Oreo-MR1 的开发里程碑版本。以下测试的源代码可以与开源树中的“android-cts-8.1_r18”标记同步。
Android 8.1 R18 兼容性测试套件 (CTS) - ARM
Android 8.1 R18 兼容性测试套件 (CTS) - x86
Android 8.1 R18 CTS 验证程序 - ARM
Android 8.1 R18 CTS 验证程序 - x86
Android 8.0 是代号为 Oreo 的开发里程碑版本。以下测试的源代码可以与开源树中的“android-cts-8.0_r22”标记同步。
Android 8.0 R22 兼容性测试套件 (CTS) - ARM
Android 8.0 R22 兼容性测试套件 (CTS) - x86
Android 8.0 R22 CTS 验证程序 - ARM
Android 8.0 R22 CTS 验证程序 - x86
Android 7.1 是代号为 Nougat-MR1 的开发里程碑版本。以下测试的源代码可以与开放源代码树中的“android-cts-7.1_r29”标记同步。
Android 7.1 R29 兼容性测试套件 (CTS) - ARM
Android 7.1 R29 兼容性测试套件 (CTS) - x86
Android 7.1 R29 CTS 验证程序 - ARM
Android 7.1 R29 CTS 验证程序 - x86
Android 7.0 是代号为 Nougat 的开发里程碑版本。以下测试的源代码可以与开放源代码树中的“android-cts-7.0_r33”标记同步。
Android 7.0 R33 兼容性测试套件 (CTS) - ARM
Android 7.0 R33 兼容性测试套件 (CTS) - x86
Android 7.0 R33 CTS 验证程序 - ARM
Android 7.0 R33 CTS 验证程序 - x86
Android 6.0 是代号为 Marshmallow 的开发里程碑版本。以下测试的源代码可以与开放源代码树中的“android-cts-6.0_r32”标记同步。
Android 6.0 R32 兼容性测试套件 (CTS) - ARM
Android 6.0 R32 兼容性测试套件 (CTS) - x86
Android 6.0 R32 CTS 验证程序 - ARM
Android 6.0 R32 CTS 验证程序 - x86
Android 5.1 是代号为 Lollipop-MR1 的开发里程碑版本。以下测试的源代码可以与开放源代码树中的“android-cts-5.1_r28”标记同步。
Android 5.1 R28 兼容性测试套件 (CTS) - ARM
Android 5.1 R28 兼容性测试套件 (CTS) - x86
Android 5.1 R28 CTS 验证程序 - ARM
Android 5.1 R28 CTS 验证程序 - x86
Android 5.0 是代号为 Lollipop 的开发里程碑版本。以下测试的源代码可以与开放源代码树中的“android-cts-5.0_r9”标记同步。
Android 5.0 R9 兼容性测试套件 (CTS) - ARM
Android 5.0 R9 兼容性测试套件 (CTS) - x86
Android 5.0 R9 CTS 验证程序 - ARM
Android 5.0 R9 CTS 验证程序 - x86
Android 4.4 是代号为 KitKat 的开发里程碑版本。Android 4.4 的源代码位于开放源代码树中的“android-cts-4.4_r4”分支中。
Android 4.4 R4 兼容性测试套件 (CTS) - ARM
Android 4.4 R4 兼容性测试套件 (CTS) - x86
Android 4.4 R4 CTS 验证程序 - ARM
Android 4.4 R4 CTS 验证程序 - x86
Android 4.3 是代号为 Jelly Bean-MR2 的开发里程碑版本。Android 4.3 的源代码位于开放源代码树中的“android-4.3_r2.2-cts”分支中。
Android 4.2 是代号为 Jelly Bean-MR1 的开发里程碑版本。Android 4.2 的源代码位于开放源代码树中的“android-4.2.2_r1”分支中。
Android 4.1 是代号为 Jelly Bean 的开发里程碑版本。以下兼容性测试套件修订版的源代码位于开放源代码树中的“android-cts-4.1_r4”标记中。
Android 4.0.3 是代号为 Ice Cream Sandwich 的开发里程碑版本。Android 4.0.3 的源代码位于开放源代码树中的“android-4.0.3_r1”分支中
Android 2.3 是代号为 Gingerbread 的开发里程碑版本。Android 2.3 的源代码位于开放源代码树中的“gingerbread”分支中。
Android 2.2 是代号为 FroYo 的开发里程碑版本。Android 2.2 的源代码位于开放源代码树中的“froyo”分支中。
Android 2.1 是代号为 Eclair 的开发里程碑版本。Android 2.1 的源代码位于开放源代码树中的“eclair”分支中。请注意,由于技术原因,我们尚未推出针对 Android 2.0 或 2.0.1 的兼容性计划,因此新设备必须使用 Android 2.1。
Android 2.1 R5 兼容性测试套件 (CTS)
Android 1.6 是代号为 Donut 的开发里程碑版本。Android 1.6 已被 Android 2.1 淘汰。Android 1.6 的源代码位于开放源代码树中的“donut”分支中。
以下媒体文件是进行 CTS 媒体压力测试所必需的。
我们尚未推出针对更早的 Android 版本(例如 Android 1.5,在开发过程中称为 Cupcake)的兼容性计划。新设备必须搭载 Android 1.6 或更高版本才能与 Android 兼容。
CTS 版本说明