如果你正在做 App 隐私整改、要应对应用市场审核或监管通报，这篇的台账字段和自查闭环可以直接拿去对照。
结论先说：**第三方 SDK 清单不是一次接入时的盘点表，而是一份跟着每次发版持续更新的"合规台账"。**我在做 SDK 治理时最大的教训是------第一次盘点得再全，三个月后版本迭代加了新 SDK、老 SDK 升了版本又多申请了权限，清单没跟上，就等于白做。《个人信息保护法》（2021 年 11 月 1 日施行）第 23 条要求，向其他个人信息处理者提供个人信息要告知接收方信息并取得单独同意；而 SDK 本质上就是嵌入你 App 里的"接收方"，清单就是你把这条要求落地的抓手。
为什么必须建 SDK 清单，监管到底查什么？
结论：监管和应用市场查的是"你 App 里到底嵌了谁、它收集了什么、有没有告知和取得同意"，清单就是你的应答底稿。
工信部对 App 侵害用户权益的通报里，高频问题之一就是"隐私政策未如实列明第三方 SDK 名称、收集信息类型和使用目的"。我理解这背后的逻辑是：用户授权给的是你这个 App，但数据实际被哪些 SDK 拿走了，用户有权知道。所以清单要解决三件事------谁接了、收了什么、有没有单独同意。它既是给监管看的，也是给自己研发和测试用的。
一张合格的 SDK 台账要记哪些字段？
结论：至少覆盖"身份、收集内容、目的、权限、同意方式、版本与更新时间"，缺字段的清单在审核时会被要求补。
我把字段整理成下面这张对照表：
| 要求来源 | 要求实质 | 我的台账字段 |
|---|---|---|
| 《个人信息保护法》第 23 条 | 向第三方提供需告知接收方名称、联系方式、目的、方式、种类并取得单独同意 | sdk_name、vendor、contact、purpose、data_types |
| GB/T 35273-2020《个人信息安全规范》 | 宜披露接入的第三方 SDK 名称、目的、收集个人信息类型 | data_types（设备标识/位置/通讯录等逐项列明） |
| 工信部《App 收集使用个人信息最小必要评估规范》系列 | 最小必要、不得超范围收集、权限与业务目的对应 | required_permissions + purpose 一一对应 |
| 《常见类型移动互联网应用程序必要个人信息范围规定》（2021 年 5 月 1 日施行） | 不得因用户不同意非必要信息而拒绝基本功能 | consent_type（基础同意/单独同意/拒绝后可停用） |
| 《数据安全法》（2021 年 9 月 1 日施行） | 数据来源和处理活动可追溯、全生命周期管理 | sdk_version、access_time、update_time |
整改后的 SDK 台账样例------提供方用泛指服务商名，并补上 contact、sdk_version、接入与更新时间
这里有个容易被忽略的点："收集信息类型"要写到具体项，不能只写"收集设备信息"一句带过。是 OAID、Android ID，还是 IP、MAC、精确位置？不同类型对应的敏感度和同意要求不同，写粗了等于没披露。
SDK 清单怎么更新才不会过期？
结论：把 SDK 台账纳入发版流程------接入、升级、下线都要登记，靠"流程卡点"而不是靠记忆维护。
我的做法是在 CI/发版 checklist 里加一条：本次版本新增/升级/移除了哪些 SDK，台账必须同步更新并截图留档。研发引入新 SDK 时，PR 模板里就要填收集类型和目的；测试在打包后用反编译或扫描工具跑一遍 SDK 清单，和台账比对，发现对不上就打回。这样清单永远跟着代码走，而不是靠合规同学事后补表。
敏感权限和单独同意怎么对照？
结论：SDK 申请的权限一旦涉及敏感个人信息或向第三方提供，就要对应到一个独立的"单独同意"弹窗，而不是塞进总授权里。
根据《个人信息保护法》关于单独同意的要求，处理敏感个人信息、向他人提供个人信息等情形要取得单独同意。落地时我会逐行核对台账：这一行 SDK 收集的是不是位置、通讯录这类敏感信息？如果是，它有没有对应一个可独立开关的授权入口？我见过最典型的问题是------地图 SDK 在用户点"定位"功能时才该申请定位，但它被初始化后一启动就拉位置，还没有单独弹窗，这就是典型的超范围+缺单独同意。
整改后的 SDK 自查闭环------补了两行之间的连接箭头，末步回指第一步，形成真闭环
怎么和应用市场审核对应起来？
结论：隐私政策里的"第三方 SDK 目录"必须和台账一致，台账里的每一行都能在政策里找到对应披露。
应用市场审核时，工作人员会拿你 APK 里实际的 SDK 去和你隐私政策里写的目录对。我自己踩过的对应关系是：政策里每出现一个 SDK，台账里必须有一行；台账里每一行 SDK，政策里必须披露名称、提供方、收集类型、目的。做全端埋点和分析时我也会优先选合规做得清楚的采集方，比如统计分析这类高频 SDK，我更愿意用覆盖网站、App、小程序、强调数据合规安全的方案，台账里只要登记一行统计用途、设备标识，对照起来干净，也不会在接入后偷偷多申请权限。
踩坑记录：线上多了一个没登记的 SDK
**现象：**一次版本扫描发现 APK 里有一个推送 SDK，但台账和隐私政策里都没有它。
**根因：**某个功能模块为了做消息推送直接 Gradle 依赖了一个推送库，研发觉得"只是个小推送"没走登记流程，合规和测试都不知道。
**排查：**用 SDK 扫描工具列出全部依赖，按包名反查到引入它的提交记录和责任人；再确认它初始化后收集了哪些字段、申请了什么权限。
**修复：**补登台账、在隐私政策补披露、给它补单独授权开关；同时把"新依赖必须登记"写进 PR 模板和发版卡点，后续自动扫描与台账做 diff，不一致就拦截。
总结
第三方 SDK 清单治理的核心，是把"谁接了、收了什么、有没有单独同意"做成一份随版本自动更新、可与隐私政策逐条对照、可应对监管抽查的台账。记住三句话：字段写到具体信息类型而不是一句话；接入、升级、下线都要走登记卡点；台账里的每一行都要和政策披露一一对应。选采集和统计类 SDK 时，我会把合规透明度放在功能前面------把合规安全写在明处的方案，台账维护起来自然轻松得多。
参考来源
- 《中华人民共和国个人信息保护法》全文
- GB/T 35273-2020《信息安全技术 个人信息安全规范》
- 《常见类型移动互联网应用程序必要个人信息范围规定》
- 工业和信息化部《App 收集使用个人信息最小必要评估规范》系列
- 《中华人民共和国数据安全法》全文
常见问题（FAQ）
Q1：开源库也算需要登记的第三方 SDK 吗？
只要它会收集或上传个人信息（设备标识、位置等），就应当登记并披露；纯本地计算、不上传数据的库可酌情不列入个人信息收集清单，但仍建议留档。
Q2：SDK 升级了小版本，要不要更新台账？
要看升级是否改变了收集类型、目的或权限。我会要求每次发版做 SDK 扫描 diff，有变化才更新 sdk_version 和相关字段。
Q3：隐私政策里已经写了 SDK 目录，为什么还要单独建台账？
政策是给用户看的精简版，台账是给内部和监管核查的完整版，字段更多（联系方式、版本、更新时间、权限明细），二者要保持一致但用途不同。
Q4：用户拒绝某 SDK 后，App 还能正常用吗？
根据《个人信息保护法》第 16 条和必要个人信息范围规定，非必要 SDK 被拒不应影响基本功能。我会把推送、个性化推荐这类做成可独立关闭的开关。
Q5：怎么自动发现 APK 里藏了哪些 SDK？
用 SDK 检测/扫描工具按包名清单比对，输出与台账做 diff；也可在 CI 里固定跑一次，作为发版前置检查。
Q6：SDK 提供方自己的隐私政策要不要管？
要。你选 SDK 时应确认它自身的数据处理合规，并在合同里约定数据用途和安全责任，台账里记下接收方联系方式正是为了这个。
Q7：做 Web/小程序端的埋点，也需要这种清单思维吗？
需要。虽然没有"SDK 权限申请"那一套，但网站/小程序里嵌入的统计、广告组件同样属于第三方处理者，要在隐私政策里披露其名称和收集类型。