Android合规测试是一套围绕Google生态准入的验证体系，并非只测某个应用能否安装或某项功能能否启动。设备厂商和ODM在基于AOSP开发固件时，必须同时满足兼容性定义文档CDD的软硬件行为要求，通过兼容性测试套件CTS以及Google移动服务GMS认证，才能获得Google授权并面向海外市场出货。如果其中任何一项出现偏差，轻则无法通过认证，重则被判定为不兼容设备，直接影响后续系统更新和Play Store服务可用性。
一、合规测试的核心依据：CDD与CTS的关系
CDD是Google针对每个Android版本发布的兼容性定义文档，内容覆盖设备硬件、传感器、图形、多媒体、连接能力、安全机制、电源管理等各个方面。它不提供具体测试用例，而是作为测试判定的基准。例如CDD会规定设备必须支持的最低内存、屏幕分辨率、GPS精度、传感器采样率以及多媒体格式。如果设备硬件本身不满足这些基线，后续任何软件测试都无法弥补。
CTS则是运行在设备上的自动化测试套件，用来验证Android框架API行为是否与AOSP标准一致。它包含Activity生命周期、Intent处理、ContentProvider、权限模型、图形渲染、音频焦点、输入事件分发等大量用例。CTS测试通常需要在userdebug构建上运行，并且要配置测试SIM卡、Wi-Fi、蓝牙、摄像头等真实环境。许多用例还依赖Google服务框架，因此单独跑CTS并不等于完成GMS认证。
实际项目中常有一个误区：只跑CTS主计划而忽略CTS Verifier。Verifier包含大量需要人工操作的测试项，比如传感器方向校准、相机对焦、USB音频、指纹识别等。这些项目如果仅靠自动化用例很难暴露问题，但认证审核会通过Verifier记录判断设备是否真正符合CDD要求。因此合规测试必须把文档审查、自动化测试和人工验证结合起来，三者缺一不可。
二、常见合规测试类型与执行方法
除CTS之外，Google还提供了GTS、VTS、STS等测试套件。GTS主要验证GMS应用与服务在设备上的行为，例如Google Play服务、Chrome、Gmail、地图等预置应用是否能正确登录、同步、定位和推送。VTS面向HAL和供应商实现，检查Treble架构下厂商分区的接口是否规范。STS则聚焦安全补丁与内核配置，验证已知CVE是否被正确修复。不同套件覆盖不同层级，认证时需要根据设备类型选择对应计划。
测试前的准备同样关键。需要先解锁bootloader，刷入userdebug固件，并设置屏幕常亮、语言、时区、Wi-Fi网络。常用执行命令如下：
# 运行完整CTS计划 ./cts-tradefed run cts --plan CTS # 运行安全测试套件 ./sts-tradefed run sts-dynamic --plan STS
测试结束后会生成报告目录，包含test_result.xml和失败日志。CTS失败通常分两类：一类是环境问题，比如网络不稳定、Google账号未登录；另一类是真实兼容性缺陷，比如缺少某个系统API或返回格式错误。团队需要逐条查看失败堆栈，常见定位命令如下：
adb logcat -b all -d > compliance_logcat.txt adb shell dumpsys package com.example.app
GMS认证除了自动化套件，还包括Google审核流程。厂商需要提交设备信息、软件版本、安全补丁声明以及预置应用清单。某些海外运营商还会增加额外的准入测试，比如运营商网络参数、SIM锁策略、紧急呼叫行为等。这些要求虽然不直接属于CTS，但同样影响合规结果。
三、应用层合规与隐私权限专项测试
系统合规之外，预置应用和第三方应用也面临严格约束。Google Play政策要求应用必须声明真实使用的权限，敏感权限需要通过运行时动态申请，不能依赖隐式广播启动后台任务。Android 10及以上的分区存储Scoped Storage改变了文件访问方式，应用若直接读取外部存储根目录可能触发合规风险。开发者需要从AndroidManifest.xml开始核查，例如<uses-permission>和<uses-feature>的声明是否与代码实际调用一致。
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.app">
<uses-permission android:name="android.permission.CAMERA" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<application android:theme="@style/AppTheme">
<activity android:name=".MainActivity" />
</application>
</manifest>
运行时权限申请同样需要规范处理。下面是一段Java代码示例，用来检查相机权限是否已授予，并在未授权时发起系统权限请求：
if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
!= PackageManager.PERMISSION_GRANTED) {
ActivityCompat.requestPermissions(this,
new String[]{Manifest.permission.CAMERA},
CAMERA_PERMISSION_REQUEST);
}
应用层合规还会检查隐私政策链接、数据收集披露、广告ID使用限制以及后台定位频率。很多认证失败并非因为功能缺失，而是权限声明与应用实际行为不一致，或者在后台频繁访问位置导致系统拦截。因此建议在提交认证前，使用静态扫描工具和动态测试脚本对预置应用做一遍完整审计。
四、自动化流水线与常见整改项
将合规测试纳入持续集成可以显著降低认证失败概率。建议至少维护两条流水线：一条在每日构建后自动运行CTS smoke模块，覆盖核心API和权限相关用例；另一条在发布候选版本时运行完整CTS、GTS和STS。测试设备池需要保持固定网络环境，并配置Google测试账号。脚本示例：
#!/bin/bash set -e # 检查设备连接状态 adb wait-for-device adb shell svc power stayon true # 运行CTS中与权限相关的模块 ./cts-tradefed run cts -m CtsPermissionTestCases --skip-preconditions
常见整改项集中在几个方面。第一是SELinux策略缺失或过度宽松，很多设备为了快速点亮功能使用permissive模式，但CTS和GTS要求关键进程必须处于enforcing状态。第二是安全补丁级别声明与内核实际补丁不一致，STS会扫描CVE。第三是系统属性ro.build.fingerprint格式必须符合Google规范。第四是预置应用缺少必要的权限声明或错误声明了android.software.feature，导致Google Play过滤异常。
整改过程需要保留完整测试证据。每次修复后应重新执行失败模块，而不是只重跑单条用例。CTS报告中的summary可以帮助追踪通过率变化。随着Android大版本更新，CDD和测试套件都会同步调整，旧基线可能不再适用。测试团队应当把合规测试视为持续过程，而不是一次性的认证冲刺，这样才能降低量产后的合规风险。
Android合规测试CDDCTS认证修改时间：2026-09-23 02:34:17