直接回答
第三方 SDK 清单回答的是静态问题：某个应用制品包含哪些代码、团队认为每个组件的用途是什么、支持这些判断的证据在哪里。它不等同于观察网络流量；包中出现 SDK 并不能证明它在测试会话中执行或传输了数据。反过来，顶层依赖文件里没有某个名称，也不能证明最终包没有传递依赖或捆绑代码。PRIVACY-01 和 PRIVACY-02 支持记录数据边界与披露判断，却不说明某个特定发行包的实际内容。 先固定包变体和构建类型。记录应用版本、构建变体、依赖锁文件修订、解析后的依赖图和被检查制品。Debug APK、Release APK、动态功能和分包安装可能不同。还需盘点原生库、生成代码、插件及其他库带入的 SDK。依赖树应作为证据保存，不能直接照抄供应方营销名单。如果 SDK 可选或只在同意后启用，记录配置及真正执行该控制的代码路径。 为每个组件建立行记录：准确制品及版本、直接或传递依赖路径、调用它的功能、初始化时机、权限或敏感 API、已知数据类别、供应方描述的目的地及收集控制。把确认事实、供应方说法、代码推断和未知项分开。笼统写“用于分析”并不能说明哪些字段离开进程。阅读当前供应方隐私文档和版本说明，但在核对实际打包版本与集成前，应把它们标成供应方公开声明，而非已证实行为。 采用一致的数据分类：应用提供内容、设备或诊断元数据、账号标识符、传输元数据和从用户活动推导的数据。不能只因标识符经过假名化就称其为匿名，也不能从字段名推断用途。记录数值来自用户输入、模型生成、设备生成，还是 SDK 自己采集。如果 SDK 文档没有说明字段是否会被传输，就标为未知，不能用假设填补。 还要把清单与最终制品对照。检查确切 Release Candidate 的解析依赖报告、包内容、Manifest、原生库和功能开关。某个依赖可能存在但未激活，也可能在用户打开明显功能前自动初始化。静态检查能证明纳入和配置，不能证明运行时行为。动态测试应另行记录请求、触发条件和负载；两种记录可以互相引用，但结论不能合并。 权限是调查线索，不是数据采集证明。声明的权限在具体流程中可能未使用，库也可能调用不需运行时权限的 API。将每个权限和敏感 API 映射到功能所有者及测试。如果没有面向用户的功能需要某组件，记录移除候选，并检查移除是否会破坏其他功能。不能只凭这份清单就删除生产代码或更改应用权限。 最后将清单映射到产品披露审核。Google Play 说明开发者仍对发行应用中的第三方代码及其用户数据实践负责；Apple 的平台文档也描述应用与 SDK 的责任。这些来源支持审核流程，不会自动给出合规结论。完整清单应含未解决问题、审核人、日期、包身份、证据链接和下一步。依赖升级或构建变体变化后应重复检查。本文让清单可复现，不表示任何特定本地 AI 应用没有 SDK 数据流。
Release 审核发现陌生的传递 SDK
移动团队准备审核 Release 版本的隐私行为时，发现一项未出现在功能团队顶层依赖清单中的传递分析库。审核者需要先确定它的准确版本和所有者，再判断是否需要进行运行时测试。
决策
检查解析后的依赖图和最终包，将供应方声明与已观测行为分开，不经测试触发路径就声称组件处于休眠状态。
预期结果
发行记录写明制品、依赖路径、公开用途、未知项和后续审核，而不宣称应用不收集数据。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- PRIVACY-01：本地推理不能代表所有数据路径均本地
- PRIVACY-02：隐私披露需覆盖应用集成的第三方代码
隐私声明需要数据清单和流量证据；“本地模型”标签本身不是证明。
实施流程
- 固定检查制品. 记录 Release 构建变体、应用版本、锁文件修订、解析依赖报告、包摘要以及动态功能或 split 配置。
- 枚举直接和传递组件. 包含插件、原生库、生成代码和依赖带入的 SDK；每行都关联准确包名、版本和最终构建证据。
- 映射功能、访问和供应方声明. 对每个组件记录功能所有者、初始化路径、权限/API、公开数据类别、目的地、控制与未知项。
- 对照最终打包内容. 检查 Release Candidate 的 Manifest 和打包库，然后把组件存在证据与真实会话的请求负载证据分开。
- 处理未知项或指派跟进. 为未说明字段、可选模块和无法解释的组件指派负责人及测试；依赖或构建变化后重跑审核。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每个组件都关联准确包版本和构建制品；清单区分直接依赖与传递依赖。
- 供应方声明、静态代码观察和运行时观察作为不同证据类型明确标注。
- 未知用途或字段保持未知，并指派责任人与后续测试，不转写成隐私保证。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 解析依赖清单 | 枚举构建图中包含的代码 | 能说明组件和版本，不证明任务期间运行或传输了数据。 |
| 供应方文档 | 查看 SDK 作者公开的数据说明 | 能说明预期行为，但未必覆盖确切集成与版本。 |
| 运行时流量审计 | 触发功能并检查观测到的请求 | 只说明受测会话行为，不能替代静态组件清单。 |
需要避免的失败模式
- 只检查顶层依赖，忽略传递依赖
- 把供应方声明当成已观测行为
- 把组件在包内等同于该组件已发送数据
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
依赖图出现 SDK 就证明它采集了数据吗？
不能。依赖图证明组件被纳入构建，不证明它执行或传输数据。触发条件与实际负载需另做运行时测试并记录受测版本，留存原始证据。
SDK 供应方的隐私说明能替代应用审核吗？
不能。供应方文档只是一个输入。应用团队仍需核对准确包版本、集成方式、配置状态及发行构建实际传出的数据，并留存制品证据和审核日期。
如果 SDK 处于休眠状态，可以不列入清单吗？
不可以。应记录组件确实存在，并附上证明它未触发的证据。将来功能开关、初始化路径或依赖升级都可能改变行为，升级后要复测。