App 加固后动态功能模块下载与安装怎样回归

动态功能回归的对象不是单个 base APK

动态功能应用的发布输入是 AAB，设备最终运行的是根据设备配置和交付条件选择的 base、配置拆分以及 feature 拆分。Play Feature Delivery 允许模块在安装时、满足条件时或用户触发后交付，因此初次安装成功只证明当前集合可用。一个尚未交付的模块没有代码和资源可供 base 直接使用，加固回归必须把交付前、交付中和交付后的集合变化纳入同一测试计划。

加固会改变最终代码或打包产物，风险可能出现在多个边界：base 到 feature 的入口名称、资源引用、反射或组件发现、feature 内的 Native 库、拆分安装后的类加载、签名与版本一致性，以及失败后的状态清理。不能看到 base 首页正常就推断 feature 也正常，也不能只验证模块显示为 installed 而不进入真实业务页面、执行关键输入并观察退出与重进。

范围还要和保护策略分开。本文回答如何验证动态功能在加固候选中的下载、安装、加载、升级和回退，不回答哪些 feature 或方法应进入 VMP。保护清单应由另一个资产评审产生；这里把它当作候选身份的一部分，用于解释差异。这样测试失败可以定位到交付、签名、加载、资源、保护或业务入口，而不是把所有现象归到动态模块。

先枚举模块、交付模式和跨模块契约

测试清单从构建配置和 AAB 模块视图生成，至少记录模块稳定名称、是否按需、是否安装时交付、条件表达式、依赖的 base API、公开组件、深链入口、资源命名、Native ABI、预计触发页面和失败替代路径。Play Feature Delivery 的交付模式决定模块何时可能存在，测试用例不能把条件模块和按需模块都当成首次安装必有文件。

跨模块契约比页面名称更重要。base 可能通过显式 Activity、导航路由、接口实现、反射类名、资源 ID、ServiceLoader 或 JNI 入口到达 feature。加固与优化可能改变名称或可达性，资源处理也可能改变查找结果。每条契约需要唯一标识、所有者、调用方向、预期失败行为和测试入口；仅保存模块包名不足以解释为什么下载成功后仍无法打开。

条件交付需要固定条件证据。设备 API、硬件能力、地区或其他配置可能影响是否交付，测试报告必须记录实际 device spec 与模块选择结果。未满足条件时没有模块不等于失败；满足条件却缺少预期模块才是差异。按需模块则从未安装状态开始，确认查询结果、发起请求、状态监听和入口门控，避免用户在模块到达前直接触发不存在的类或资源。

用同一 AAB 派生可重现的设备 APK 集

Build and test Android App Bundles 说明可以使用 bundletool 从 AAB 生成 APK set，并按连接设备或 device spec 安装适配集合。回归时先保存最终 AAB 摘要，再保存 bundletool 版本、构建命令参数、device spec 摘要、生成的 apks 文件摘要以及选中的 APK 列表。相同 AAB 面向不同 ABI、密度、语言和系统版本可能产生不同集合，不能用一台设备的 split 列表当成全局基线。

bundletool 适合检查和重现派生结构，但签名必须明确。bundletool 文档说明生成 APK 时可以提供签名信息；未显式提供发布签名材料的本地测试产物不能被标成生产候选。若生产采用 Play App Signing，本地 set 与 Play 实际交付可能经过不同签名责任和分发路径，因此报告要把“本地结构回归”“本地设备安装”和“测试轨道交付”分成不同证据等级。

设备现场还要记录当前已安装集合。测试开始前确认包版本、base、配置 split、已安装 feature、证书摘要和残留会话；必要时分别执行全新安装与保留数据升级。只删除应用数据不会移除安装包集合，只覆盖安装也可能保留已安装模块。若前置状态不固定，某次按需请求立即成功可能只是模块已经存在，而不是下载、安装和加载流程本次真正通过。

把按需安装当成可恢复状态机测试

按需模块不是一个同步布尔值。请求可能经历 pending、downloading、downloaded、installing、installed，也可能等待用户确认、被取消或以错误结束。具体状态与错误以使用的 Play Feature Delivery API 为准。测试应保存 sessionId、模块集合、每次状态、错误码、已下载字节、总字节、时间戳和触发动作；业务界面只在确认模块可用后进入，不用最后一次回调覆盖完整时间线。

