App监管「新」规 —— 存储访问框架 - Momoko

一、关于App 监管新规

2026年1月1日发布的 《互联网应用程序个人信息收集使用规定（征求意见稿）》（以下简称《新规》），引起了行业内的讨论。
笔者认为很多要求都在之前的标准或文件中有提及，不过现在重新发布的新规体现了监管确实要求越来越严格了，开始抓落实了。

比如：

1、全生态的App隐私合规要求

从《新规》文章标题结构可以看出，对如下对象提出了安全要求：

• 第二章 互联网应用程序运营安全管理要求
• 第三章 软件开发工具包运营安全管理要求
• 第四章 应用程序分发平台安全管理要求
• 第五章 智能终端安全管理要求

早在2021年工信部发布的《移动互联网应用程序个人信息保护管理暂行规定（征求意见稿）》 文章中就提出过对App整个上下游生态链的安全要求：

2、生物识别信息存储

在《人脸识别技术应用安全管理办法》中第八条规定“人脸信息应当存储于设备内”

第八条 除法律、行政法规另有规定或者取得个人单独同意外，人脸信息应当存储于识别设备内，不得通过互联网对外传输。

在《新规》第十五条也规定了要生物信息要存储于设备内：

第十五条 互联网应用程序收集人脸、指纹、声纹等生物识别信息应当具有特定的目的和充分的必要性，采取对个人权益影响最小的方式，并实施严格的保护措施。

除法律、行政法规另有规定或者取得用户单独同意外，互联网应用程序收集使用人脸、指纹、声纹等信息应当存储于生物识别设备内，不得通过互联网对外传输。除法律、行政法规另有规定外，生物识别信息的保存期限不得超过实现处理目的所必需的最短时间。

3、存储访问框架

其中笔者认为可以详细探究的「新」内容是 ——存储访问框架。

《新规》中的第十四条：

用户选择使用上传或者发送图片、文件等功能，互联网应用程序可使用智能终端提供的存储访问框架实现的，不得索要手机相册、通讯录、短信、存储等权限。互联网应用程序通过提供文件编辑、文件备份等功能获得存储权限的，不得访问用户主动选择以外的文件。

关键的一句是：使用系统级功能实现 替换 APP索取权限的方式。

“可使用智能终端提供的存储访问框架实现的，不得索要手机相册、通讯录、短信、存储等权限”

二、存储访问框架

存储访问框架是一种系统级的采集用户信息的实现，支持用户手动选择此次需要共享的数据，用来替代 应用获取授权采集用户信息的方式。

1、实现方式

简单来说，提供系统级 照片视频选择功能，允许用户在应用内通过一个统一的系统界面选择并授权共享特定照片视频，应用随后能读取这些用户选中的照片视频数据。

实现流程：

App
↓
唤起系统组件
↓
用户主动选择
↓
App 只获得“被选中的结果”

当前在移动端隐私保护设计中，Android 与 iOS 均提供了“用户主动选择式（Picker）访问能力”，作为申请高权限数据访问权限的替代方案。

在 Android 平台，App 可通过系统提供的 Photo Picker、SAF（Storage Access Framework）或基于 MediaStore 的系统选择器，在不申请存储类敏感权限的前提下，实现用户主动选择照片、视频或文件等业务功能；在特定场景下，还可通过系统联系人选择器获取用户选定的单个联系人信息。

在 iOS 平台，App 可通过 进程外选取器（Out-of-Process Pickers），包括 Photos Picker、File Picker / Document Picker、Contacts Picker，以及 共享列表（Share Sheet），在无需申请照片、文件或通讯录访问权限的情况下，仅获取用户明确选取的数据结果。

上述机制的共同特点在于：由系统界面触发、用户显式操作确认、App 仅获得被选中的数据或引用，从而避免 App 借助系统权限对用户照片、文件、通讯录等敏感数据进行超范围采集。

需要注意的是，Picker 模式仅适用于“用户主动提供数据”的业务场景，对于需要持续访问、后台处理或批量分析的数据处理活动，仍需依法申请对应系统权限，并结合最小化、目的限制等原则进行设计。

在实际评估中，还需结合 App 是否存在通过 SDK 或 Native 层绕过系统选择器、直接调用敏感 API 的情况，避免出现“表面使用 Picker、实质仍具备全量访问能力”的合规风险。

三、应用级实现

给App授权有“不允许访问”“部分允许访问”和“允许完全访问”三个选项，而上面提到的方式使用系统控件替代了这一授权操作，直接阻止App访问包括信息、图库等所有隐私内容。

实现流程：

App
↓
申请权限
↓
直接读取敏感数据（文件 / 照片 / 联系人 / 位置）

存在的风险点：权限 粒度太粗，App 能看到不该看的数据/用户没意识到的数据，很容易超范围、超频次采集用户信息。

什么时候仍需要采用应用级实现（申请权限和调用相关API）

• 持续性的/后台的/自动采集
• 需要全量数据
• SDK 的“暗中行为”：App 用 Picker 做表面合规，SDK 仍然调用相关敏感API、或通过Native 层采集

四、总结

存储访问框架并不是强制禁止权限使用，而是一种更合规、更安全的能力实现方式。在仅需要用户选择结果的场景下，可以完全替代对应的敏感权限，App 也不需要在 Manifest 中声明相关权限或通过敏感 API 采集数据。但如果业务需要持续、自动或全量访问，存储访问框架 本身是无法满足的，此时仍需权限，并接受更严格的合规评估。

Refer：
金标联盟标准文档（涵盖各自picker的实现方式）：https://www.itgsa.com/doc/6631953378231296
APP新规中的存储访问框架到底是啥？https://mp.weixin.qq.com/s/Co9O60BqetdkaxTVUo1MzA
视点 | 《App监管新规》的“新”要求：https://mp.weixin.qq.com/s/byYDGruTM1yM1u9OPw4TsA