直接回答
第三方 SDK 网络审计要回答的是某个应用动作运行时出现了什么请求，而不只是包内列了哪些 SDK。测试必须记录构建、设备、网络状态、动作、请求时间、主机、方法、负载类别和响应观察。PRIVACY-01 与 PRIVACY-02 要求数据边界说清楚。Android Studio Network Inspector 可以显示受支持的 HttpsURLConnection 与 OkHttp 流量，但未看到事件不等于没有网络：其他库、原生 socket 或不同进程路径可能不在视图中。 从静态清单开始，做触发矩阵。将冷启动、模型设置、打开页面、本地推理、取消、错误处理、反馈、导出和设置变化分成独立动作。每个动作前先抓基线，然后用合成输入逐次只触发一个动作。区分应用代码、SDK 初始化、系统服务和文件/媒体提供者造成的流量。归因不清就标未知，不能凭主机名猜是哪家 SDK 发起。 在可检查的构建和适合协议的受控环境中抓取。记录 TLS 中间人限制、证书固定、不支持的库、后台 worker、DNS 以及连接建立等盲区。不能为了抓请求而关闭证书验证。如果无法查看请求正文，就保留可见端点、时间、字节数、触发动作和正文不可用原因，再用源码与 SDK 文档作辅助证据。这是有范围的审计，并非看见了所有网络通道的证明。 准备提示词、转录片段、图片标记、账号标识和本地文件名等金丝雀字符串，只用合成内容。检查精确值或其变换是否出现在请求正文、头字段、查询参数、日志、分析事件或崩溃记录。将正常动作与关闭功能或应用 SDK 文档退出开关后的同一动作对照。对照可能帮助发现路径，但安静运行并不说明其他功能或代码路径也不会发送数据。 对每个观察到的目的地记录经核实的运营方、发起它的 SDK 或功能路径、该请求是否为用户动作必需、包含哪些数据类别以及用户能否阻止。不能仅由域名推断接收方。CDN、指标端点、身份服务和支持 API 可能属于不同组织。保存核实运营方的链接，并将其与未证实归因分开。 每轮只变一个条件重复：冷/热启动、受支持时的登录/匿名状态、正常连接/阻断网络、资源存在/缺失、Release/Debug 构建。不要同时改多个开关。检查取消是否阻止或标记继续执行的工作；排队的后台请求可能在页面退出后继续。恢复联网后的请求也要记录。 最终报告只描述具体构建与动作观察到的流量。不能凭一次飞行模式、一种代理抓包或空白 Inspector 面板承诺设备没有任何数据离开。应列出覆盖范围和盲区，并将发现关联到静态 SDK 清单及用户可见隐私说明。依赖更新、新遥测事件或新回退路径后要重新审核。本方法帮助发现数据流，同时避免没有证据的零网络保证。
测试员检查本地推理是否触发第三方请求
QA 审核者拿到包含多个库的 Release Candidate，想验证点击本地文本辅助功能是否会触发请求。缓存页面和一次 Network Inspector 截图不能证明行为，因此需要受控动作及抓取限制记录。
决策
将无操作基线与每次一项的合成任务对照，只归因已核实请求，并明确记录现有工具无法检查的流量。
预期结果
报告列明此构建观察到的目的地与数据类别，不声称所有网络活动都可见。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- PRIVACY-01：本地推理不证明其他请求不存在
- PRIVACY-02：第三方数据流需要披露边界
隐私声明需要数据清单和流量证据；“本地模型”标签本身不是证明。
实施流程
- 固定构建与静态 SDK 清单. 抓包前记录应用制品、构建变体、依赖版本、网络库、SDK 清单、设备、系统和测试账号状态。
- 定义单动作触发用例. 用合成金丝雀数据分别测试冷启动、模型设置、一次推理、取消、反馈、导出和错误状态。
- 捕获并标记网络观察. 每个请求记录时间、主机、方法、触发动作、数据类别、响应，以及归因已核实还是未知。
- 对比关闭功能与断网运行. 每次只改一个变量，检查后台任务与恢复联网队列，并标出原生流量等已知抓取盲区，保存抓取记录。
- 将发现映射到控制和披露. 核实接收方和用户控制，再把观测到的数据路径与功能目的及隐私说明对照，并注明判断依据。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每项网络观察都绑定具体构建和用户动作，并明确记录抓取限制。
- 除非目的与路径获准并有说明，否则合成金丝雀不应出现在观测负载中。
- 报告区分已观察、未知和不可见流量，不作零网络保证。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 静态 SDK 清单 | 读取解析依赖和包内容 | 显示包含哪些组件，但不证明用户动作期间发起请求。 |
| Network Inspector 抓取 | 观察进程内受支持 HTTP 库流量 | 能提供被覆盖请求详情，但仍有文档说明的库与协议盲区。 |
| 受控触发对比 | 对比基线、动作、退出和断网运行 | 帮助归因到功能，却不能证明所有通道均已完整观察。 |
需要避免的失败模式
- 把 Network Inspector 没显示当成无流量
- 关闭证书验证来方便抓包
- 从域名名称猜测数据接收方
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
Network Inspector 空白能证明应用没有发送数据吗？
不能。Inspector 只覆盖支持的流量。要记录它能观察的库和协议，并结合源码检查或其他批准的抓取方法，列出进程范围、请求类型和盲区。
为了查看加密请求，是否应该关闭证书验证？
不应该。不能为方便抓取而削弱应用。应记录证书固定或中间人限制，再用源码、SDK 文档及获准方法作不同证据，同时保持生产证书验证。
一次飞行模式测试能证明所有功能离线吗？
不能。新任务、首次设置、后台工作与恢复联网要分别测试。离线结果或缓存画面不能说明其他动作的数据路径，也要检查连接恢复队列和请求重试。