最终 APK 中 Provider authority 冲突怎样在发布前发现

把 authority 冲突定义成最终产物问题

Provider authority 冲突最容易被误判为一行 Manifest 配置错误。实际发布包通常同时合并主工程、构建变体、渠道模块、AndroidX 初始化组件和第三方 SDK 的清单声明；源码目录里看到的值只是合并输入之一。可靠检查必须以准备交付的最终 APK 为对象，读取二进制 Manifest 中每个 Provider 的真实声明，并把结果绑定到候选文件摘要、versionCode、variant 和生成时间。只有这样，发现的冲突才与将要安装的字节一致。

冲突也不只等于两个完全相同的字符串。空 authority、残留的 `${applicationId}` 占位符、多个 authority 别名中某一项重复、测试后缀在生产变体中消失、依赖升级后出现同名初始化 Provider，都可能让安装、解析或应用启动阶段出现异常。门禁需要先把 authority 拆成规范化集合，再按候选内部重复、允许基线差异和变体间漂移三个维度判断。简单搜索 `android:authorities` 无法覆盖分号分隔值、占位符和最终合并来源。

本文只处理最终 APK 中 Provider authority 冲突的发布前发现方法，不把问题扩大成完整的 ContentProvider 攻击面审计，也不重复讨论 APK 升级连续性。静态一致只能说明所列声明在某个候选中可解释，不能证明设备初始化一定成功，更不能证明 Provider 的查询、写入或 URI 授权安全。发布结论必须分别写清产物检查、设备回归和访问控制覆盖范围。

理解 authority 在组件入口中的作用

Android Manifest 用来声明应用组件、权限、intent filter、SDK 约束和元数据，Provider 也通过清单进入系统组件注册过程。authority 是其他组件定位 Provider 的关键标识之一，它不应被当成只在本应用内部使用的随意标签。发布团队需要为每个最终值建立所有者、用途和来源记录，尤其要区分业务 Provider、文件共享 Provider、启动初始化 Provider 与第三方 SDK Provider。缺少用途说明的 authority 即使没有重复，也不应直接进入生产。

常见做法是用 applicationId 作为 authority 前缀，再追加稳定后缀，以降低同一设备上不同应用相互碰撞的机会。这是一项工程约定，不是看到 `${applicationId}` 字样就自动安全。占位符必须在最终清单中展开为实际值，测试包和生产包的 applicationIdSuffix 必须得到预期隔离，多个 Provider 的后缀也必须各自唯一。若库写死通用 authority，宿主再怎样更换包名都无法自动消除碰撞。

有些 Provider 允许用分隔形式声明多个 authority，检查器因此要把字段拆开、去除首尾空白并保留原始表示，不能把整串当成一个值。大小写和字符合法性应按照最终平台解析结果处理，内部比较规则还要稳定，避免同一字段因工具格式差异产生噪声。规范化不是修改 APK 的借口；原始值、规范化值和来源都要同时保留，任何空项、重复项或无法解析项都应形成明确失败。

• 每个 authority 都能对应到明确 Provider 类和用途
• 最终值不含未展开的 Manifest 占位符
• 多个 authority 别名已拆分并逐项比较
• applicationId 前缀与当前发布变体一致
• 第三方 SDK 的固定 authority 有来源说明
• 原始值和规范化值都进入不可变回执

从 Manifest 合并追到每个最终值

排查顺序应从最终结果反向追踪，而不是先猜哪份源码写错。第一步从最终 APK 导出二进制 Manifest，列出所有 `<provider>` 的类名、authorities、exported、permission、readPermission、writePermission、grantUriPermissions、process 和 initOrder。第二步读取 Manifest merger 报告，定位每个节点与属性来自主工程、变体 source set 还是某个 AAR。第三步再回到对应依赖和配置确认这是计划声明还是意外合并。缺少最终字段时，不应用源码默认值补齐。

合并规则可能覆盖、追加或移除节点，同一个类名也可能在多个输入清单中出现。只看合并报告的成功状态并不能证明最终语义符合发布计划，因为构建系统可以合法地产生一个业务上错误的结果。门禁应该把最终 Provider 集合与批准基线比较：新增项要求来源和用途，删除项要求兼容性说明，authority 变化要求变体与迁移说明，安全相关属性变化则进入独立审查。任何无法定位来源的最终节点都应阻断。

占位符检查要以展开后的最终值为准，同时保存其配置来源。例如库使用 `${applicationId}.startup`，主工程使用 `${applicationId}.files`，两者在不同后缀下通常形成不同值；但若两个库都选用相同后缀，它们仍可能在同一 APK 内重复。另一个风险是自定义占位符只在 debug 配置赋值，release 合并时落入空值或意外默认值。门禁要针对每个实际发布 variant 重建清单，不能用 debug 的合并报告替代 release。

依赖图变化怎样引入新的 Provider

Gradle 会把直接依赖和传递依赖解析成具体版本图，最终进入某个变体的运行时 classpath。SDK 升级、版本约束变化、平台依赖或依赖替换，都可能让解析结果与上一个发布候选不同。新的 AAR 可以携带自己的 Manifest，从而新增 Provider 或改变原有属性。发布前应保存目标 variant 的解析图和锁定结果，将新增 Provider 映射到真实组件坐标，而不是只在仓库里搜索类名。依赖声明相同也不保证解析结果未变。

