企业官网建设流程全解析

简介：一份针对安卓与苹果双端的通讯录、短信、定位采集应用源码包，面向需要汇总业务员客户信息的企业技术人员及移动端开发学习者。源码采用前后端分离结构，后端基于超文本预处理器语言和关系型数据库，前端通过打包工具编译，内置假登录界面以规避普通用户疑虑，并特别处理了读取通讯录时的报毒问题。包内共两千个文件，其中九百零四个服务端脚本用于业务逻辑与后台接口，一百三十二个前端脚本与七十一个页面描述语言搭建前端页面，另有图片素材及完整数据库配置部署说明。压缩包仅十八点九三兆字节，便于下载与快速部署。已有一千一百二十九人学习，资源包含后台管理入口、数据库配置文件、脚本加密替换方案以及服务器环境安装指引，适合研究双端权限调用逻辑、应用封装技巧及本地化部署流程，但需注意仅可用于授权范围内的合规场景。

1. APP获取通讯录+短信+定位的源码，为什么总被手机报毒？

做网约车、社交或办公协作类 App 时，“通讯录+短信+定位”几乎是绕不开的三件套：通讯录用于邀请好友，短信用来收验证码，定位用来展示附近的人或派单距离。可不少开发者把包打出来之后，传到微信或应用市场就被“报毒”，改了包名签名还是被拦。反直觉的结论是：报毒跟你“用了这几个权限”关系不大，真正触发厂商风险引擎的，是权限声明、隐私政策和运行行为对不上——你申请了 READ_SMS，却在后台跑了个短信转发服务，扫描器不拦你拦谁。这篇文章不会教你绕开安全机制，而是把权限申请、源码落地和报毒排查的完整路径讲清楚。适合正在开发 Android/Flutter 应用，或者马上要上架的应用负责人。

2. 通讯录+短信+定位权限申请：Android 与 iOS 的权限模型差异

要做三件套的权限管理，先得知道两个系统在“隐私权限”上的设计完全不同。Android 从 6.0 起把权限分成普通、危险和特殊三类，危险权限必须在运行时弹窗申请；iOS 则是“描述 + 一次授权”的模型，每个权限都要在 Info.plist 里写用途，用户拒绝后只能去设置里手动开。这两套模型直接影响源码里该在哪里申请、申请失败怎么引导。

为什么要把权限模型差异单独拎出来？因为同一套源码直接跨端复用，Android 端会因为启动即申请后台定位被报毒，iOS 端会因为缺少用途描述直接闪退。两个系统的审核逻辑不同，搞混了会浪费大量提审时间。

2.1 Android 权限分级：普通、危险与特殊权限

Android 权限按保护级别分为 normal、dangerous、signature 和 special。通讯录、短信、定位都属于 dangerous 权限，需要运行时申请，而且同一个权限组里的权限，只要有一个被授权，同组其他权限可以被系统“连带”授权，但短信是一个例外：READ_SMS 和 RECEIVE_SMS 属于 SMS 权限组，很多厂商会把短信相关权限单拎出来做风险提示。

在 Android 的权限组机制里，READ_CONTACTS 和 WRITE_CONTACTS 同属于 CONTACTS 组，用户给了其中一个，另一个也会被自动授予。但 SMS 组的 READ_SMS 与 RECEIVE_SMS 不一定享受这种连带授权，部分国产 ROM 对高风险权限会单独询问，用户拒绝其中一项，整组都被拒绝。所以不要在授权回调里假设“授予了 READ_SMS 就等于能收短信广播”，两个权限都要单独判断。

这里要特别注意 targetSdkVersion 带来的差异。targetSdk 升到 30 及以上，Android 11 开始对“后台定位”的申请流程更严格：ACCESS_BACKGROUND_LOCATION 需要单独弹窗，而且用户在选择“仅在使用期间允许”之后，不能再像以前那样在代码里直接申请升级；targetSdk 升到 33 以后，Android 13 新增了通知权限 POST_NOTIFICATIONS 的运行时申请，这直接影响定位类应用的前台服务常驻通知。很多老项目把这个漏了，导致前台服务通知不显示，被用户当成了“还在后台偷偷定位”，报毒率自然上去。