取消场景至少覆盖请求后立即取消和下载过程中取消，观察最终状态、临时 UI、再次请求以及进程重建后的状态。取消不是删除已经安装的模块，也不应被实现成全局失败。若 API 在特定阶段无法接受取消，产品要呈现明确的继续或等待状态。回归结论记录实际观察，不凭测试脚本预期伪造平台结果。

失败与重试要区分可恢复和不可恢复原因。网络中断、空间不足、服务不可用、会话冲突、模块名错误或版本不匹配需要不同动作。测试不能把所有错误都立即无限重试；应验证退避、用户提示、重复点击的幂等、旧 session 清理和 base 功能仍可用。On-demand feature delivery testing 提供本地测试手段，但故障注入通过只说明业务分支可执行，真实轨道仍需复验。

安装成功后还要验证代码、资源和业务入口

installed 只表示交付管理器认为模块可用，不能代表 feature 内所有契约都通过。下一步从真实入口打开 Activity、Fragment、Compose 路由或其他公开能力，验证类加载、资源、主题、字符串、导航参数、持久状态和异常边界。若入口由字符串、反射或框架发现，核对优化与保留规则；若使用模块资源，验证不同语言、密度与夜间模式，不只看默认配置。

feature 携带 Native 库时还要覆盖目标 ABI、库加载顺序、JNI 注册和依赖解析。模块未安装时 base 不应提前加载其中的库；安装完成后应在目标线程和生命周期调用真实入口。一个 ABI 成功不能代表其他 ABI，模拟器通过也不能替代所需真机。本文不提供通用兼容结论，矩阵应根据实际模块携带的库和最低系统版本建立。

业务验证必须包含拒绝与回退路径。模块安装后若账号无权限、服务端配置关闭或依赖数据缺失，应回到可理解的业务状态，而不是把交付成功当成授权成功。模块安装失败时，base 的核心导航和非相关能力仍应可用。相关设备选择方法可参照同站的 [加固验收设备、API 与 ABI 矩阵](/zh-cn/articles/device-api-abi-hardening-test-matrix/)，但当前候选仍需独立列出实际覆盖。

• 从真实导航或组件入口进入模块
• 验证类加载、参数、资源、主题与配置变化
• Native 模块按实际 ABI 覆盖加载和 JNI
• 安装后杀进程并重新进入功能
• 无权限与配置关闭不被交付状态绕过
• 模块失败不破坏 base 的非相关能力

用统一驱动执行安装、取消、失败和升级场景

自动化需要把业务场景与具体交付环境分开。定义一个 FeatureDeliveryDriver，由本地 Fake 管理器、bundletool 安装环境和测试轨道设备各自提供适配器；场景层只关心模块集合、会话状态、入口结果和候选版本。这样同一组断言可以在不同证据层执行，同时清楚标记哪个适配器能够注入网络失败，哪个适配器代表真实服务。

下面 Kotlin 示例是公开安全的测试编排核心，不包含证书、账号、内部模块名或攻击操作。它枚举允许模块，执行首次安装、取消、网络失败后重试、安装后入口、进程恢复以及 base 升级。驱动必须把每一步落到对应测试环境的官方 API，并返回真实状态；示例故意不把 Fake 结果伪装成轨道回执，也不设置任何性能阈值。

生产项目应为驱动增加证据写入：候选摘要、适配器类型、设备规格、开始集合、sessionId、状态序列、错误和最终集合。resetToBase 必须是受控测试操作，只能在测试设备清理到指定基线；upgradeTo 接受已生成且已签名的目标候选，不能在测试中临时重签。断言失败时保留现场，不继续运行依赖前一步的场景，以免第二个错误覆盖第一处差异。

• 每个模块从受控未安装基线开始
• 适配器明确标记 Fake、本地或测试轨道
• 每个 session 保存完整状态序列和错误
• 取消和失败后确认模块集合没有误更新
• 重试、进程恢复和升级使用真实入口断言
• 失败立即保留现场并停止依赖场景

enum class DeliveryState { REQUESTED, DOWNLOADING, INSTALLED, CANCELED, FAILED }

data class FeatureCase(
    val moduleName: String,
    val entryId: String
)

interface FeatureDeliveryDriver {
    fun resetToBase(candidateId: String)
    fun installedModules(): Set<String>
    fun request(moduleName: String): Int
    fun awaitTerminal(sessionId: Int): DeliveryState
    fun cancel(sessionId: Int): DeliveryState
    fun injectNetworkFailure(enabled: Boolean)
    fun launchEntry(entryId: String): Boolean
    fun recreateProcess()
    fun upgradeTo(candidateId: String)
}

