Android 设备信息采集合规指南：MobileInfo 需要哪些权限、如何避免过度收集
项目地址: https://gitcode.com/gh_mirrors/mo/MobileInfo MobileInfo 是一个 Android 设备硬件信息采集框架，提供 CPU、内存、电池、屏幕、SIM 卡、信号、网络等模块化的设备参数读取能力。本文以 MobileInfo 为例，梳理 Android 设备信息采集需要申请哪些权限、哪些数据可以"免权限"获取，并给出避免过度收集个人信息的实操建议，帮助开发者合规开发，也帮助普通用户看懂 App 的权限申请。
📱 MobileInfo 是什么：模块化采集设备参数
MobileInfo 采用「采集框架 + 演示 App」的结构：
- 采集框架：
mobilehardware/模块，按功能拆分成 30 多个 Helper/Info 类（如 SimCardInfo.java、CpuHelper.java），统一通过 MobileHardWareHelper.java 对外提供 JSON 格式的设备信息； - 演示 App：
app/模块，分「安全 / 应用 / 网络 / 手机 / 唯一标识」五个页签展示采集结果。
MobileInfo 演示 App 的设备参数采集界面（对应 README 中 Display 部分的 param.gif 演示动图）
值得一提的是，项目 README 开头即声明：请自觉遵循《信息安全技术移动互联网应用（App）收集个人信息基本规范（草案）》，合规意识贯穿了整个项目设计。
🔍 权限清单：MobileInfo 到底申请了哪些权限
权限声明分布在两份清单文件中：演示 App 的 AndroidManifest.xml 和框架模块的 AndroidManifest.xml。逐条拆解如下：
| 权限 | 用途 | 对应采集模块 |
|---|---|---|
READ_PHONE_STATE | 读取电话/设备标识 | SIM 卡信息、设备唯一标识（SimCardInfo.java） |
ACCESS_COARSE_LOCATION / ACCESS_FINE_LOCATION | 读取粗略/精确位置 | 频段、信号相关诊断 |
CAMERA | 读取摄像头参数 | 相机能力检测（CameraHelper） |
BLUETOOTH | 读取蓝牙适配器信息 | 蓝牙模块（BluetoothInfo） |
ACCESS_WIFI_STATE | 读取 WiFi 状态 | WiFi 列表、信号强度 |
ACCESS_NETWORK_STATE | 读取网络连接状态 | 网络诊断（NetWorkInfo） |
CHANGE_WIFI_STATE / CHANGE_NETWORK_STATE | 修改网络状态 | 框架层预留，仅诊断场景使用 |
INTERNET | 访问网络 | 拉取远程配置（如 OAID 供应商标配 supplierconfig.json） |
WRITE_EXTERNAL_STORAGE | 写入外部存储 | 将采集结果导出为 output.json |
从清单可以看出一个关键事实：MobileInfo 的绝大多数采集项（CPU、内存、电池、屏幕、Build 信息）根本不需要任何运行时权限，权限只集中在少数涉及系统敏感资源的模块上——这正是"权限最小化"的正面示范。
⚖️ 如何避免过度收集：4 条可落地的原则
1. 运行时动态申请，而非安装时全量索要
Android 6.0 之后，危险权限必须在用户真正触发对应功能时才弹窗申请。MobileInfo 用 PermissionUtil.java 实现了动态申请：逐项 checkSelfPermission 检测，只把"未授权"的权限打包申请，已授权的绝不重复打扰。
建议：把权限申请放到用户进入"SIM 卡""位置"等具体功能页时触发，而不是一进 App 就弹一大串请求框——后者是应用商店审核的重灾区。
2. 能不采集的敏感字段，直接不采集
对比 SimCardInfo.java 可以看到，IMSI（用户识别码）等敏感字段的读取代码已被注释禁用，只保留"是否有 SIM 卡"这类非敏感状态。同时框架层通过 MobInitializer.java 把 Context 以内部初始化方式注入，采集结果仅以 JSON 返回给调用方，不额外落盘。
另外要特别注意系统版本差异：
- Android 10 起，获取 IMEI、
SIM_SERIAL等硬件标识需要READ_PHONE_STATE，且对用户可见的获取行为会受到系统拦截； Build.getSerial()在 Android 8.0+ 同样需要该权限（见 PhoneIdHelper.java 中对版本号的分支处理）。
合规替代方案：优先使用 ANDROID_ID 或厂商 OAID（项目中的 oaid/ 模块即为此设计）来标识设备，而非硬件序列号。
3. 本地处理优先，数据不出端
MobileInfo 采集完成后生成 output.json 这类本地报告，采集逻辑全部在设备端完成。对于只需要本地判断的场景（如 Root 检测、模拟器检测），不应为此申请网络或位置权限——"权限与功能不匹配"是过度收集的典型特征。
4. 声明的权限要"够用就收手"
注意框架清单中比 App 多出的 CHANGE_WIFI_STATE、CHANGE_NETWORK_STATE 两个修改型权限。只做"读取诊断"的 App 不需要"修改"权限。发布正式产品前，建议逐项自查：这条权限删掉后，用户能感知的功能损失是什么？ 答不上来，就该删。
📋 普通用户自查：App 是否超范围收集
安装前或日常使用中，可用以下清单快速判断：
- 看用途与权限是否匹配：天气 App 申请摄像头、计算器 App 读取电话状态，均属异常；
- 拒绝非必要权限后观察：若拒绝位置权限后 App 仍能完成核心功能，说明其"强依赖"不成立；
- 关注唯一标识类申请：反复索取 IMEI、序列号而业务上只需"识别登录用户"的，大概率过度收集；
- 用 MobileInfo 这类工具反向理解：它把每个模块对应的系统权限透明展示出来，是理解"哪些数据需要什么代价"的好教材。
✅ 总结
- MobileInfo 展示了 Android 设备信息采集的完整权限版图：9 项权限中，只有电话状态、位置、相机、蓝牙 4 类属于危险权限，其余 CPU/内存/屏幕等参数零权限即可采集；
- 避免过度收集的核心是四件事：用时再申请、敏感字段不采集、数据本地处理、权限声明做减法；
- 框架与演示 App 双模块结构清晰，权限声明、动态申请、敏感字段禁用均可在源码中逐一对照学习，是研究 Android 合规采集的优秀范例。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
