依赖注入生成代码怎样划定 VMP 保护边界

保护目标是业务决策，不是生成代码数量

依赖注入会把对象创建、参数传递、作用域缓存和成员赋值展开成大量生成类。它们在 DEX 中占据可见体积，也常出现在关键业务调用链上，但这不等于每个生成方法都是高价值资产。VMP 范围应从被读取或修改后会造成直接损失的业务决策开始，例如授权、权益、风控、协议和核心算法，再确认这些实现通过哪些生成节点被创建和调用。

生成装配代码通常具有重复、结构化和可由源码重新产生的特点。高强度保护它们会扩大处理数量、构建差异和回归面，却未必显著增加攻击者理解核心算法的成本。工程判断是默认把生成层列为“保持兼容、验证连接”，把手写核心实现列为“评估 VMP”；只有生成方法本身承载定制校验、敏感常量或不可替代业务逻辑时，才作为例外进入保护。

边界不能靠包名一次圈选。生成代码可能与手写类位于同包，手写适配器也可能使用 Factory 或 Provider 命名。资产表至少记录源码所有者、源文件来源、生成任务、编译后类、调用入口、业务损失、执行频率和回滚条件。这样审阅者能解释某类为何保护、为何排除，而不是用“依赖注入相关代码全部保护”替代判断。

用来源证据区分生成类和手写类

可靠分类应从构建产物向生成源回溯。编译流水线记录生成源目录、代码生成任务、源文件清单和 class 输出；R8 mapping 连接原始名称与最终名称；保护清单记录最终命中的方法。四类记录合并后，才能判断一个 DEX 类由哪个源产生、是否经过名称变化、最终是否被保护。只看最终类名后缀容易受混淆和项目命名影响。

生成来源也可能跨模块。某个库通过注解处理或其他编译插件产生代码，最终进入应用模块；传递依赖升级后，生成器版本和输出结构可能变化。Android Gradle dependency resolution 说明直接与传递依赖形成版本解析图，实际解析结果变化可能带来运行差异。项目应保存每个发布变体的解析图和生成器版本，不用仓库声明版本推断最终结果。

分类规则需要失败关闭但允许解释性例外。来源标记缺失、同一类同时被标为生成与手写、映射无法连接或生成任务未知时，不应自动归入排除清单。流水线把这些条目标为待审阅，要求负责人补来源证据。例外保护则记录业务原因、性能预算和回归入口，避免下一次生成器升级后继续沿用已经失效的类名规则。

依赖图要按发布变体分别固定

Android build variants 说明 build type、product flavor、source set、applicationId 和签名配置组合成不同变体。不同变体可能选择不同实现模块、测试替身、地区 SDK 或生成参数，使注入图、生成类和核心入口发生变化。一个变体的保护清单不能直接复制给另一个变体，即使两者共享大部分源码。

Debug Android dependency resolution 建议从目标变体对应的依赖树和实际解析结果定位重复类与版本冲突。这个方法同样适合保护边界排查：先确认出问题候选到底解析到哪个框架、生成器和传递库，再检查生成输出。构建冲突被修复只说明编译图恢复，不证明加固后的运行时连接和生命周期语义正确。

每个可发布变体应归档依赖锁定结果、生成任务、生成类摘要、手写资产清单、R8 配置、mapping 和 VMP 命中报告。流水线比较上一候选，新增生成类不自动进入保护，核心实现消失或移动则要求重新评审。工程判断是把变化分类为依赖变化、生成器变化、业务重构或保护规则漂移，避免所有差异都归咎于加固工具。

R8 keep 规则与 VMP 清单承担不同职责

Enable app optimization with R8 说明 R8 会执行代码与资源缩减、优化和名称混淆。依赖注入生成代码若通过直接引用连接，R8 可以分析可达性；若框架通过反射、JNI、清单或其他间接方式发现入口，就需要保留必要名称、构造器、注解或成员。R8 keep rules best practices 强调精确规则，宽泛保留会掩盖边界错误并削弱优化。