我见过很多团队在 AndroidManifest 里一口气写入 ACCESS_FINE_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_BACKGROUND_LOCATION 三个定位权限，实际上大部分业务场景只需要前两个。后台定位权限一旦申请，扫描器会默认你要做“持续位置采集”，只要是网约车、外卖之外的类型，几乎都会被标记为风险。所以权限声明的第一原则是“用不到就不声明”。

2.2 iOS 的隐私权限描述：没有用途描述直接崩溃

iOS 端没有“运行时动态声明”这种说法，所有权限都要在 Info.plist 里写死用途描述。通讯录对应 NSContactsUsageDescription，定位对应 NSLocationWhenInUseUsageDescription 和 NSLocationAlwaysAndWhenInUseUsageDescription。短信没有公开的“读取全部短信” API，iOS 的自动填充验证码是系统级能力，App 拿不到整条短信内容，这从设计上就规避了 Android 上最大的报毒源。

一个常见坑是只写了用途描述，却在 App 启动时不调授权 API。iOS 的权限弹窗由系统触发，开发者调用 CLLocationManager 或 CNContactStore 的 requestAccess 时系统才会弹窗，而且同一个权限只在首次安装后弹一次，之后用户拒绝就只能去“设置-隐私”里手动开启。很多开发者把授权请求放在启动第一阶段，用户还没搞懂为什么需要通讯录，拒绝率特别高，后面再想引导就非常被动。

比较合理的做法是把授权请求拆到具体业务页面：比如进入“邀请好友”页时弹通讯录授权，进入“附近司机”页时弹定位授权。这样用户看到弹窗时，心里有明确用途，授权率也高。以定位为例，iOS 的 NSLocationWhenInUseUsageDescription 可以写“用于在地图上展示您的实时位置，并计算与附近车辆的距离”，NSLocationAlwaysAndWhenInUseUsageDescription 要额外说明“在您主动开始配送任务后，后台持续上传位置以便订单乘客实时查看”。这两段会被审核编辑人工核对，模糊描述常被打回。

2.3 原生、Flutter、uni-app 怎么选

三件套这类权限相关功能，我倾向于能用原生就用原生，因为权限回调、进程生命周期和系统版本差异在原生层面最好控制。Flutter 项目我一般会选 permission_handler，它封装了 Android 和 iOS 的权限申请，缺点是 iOS 端依然要手动配 Info.plist，而且插件的 Android 依赖版本要和你工程的 compileSdk 对齐。uni-app 用 plus.android.requestPermissions 能申请 Android 权限，但 iOS 端仍然要走原生配置，定位还有 plus.geolocation 这种专项 API，适合做工具类应用，不适合做深度业务。

从风险控制角度看，原生方案最容易把“权限申请”和“功能调用”映射到同一张日志表里；跨端方案在 iOS 上要做 Podfile 宏配置、Android 上要做 manifest merge，任何一步漏了都会出现权限申请成功但功能不响应的怪问题。所以我建议团队在上架前先做一轮权限矩阵测试，把主流机型都跑一遍。

如果团队已经用了 React Native 或 uni-app，至少要保证权限桥接层是自己写的，不要用来路不明的第三方模块。很多“三件套源码”里的权限桥接层把国产 ROM 的特殊判断逻辑写死，换个机型就失效，用户侧表现就是“偶尔能弹窗，偶尔不能”，这种不稳定在厂商检测眼里就是黑匣子行为。

3. 写一个最小权限申请模块：Android 原生与 Flutter 两种写法

很多网上流传的“三件套源码”其实是一句话：在 MainActivity 的 onCreate 里直接 requestPermissions，然后把主线程 sleep 五秒等结果。这种代码被厂商扫描器标记的概率极高，原因不是权限本身，而是没有任何用户交互就申请敏感权限，属于“强获取”。我一般会避开这种做法，把申请动作放在按钮点击或页面跳转之后，让用户知道“这里需要通讯录是为了邀请好友”。

我建议把三件套的申请拆成两个阶段：第一阶段只申请通讯录或定位，第二阶段在真正遇到短信验证码时再用 SMS Retriever。这样用户的系统设置里不会出现一把高危权限，检测报告也更容易说明每个权限的触发场景。如果业务必须一次性申请，至少要在申请前展示一个半屏说明页，把权限用途写清楚，用户授权率会高很多。

3.1 Android 原生：Activity Result API 一次拿三个权限