Android 的依赖解析错误指南常用依赖树定位重复类和版本冲突，这种思路同样适合缩小 Provider 来源范围，但不能直接证明某个 SDK 是冲突根因。构建通过说明类和资源达到了可打包状态，不说明 Manifest 中的 authority 与其他组件、其他变体或同设备应用不冲突。只有把依赖图、合并报告与最终清单三者关联起来，才能从“可能来自这个库”收敛到“这个候选实际包含这条声明”。

依赖升级审查应关注语义差异而非版本号大小。对比前后候选时，至少列出 Provider 新增、删除、类名变化、authority 集合变化、进程变化、导出变化和权限变化。若 SDK 发布说明没有提到清单变更，也不能跳过二进制差异。相反，发现新增项也不等于 SDK 有缺陷，宿主可能需要配置唯一占位符或显式移除不使用的初始化组件。处置必须以官方集成要求和实际业务用途为依据。

• 依赖树来自目标发布 variant 而非默认 debug
• 每个第三方 Provider 能映射到具体组件坐标
• 版本约束和替换规则随回执保存
• 新增清单节点与 SDK 集成要求逐项核对
• 构建成功不作为 authority 唯一性的证明
• 删除第三方 Provider 前确认初始化和功能依赖

每个发布变体都要有独立 authority 基线

Android 构建变体由 build type、product flavor、source set、applicationId 和签名等配置组合而成。Provider authority 经常引用 applicationId 或渠道占位符，因此变体本身就是检查边界。一个 debug APK 通过查重，不能推断 release、海外渠道或企业分发包也通过；反过来，两个变体故意使用不同 applicationId 时，authority 不同可能是正确结果。基线要记录允许差异，而不是强迫所有变体生成相同字符串。

建立基线时，先枚举真正会交付的 variant，再为每个 variant 保存 applicationId、versionCode、签名责任、Provider 集合和允许的 authority 模板。比较时同时做两个方向：候选内部检查同一 authority 是否被多个 Provider 声明，候选之间检查同一业务 Provider 是否发生无法解释的后缀或前缀漂移。前者容易导致直接冲突，后者可能破坏既有 URI、初始化约定或渠道隔离。两类结果不能混成一个告警。

跨变体检查还要防止测试配置泄漏。生产候选若出现 `.debug`、`.staging` 或内部环境标识，应先定位占位符和 source set，而不是简单删除字符串；测试候选若与生产候选使用相同 authority，也要判断两者是否可能共存安装。门禁不需要臆测所有设备场景，但必须把共存假设写清：哪些包允许同时安装、哪些由升级替换、哪些属于互斥渠道。没有交付模型，唯一性结论就缺少边界。

导出、权限和进程必须与唯一性一起查看

authority 唯一性解决的是标识冲突，不是完整的安全判断。Android 关于导出组件风险的资料指出，跨应用可达入口需要显式考虑权限和输入校验。审查 Provider 时，应把 exported 与 permission、readPermission、writePermission、grantUriPermissions 和 path permission 放在同一行比较。一个 authority 没有重复，但 Provider 意外导出且没有合适权限，仍然属于独立的高优先级问题，不能因为查重通过而放行。

进程属性也会改变故障表现。某些初始化 Provider 在主进程启动早期运行，另一些被放到远程进程；authority 冲突可能在安装解析、组件注册或进程初始化的不同阶段暴露。静态报告应保留 process 和 initOrder，设备回归则观察安装结果、首进程启动、目标组件初始化和相关系统日志。不能仅凭一次首页正常显示断言所有 Provider 都初始化成功，因为某个按需进程可能尚未启动。

访问控制结论要保持克制。exported 为 false 可以收窄外部直接调用面，但应用内代码、URI 临时授权、共享用户历史行为或其他系统机制仍需按实际实现审查；exported 为 true 也不自动等于漏洞，可能有明确权限和业务用途。本文的门禁只要求字段变化可解释并把风险送入正确审查流程，不根据单个属性替代威胁建模。缺少项目代码和设备证据时，只能报告声明事实。

• exported 读取最终显式值并与基线比较
• 总权限、读权限和写权限分别记录
• URI 临时授权与路径权限进入独立审查
• process 和 initOrder 随 Provider 清单保存
• 按需远程进程纳入设备回归范围
• 唯一性通过不覆盖访问控制问题

用静态脚本阻断重复、空值和变体漂移

下面的 Python 示例读取从最终 APK 提取的 Provider JSON，并可选读取同一 variant 的上一版批准基线。输入中的每个 Provider 包含类名、authorities、来源、进程、导出和权限字段。脚本拆分 authority 别名，拒绝空值和未展开占位符，检测同一候选中被不同 Provider 占用的重复值，并把新增、删除和属性变化输出为漂移报告。它不解析私钥、不修改 APK，也不包含攻击或绕过逻辑。