fun runDeliveryMatrix(
    driver: FeatureDeliveryDriver,
    baseCandidate: String,
    upgradeCandidate: String,
    cases: List<FeatureCase>
) {
    require(cases.isNotEmpty())
    require(cases.map { it.moduleName }.toSet().size == cases.size)

    for (case in cases) {
        driver.resetToBase(baseCandidate)
        check(case.moduleName !in driver.installedModules())

        val installSession = driver.request(case.moduleName)
        check(driver.awaitTerminal(installSession) == DeliveryState.INSTALLED)
        check(case.moduleName in driver.installedModules())
        check(driver.launchEntry(case.entryId))

        driver.resetToBase(baseCandidate)
        val cancelSession = driver.request(case.moduleName)
        check(driver.cancel(cancelSession) == DeliveryState.CANCELED)
        check(case.moduleName !in driver.installedModules())

        driver.injectNetworkFailure(true)
        val failedSession = driver.request(case.moduleName)
        check(driver.awaitTerminal(failedSession) == DeliveryState.FAILED)
        check(case.moduleName !in driver.installedModules())

        driver.injectNetworkFailure(false)
        val retrySession = driver.request(case.moduleName)
        check(driver.awaitTerminal(retrySession) == DeliveryState.INSTALLED)
        check(driver.launchEntry(case.entryId))

        driver.recreateProcess()
        check(case.moduleName in driver.installedModules())
        check(driver.launchEntry(case.entryId))

        driver.upgradeTo(upgradeCandidate)
        check(case.moduleName in driver.installedModules())
        check(driver.launchEntry(case.entryId))
    }
}

签名、升级与回退要使用真实发布责任

Android 应用签名文档区分应用签名密钥、上传密钥、证书和 Play App Signing 的责任。动态功能回归需要知道最终设备 APK 由谁签名，而不是只确认 AAB 上传文件可接受。本地 bundletool set 若使用测试证书，只能证明对应测试身份下的安装与加载；测试轨道上的交付包应记录实际应用签名证书摘要。文档说明责任模型，但不能替任何候选确认签名正确。

升级矩阵至少包含两种前置状态：旧 base 已安装但 feature 未安装，以及旧 base 与 feature 都已安装。升级到新候选后，前者验证新版本按需请求和入口，后者验证已安装模块与新 base 的契约、资源和持久数据。还要覆盖升级过程中进程仍存活、升级后首次冷启动以及服务端配置变化。不能把卸载重装的成功结果当成保留数据升级通过。

回退要区分应用版本回退和业务能力关闭。商店分发通常不能依赖任意降 versionCode 覆盖安装，因此快速止损更适合使用服务端开关、隐藏入口、停止新请求或发布修复版本；已安装模块和本地数据如何处理需要产品契约。加固候选的回滚方案不能临时替换签名、从另一个 AAB 拼 split 或修改已签名文件。任何新候选都产生新身份并需要重新执行相应矩阵。

设备回执决定动态交付能否放行

Android instrumented tests 适合验证依赖真实 Android 运行时、组件、资源与系统 API 的行为。动态 feature 的设备测试应从模块未安装的 UI 或业务入口开始，记录请求到安装的状态，再进入真实功能；随后覆盖重启、进程恢复、配置变化和升级。测试用例要以最终用户可观察结果结束，而不是以 SDK 回调到达 installed 结束。

设备矩阵由实际交付条件和模块内容决定。至少按目标 API、ABI、密度、语言、安装来源、账号资格和旧版状态选代表组合；含 Native 库的 feature 扩展 ABI 覆盖，条件模块覆盖条件满足与不满足。单一设备、单一账号或本地模拟通过都不能外推。报告逐项列出执行、失败、未执行和阻塞原因，不用百分比或“全面兼容”掩盖空白。

最终放行记录应写成指定摘要 AAB 在列出的签名责任、device spec、测试轨道、设备和状态机路径下，派生集合符合预期且模块入口完成回归。它不能扩写为所有网络永久可用、所有设备兼容或加固不会影响任何模块。准备评估时，可整理最终 AAB、模块与交付模式、应用签名证书摘要、bundletool set、测试轨道版本、状态机回执和设备矩阵，再通过御盾中央平台提交申请。