简介这是一套面向移动应用开发者与学生群体的跨平台通讯录、相册管理及短信与视频通话功能源码项目支持安卓及苹果双端。压缩包共5个文件包含APK安装包、IPA安装包、SQL数据库脚本、后台服务压缩包与搭建教程TXT整体仅20.09MB结构清晰便于查阅。目前已有2619人学习下载。源码覆盖联系人管理、图片浏览、短信及多媒体消息服务等核心模块并可通过附带的文本教程配合雷电模拟器快速安装调试无需真实设备。后台服务与数据库脚本则提供了完整的数据存储与通信处理思路适合进行移动端通信类项目的架构分析、毕业设计参考或二次功能开发对理解跨平台数据同步和媒体交互也有较好的学习价值。1. 这三个权限为什么被安卓系统钉在“敏感名单”里“通讯录、相册、短信”这三个词放在同一个标题下还带着“源码”和“提供研究”我第一反应是皱眉——这个组合太容易被往歪了想。但如果换个角度它恰好是安卓开发里最能体现“权限设计”和“数据合规”的一组典型场景。我这些年见过太多应用因为一口气申请了这三个权限上架审核被打回好几次还不知道问题出在哪。也有不少初学者拿到类似项目只会复制粘贴权限声明却说不清每个权限背后系统限制的逻辑。这篇博文想聊的不是怎么把这些数据拿到手而是反过来研究系统为什么把这三类数据管得那么严在合规框架下一个包含通讯录、相册、短信处理能力的应用应该怎么设计、怎么写、怎么排查问题。如果你在做联系人管理工具、相册备份应用、短信验证码辅助类产品或者课程设计里正好需要处理敏感权限这条路线值得完整跟一遍。1.1 通讯录关系链数据为什么是最先被收紧的通讯录不是一串名字加号码它是社交关系链。拿到一份完整通讯录结合机主身份信息可以推算出家庭关系、同事网络、消费水平甚至日常活动轨迹。这些数据组合起来比单一的身份信息值钱得多也正因如此它长期是黑灰产盯上的目标。安卓系统从 Android 6.0 开始引入运行时权限机制把READ_CONTACTS归入危险权限应用在读取联系人前必须弹窗让用户手动确认。在更早的版本里应用安装时展示一次权限清单就算“告知”了用户通常看都不看直接点安装。运行时权限的出现等于把决定权从“安装时一次性背书”改成了“使用时逐次确认”这是通讯录数据保护的第一道闸门。值得注意的是通讯录权限在代码里虽然只是几行声明和一次checkSelfPermission但它触发的用户疑虑远高于普通权限。原因很简单用户能直观感知到“我的联系人列表被人拿走了”。如果你做的是联系人管理类应用这个权限绕不开但一定要让用户清楚知道为什么要给。1.2 相册从“存储权限”到“细分媒体权限”的演进相册相关权限的收紧过程最典型。早期的安卓应用读相册只要声明一个READ_EXTERNAL_STORAGE用户授权后就能读取整个共享存储空间。这个权限模型的漏洞在于应用明明只是想选一张头像却拿到了你全部照片的读取能力。Android 10 开始引入分区存储应用只能直接访问自己的私有目录外部图片、视频、音频必须通过 MediaStore 的受控接口访问。到了 Android 13系统干脆把旧的存储权限拆成READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO三份用户可以只给图片权限而不给视频权限。Android 14 又进一步允许用户“选择部分照片授予访问权”。这一整套演进背后的逻辑很清晰把“整个存储空间的宽泛钥匙”逐步换成“只开一扇门的钥匙”。如果还有人抱着旧思维在工程里无脑申请READ_EXTERNAL_STORAGE在 Android 13 以上设备基本是拿不到数据的就算拿到了上架审核也会被单独拎出来问话。1.3 短信验证码与隐私交汇处的高危地带短信权限是三个里面最敏感的。原因不是短信内容本身有多机密而是短信验证码已经成为大多数账号系统的最后一道防线。一个能读短信的应用等于可以自动收割验证码再配合通讯录数据几乎能完成账号接管链条里最危险的一环。所以READ_SMS、RECEIVE_SMS在应用商店的审核框架里属于极高敏感级别普通工具类应用基本没有获批的可能。无论是 Google Play 还是国内主流商店都要求应用必须先证明自己是默认短信应用、或者核心功能确实围绕短信处理展开否则不会批准你用这个权限。如果只是做验证码自动填充正确路线是使用 SMS Retriever API它不需要申请任何短信权限系统会直接把发给你的验证码短信精准推送给匹配的应用。这个设计本质上是把“读取全部短信”的能力从开发者手里收走只留下“用户真正需要的那一条验证码”的窄通道。数据类别对应权限常量权限级别核心限制推荐替代方案通讯录READ_CONTACTS危险权限需运行时申请商店审核关注关系链数据的使用目的系统联系人选择器ACTION_PICK相册READ_MEDIA_IMAGESAndroid 13READ_EXTERNAL_STORAGEAndroid 12-危险权限分区存储限制Android 14 支持部分照片授权系统 Photo Picker短信READ_SMS/RECEIVE_SMS危险权限/极高敏感仅默认短信应用或核心功能场景可申请SMS Retriever API2. 研究型项目的基础工程怎么搭版本策略与授权脚手架明确权限的敏感度之后下一步是把工程底座搭对。很多人拿到“源码型”项目第一件事是把代码跑起来看效果这没错但如果工程本身的版本策略就是错的跑起来之后的行为和预期会差得很远排查起来也一头雾水。2.1 版本基线的选择minSdk 24 与 targetSdk 34合规研究的第一步是站在当前系统版本的行为规则上做开发而不是躲开它。我建议把compileSdk和targetSdk都设置到当前主流水准比如 34minSdk可以放在 24 左右。有人图省事把targetSdk拉得很低以为这样能绕开高版本的系统限制实际上这正好踩坑。新系统对低targetSdk应用有兼容性降级提示应用市场也普遍要求达到一定等级更关键的是低 targetSdk 应用在高版本系统上运行时权限行为处于旧的兼容模式代码里用新权限写法去判断两边会对不上。这个问题我在后面排查章节会详细展开。android { compileSdk 34 defaultConfig { applicationId com.example.sensitivepermissionresearch minSdk 24 targetSdk 34 } }2.2 权限状态管理三种状态的分支处理权限不是一锤子买卖。用户在系统弹窗点了拒绝之后应用还会遇到“下次再问会不会被系统自动忽略”的问题。Android 有一套“永久拒绝”机制用户连续拒绝两次后系统不再弹窗后续请求会直接回调false。所以应用层必须维护三种状态已授权、未授权但可以弹窗、永久拒绝。我建议写一个统一的权限管理工具类所有涉及权限判断的地方都走这个类不要在业务代码里散落大量ContextCompat.checkSelfPermission判断否则后面改一处要翻遍全项目。enum class PermissionState { GRANTED, DENIED_CAN_RETRY, DENIED_FOREVER } fun getPermissionState(context: Context, permission: String): PermissionState { return if (ContextCompat.checkSelfPermission(context, permission) PackageManager.PERMISSION_GRANTED) { PermissionState.GRANTED } else if (ActivityCompat.shouldShowRequestPermissionRationale(activity, permission)) { PermissionState.DENIED_CAN_RETRY } else { PermissionState.DENIED_FOREVER } }注意shouldShowRequestPermissionRationale这个判断的关键语义首次请求前返回 false被拒绝后返回 true被拒绝且勾选了“不再询问”后返回 false。很多人把它当成“是否被拒绝过”的判断其实它是“是否还能弹窗”的判断。2.3 数据流向研究数据只进沙盒不出设备做敏感权限研究数据流向最好坚持一个原则只进不出。所有读取到的数据都只留在应用私有目录里不写外部共享目录不通过任何网络接口上传。如果确实需要统计分析只上报脱敏后的计数比如“本地有 300 条联系人记录”而不是上报联系人内容本身。这不只是给自己省审核麻烦也是在给用户一个实在的交代。很多项目翻车不是功能实现有问题而是数据处理链路经不起追问。一个连完整通讯录副本都往本地明文存储的应用不管跑得多流畅都称不上合格。3. 通讯录、相册、短信三个模块的实现路线与正当打开方式工程底座就绪后进入核心功能的实现。这三个模块说起来都是“读数据”但各有各的技术细节和适配陷阱逐个拆开讲更容易说清楚。3.1 通讯录模块用最小字段集查询避免整表扫描读取通讯录的标准入口是ContentResolver加ContactsContract。这里我特别强调一点查询时要明确 projection只取真正用到的字段。别图省事直接传 null 或者用“*”联系人表字段非常多把整行数据拉回来既浪费内存又让代码审查的人产生“你为什么需要这些字段”的疑问。一个做联系人备份的管理工具通常只需要姓名、号码、最近更新时间这几个字段就够了。val projection arrayOf( ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER, ContactsContract.CommonDataKinds.Phone.CONTACT_LAST_UPDATED_TIMESTAMP ) val cursor contentResolver.query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, projection, null, null, ${ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME} ASC )另外要注意读取时序。几万条联系人数据的查询如果直接跑在主线程界面会明显卡顿甚至触发StrictMode警告。正确做法是放到协程或者子线程里执行必要时加个分页一次读 500 条配合RecyclerView的加载更多来做。我在真机上实测过3000 条以下一次性读取问题不大超过 8000 条就能感觉到明显的掉帧。3.2 相册模块优先系统 Photo Picker而不是自己扫图库如果你只是“让用户选一张图”别自己造轮子直接用ActivityResultContracts.PickVisualMedia调起系统 Photo Picker。这个方案的好处很直接不需要申请任何存储权限也不需要处理 Android 13 和 Android 14 之间的权限差异用户在自己熟悉的选择界面里选图系统帮你完成所有访问控制你拿到的只是一个 content URI。val pickMedia registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - uri?.let { // 这里拿到的是 content URI直接加载或复制到私有目录 } } pickMedia.launch( PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly) )只有在应用场景必须自己浏览整个媒体库时——比如做相册整理、备份工具——才考虑用 MediaStore 查询并申请READ_MEDIA_IMAGES。一个实用的小技巧列表页展示缩略图时尽量用 MediaStore 自带的缩略图字段或者图片加载库的缩略图接口不要直接加载原图。几百张图片的列表原图加载和缩略图加载的性能差异在天上地下前者会让你 APP 卡到用户直接卸载。3.3 短信模块优先“免权限”方案直接读取留作备选短信场景里九成需求是验证码自动填充而这个需求根本不需要申请READ_SMS。用 SMS Retriever API应用先在客户端注册一个唯一的 Hash 字符串服务端发短信时把这串 Hash 写进内容里系统会把匹配的短信直接发给应用。整个过程不需要任何短信权限审核风险低体验也更好——不会出现那种系统提示“应用想要读取你的短信”的红色警告。SmsRetrieverClient client SmsRetriever.getClient(context) client.startSmsUserConsent(8613800138000) // 指定号码只有当你确实在做“短信备份”“短信管理”这类核心功能时才需要申请READ_SMS。这种情况下应用通常还得被设定为默认短信应用才能拿到授权而且商店审核时会被要求证明这个应用确实需要READ_SMS才能完成核心功能。对普通项目来说这条路几乎走不通所以我的建议是能用替代方案就坚决不用直接读取。4. 权限申请不是弹窗那么简单节奏、文案与二次引导很多项目喜欢在MainActivity的onCreate里一口气申请全部权限这是我见过最差的设计。用户刚打开应用还不知道你要干嘛弹窗一个接一个大部分人会全部拒绝后面再想拿到授权就难了。权限申请这件事节奏比代码本身更重要。4.1 权限触发的时机让用户理解“功能走到哪权限要到哪”正确的节奏是功能驱动。用户走到“同步联系人”按钮你才申请READ_CONTACTS用户点“添加到相册”才申请图片访问权限。权限请求和用户当前动作之间要有明确的因果关系用户才更容易接受。反过来一个记账应用在启动时就弹出“需要读取您的短信”用户第一反应绝对是“你想干嘛”。这个道理说起来简单但实际操作中需要克制。功能列表里凡是用不到的权限一律不要申请。我见过某些项目为了“以后可能用得上”提前把三个敏感权限全部声明进 Manifest结果审核被拒连累了整个版本上线。4.2 系统弹窗前的业务说明一句有效文案胜过重新弹窗系统权限弹窗里的说明文字是应用名加一句固定描述不会自动向用户解释业务背景。所以在正式调用系统授权前建议先在自己应用内弹一个说明层告诉用户三件事这个功能为什么需要权限、数据用来做什么、不会被上传到哪里。等用户点击同意说明层再调用系统授权弹窗。这一步虽然多了一个环节但转化率通常比直接弹系统弹窗高不少。用户拒绝权限很多时候不是真的不愿意给而是不知道给了之后会发生什么。把话说清楚拒绝率会明显下降。4.3 被拒绝后的处理链路不纠缠给退路一旦进入永久拒绝状态不要反复弹窗硬问。更好的做法是用一个引导页告知“该功能需要通讯录权限请前往系统设置开启”按钮可以直接跳转到应用设置详情页代码就是Settings.ACTION_APPLICATION_DETAILS_SETTINGS。这比让用户自己翻到设置里去慢慢找你的应用体验要好得多。val intent Intent( Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.parse(package:$packageName) ) startActivity(intent)4.4 一个可参考的权限请求实现把前面几节串起来一个比较完整的权限请求流程是这样的val requestPermission registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted - if (granted) { // 继续执行需要权限的逻辑 } else { // 判断是否永久拒绝决定展示引导页还是直接提示 } } // 1. 检查权限状态 when (getPermissionState(this, Manifest.permission.READ_CONTACTS)) { PermissionState.GRANTED - loadContacts() PermissionState.DENIED_CAN_RETRY - showRationaleDialog() PermissionState.DENIED_FOREVER - showSettingsGuide() }核心思路就一条每一次弹窗都要有明确的目的和上下文不能把系统弹窗当作用户教育的唯一手段。5. 数据脱敏和存储加密研究代码里必须守住的两条底线功能能跑通只是第一步。真正让一个项目从“能跑”变成“能拿得出手”的是数据处理环节是否经得起推敲。有三件事我每次做敏感权限项目都会反复检查。5.1 日志脱敏手机上的一行日志也可能成为突破口我见过最危险的代码是Log.d(Contact, contact.number)。开发阶段无所谓但一旦应用发布日志被上报到崩溃分析平台或者被 adb 命令抓取真实的手机号、姓名就会泄露出去。哪怕只是调试版本也建议先做脱敏再打印只保留必要的定位信息。fun maskPhone(number: String): String { return if (number.length 7) { number.substring(0, 3) **** number.substring(number.length - 4) } else { **** } }脱敏后的信息足够定位大多数 bug同时把泄露风险降到最低。养成这个习惯之后你会发现排查问题时反而更容易聚焦——因为你不容易在日志里被一堆完整的个人信息分心。5.2 标识符加盐哈希脱敏不是删掉而是不可逆转换有人觉得脱敏就是把手机号换成 MD5。这个想法很危险。手机号是典型的低熵值总共就十几亿个组合网上现成的彩虹表可以秒解一整段号码的 MD5。正确做法是加盐哈希为每个用户生成一个随机盐把盐和哈希值一起存储。这样即使哈希泄露也无法反向推出原文。fun saltedHash(input: String, salt: ByteArray): String { val digest MessageDigest.getInstance(SHA-256) digest.update(salt) return digest.digest(input.toByteArray()).joinToString() { %02x.format(it) } }加盐哈希的代价是每次比对都需要带上盐但对于通讯录、短信这类低熵数据这是值得的。5.3 存储加密与最小化数据躺在本地也要上锁如果要把读取到的数据落盘建议用 Jetpack Security 的EncryptedFile或者把数据库换成 SQLCipher。联系人和短信这类数据的本地存储也应当是加密的因为手机丢失、备份文件泄露都是现实威胁。最后一条原则是数据最小化。不要在本地存“完整通讯录副本”这种大而全的数据只保留当前功能需要的最小字段集。功能迭代后不再使用的数据要主动清理。这既是合规要求也是降低自身维护成本的做法。6. 真机调试中的权限异常排查一次完整的排错过程权限类问题最磨人的地方在于不同系统版本、不同状态下的行为千差万别有时候代码看着没问题真机上就是跑不通。下面用一次真实排查过程把思路完整梳理一遍。6.1 现象Android 13 上申请了权限却读不到相册某次调试相册类项目设备是 Android 13Manifest 里写好了READ_MEDIA_IMAGES运行到相册页面也正常弹窗用户点了允许但查询 MediaStore 返回的是空 cursor。第一反应是查询代码写错了反复检查后确认查询语句没问题权限回调状态也是granted。后来用adb shell dumpsys package查看发现授予的权限列表里READ_MEDIA_IMAGES的 granted 状态确实为 true但应用的 targetSdk 实际停留在 29。系统在兼容模式下把新权限映射到了旧的READ_EXTERNAL_STORAGE代码里按新权限写法去查询 MediaStore两边对不上返回空结果也就顺理成章了。6.2 排查链路从授权状态到查询条件的逐层验证经历过这次排错之后我整理了一套固定的排查链路遇到权限类问题按顺序走一遍基本能定位大部分问题第一步确认基础信息设备 API 级别、应用 targetSdk 版本两个信息不一致时会有一堆兼容性问题。第二步确认权限真实状态用adb shell dumpsys package 包名 | grep -A 5 permission查看实际授予的权限列表不要只依赖代码里的回调。第三步确认查询代码分支Android 13 及以上走READ_MEDIA_IMAGES分支Android 12 及以下走READ_EXTERNAL_STORAGE分支两个分支要分开写。第四步确认 MediaStore 查询条件curosr 为空不一定是权限问题也可能是筛选条件写错比如把旧版本的绝对路径硬编码进了新系统无法访问的目录。6.3 第二个坑同时申请多个权限时的交互抖动另一个常见问题是多个权限同时申请时的用户交互。比如通讯录和存储权限同时弹窗用户手滑点了某一次的“拒绝”应用当场收到 false 就中断了整个流程但用户后面可能又愿意给另一个权限重试时系统不再弹窗直接返回 false也没有任何提示。整个体验非常差。这种问题没有特别优雅的代码解法但可以做一个统一的“权限未完全满足”状态判断把所有还没拿到的权限汇总起来一次性引导用户去设置页开启而不是每次进页面都重新请求一次。尾声权限不是代码里的布尔值而是用户和开发者之间的一纸契约研究通讯录、相册、短信相关的项目最大的收获不是学会几段读取数据的代码。我个人的体会是这几年在处理敏感权限项目时最花时间的往往不是功能实现而是“怎么把权限申请得合理”和“怎么把数据处理得干净”。用户在系统弹窗上点下“允许”的那一下交付的是信任不是义务。真正值得研究的恰恰是系统那些限制背后的设计意图——理解它们想防什么你就知道产品应该往哪个方向做而不是往哪个方向绕。本文还有配套的精品资源点击获取 安卓敏感权限合规指南：通讯录相册短信的权限设计与实现
简介这是一套面向移动应用开发者与学生群体的跨平台通讯录、相册管理及短信与视频通话功能源码项目支持安卓及苹果双端。压缩包共5个文件包含APK安装包、IPA安装包、SQL数据库脚本、后台服务压缩包与搭建教程TXT整体仅20.09MB结构清晰便于查阅。目前已有2619人学习下载。源码覆盖联系人管理、图片浏览、短信及多媒体消息服务等核心模块并可通过附带的文本教程配合雷电模拟器快速安装调试无需真实设备。后台服务与数据库脚本则提供了完整的数据存储与通信处理思路适合进行移动端通信类项目的架构分析、毕业设计参考或二次功能开发对理解跨平台数据同步和媒体交互也有较好的学习价值。1. 这三个权限为什么被安卓系统钉在“敏感名单”里“通讯录、相册、短信”这三个词放在同一个标题下还带着“源码”和“提供研究”我第一反应是皱眉——这个组合太容易被往歪了想。但如果换个角度它恰好是安卓开发里最能体现“权限设计”和“数据合规”的一组典型场景。我这些年见过太多应用因为一口气申请了这三个权限上架审核被打回好几次还不知道问题出在哪。也有不少初学者拿到类似项目只会复制粘贴权限声明却说不清每个权限背后系统限制的逻辑。这篇博文想聊的不是怎么把这些数据拿到手而是反过来研究系统为什么把这三类数据管得那么严在合规框架下一个包含通讯录、相册、短信处理能力的应用应该怎么设计、怎么写、怎么排查问题。如果你在做联系人管理工具、相册备份应用、短信验证码辅助类产品或者课程设计里正好需要处理敏感权限这条路线值得完整跟一遍。1.1 通讯录关系链数据为什么是最先被收紧的通讯录不是一串名字加号码它是社交关系链。拿到一份完整通讯录结合机主身份信息可以推算出家庭关系、同事网络、消费水平甚至日常活动轨迹。这些数据组合起来比单一的身份信息值钱得多也正因如此它长期是黑灰产盯上的目标。安卓系统从 Android 6.0 开始引入运行时权限机制把READ_CONTACTS归入危险权限应用在读取联系人前必须弹窗让用户手动确认。在更早的版本里应用安装时展示一次权限清单就算“告知”了用户通常看都不看直接点安装。运行时权限的出现等于把决定权从“安装时一次性背书”改成了“使用时逐次确认”这是通讯录数据保护的第一道闸门。值得注意的是通讯录权限在代码里虽然只是几行声明和一次checkSelfPermission但它触发的用户疑虑远高于普通权限。原因很简单用户能直观感知到“我的联系人列表被人拿走了”。如果你做的是联系人管理类应用这个权限绕不开但一定要让用户清楚知道为什么要给。1.2 相册从“存储权限”到“细分媒体权限”的演进相册相关权限的收紧过程最典型。早期的安卓应用读相册只要声明一个READ_EXTERNAL_STORAGE用户授权后就能读取整个共享存储空间。这个权限模型的漏洞在于应用明明只是想选一张头像却拿到了你全部照片的读取能力。Android 10 开始引入分区存储应用只能直接访问自己的私有目录外部图片、视频、音频必须通过 MediaStore 的受控接口访问。到了 Android 13系统干脆把旧的存储权限拆成READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO三份用户可以只给图片权限而不给视频权限。Android 14 又进一步允许用户“选择部分照片授予访问权”。这一整套演进背后的逻辑很清晰把“整个存储空间的宽泛钥匙”逐步换成“只开一扇门的钥匙”。如果还有人抱着旧思维在工程里无脑申请READ_EXTERNAL_STORAGE在 Android 13 以上设备基本是拿不到数据的就算拿到了上架审核也会被单独拎出来问话。1.3 短信验证码与隐私交汇处的高危地带短信权限是三个里面最敏感的。原因不是短信内容本身有多机密而是短信验证码已经成为大多数账号系统的最后一道防线。一个能读短信的应用等于可以自动收割验证码再配合通讯录数据几乎能完成账号接管链条里最危险的一环。所以READ_SMS、RECEIVE_SMS在应用商店的审核框架里属于极高敏感级别普通工具类应用基本没有获批的可能。无论是 Google Play 还是国内主流商店都要求应用必须先证明自己是默认短信应用、或者核心功能确实围绕短信处理展开否则不会批准你用这个权限。如果只是做验证码自动填充正确路线是使用 SMS Retriever API它不需要申请任何短信权限系统会直接把发给你的验证码短信精准推送给匹配的应用。这个设计本质上是把“读取全部短信”的能力从开发者手里收走只留下“用户真正需要的那一条验证码”的窄通道。数据类别对应权限常量权限级别核心限制推荐替代方案通讯录READ_CONTACTS危险权限需运行时申请商店审核关注关系链数据的使用目的系统联系人选择器ACTION_PICK相册READ_MEDIA_IMAGESAndroid 13READ_EXTERNAL_STORAGEAndroid 12-危险权限分区存储限制Android 14 支持部分照片授权系统 Photo Picker短信READ_SMS/RECEIVE_SMS危险权限/极高敏感仅默认短信应用或核心功能场景可申请SMS Retriever API2. 研究型项目的基础工程怎么搭版本策略与授权脚手架明确权限的敏感度之后下一步是把工程底座搭对。很多人拿到“源码型”项目第一件事是把代码跑起来看效果这没错但如果工程本身的版本策略就是错的跑起来之后的行为和预期会差得很远排查起来也一头雾水。2.1 版本基线的选择minSdk 24 与 targetSdk 34合规研究的第一步是站在当前系统版本的行为规则上做开发而不是躲开它。我建议把compileSdk和targetSdk都设置到当前主流水准比如 34minSdk可以放在 24 左右。有人图省事把targetSdk拉得很低以为这样能绕开高版本的系统限制实际上这正好踩坑。新系统对低targetSdk应用有兼容性降级提示应用市场也普遍要求达到一定等级更关键的是低 targetSdk 应用在高版本系统上运行时权限行为处于旧的兼容模式代码里用新权限写法去判断两边会对不上。这个问题我在后面排查章节会详细展开。android { compileSdk 34 defaultConfig { applicationId com.example.sensitivepermissionresearch minSdk 24 targetSdk 34 } }2.2 权限状态管理三种状态的分支处理权限不是一锤子买卖。用户在系统弹窗点了拒绝之后应用还会遇到“下次再问会不会被系统自动忽略”的问题。Android 有一套“永久拒绝”机制用户连续拒绝两次后系统不再弹窗后续请求会直接回调false。所以应用层必须维护三种状态已授权、未授权但可以弹窗、永久拒绝。我建议写一个统一的权限管理工具类所有涉及权限判断的地方都走这个类不要在业务代码里散落大量ContextCompat.checkSelfPermission判断否则后面改一处要翻遍全项目。enum class PermissionState { GRANTED, DENIED_CAN_RETRY, DENIED_FOREVER } fun getPermissionState(context: Context, permission: String): PermissionState { return if (ContextCompat.checkSelfPermission(context, permission) PackageManager.PERMISSION_GRANTED) { PermissionState.GRANTED } else if (ActivityCompat.shouldShowRequestPermissionRationale(activity, permission)) { PermissionState.DENIED_CAN_RETRY } else { PermissionState.DENIED_FOREVER } }注意shouldShowRequestPermissionRationale这个判断的关键语义首次请求前返回 false被拒绝后返回 true被拒绝且勾选了“不再询问”后返回 false。很多人把它当成“是否被拒绝过”的判断其实它是“是否还能弹窗”的判断。2.3 数据流向研究数据只进沙盒不出设备做敏感权限研究数据流向最好坚持一个原则只进不出。所有读取到的数据都只留在应用私有目录里不写外部共享目录不通过任何网络接口上传。如果确实需要统计分析只上报脱敏后的计数比如“本地有 300 条联系人记录”而不是上报联系人内容本身。这不只是给自己省审核麻烦也是在给用户一个实在的交代。很多项目翻车不是功能实现有问题而是数据处理链路经不起追问。一个连完整通讯录副本都往本地明文存储的应用不管跑得多流畅都称不上合格。3. 通讯录、相册、短信三个模块的实现路线与正当打开方式工程底座就绪后进入核心功能的实现。这三个模块说起来都是“读数据”但各有各的技术细节和适配陷阱逐个拆开讲更容易说清楚。3.1 通讯录模块用最小字段集查询避免整表扫描读取通讯录的标准入口是ContentResolver加ContactsContract。这里我特别强调一点查询时要明确 projection只取真正用到的字段。别图省事直接传 null 或者用“*”联系人表字段非常多把整行数据拉回来既浪费内存又让代码审查的人产生“你为什么需要这些字段”的疑问。一个做联系人备份的管理工具通常只需要姓名、号码、最近更新时间这几个字段就够了。val projection arrayOf( ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER, ContactsContract.CommonDataKinds.Phone.CONTACT_LAST_UPDATED_TIMESTAMP ) val cursor contentResolver.query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, projection, null, null, ${ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME} ASC )另外要注意读取时序。几万条联系人数据的查询如果直接跑在主线程界面会明显卡顿甚至触发StrictMode警告。正确做法是放到协程或者子线程里执行必要时加个分页一次读 500 条配合RecyclerView的加载更多来做。我在真机上实测过3000 条以下一次性读取问题不大超过 8000 条就能感觉到明显的掉帧。3.2 相册模块优先系统 Photo Picker而不是自己扫图库如果你只是“让用户选一张图”别自己造轮子直接用ActivityResultContracts.PickVisualMedia调起系统 Photo Picker。这个方案的好处很直接不需要申请任何存储权限也不需要处理 Android 13 和 Android 14 之间的权限差异用户在自己熟悉的选择界面里选图系统帮你完成所有访问控制你拿到的只是一个 content URI。val pickMedia registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - uri?.let { // 这里拿到的是 content URI直接加载或复制到私有目录 } } pickMedia.launch( PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly) )只有在应用场景必须自己浏览整个媒体库时——比如做相册整理、备份工具——才考虑用 MediaStore 查询并申请READ_MEDIA_IMAGES。一个实用的小技巧列表页展示缩略图时尽量用 MediaStore 自带的缩略图字段或者图片加载库的缩略图接口不要直接加载原图。几百张图片的列表原图加载和缩略图加载的性能差异在天上地下前者会让你 APP 卡到用户直接卸载。3.3 短信模块优先“免权限”方案直接读取留作备选短信场景里九成需求是验证码自动填充而这个需求根本不需要申请READ_SMS。用 SMS Retriever API应用先在客户端注册一个唯一的 Hash 字符串服务端发短信时把这串 Hash 写进内容里系统会把匹配的短信直接发给应用。整个过程不需要任何短信权限审核风险低体验也更好——不会出现那种系统提示“应用想要读取你的短信”的红色警告。SmsRetrieverClient client SmsRetriever.getClient(context) client.startSmsUserConsent(8613800138000) // 指定号码只有当你确实在做“短信备份”“短信管理”这类核心功能时才需要申请READ_SMS。这种情况下应用通常还得被设定为默认短信应用才能拿到授权而且商店审核时会被要求证明这个应用确实需要READ_SMS才能完成核心功能。对普通项目来说这条路几乎走不通所以我的建议是能用替代方案就坚决不用直接读取。4. 权限申请不是弹窗那么简单节奏、文案与二次引导很多项目喜欢在MainActivity的onCreate里一口气申请全部权限这是我见过最差的设计。用户刚打开应用还不知道你要干嘛弹窗一个接一个大部分人会全部拒绝后面再想拿到授权就难了。权限申请这件事节奏比代码本身更重要。4.1 权限触发的时机让用户理解“功能走到哪权限要到哪”正确的节奏是功能驱动。用户走到“同步联系人”按钮你才申请READ_CONTACTS用户点“添加到相册”才申请图片访问权限。权限请求和用户当前动作之间要有明确的因果关系用户才更容易接受。反过来一个记账应用在启动时就弹出“需要读取您的短信”用户第一反应绝对是“你想干嘛”。这个道理说起来简单但实际操作中需要克制。功能列表里凡是用不到的权限一律不要申请。我见过某些项目为了“以后可能用得上”提前把三个敏感权限全部声明进 Manifest结果审核被拒连累了整个版本上线。4.2 系统弹窗前的业务说明一句有效文案胜过重新弹窗系统权限弹窗里的说明文字是应用名加一句固定描述不会自动向用户解释业务背景。所以在正式调用系统授权前建议先在自己应用内弹一个说明层告诉用户三件事这个功能为什么需要权限、数据用来做什么、不会被上传到哪里。等用户点击同意说明层再调用系统授权弹窗。这一步虽然多了一个环节但转化率通常比直接弹系统弹窗高不少。用户拒绝权限很多时候不是真的不愿意给而是不知道给了之后会发生什么。把话说清楚拒绝率会明显下降。4.3 被拒绝后的处理链路不纠缠给退路一旦进入永久拒绝状态不要反复弹窗硬问。更好的做法是用一个引导页告知“该功能需要通讯录权限请前往系统设置开启”按钮可以直接跳转到应用设置详情页代码就是Settings.ACTION_APPLICATION_DETAILS_SETTINGS。这比让用户自己翻到设置里去慢慢找你的应用体验要好得多。val intent Intent( Settings.ACTION_APPLICATION_DETAILS_SETTINGS, Uri.parse(package:$packageName) ) startActivity(intent)4.4 一个可参考的权限请求实现把前面几节串起来一个比较完整的权限请求流程是这样的val requestPermission registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted - if (granted) { // 继续执行需要权限的逻辑 } else { // 判断是否永久拒绝决定展示引导页还是直接提示 } } // 1. 检查权限状态 when (getPermissionState(this, Manifest.permission.READ_CONTACTS)) { PermissionState.GRANTED - loadContacts() PermissionState.DENIED_CAN_RETRY - showRationaleDialog() PermissionState.DENIED_FOREVER - showSettingsGuide() }核心思路就一条每一次弹窗都要有明确的目的和上下文不能把系统弹窗当作用户教育的唯一手段。5. 数据脱敏和存储加密研究代码里必须守住的两条底线功能能跑通只是第一步。真正让一个项目从“能跑”变成“能拿得出手”的是数据处理环节是否经得起推敲。有三件事我每次做敏感权限项目都会反复检查。5.1 日志脱敏手机上的一行日志也可能成为突破口我见过最危险的代码是Log.d(Contact, contact.number)。开发阶段无所谓但一旦应用发布日志被上报到崩溃分析平台或者被 adb 命令抓取真实的手机号、姓名就会泄露出去。哪怕只是调试版本也建议先做脱敏再打印只保留必要的定位信息。fun maskPhone(number: String): String { return if (number.length 7) { number.substring(0, 3) **** number.substring(number.length - 4) } else { **** } }脱敏后的信息足够定位大多数 bug同时把泄露风险降到最低。养成这个习惯之后你会发现排查问题时反而更容易聚焦——因为你不容易在日志里被一堆完整的个人信息分心。5.2 标识符加盐哈希脱敏不是删掉而是不可逆转换有人觉得脱敏就是把手机号换成 MD5。这个想法很危险。手机号是典型的低熵值总共就十几亿个组合网上现成的彩虹表可以秒解一整段号码的 MD5。正确做法是加盐哈希为每个用户生成一个随机盐把盐和哈希值一起存储。这样即使哈希泄露也无法反向推出原文。fun saltedHash(input: String, salt: ByteArray): String { val digest MessageDigest.getInstance(SHA-256) digest.update(salt) return digest.digest(input.toByteArray()).joinToString() { %02x.format(it) } }加盐哈希的代价是每次比对都需要带上盐但对于通讯录、短信这类低熵数据这是值得的。5.3 存储加密与最小化数据躺在本地也要上锁如果要把读取到的数据落盘建议用 Jetpack Security 的EncryptedFile或者把数据库换成 SQLCipher。联系人和短信这类数据的本地存储也应当是加密的因为手机丢失、备份文件泄露都是现实威胁。最后一条原则是数据最小化。不要在本地存“完整通讯录副本”这种大而全的数据只保留当前功能需要的最小字段集。功能迭代后不再使用的数据要主动清理。这既是合规要求也是降低自身维护成本的做法。6. 真机调试中的权限异常排查一次完整的排错过程权限类问题最磨人的地方在于不同系统版本、不同状态下的行为千差万别有时候代码看着没问题真机上就是跑不通。下面用一次真实排查过程把思路完整梳理一遍。6.1 现象Android 13 上申请了权限却读不到相册某次调试相册类项目设备是 Android 13Manifest 里写好了READ_MEDIA_IMAGES运行到相册页面也正常弹窗用户点了允许但查询 MediaStore 返回的是空 cursor。第一反应是查询代码写错了反复检查后确认查询语句没问题权限回调状态也是granted。后来用adb shell dumpsys package查看发现授予的权限列表里READ_MEDIA_IMAGES的 granted 状态确实为 true但应用的 targetSdk 实际停留在 29。系统在兼容模式下把新权限映射到了旧的READ_EXTERNAL_STORAGE代码里按新权限写法去查询 MediaStore两边对不上返回空结果也就顺理成章了。6.2 排查链路从授权状态到查询条件的逐层验证经历过这次排错之后我整理了一套固定的排查链路遇到权限类问题按顺序走一遍基本能定位大部分问题第一步确认基础信息设备 API 级别、应用 targetSdk 版本两个信息不一致时会有一堆兼容性问题。第二步确认权限真实状态用adb shell dumpsys package 包名 | grep -A 5 permission查看实际授予的权限列表不要只依赖代码里的回调。第三步确认查询代码分支Android 13 及以上走READ_MEDIA_IMAGES分支Android 12 及以下走READ_EXTERNAL_STORAGE分支两个分支要分开写。第四步确认 MediaStore 查询条件curosr 为空不一定是权限问题也可能是筛选条件写错比如把旧版本的绝对路径硬编码进了新系统无法访问的目录。6.3 第二个坑同时申请多个权限时的交互抖动另一个常见问题是多个权限同时申请时的用户交互。比如通讯录和存储权限同时弹窗用户手滑点了某一次的“拒绝”应用当场收到 false 就中断了整个流程但用户后面可能又愿意给另一个权限重试时系统不再弹窗直接返回 false也没有任何提示。整个体验非常差。这种问题没有特别优雅的代码解法但可以做一个统一的“权限未完全满足”状态判断把所有还没拿到的权限汇总起来一次性引导用户去设置页开启而不是每次进页面都重新请求一次。尾声权限不是代码里的布尔值而是用户和开发者之间的一纸契约研究通讯录、相册、短信相关的项目最大的收获不是学会几段读取数据的代码。我个人的体会是这几年在处理敏感权限项目时最花时间的往往不是功能实现而是“怎么把权限申请得合理”和“怎么把数据处理得干净”。用户在系统弹窗上点下“允许”的那一下交付的是信任不是义务。真正值得研究的恰恰是系统那些限制背后的设计意图——理解它们想防什么你就知道产品应该往哪个方向做而不是往哪个方向绕。本文还有配套的精品资源点击获取