动态功能模块的最终 Manifest 怎样按交付条件验收

直接答案：以设备派生 APK 集为最终 Manifest 验收对象

动态功能的源码模块 Manifest 只是构建输入。Android App Bundle 会把 base、feature、配置和资产模块组织成发布包，分发服务再按设备能力与交付条件生成 APK 集。相同 AAB 对不同语言、ABI、密度、系统版本和条件可能产生不同工件，审计必须写清 deviceSpec 与实际选择结果。

验收流程先冻结 AAB SHA-256、构建工具与模块图，再为代表设备生成 APK set，列出将安装的 base、配置和 feature APK。对每个 feature 核对 deliveryType、条件、依赖、fusing、split 名称、组件、权限和摘要。未交付模块的组件不能进入该设备已安装能力清单。

本地 bundletool 结果仍不是线上交付结论。未显式签名时工具可能使用调试签名，Play 服务器也可能执行平台侧处理。发布报告把 local-derived、test-track-observed 和 device-installed 分成不同证据等级，只有真实工件和设备回执存在时才登记对应通过。

先画模块图：base、feature、配置和资产不能混成文件列表

App Bundle format 区分 base、feature、配置和资产模块。base 提供应用基础代码与资源，feature 可以依赖 base 或其他允许关系，配置 APK 承载 ABI、密度或语言差异。审计表必须保留 moduleType 和 parent，不用文件名猜测模块角色，也不把资产包误当成可执行组件。

组件归属必须明确。Activity、Service、Receiver、Provider、权限和 metadata 可能在 feature Manifest 中声明，只有相应 split 安装后才进入设备能力。base 如果通过反射或类名提前引用按需模块，首次启动可能出现类缺失；代码审查需要把可达性与交付时机对应。

资源依赖与代码依赖分别检查。feature 使用 base 资源属于常见路径，但另一个未交付 feature 的类或资源不能被默认认为存在。模块图若出现未知依赖、循环、缺失 parent 或仅靠运行时字符串维持关系，门禁应要求构建与设备证据，不能凭编译成功放行。

安装时、条件和按需交付必须使用不同验收路径

Play Feature Delivery 定义安装时、条件和按需等生命周期。安装时模块可与首次安装一起交付，条件模块依赖国家、设备特性或其他配置，按需模块在运行后由应用请求。测试计划不能用一个模块存在用例覆盖三种路径，每种路径的初始状态和失败点都不同。

安装时路径检查首次启动前工件集合、组件注册和依赖。条件路径至少选择满足与不满足条件的 device spec，确认模块只在预期配置出现。按需路径要覆盖未安装 UI、请求开始、下载、确认、安装、取消、失败、重试以及更新后的状态恢复。

业务代码必须把 moduleAvailable 当成运行状态，而不是编译常量。按需模块未到达时不实例化其类、不访问其资源，也不暴露只能由模块实现的组件入口。服务端不能因为客户端声称模块已安装就放宽权限，模块交付与账号授权仍是不同边界。

交付条件要转成代表设备矩阵，而不是停留在 XML

条件声明只有转成设备配置才能验证。团队先列出支持的 API、ABI、语言、密度、国家和硬件特性，再用边界值生成 deviceSpec。每条条件至少包含匹配、临界和不匹配用例，记录模块选择原因，避免只测试开发者手中的一台高配设备后就宣告覆盖完成。

矩阵需要控制组合爆炸。优先覆盖条件边界、主流设备、最低系统、最高系统和历史故障配置，配置 APK 的 ABI 与语言另行做成对覆盖。未测试组合标为 not-tested，不用相邻配置通过自动填充，也不虚构全设备兼容。

条件如果来自运行时服务或账号，不要误写成 Bundle 静态交付条件。静态设备条件决定派生 APK，账号资格决定业务入口，两者必须在数据模型和报告中分开。否则会出现模块已交付但账号无权使用，或账号有权但设备从未收到模块的混乱状态。

fusing 与旧系统路径必须明确记录，不凭通用包推断

动态 feature 的 fusing 配置会影响特定旧系统或通用 APK 路径是否把模块合并进基础工件。验收不能只检查现代 split 安装，还要根据产品 minSdk 与实际分发模式核对旧路径。fusing 值、模块条件和生成结果必须并列保存，不用源码默认值代替最终结果。

通用 APK 方便本地测试，但不等于设备定向 Play 交付。若 universal 构建包含更多 feature，测试通过可能掩盖真实设备缺失模块；若排除某些模块，也不能据此判断线上一定排除。报告必须标注 buildMode，禁止把 universal、device-specific 和 store-delivered 结果混为一项。

最低系统路径还涉及组件是否在 base 或 fused Manifest 中可见、资源是否合并和启动是否提前引用模块代码。门禁使用实际生成 APK 提取最终 Manifest 并检查类可达性，再在真实最低系统上安装。没有设备证据时只登记静态派生结果。

最终 Manifest 要核对组件、权限、intent filter 与元数据

Android app manifest 定义组件、权限、intent filter、SDK 约束和应用元数据。对选中的每个 APK，审计器应提取最终合并 Manifest，不只读取源码 XML。组件记录包括完全限定名、exported、permission、process、enabled 和所属模块，便于发现合并规则或条件交付造成的变化。

同名组件跨模块出现时，不能简单集合去重。需要确认最终安装集合是否产生重复、属性冲突或覆盖，尤其是 Provider authorities、deep link 和自定义 permission。某模块未交付时，base 的 intent filter 不应把请求路由到不存在实现；交付后也不应意外扩大导出面。

静态 Manifest 通过不证明运行时授权正确。exported、permission 和组件禁用状态只是平台入口控制的一部分，业务代码仍要验证用户、对象和数据。本文只验收声明与交付一致性，不把它扩写为组件篡改或运行时鉴权的第二套答案。