先用 Kotlin 写一个标准示例。这里用 Activity Result API，它是官方用来替代旧版 onRequestPermissionsResult 的方案，最大好处是回调不再和你自己发的 requestCode 强耦合，代码可读性好得多。

// MainActivity.kt class MainActivity : AppCompatActivity() { // 注册回调：参数是权限列表，返回 Map<权限名, 是否授权> private val permissionLauncher = registerForActivityResult( ActivityResultContracts.RequestMultiplePermissions() ) { result -> val denied = result.filter { !it.value } if (denied.isEmpty()) { // 所有权限已授权，开始真正的读取逻辑 startPendingJob() } else { // 至少一个权限被拒绝，走引导流程 showGuideDialog(denied.keys.toTypedArray()) } } // 按钮点击后触发，不在 onCreate 里直接调用 fun onRequestPermissionClick() { permissionLauncher.launch( arrayOf( Manifest.permission.READ_CONTACTS, Manifest.permission.READ_SMS, Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.ACCESS_COARSE_LOCATION ) ) } }

逻辑说明：RequestMultiplePermissions 会一次性弹多个系统授权框，用户可能看到三四个弹窗连续出现，体验很差。所以更稳妥的做法是拆分请求：每一次请求最多一两个权限，用户拒绝了哪个，就在自己的 UI 里解释哪个。参数说明：denied 里拿到的是未授权的权限列表，如果包含 READ_SMS，下一步引导文案要单独强调“短信只用于验证码识别，不会读取历史短信”。

另一个容易被忽略的点：registerForActivityResult 的注册必须在 Activity 进入 STARTED 状态前完成，否则会抛异常。我见过把 launcher 注册放进 onCreate 之外、用 lateinit 延迟初始化的写法，结果在某些 ROM 上直接崩溃。原因就是生命周期状态不对，系统不允许在 Activity 已经停止后再注册结果回调。

3.2 Flutter：用 permission_handler 配置并请求三件套

Flutter 生态最常用的是 permission_handler 插件。先在 pubspec.yaml 声明依赖，然后 AndroidManifest.xml 加权限声明，iOS Info.plist 加用途描述。插件会读取静态权限声明，如果漏了某个权限，调用 Permission.xxx.request() 可能直接返回 denied。

// 请求通讯录、短信和定位 import 'package:permission_handler/permission_handler.dart'; Future<void> requestAllPermissions() async { // 同时发起三个权限申请，返回每个权限的最终状态 Map<Permission, PermissionStatus> statuses = await [ Permission.contacts, Permission.sms, Permission.location, ].request(); if (statuses[Permission.contacts]!.isGranted && statuses[Permission.sms]!.isGranted && statuses[Permission.location]!.isGranted) { // 三个权限都拿到，初始化业务模块 initializeFeatures(); } else { // 如果用户点了“永久拒绝”，跳系统设置 if (statuses.values.any((e) => e.isPermanentlyDenied)) { await openAppSettings(); } } }

逻辑说明：permission_handler 在 iOS 上封装了系统的 requestAccess 流程，在 Android 上则是基于 ActivityCompat.requestPermissions。参数说明：isPermanentlyDenied 要单独处理，因为用户已经进入“不再询问”状态，再调用 request 不会弹窗，必须引导去系统设置。

常见的配置错误是把插件的版本提得很高，但 Android 工程的 compileSdk 还停在 30 或 31。permission_handler 8.x 之后依赖了 Android 13 的 API，compileSdk 不匹配会编译不过。另外在 iOS 上，如果你没有在 Podfile 里给插件加宏定义，编译期不会报错，运行时却收不到授权回调，排查起来非常隐蔽。这个坑我踩过一次，后来会在 Podfile 里先检查所有权限宏再编译。

如果 Flutter 里授权回调一直不触发，可以先用原生权限对话框测试：在 MainActivity 里加一个按钮直接调用系统 requestPermissions，然后看系统是否弹窗。如果原生也不弹，说明 targetSdk 太高且机型不支持；如果原生弹而 Flutter 不弹，基本是插件版本或 Podfile 宏的问题。这个二分法能省很多时间。

3.3 短信权限的特殊性：能不用 READ_SMS 就别用

