Android 16 EDLA认证中，STS（Security Test Suite）是让不少开发者头疼的一环——它需要Debug版本、依赖VPN网络、环境配置坑多，网上相关教程却少之又少。本文基于实战经验，系统梳理STS测试的完整流程与避坑指南，帮助你高效通过这一认证关卡。

一、EDLA认证测试体系概览

EDLA（Enterprise Device Licensing Agreement）设备必须通过全套GMS认证测试，才能获得Google的正式授权。这些测试项涵盖了系统兼容性、安全性、性能表现等多个维度。

测试类型主要内容
CTSAndroid 兼容性测试，验证 API 符合性和系统功能完整性
GTSGoogle 服务测试，确保 GMS（Play 商店、Drive 等）正常运行
VTS内核测试、Vulkan 图形性能测试，验证 3D 渲染兼容性
GSI烧录通用系统镜像后测试，确保设备支持官方系统更新和系统兼容
STS安全测试套件，验证系统安全漏洞
手动测试 (CTSV/GTSV)针对特定功能的人工验证，如摄像头、显示、网络、通知等
BTSGoogle系统固件扫描，主要测试代码中的权限是否滥用，签名信息校验
CheckList系统属性配置和 Android 版本新特性检查

上述各类测试需要分别下载对应的测试套件执行，完成后会生成相应的测试报告。其中，STS测试与其他项目存在显著差异：它强制要求设备运行Debug版本固件，并且需要额外配置特定的测试环境。这也是很多开发者觉得STS门槛较高的原因。

与CTS、BTS等测试不同，STS侧重于验证设备的安全补丁级别和系统安全机制。如果你熟悉Java或C++层面的Android系统开发，理解STS的测试逻辑会更加顺畅。下面将详细介绍STS测试的准备工作与执行过程。

二、STS测试包的获取与初步运行

STS测试的准备工作相比其他认证项目更为繁琐，很多开发者在这一阶段就容易放弃。但只要按照步骤耐心配置，后续测试其实并不复杂。

2.1 下载STS测试包

首先需要根据设备对应的SPL（Security Patch Level）月份选择正确的STS版本，可向项目工程师确认具体的SPL月份。下载地址需要通过VPN访问Google Drive：

https://drive.google.com/drive/folders/1xqPTtC6MWiQizfFVdG7Ho0f2oGsmH0e-

解压密码为sts。选择arm64.zip文件下载即可。

在这里插入图片描述

目前最新版本为16-sts-r47，前几个月测试时使用的是16-sts-r44，但现在已经看不到r44版本了，具体原因不明。解压完成后，进入android-sts/tools目录，在该目录下执行./sts-fradefed即可启动STS测试控制台。

2.2 执行STS测试命令

启动控制台后，输入相应的测试命令即可开始测试：

run sts-dynamic-incremental -m XXX [-t XXX]
测试命令示例：
run sts-dynamic-incremental CtsSecurityBulletinHostTestCases
run sts-dynamic-incremental -m CtsSecurityTestCases -t android.security.cts.DynamicPermissionsTest

⚠️ 注意：首次运行几乎100%会失败，因为测试环境尚未配置。不过仔细阅读报错信息，通常能大致判断需要补充哪些文件。无论是下载测试包、配置环境还是执行测试，全程都需要VPN网络支持。

[AFFILIATE_SLOT_1]

三、STS环境配置：两大核心依赖项

首次运行STS时，系统会提示缺少必要文件。根据报错信息下载对应文件并放置到指定目录即可。主要涉及两个依赖项的配置。

3.1 配置frida-inject文件

第一次运行STS通常会遇到如下报错：

在这里插入图片描述

根据提示，将报错信息中的https://github.XXX/frida-inject-17.6.2-android-arm64.xz复制到浏览器即可自动下载。该文件版本会不定期更新，比如上个月下载的还是17.5.2版本。

下载完成后，需要将文件放入android-sts/testcases目录，并重命名为frida-inject-version-android-arm64。这一步看似简单，但存在几个容易踩的坑：

  1. 命名必须严格为frida-inject-version-android-arm64，不能使用带具体版本号的名称。我最初尝试用frida-inject-17.6.2-android-arm64命名，结果无法识别，最后把原文件和两种命名方式的文件都放进去了才通过。
  2. 重命名后需确保文件变为可执行文件。有些情况下修改名称后文件类型仍然是归档文件。此时双击该归档文件，会在同级目录生成一个可执行文件，再将其重命名即可。
在这里插入图片描述

执行文件的属性信息如下图所示，图标和属性与普通归档文件明显不同：

在这里插入图片描述
  1. 文件权限需设置为644。默认情况下该目录文件只有只读权限，需要确保frida-inject-version-android-arm64具有可执行权限。如果不想逐个设置，可以直接执行chmod 777 *赋予最高权限。

配置完frida后再次运行STS，通常还会遇到新的报错：