keep 只回答 R8 是否保留或允许优化某个元素，不回答它是否应进入 VMP。把 keep 清单复制成 VMP 清单，会把框架入口、序列化模型和生成装配层全部当成核心资产；反过来，用 VMP 排除规则代替 keep，又可能让 R8 删除运行所需入口。两个文件应分别版本化，但通过相同资产标识、原始符号和最终 mapping 进行一致性检查。

精确 keep 规则需要真实证据。规则应说明哪个间接入口需要何种属性，测试用例覆盖该入口，usage 报告确认没有意外保留整个包。若为了修复崩溃临时添加通配 keep，应记录到期和缩小计划。工程判断是先恢复最小可达性，再评估手写核心方法的 VMP；不要用全包 keep 加全包保护让问题暂时消失。

生成层通常排除，手写提供方法逐项评估

默认排除生成工厂并不意味着忽略依赖注入。保护后的手写构造器、提供方法和核心服务仍由生成层调用，参数顺序、异常传播、泛型桥接和生命周期都可能受影响。保护清单要沿调用图标注生成入口与手写目标，测试从真实注入入口触发核心逻辑，而不是直接 new 核心类绕过框架。

手写提供方法是常见边界。它可能只创建对象，也可能根据账号、地区、授权或风险选择实现。前者更接近装配层，后者可能是高价值业务决策。评审按输入、输出、分支价值、执行频率、线程、异常与可回滚性选择保护级别，不能仅因方法位于 Module 或 Provider 类就统一排除。

作用域和延迟获取也需要单独判断。单例缓存、会话作用域、延迟提供器和循环依赖可能让问题只在第二次调用、进程恢复或特定生命周期出现。工程判断是生成层保持低变化并用回归保护，核心实现按价值进入 VMP；若工具或运行时对某类生成结构存在已知边界，记录具体生成器版本和候选证据，不扩大成所有依赖注入代码都不能保护。

• 生成节点与手写目标在调用图中成对记录
• 手写提供方法按业务分支而非类名评估
• 测试从真实注入入口触发核心逻辑
• 作用域、延迟获取和异常路径分别覆盖
• 性能敏感构造和启动链先建立基线
• 例外规则绑定生成器版本与候选摘要

用来源清单识别生成类和保护漂移

自动门禁可以读取构建阶段导出的类来源清单，其中每项记录原始类名、sourceOrigin、generator、variant、最终映射名、业务资产标识和预期保护决策。实际保护报告再列出命中的最终类。验证器要求所有业务核心资产都有唯一手写来源并按策略命中，生成类默认不被高强度保护，除非带有可审阅例外原因。

下面 Python 示例只读取公开结构的 JSON，不扫描客户字节码，不包含真实包名，也不修改产物。它检查类标识唯一、来源类型有效、生成项带生成器、核心资产来自手写代码、实际保护集合不包含无例外生成类，并确认预期核心类全部命中。真实工程还要验证 mapping 和保护报告来自同一 APK 摘要。

名称后缀不参与最终决定。一个手写类叫 Factory 仍由 sourceOrigin=handwritten 识别，一个混淆后的生成类则依靠来源与 mapping 连接。门禁失败输出稳定资产标识和错误类别，不公开核心类全名。工程判断是把来源缺失当成阻塞，因为错误排除手写核心逻辑比多做一次人工分类风险更高。

• 来源清单由构建系统自动导出
• 生成器身份与发布变体同时记录
• mapping 和保护报告绑定同一候选
• 核心资产必须拥有唯一手写来源
• 生成类保护例外包含可审阅原因
• 未知保护命中和遗漏核心类都阻断发布

from pathlib import Path
import json
import sys

if len(sys.argv) != 2:
    raise SystemExit("usage: check_di_boundary.py inventory.json")

source = Path(sys.argv[1])
if not source.is_file():
    raise SystemExit("inventory file does not exist")

payload = json.loads(source.read_text(encoding="utf-8"))
classes = payload.get("classes")
protected = set(payload.get("protectedFinalClasses", []))
if not isinstance(classes, list) or not classes:
    raise SystemExit("class source inventory is required")