提取器必须在脚本之前对最终二进制 Manifest 工作，并把 JSON 与候选 SHA-256 摘要绑定。示例故意不从源码 Manifest 推断缺失字段，也不会自动接受新增 Provider。若输入结构错误、authority 为空、仍含 `${...}`、同一值存在多个所有者或基线 variant 不一致，程序会走到可达失败路径。漂移本身不是一律失败，但必须经过所有者审查并更新批准基线，不能在流水线里静默覆盖。

生产实现还应加入 Manifest merger 来源坐标、依赖图摘要和允许模板校验，并把结果转换成稳定的机器回执。模板匹配只能用于解释预期前缀，最终仍要对展开值做全量查重。脚本的通过仅表示输入数据满足这些静态规则，不证明提取过程完整，也不证明设备能够安装和启动。发布门禁应把静态结果与设备测试并列保存，而不是让一个绿色退出码覆盖所有证据。

from pathlib import Path
import json
import re
import sys

if len(sys.argv) not in (2, 3):
    raise SystemExit("usage: check_provider.py candidate.json [baseline.json]")

def load(path_text):
    path = Path(path_text).resolve()
    if not path.is_file():
        raise SystemExit(f"input missing: {path.name}")
    data = json.loads(path.read_text(encoding="utf-8"))
    if not isinstance(data.get("providers"), list):
        raise SystemExit("providers must be a list")
    return data

def authorities(value):
    raw = value if isinstance(value, list) else str(value or "").split(";")
    items = [str(item).strip() for item in raw]
    if not items or any(not item for item in items):
        raise SystemExit("empty provider authority")
    if any(re.search(r"\$\{[^}]+\}", item) for item in items):
        raise SystemExit("unresolved manifest variable")
    return sorted(set(items))

def project(document):
    result = {}
    owners = {}
    for provider in document["providers"]:
        name = str(provider.get("name") or "").strip()
        source = str(provider.get("source") or "").strip()
        if not name or not source:
            raise SystemExit("provider name and source are required")
        values = authorities(provider.get("authorities"))
        record = {
            "authorities": values,
            "process": str(provider.get("process") or "main"),
            "exported": provider.get("exported"),
            "permission": provider.get("permission"),
            "source": source,
        }
        if name in result:
            raise SystemExit(f"duplicate provider class: {name}")
        result[name] = record
        for value in values:
            owners.setdefault(value, []).append(name)
    collisions = {key: value for key, value in owners.items() if len(value) > 1}
    if collisions:
        raise SystemExit(json.dumps({"authority_collisions": collisions}, ensure_ascii=False))
    return result

candidate_doc = load(sys.argv[1])
candidate = project(candidate_doc)
report = {"variant": candidate_doc.get("variant"), "providers": candidate}
if len(sys.argv) == 3:
    baseline_doc = load(sys.argv[2])
    if baseline_doc.get("variant") != candidate_doc.get("variant"):
        raise SystemExit("candidate and baseline variant differ")
    baseline = project(baseline_doc)
    report["added"] = sorted(candidate.keys() - baseline.keys())
    report["removed"] = sorted(baseline.keys() - candidate.keys())
    report["changed"] = sorted(
        key for key in candidate.keys() & baseline.keys()
        if candidate[key] != baseline[key]
    )
print(json.dumps(report, ensure_ascii=False, indent=2))

设备回归和发布证据要覆盖真实入口

依赖 Android 组件和系统 API 的行为需要在设备端 instrumented test 中验证。对 Provider authority 变更，测试至少覆盖候选安装、首次启动、主进程与声明的远程进程、实际使用该 Provider 的功能入口，以及升级或共存模型下的目标场景。设备回执要绑定 APK 摘要、variant、系统版本、ABI、安装方式、测试用例和日志时间。单一模拟器或一次冷启动通过，只能支持所列环境，不能代表完整 API 和厂商矩阵。

测试断言要针对问题本身。安装成功用于观察包解析和组件注册，首进程启动用于观察初始化 Provider，真实功能入口用于验证 authority 引用方与权限语义，升级场景用于确认前后版本的 URI 和组件约定。若某个 Provider 只在远程进程或特定功能中加载，必须显式触发该路径。出现失败时，先核对设备安装的候选摘要和最终清单，再分析日志，不能因为源码已修复就假定设备包已经替换。

最终发布记录应包含候选摘要、最终 Provider 清单、authority 所有者映射、变体基线差异、依赖图摘要、合并来源、静态脚本结果和设备用例。每项结论都写到证据覆盖的层次：静态通过表示未发现既定规则中的重复与残留，设备通过表示列出的场景执行成功，访问控制通过则必须来自单独安全审查。需要核对实际 APK 时，可通过御盾中央平台提交脱敏候选和变体清单，先固定检查范围，再安排发布验证。

• 安装与运行的 APK 摘要和静态检查对象一致
• 主进程、远程进程和真实 Provider 入口均被触发
• 升级、替换或共存模型与实际渠道一致
• 设备、系统、ABI、安装方式和时间完整记录
• 静态、设备和访问控制结论分别登记
• 相邻的升级连续性问题参考本站对应技术说明