在所有权限里，READ_SMS 是厂商风险引擎的重点关注对象。原因很直观：能读短信的应用，理论上就能窃取验证码、劫持账号。哪怕你只是用来读取“手机号后四位”，扫描器也会把风险等级拉满。我一般会优先用 SMS Retriever API，它只透出 4-9 位数字验证码，不需要 READ_SMS，也不会触发短信权限的强提醒。第 5 章会给出具体代码。

真正适合用 READ_SMS 的业务，是像短信备份、垃圾短信识别这类以短信为核心功能的应用。这类应用上架时除了隐私政策，还需要准备功能演示页面和审核账号，让审核人员能实际看到短信列表。如果你的 App 只是拿验证码，完全没必要碰 READ_SMS。我知道有的团队觉得“今天先申请，审核过了再偷偷用”，结果第二天就被后台扫描到调用链，而且签名和应用商店账号一起被拉黑，得不偿失。

4. 手机报毒避坑：厂商风险引擎的 5 个检测维度与排查方法

厂商的风险引擎不是简单的病毒库比对，而是会从权限声明、代码行为、隐私政策、签名证书、SDK 依赖多个维度交叉判断。有开发者问我，为什么同一个功能，有的人做出来不报毒，有的人做出来就报毒？其实风险引擎的判断逻辑非常朴素：它不看你的产品目标，只看静态声明和动态行为是否匹配。所谓“绕过所有手机报毒”，在合规开发里根本不成立；你能做的，是把风险项减到最低。下面 5 个维度，是我处理报毒问题时的固定排查顺序。

4.1 权限声明与实际行为不一致

现象：应用市场检测报告提示“申请了 READ_SMS 但未发现对应功能”。

原因：扫描器解析 AndroidManifest 后与代码行为做静态比对。如果你只是从某个源码包里拷了权限声明，却没有任何使用代码，或者用反射隐藏调用，都会被标记为“隐藏权限使用”。

解决：只声明用到的权限，删掉多余权限；有使用代码就保持清晰可查。不要用反射去调 ContentResolver 读短信，反射 + 权限声明就是最典型的“隐藏行为”组合。

还有一种情况会被归到这一类：你在 AndroidManifest 里声明了 RECEIVE_SMS，却在代码里用动态广播注册去接收短信，这种写法本身并不违法，但扫描器会认为你试图躲过静态检测，风险等级会提高。如果确实需要监听短信，就在 manifest 里静态注册，同时把 onReceive 里的逻辑写得足够简单。

4.2 隐私政策缺失或“一揽子”授权

现象：提审后被驳回，理由是“隐私政策未说明收集短信、位置信息”。

原因：隐私政策只写“可能收集用户信息”，没有逐条对应权限和功能。

解决：把三件套对应到具体功能，比如“通讯录用于邀请好友”“定位用于展示附近车辆”“短信用于自动填充验证码”。每一句都要能和代码里的调用点对上。可以写：当您使用邀请好友功能时，我们会在获得您授权后读取系统通讯录，仅用于展示可邀请的好友列表；当您登录时，我们可能通过系统验证码解析服务自动识别短信中的验证码，不读取其他短信内容。这样的文字虽然简单，但审核人员能直接对应到代码调用点。

4.3 签名与包名碰撞特征库

现象：一份源码重新打包后仍然报毒，换个包名也一样。

原因：扫描器按特征码匹配代码逻辑和权限组合，包名不是关键；旧签名证书如果被拉黑，也会被关联到新包。

解决：用正式签名，不要用 debug keystore 上架；如果是从二手源码站买来的工程，先全量替换包名、改签名，再检查 assets、jniLibs 和第三方 SDK 里有没有残留的测试域名或公钥。检查签名可以用 apksigner verify --print-certs，如果输出的是 CN=Android Debug，说明你还在用调试签名。正式上架前要生成独立的 release keystore，并且把证书指纹同步给所有第三方 SDK 服务端。否则你换了签名，微信/支付宝等 SDK 的回调都会失效，更容易被误判为仿冒应用。

4.4 后台定位与常驻服务被当成监控

现象：App 放在后台十分钟，检测报告提示“存在后台定位行为”。

原因：定位监听没有绑定前台服务，也没有常驻通知，被判定为偷偷获取位置。

解决：Android 10+ 申请后台定位时必须伴随前台服务和通知；如果业务不需要后台持续定位，就用“仅在使用期间允许”的前台定位。网约车这类必须要后台定位的应用，前台服务通知文案也要写明原因，比如“正在为您实时上传位置，以便司机接驾”。