在这里插入图片描述

3.2 配置ghidra文件

根据报错提示，需要下载ghidra的zip文件：

在这里插入图片描述

一般选择较新版本即可，我这里根据提示下载的是12.0.1版本。这里有一个关键坑点：必须将zip文件放到固定目录：

/tmp/tradefed_ghidra/ghidra_12.0.1_PUBLIC_20260114.zip

注意：ghidra_12.0.1_PUBLIC_20260114.zip在这里是文件夹名称，Linux系统允许文件夹名称包含点号。tmp目录是home的同级目录，即用户目录的上上级目录。

在这里插入图片描述

我最初没仔细看报错，把zip文件直接放到了tradefed_ghidra目录下，结果仍然报同样的错误。正确的做法是在tradefed_ghidra下新建一个文件夹，将zip文件放入其中，再将文件夹重命名为与文件相同的名称。后续STS会自动解析和解压该文件，无需手动干预。

通常配置好上述两个文件后，STS就可以正常测试了。如果仍然报错，请仔细检查是否有遗漏步骤；如果出现新的报错，根据提示逐步适配即可。

四、运行STS测试与结果分析

环境配置完成后，后续测试流程与CTS类似，只是STS的命令格式比较特殊：

run sts-dynamic-incremental CtsSecurityBulletinHostTestCases

运行窗口中的测试结果界面如下：

在这里插入图片描述

如果测试无异常，无需查看更详细的HTML报告。但如果存在Failed项，就需要打开HTML界面查看具体报错信息：

在这里插入图片描述

HTML报告中可以看到详细的错误信息和堆栈跟踪。更底层的日志则需要到logs目录下查看设备的具体日志。对于熟悉Python或JavaScript的开发者来说，分析这些日志并不困难。

五、STS测试关键要点与版本说明

整体流程总结如下：

（1）下载sts套件
（2）尝试测试sts某一项
（3）根据测试报错下载并配置下载frida-XXX.xz文件
（4）重新测试，根据测试报错下载并配置 ghidra_XXX.zip 文件
（5）测试完成查看sts测试报告

另外需要特别注意：STS测试必须使用Debug版本，因为部分测试项需要root设备权限。

关于STS测试版本，Android设备固件分为user/userdebug/eng三类。STS对各版本的支持差异源于系统权限、测试基线生成和底层调试接口的开放程度：

STS 测试类型支持的设备版本禁止的版本核心限制点
全量 STS 普通测试（）user/uerdebug/eng无user 版本仅限制少数底层内核安全用例，核心 EDLA / 网络安全用例均可执行
模块定向测试（）user/uerdebug/eng无同全量，仅底层模块（StsKernelSecurity）在 user 版本会部分跳过
增量测试（）userdebug/enguseruser 版本无变更指纹记录 / 基线生成能力，增量过滤逻辑直接失效，会退化为全量测试
EDLA 深度安全测试（异常链路 / 加密强度）userdebug/eng 优先，user 兼容无user 版本会关闭部分 EDLA 调试接口，少数极端场景用例会报权限错误
底层安全测试（内核 / 驱动 / 证书底层）userdebug/enguseruser 版本屏蔽内核调试、底层文件读写权限，用例直接失败

关键要点：你高频使用的增量测试模式强制要求userdebug或eng版本，这是增量测试的核心前提。如果在user版本执行，会出现两个问题：

  • 增量过滤逻辑失效，自动执行全量用例，失去增量测试省时的意义
  • 无法生成或读取增量测试基线，多次执行会重复生成无效缓存，导致测试异常

部分开发者提到可以用sts -m XXX运行特定测试项，但我尝试了几个模块后效果不太理想，可能和具体版本有关。

六、EDLA其他认证测试简介

Android EDLA认证主要包含CTS、GTS、VTS、BTS等测试项。

BTS测试的Failed数量通常不多，几十到几百个。测试内容主要涉及系统补丁、系统签名、应用签名和应用权限。BTS的检测方式是生成文件包上传到Google网址，等待几个小时即可获得结果。相比STS，BTS的配置过程要简单得多。

CTS测试是认证项中用例数量最多的，因为很多framework或系统应用的修改都可能导致报错。CTS的测试流程相对标准化，但排查失败的用例需要较多时间。如果你有TypeScript或C++的开发经验，理解CTS的测试用例结构会更加轻松。

[AFFILIATE_SLOT_2]

总结

STS测试是Android 16 EDLA认证中门槛较高的环节，核心难点在于环境配置：需要下载frida-inject和ghidra两个依赖文件，并严格按照规定命名和放置。测试全程依赖VPN网络，且必须使用Debug版本固件。配置完成后，后续测试流程与CTS类似，重点关注HTML报告中的Failed项即可。希望本文能帮助你少走弯路，顺利通过STS认证。✅

run stsrun sts -mrun sts-dynamic-incremental