allowed_origins = {"generated", "handwritten"}
seen = set()
failures = []
expected_protected = set()

for item in classes:
    asset_id = item.get("assetId")
    origin = item.get("sourceOrigin")
    final_name = item.get("finalClass")
    generator = item.get("generator")
    decision = item.get("protectionDecision")
    exception = item.get("exceptionReason")
    if not asset_id or asset_id in seen:
        failures.append(f"invalid or duplicate asset: {asset_id!r}")
        continue
    seen.add(asset_id)
    if origin not in allowed_origins or not final_name:
        failures.append(f"{asset_id}: source origin or final class is invalid")
        continue
    if origin == "generated" and not generator:
        failures.append(f"{asset_id}: generated class has no generator identity")
    if decision == "protect-core":
        if origin != "handwritten":
            failures.append(f"{asset_id}: core asset is not handwritten")
        expected_protected.add(final_name)
    if origin == "generated" and final_name in protected and not exception:
        failures.append(f"{asset_id}: generated class protected without exception")

missing = sorted(expected_protected - protected)
unknown = sorted(protected - {item.get("finalClass") for item in classes})
for final_name in missing:
    failures.append(f"expected core class was not protected: {final_name}")
for final_name in unknown:
    failures.append(f"protected class is absent from inventory: {final_name}")

if failures:
    print("dependency injection boundary gate failed:")
    for failure in failures:
        print(f"- {failure}")
    raise SystemExit(2)

print(f"validated {len(seen)} class source records")

设备回归覆盖生命周期而不只覆盖对象创建

Android instrumented tests 适合验证依赖真实 Android 运行时、组件和系统 API 的语义。依赖注入回归不能只断言容器能够创建对象，应从 Activity、Service、Worker、深链或其他真实入口触发，验证作用域实例是否复用、进程恢复后是否重建、延迟依赖何时初始化、异常是否按原契约传播，以及核心业务输入输出是否与基线一致。

启动路径尤其敏感。生成组件初始化、ContentProvider、Application 和首屏依赖可能在监控完成前执行；高强度处理手写构造器或提供方法后，异常和时延会被放大。测试要固定未保护基线与同一候选设备条件，分别观察冷启动、首次注入、重复获取和后台恢复。本文不给出通用性能数字，项目需依据真实预算记录分布。

单一设备通过不能代表完整 API、ABI 和厂商矩阵。发布证据应列出实际覆盖组合、未执行项和失败项。若某变体使用不同依赖或生成器，必须在对应变体候选上重复关键回归，不能用另一个 flavor 的成功结果证明当前包。

发布证据把依赖、映射、保护和回归连起来

可复核证据包至少包含候选 APK 摘要、发布变体、依赖解析图、生成器版本、生成源清单、R8 配置、mapping、usage、VMP 策略、实际命中报告和设备回归。每项记录都指向同一构建身份，不能拿未混淆类清单配另一个版本 mapping，也不能用 debug 依赖图解释 release 候选。

出现问题时按最早差异定位。构建阶段重复类先查变体解析图；R8 后类缺失先查 keep 与 usage；保护后对象创建失败再查命中方法、构造语义和生成入口；设备特定问题则检查 API、ABI 和生命周期。一次只改变一个可解释变量并生成新候选，避免同时扩大 keep、排除整个包和替换依赖，让根因无法归属。

最终结论应写成指定候选中列出的手写核心资产进入保护，生成装配层按策略排除，并在列出的设备路径完成回归；不能声称所有依赖注入框架永久兼容或未测试生成器也通过。准备评估时，可通过御盾中央平台提交代表性 APK、变体依赖图、生成源清单、mapping 和保护范围，先固定资产与验收边界。

• 所有构建和回归记录绑定同一 APK 摘要
• 发布变体与依赖解析图一一对应
• 生成源、mapping 与最终保护命中可连接
• keep 规则与 VMP 策略分别归档
• 未覆盖设备和生成器版本明确标记
• 结论区分事实、工程判断与项目待验证项