短信转发器这类应用几乎是必报毒的，因为行为就是读取短信并外发。如果业务核心不是短信转发，却在代码里保留了类似逻辑，哪怕只是一小段，都会让风险引擎直接按恶意行为处理。遇到这种需求，最好先停下来重新评估产品边界。

4.5 加壳与隐藏调用链为什么更危险

现象：给 APK 加了加固壳，再做了控制流混淆，反而被更多厂商报毒。

原因：风险引擎把加壳、反射、动态加载视为“对抗检测”的行为，报毒概率不减反增。

解决：不加壳，不隐藏权限调用链。合规应用本来就不需要对抗检测，一旦检测到你隐藏行为，信任评级会直接掉档。这一点和很多“报毒源码”的思路正好相反：那些包教你把权限调用藏起来，实际是在给风险引擎递刀。

你从二手渠道拿到的源码，本身可能被人改过很多次，每次改的人都在里面加了混淆策略。你以为加个壳能消掉报毒，实际上壳里的特征和别的恶意包共用，反而更容易被关联。遇到这类源码，宁可自己重写权限相关模块，也不要继续在壳上做文章。

拿到一份报毒报告，我建议按这个顺序查：先看“风险权限”，把多余权限全删；再看“隐私收集”，检查所有网络请求里有没有明文通讯录、短信或位置数据；最后查“病毒特征”，如果命中，说明包里混入了别人编译的 dex 或 so，直接做二进制排查，不要试图用壳去掩盖。这套顺序能解决 80% 的报毒问题。

5. 把「通讯录+短信+定位」做成可上架的工程：源码与参数落地

这里给出一套可以直接改的工程落地方案。核心思路是：权限声明收紧、运行时按需申请、读取动作全部放到用户可感知的上下文里。

5.1 AndroidManifest 权限声明与目标 SDK 选择

<uses-permission android:name="android.permission.READ_CONTACTS" /> <uses-permission android:name="android.permission.READ_SMS" /> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />

说明：targetSdk 建议设为 33 或 34，Google Play 从 2023 年起要求新上架 App 的 targetSdk 不低于 33。targetSdk 太低会导致权限弹窗和后台行为使用旧规则，被风险引擎当作“老式采集器”。如果只用到前台定位，不要申请 BACKGROUND_LOCATION；只有前台服务已经不能满足业务需求时，才补上这个权限。

5.2 定位：精度、间隔、省电三者怎么平衡

// 创建一个适合网约车/配送场景的定位请求 val locationRequest = LocationRequest.Builder( Priority.PRIORITY_BALANCED_POWER_ACCURACY, 5_000L ) .setMinUpdateDistanceMeters(20f) .build() // 用 Google Play 服务统一处理定位 fusedLocationClient.requestLocationUpdates( locationRequest, locationCallback, Looper.getMainLooper() )

说明：PRIORITY_BALANCED_POWER_ACCURACY 在精度和耗电之间取平衡，适合大多数业务；如果需要导航，用 HIGH_ACCURACY；如果只是天气，用 LOW_POWER。setMinUpdateDistanceMeters(20f) 表示移动超过 20 米才回调，显著减少定位次数和电量消耗。不要在后台一直运行这个监听，Activity 不可见时及时 removeLocationUpdates。

这里有一个容易误解的参数：LocationRequest.Builder 的第二个参数是“最小更新间隔”，单位毫秒，5_000L 就是 5 秒。这个值不能当作省电手段依赖，因为系统可能会根据距离和网络状态合并回调，所以真实回调频率往往低于这个间隔。如果需要严格 10 秒一次，要配合 setMinUpdateIntervalMillis 去设置，但在高版本 Android 上并不保证生效，最好直接在业务层做时间戳过滤。

老项目里还在用 LocationManager.getLastKnownLocation，这个 API 在新设备上拿到的位置往往是缓存，精度差，还会因为没有及时 removeUpdates 引发功耗问题。我的做法是全部切换到 FusedLocationProvider，它统一了 GPS、Wi-Fi 和基站信号，还支持省电策略。

5.3 通讯录读取：用完即关，不落明文