bundletool 本地派生要固定版本、签名与 device spec

bundletool 可以从 AAB 生成、检查和部署 APK set。流水线要固定工具版本和摘要，保存 build-apks 命令、device spec、AAB SHA-256、签名角色和输出 APKS 摘要。未显式提供生产签名信息时可能产生调试签名，因此本地工件只能按其实际角色登记。

每次生成后列出 APK set 元数据、模块名、split ID、targeting、文件摘要和 signer，再用 extract-apks 或 install-apks 对代表配置验证。不要只保留命令 exit 0；必须检查选择结果是否符合计划，尤其是条件模块、配置 APK 和 feature 依赖。

Build and test Android App Bundles 支持本地重现与测试轨道验证。线上测试轨道用于观察 Play 真实处理和设备交付，本地生成用于快速诊断，两者相互补充。任何差异都保持 blocked 并记录平台、工具和配置，不修改预期去迎合单次结果。

用结构化投影检查交付模块、组件和依赖

下面的 Python 示例读取 bundletool 或构建流水线导出的公开 JSON 投影，包含 deviceSpec、modules、selectedModules、dependencies 和 finalComponents。它检查 base 必选、模块唯一、所有已选模块依赖已选、未选模块组件未进入最终清单，以及组件名和归属完整。

脚本不解包生产工件、不执行安装、不读取签名密钥。输入派生的缺失依赖、未知模块、重复组件或交付泄漏会生成错误并非零退出。真实项目可以先用 bundletool 与 Manifest 解析器生成投影，再用这段逻辑作为可复核门禁。

通过只说明投影内部一致，不证明投影来自真实 AAB、签名正确或 Play 线上选择相同。下游应把投影、AAB、APKS、device spec 和工具摘要绑定，并追加测试轨道与设备回执；任何输入变化都必须重新生成。

import json
import sys
from collections import Counter
from pathlib import Path

if len(sys.argv) != 2:
    raise SystemExit("usage: audit_feature_delivery.py delivery-projection.json")
projection_path = Path(sys.argv[1]).resolve()
if not projection_path.is_file():
    raise SystemExit(f"projection missing: {projection_path.name}")
with projection_path.open("r", encoding="utf-8") as stream:
    projection = json.load(stream)
if not isinstance(projection, dict):
    raise SystemExit("projection root must be an object")

modules = projection.get("modules")
selected = projection.get("selectedModules")
final_components = projection.get("finalComponents")
if not isinstance(modules, list) or not isinstance(selected, list):
    raise SystemExit("modules and selectedModules must be arrays")
if not isinstance(final_components, list):
    raise SystemExit("finalComponents must be an array")
by_name = {item.get("name"): item for item in modules if isinstance(item, dict)}
if len(by_name) != len(modules) or "base" not in by_name:
    raise SystemExit("module names must be unique and include base")
selected_set = set(selected)
if "base" not in selected_set or not selected_set <= set(by_name):
    raise SystemExit("selected modules must include base and known modules")

errors = []
for module_name in sorted(selected_set):
    dependencies = by_name[module_name].get("dependencies", [])
    if not isinstance(dependencies, list):
        errors.append(f"invalid dependency list for {module_name}")
        continue
    missing = sorted(set(dependencies) - selected_set)
    if missing:
        errors.append(f"{module_name} misses dependencies {missing}")
component_names = []
for component in final_components:
    if not isinstance(component, dict):
        errors.append("component entry is not an object")
        continue
    name = component.get("name")
    owner = component.get("module")
    if not name or owner not in selected_set:
        errors.append(f"component {name!r} has an invalid owner")
    component_names.append(name)
duplicates = sorted(name for name, count in Counter(component_names).items() if name and count > 1)
if duplicates:
    errors.append(f"duplicate final components: {duplicates}")
if errors:
    print(json.dumps({"status": "failed", "errors": errors}, ensure_ascii=False, indent=2))
    raise SystemExit("dynamic feature delivery projection is inconsistent")
print(json.dumps({
    "status": "passed",
    "device_spec": projection.get("deviceSpec", {}),
    "selected_modules": sorted(selected_set),
    "component_count": len(final_components),
    "next_gate": "bind the projection to AAB/APKS hashes and test-track delivery",
}, ensure_ascii=False, indent=2))

报告要按设备配置列出实际交付与证据缺口

最终证据包包含 AAB 摘要、构建与 bundletool 版本、模块图、delivery 与 fusing 声明、device specs、APKS 摘要、selectedModules、最终 Manifest、组件差异、签名回执、测试轨道、设备安装和按需失败恢复。每项都要绑定同一 release。

可以陈述某个 device spec 的本地派生结果或某台设备的测试轨道观察，不能写成所有设备得到相同模块、所有按需流程兼容或模块已被正确保护。没有项目证据时，不提供客户、性能、攻击阻断、排名或收录数字。

组件外露问题可继续查看[Manifest 导出组件篡改审查](/zh-cn/articles/manifest-exported-component-tamper-review/)，本篇只负责交付条件与最终声明。需要提交 AAB 和设备矩阵，可从[御盾中央平台申请加固服务](https://www.leonadev.com/console/)。登录、注册、价格、购买和控制台统一由中央平台承接。

• AAB、APKS 和每个派生 APK 都有不可变摘要
• 安装时、条件和按需模块使用不同测试路径
• 代表 device spec 覆盖条件匹配、边界和不匹配
• selected module 的全部依赖进入同一安装集合
• fusing 与旧系统或 universal 路径按实际配置验证
• 最终组件、权限、intent filter 和 metadata 从派生 APK 提取
• bundletool 本地、测试轨道和设备安装证据分层登记
• 未测试配置与线上差异保持显式 blocked 或 not-tested