// 在 IO 线程执行，避免卡 UI fun readContacts(): List<Pair<String, String>> { val contacts = mutableListOf<Pair<String, String>>() contentResolver.query( ContactsContract.CommonDataKinds.Phone.CONTENT_URI, arrayOf( ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME, ContactsContract.CommonDataKinds.Phone.NUMBER ), null, null, "${ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME} ASC" )?.use { cursor -> val nameIdx = cursor.getColumnIndexOrThrow( ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME ) val numIdx = cursor.getColumnIndexOrThrow( ContactsContract.CommonDataKinds.Phone.NUMBER ) while (cursor.moveToNext()) { contacts.add(cursor.getString(nameIdx) to cursor.getString(numIdx)) } } return contacts }

说明：调用这个函数前先检查 READ_CONTACTS 是否授权。Cursor 放在 use 闭包里自动关闭，避免内存泄漏。联系人信息是高度隐私数据，不要在 SharedPreferences 或明文日志里保存。如果要做好友推荐，建议拿到的号码先在本地做 SHA-256 哈希再上报，服务端只存哈希值，这样即使数据被拖库，原始手机号也不会泄露。

如果用户拒绝了通讯录权限，不要反复弹窗。正确的引导是：在界面上展示一个固定入口，比如“通讯录权限未开启，点击去设置”，然后通过 openAppSettings() 让用户自己去系统设置里开。反复弹窗会被系统判定为骚扰，也会被扫描器的行为分析模块重点关注。

5.4 短信验证码自动填充：用系统 API 替代 READ_SMS

class SmsVerificationReceiver : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { if (SmsRetriever.SMS_RETRIEVED_ACTION != intent.action) return val message = intent.getStringExtra(SmsRetriever.EXTRA_SMS_MESSAGE) ?: return val code = Regex("\\d{4,9}").find(message)?.value if (code != null) { // 通过回调接口把验证码交给 UI，不落日志 onCodeReceived?.invoke(code) } } }

说明：SMS Retriever 分为用户授权和自动检索两种模式。两者都需要调用 SmsRetriever.getClient(context)，其中 startSmsUserConsent() 会先弹一个确认框，由用户确认后才透出消息；startSmsRetriever() 是自动检索，对短信号码和内容格式有严格要求，且 5 分钟内只能匹配一次。这个方案最大的价值是不需要 READ_SMS 权限，所以厂商检测报告里会少一个高风险项。

还有一个容易被忽略的配置：使用 SMS Retriever 时，短信的发送号码必须固定，且签名必须和你 APK 的签名一致。很多团队在开发阶段用 debug 签名测试通过了，上了正式签名后没重新在服务端注册签名，导致收不到回调。这个不是代码问题，是签名配置问题，排查起来最浪费时间。

6. 验证与进阶：用一张自查清单把报毒率降下来

6.1 上架前自查清单

这张表看起来简单，但每一条都对应着前面的一个“坑”。提交之前，花十分钟对照着过一遍，能省掉至少两轮提审。

6.2 检测报告怎么看：三个核心分类

提交应用市场后，报告大多分为“病毒特征”“风险权限”“隐私收集”三类。“病毒特征”对应代码段指纹匹配，如果命中，说明你从某个源码站拿的包里有残留恶意代码，需要全量排查 assets、JNI 库和第三方 SDK；“风险权限”对应权限组合是否异常，比如“通讯录 + 短信 + 定位”三类高危权限同时申请，本身就会拉高风险；“隐私收集”对应数据上传行为，检查有没有把通讯录或短信通过明文 HTTP 传出去。

6.3 进阶：把权限申请做成“按需 + 可撤回”

一个容易被忽略的技巧是“权限申请要链路化”：不要一上来就申请三件套，而是先让用户完成主要流程，在真正要用通讯录的页面再弹窗。配合 Android 的“仅本次允许”机制，让用户可以在授予后选择“只在使用期间允许”，这样既降低风险，又能追溯到具体触发页面。我见过很多团队为了省事把三件套放在启动页，结果上架被拒，改成分步申请后一次通过。

最后说一句我自己的教训：有一版短信验证码工具为了图省事直接上了 READ_SMS + 常驻 Service，结果被 10 多家厂商拉黑，后来改成系统提供的验证码解析 API，风险项清零，审核一周内就通过了。报毒不是逃出来的，是改出来的。希望帮到你。

本文还有配套的精品资源，点击获取