做Android定制系统这几年被问得最多的问题之一就是“为什么我预装的应用装好了权限却还要用户安装完以后逐个点弹窗授权”尤其是车机、大屏、收银机、企业PDA这类场景用户根本不可能跟你一个个点“允许”。更麻烦的是Android 13/14/15这几个版本的权限模型一年比一年收紧早年那种“写死权限、安装即授予”的思路已经行不通了。这篇文章我就把Android 13/14/15上默认授权应用权限的几种实现方法从最基础的adb命令调试到framework源码层修改再到出厂数据预置完整梳理一遍。适合ROM定制工程师、企业设备方案商、车机大屏开发者以及做Android自动化测试时被权限弹窗卡住的朋友。不敢说所有细节都对得上你手里的源码但只要把每一条路径的逻辑理清楚你在自己项目里改起来会快很多。1. 为什么默认授权在Android 13/14/15上越来越难搞1.1 Android权限模型演变的来龙去脉从Android 6.0引入运行时权限Runtime Permission开始应用的危险权限就分成了两派安装时静态授予和运行时动态申请。当时Google还允许安装器在安装界面一键授予“全部权限”导致很多圈外用户直接点允许App拿到了一堆跟他使用需求完全无关的权限。到了Android 11API 30以后安装流程对targetSdkVersion 30以上的应用做了严格限制安装时不允许将dangerous权限自动授予给应用必须由用户在运行时主动确认。我在Android 12上就踩过这个坑当时用老办法在PackageInstaller流程里给预装应用提前授权结果发现完全无效后来一查代码才发现是InstallPackageHelper里面对权限授予的时机做了调整。Android 13的变化更大。通知权限被单独拆成了POST_NOTIFICATIONS原来用READ_EXTERNAL_STORAGE一把梭的存储权限也被拆成了READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO三块。如果你的默认授权逻辑还在按Android 10时代那套权限名来写大概率在13上面会看到“授予成功但应用依然拿不到数据”的诡异现象。Android 14和15表面上没有动授权框架的大结构但对预装应用、后台权限、媒体选择器这些边缘场景反复加了限制。说白了Google在默认授权这件事上走得越来越坚决能不给就不给能给临时的绝不给永久的。所以“默认授权”这四个字在现在的Android版本上从来不是改一个开关就能干完的事。1.2 默认授权到底解决什么问题先说场景再说方案这样你才知道哪条路适合你。我接触到的默认授权需求基本就四类车机/大屏设备导航App、语音助手、蓝牙电话都要定位、麦克风、通讯录权限司机不可能在行驶途中逐个点弹窗必须在系统层把权限给到位。企业专用设备扫码枪、巡检PDA、收银一体机屏幕就那么大用户也不是IT人员装上App以后必须“开箱即用”任何权限弹窗都会被当成故障上报到售后。自动化测试环境跑CTS、UIAutomator、Monkey的时候权限弹窗会打断用例严重降低执行效率。测试ROM里预授权一堆系统应用能让整个测试流程顺畅很多。政企定制ROM投标文件里经常写“预置应用无需手动授权即可使用全部核心功能”这种承诺最终还是落到技术实现上。这四个场景的共同点是设备是受控的使用者不是开发者权限授予的逻辑必须在系统启动或应用安装阶段就全部搞定。1.3 三种常见的“默认授权”实现层次根据改动的位置和时机实现默认授权有三个层面我用自己的话总结一下adb/Shell层通过adb shell命令临时授予权限。适合开发联调、自动化测试和少量设备部署但量产设备上不可能用电脑一条条敲命令。Framework源码层修改AOSP的授权逻辑让系统在安装特定白名单应用时自动放行。适合整机ROM定制是真正的“安装即授权”。数据预置层直接往系统的权限数据库文件里写入已授权状态或者开机后在应用层补一次授权。适合量产镜像批量预置但需要特别注意版本兼容性问题。这三个层次不是互相替代的关系而是互相补充。比如量产ROM里我会建议用framework层做兜底再用数据预置解决首次开机时序上的问题。2. 最快速的调试方案adb pm grant与Settings注入2.1 pm grant到底能做什么、不能做什么先讲最接地气的方式。很多时候你只是要在测试机上让某个App拿到权限但发现手机已经停了开发者选项里“安装时授权”的功能那直接用adb就行# 查看设备上所有运行时权限 adb shell pm list permissions -g # 给指定应用授予权限 adb shell pm grant com.example.testapp android.permission.CAMERA adb shell pm grant com.example.testapp android.permission.ACCESS_FINE_LOCATION adb shell pm grant com.example.testapp android.permission.RECORD_AUDIO # 收回权限 adb shell pm revoke com.example.testapp android.permission.CAMERA这个命令的原理是直接调用PackageManagerService的grantRuntimePermission方法把权限授予状态写入当前用户的状态里。优点是不需要root不需要改系统一条命令立刻生效非常适合开发期验证应用对各种权限的响应。但pm grant有几个硬性限制我测试过程中反复踩到只能授予运行时权限dangerous权限对于signature级别的权限比如READ_PHONE_STATE在部分厂商系统上升级成了signature权限pm grant会直接抛SecurityException。对于特殊权限比如SYSTEM_ALERT_WINDOW、MANAGE_EXTERNAL_STORAGE、WRITE_SETTINGS并不总是有效这些权限走的是AppOps或特殊设置页面pm grant经常无法真正写入。授予结果在应用卸载重装、清除数据或恢复出厂设置后会丢失所以只适合调试不适合量产。另外要注意pm grant的权限名必须跟应用AndroidManifest.xml里声明的权限名完全一致。我曾经遇到过一个同事在manifest里写的是android.permission.READ_MEDIA_IMAGES授权时用的却是android.permission.READ_EXTERNAL_STORAGE结果自然是什么都读不到排查了半天才发现是权限名对不上。2.2 adb如何授予应用无障碍权限无障碍权限是默认授权里最特殊的一类。它不属于dangerous权限也不是普通runtime权限而是通过Settings.Secure里的配置项控制的。用户平时要去“设置-无障碍”里手动开启这在一个面向特定业务场景的定制设备上是很不友好的。用adb可以这样默认开启一个无障碍服务# 服务格式为“包名/无障碍服务完整类名” adb shell settings put secure enabled_accessibility_services com.example.testapp/com.example.testapp.MyAccessibilityService # 同时必须把无障碍总开关打开 adb shell settings put secure accessibility_enabled 1如果你是在自己写的系统应用里去做这个操作可以调用Settings.Secure的APIContentResolver cr context.getContentResolver(); String services Settings.Secure.getString(cr, Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES); String entry com.example.testapp/com.example.testapp.MyAccessibilityService; String newValue; if (services null || services.isEmpty()) { newValue entry; } else if (!services.contains(entry)) { newValue services : entry; } else { newValue services; } Settings.Secure.putString(cr, Settings.Secure.ENABLED_ACCESSIBILITY_SERVICES, newValue); Settings.Secure.putInt(cr, Settings.Secure.ACCESSIBILITY_ENABLED, 1);这里有个坑普通第三方应用直接调用Settings.Secure.putString会抛SecurityException因为写ENABLED_ACCESSIBILITY_SERVICES需要WRITE_SECURE_SETTINGS权限。只有系统应用、平台签名的应用或者通过adb shell settings命令才能修改。所以如果你的目标是预装的普通应用又想让它自己去开无障碍这条路走不通必须把权限授予放到系统进程或者用system权限做。另外就算配置项写进去了部分Android版本上需要重启SystemUI甚至重启整机才能让AccessibilityManagerService重新读取配置。我实际测试中Android 13上偶尔遇到写完配置后开关没刷新的问题重启一次系统界面就好了并不需要擦数据。2.3 把adb授权写成一个批处理脚本如果你需要部署的设备数量不大可以直接写一个Shell脚本扔给测试人员执行#!/system/bin/sh PACKAGEcom.example.testapp Perfs android.permission.CAMERA android.permission.RECORD_AUDIO android.permission.ACCESS_FINE_LOCATION android.permission.READ_MEDIA_IMAGES android.permission.READ_MEDIA_VIDEO android.permission.READ_MEDIA_AUDIO android.permission.POST_NOTIFICATIONS for perm in $Perfs; do pm grant $PACKAGE $perm 2/dev/null echo grant $perm ok || echo grant $perm fail done # 默认开启无障碍 settings put secure enabled_accessibility_services $PACKAGE/com.example.testapp.MyAccessibilityService settings put secure accessibility_enabled 1 echo accessibility configured把脚本push到设备上执行adb push grant_perms.sh /data/local/tmp/ adb shell chmod x /data/local/tmp/grant_perms.sh adb shell sh /data/local/tmp/grant_perms.sh这种方式的优点是快、直观、不依赖源码缺点是脚本只能在调试阶段用一旦设备恢复出厂设置所有授权就全丢了。如果你需要“用户拿到设备就能用”的量产效果还是要看后面两章。3. AOSP源码层修改真正实现“安装即授权”3.1 授权入口到底在哪里如果你手里有AOSP源码并且能重新编译system.img那就没必要走adb脚本这种临时方案。真正要改的入口主要有两个一个是DefaultPermissionGrantPolicy.java路径在frameworks/base/services/core/java/com/android/server/pm/permission/DefaultPermissionGrantPolicy.java。这个类负责在系统创建用户比如首次开机时给默认白名单应用、默认系统Handler应用授予权限。很多厂商的“内置App开机后自动获得权限”就是这个类在起作用。另一个是PermissionManagerService.java路径在frameworks/base/services/core/java/com/android/server/pm/permission/PermissionManagerService.java。它负责应用安装时和运行时权限的授予、撤销、查询。如果你想做到“每次安装某个包时都自动授权”就需要在这里动刀。我推荐优先改DefaultPermissionGrantPolicy因为它的语义更清晰只处理系统初始化时的默认授权不会影响运行时权限的正常申请流程。PermissionManagerService那个入口虽然也能改但容易误伤其他逻辑比如用户手动点击“允许”可能也被你的白名单逻辑拦截掉导致权限界面变成摆设。3.2 修改DefaultPermissionGrantPolicy给白名单App加权限以Android 14源码为例DefaultPermissionGrantPolicy里的核心方法是grantDefaultPermissions(int userId)系统会在创建用户时调用它把所有默认应用的权限一次性授予。你可以在方法的最后面追加一段自定义逻辑// frameworks/base/services/core/java/com/android/server/pm/permission/DefaultPermissionGrantPolicy.java Override public void grantDefaultPermissions(int userId) { // ... 系统原有的默认授权逻辑 ... grantPermissionsToDefaultSystemAllowlistedApps(userId); grantDefaultSystemHandlerPermissions(userId); // 以下为自定义给业务应用授予权限 grantRuntimePermissionsForPackage( com.example.testapp, userId, Arrays.asList( Manifest.permission.CAMERA, Manifest.permission.RECORD_AUDIO, Manifest.permission.ACCESS_FINE_LOCATION, Manifest.permission.READ_MEDIA_IMAGES, Manifest.permission.READ_MEDIA_VIDEO, Manifest.permission.READ_MEDIA_AUDIO, Manifest.permission.POST_NOTIFICATIONS ), true); }grantRuntimePermissionsForPackage方法的参数在不同版本上略有差异个别版本签名是String packageName, List permissions, int userId你需要对照自己手里的源码来调整不要直接复制。最后一个布尔参数表示是否覆盖用户之前的选择量产设备上我建议传true确保应用是被强制授予而不是等用户去改。这个方法有个特点它只在用户创建的时候执行一次。也就是首次开机、或者删除用户后重新创建用户时才会走这段逻辑。如果你修改之后烧录到已经开过机的设备上你会发现权限没有生效因为用户已经存在了grantDefaultPermissions不会重新跑。我经常用的验证方式是刷机后不要跳过初始化向导直接让它走到桌面然后检查dump信息。3.3 如何让新装应用也自动授权如果你想做到“应用在系统运行期间被安装也自动获得权限”那DefaultPermissionGrantPolicy就不够用了。这时候需要往PermissionManagerService的grantRuntimePermission方法里加白名单判断。思路其实很直接在真正执行授权前判断调用方的包名是否在白名单里如果在就直接放行// frameworks/base/services/core/java/com/android/server/pm/permission/PermissionManagerService.java Override public void grantRuntimePermission(String packageName, String permissionName, int userId) { // 自定义白名单属于业务应用时直接授权 if (DefaultPermissionGrantPolicy.isDefaultGrantPackage(packageName)) { // 走系统内部授权逻辑跳过用户确认步骤 mPermissionManagerState.grantRuntimePermission(packageName, permissionName, userId); return; } // ... 原有逻辑 }这个改法重点是搞清楚grantRuntimePermission的调用链因为Android 14上这个方法内部会经过很多状态检查如果只是简单return可能会漏掉一些持久化逻辑。我自己的做法是保留原有的grant流程只不过在权限检查阶段把白名单应用的限制判断改成true而不是直接绕过去。但我还是想提醒一句这种全局改法风险较高。在AOSP上改动授权核心方法很容易影响到其他App的正常安装和运行尤其是没有经过充分测试的ROM可能出现“所有应用都无法弹窗申请权限”的诡异bug。所以在能通过DefaultPermissionGrantPolicy解决的场景尽量不要去碰PermissionManagerService。3.4 适配Android 13/14/15的权限名变化改完授权逻辑后最容易翻车的就是权限名。Android 13以上千万不要再用老的READ_EXTERNAL_STORAGE来当存储权限了你需要按版本分别处理Android 13API 33及以上使用READ_MEDIA_IMAGES、READ_MEDIA_VIDEO、READ_MEDIA_AUDIO这三个权限分别对应图片、视频、音频文件的读取。Android 14API 34新增了READ_MEDIA_VISUAL_USER_SELECTED对应“选择照片和视频”的部分授权模式。如果你默认把权限全部授予可以只授READ_MEDIA_IMAGES和READ_MEDIA_VIDEO不授READ_MEDIA_VISUAL_USER_SELECTED。Android 13及以上通知权限独立成POST_NOTIFICATIONS如果业务App需要推送通知这条权限必须显式授予否则通知栏会静默丢弃。Android 14及以上闹钟权限、身体传感器、蓝牙附近设备等权限在授权时也要注意用户可见性。比如NEARBY_WIFI_DEVICES在Android 13上是个高的危险权限但在部分厂商ROM上会要求运行时申请不能静默授予。我踩过的一个真实坑是在一个Android 13项目里我用README_MEDIA_IMAGES给一个预装的图库应用授权结果应用在Android 14设备上依然无法读取图片最后发现是因为目标设备升级到了Android 14系统要求应用必须声明并申请READ_MEDIA_VISUAL_USER_SELECTED才能访问完整图库。版本差异这关真的一步都省不了。3.5 编译、烧录与验证修改完AOSP源码后编译路径取决于你的系统版本。常规做法是编译整个系统镜像或者只编framework模块# 在AOSP根目录 source build/envsetup.sh lunch 你的产品配置 make -j16 systemimage编完烧录后最好先在adb shell里确认授权状态adb shell dumpsys package com.example.testapp | grep -A 50 runtime permissions如果看到grantedtrue说明默认授权生效了。如果grantedfalse优先检查两件事一是应用是否确实预置在系统分区里/system/app或/product/app二是你的白名单包名是否与AndroidManifest里的package名完全一致。大小写、点号、下划线差一个字符都匹配不上。4. 系统应用白名单方案privapp-permissions与平台签名4.1 privapp-permissions.xml怎么用framework层改源码是一种“硬改”方式适合真正做ROM定制的团队。如果你的改动范围更大想通过系统已有的机制来默认授权那privapp-permissions.xml就是官方推荐的做法。在系统源码里你可以把自己的应用放到/system/priv-app目录然后在/etc/permissions目录下放一个XML文件比如privapp-permissions-com.example.testapp.xml!-- system/etc/permissions/privapp-permissions-com.example.testapp.xml -- permissions privapp-permissions packagecom.example.testapp permission nameandroid.permission.CAMERA/ permission nameandroid.permission.RECORD_AUDIO/ permission nameandroid.permission.ACCESS_FINE_LOCATION/ permission nameandroid.permission.READ_MEDIA_IMAGES/ permission nameandroid.permission.READ_MEDIA_VIDEO/ permission nameandroid.permission.READ_MEDIA_AUDIO/ /privapp-permissions /permissions系统在启动阶段读取这个XML如果应用的package name匹配就会把列出的权限全部授予。Android 13/14/15仍然支持这个机制。但这里有一个非常常见的误解很多人以为privapp-permissions可以把dangerous权限也自动授予给普通第三方应用。实际上privapp-permissions只对privileged权限生效也就是签名权限或“privileged”级别的权限。对于CAMERA、RECORD_AUDIO这类dangerous权限单靠privapp-permissions是拿不下来的必须在framework层配合DefaultPermissionGrantPolicy来做。4.2 适用范围与踩坑点privapp-permissions的生效条件非常苛刻下面这几个条件缺一个都不行应用必须放在/system/priv-app目录下不能是/data/app里后装的普通应用。应用必须使用平台签名platform key签名或者至少是系统分区的预置应用。应用在AndroidManifest.xml里必须声明了对应的权限否则系统会认为你在请求一个应用从未声明的权限直接拒绝加载。如果应用声明了某个权限但又没有在privapp-permissions.xml里列出系统在Android 9以上会直接报错提示“Signature|privileged permissions not in privapp-permissions allowlist”。最后一条导致很多国产预装应用在升级系统后疯狂崩溃原因就是把应用从普通App目录挪到了priv-app但忘了同步一份privapp-permissions白名单。4.3 平台签名搭配signature权限除了privapp-permissions平台签名也是一张默认授权的王牌。如果你的应用使用与系统ROM相同的platform key签名它对所有signature级别的权限都畅通无阻比如WRITE_SECURE_SETTINGS、READ_LOGS、INSTALL_PACKAGES这类系统权限只要在manifest里声明了安装时就会自动授予。这也是很多MDM企业设备方案喜欢用平台签名做应用的原因你把设备管理器应用用platform key签名预置到priv-app再配上privapp-permissions白名单权限列表基本可以覆盖绝大多数企业管控需求。不过平台签名也有代价你的应用升级包必须继续用同一个平台签名如果哪次编译环境变了签不对就直接安装失败。而且平台签名泄露风险极大记得保管好你的密钥库别乱提交到Git仓库。4.4 RoleManager的意外作用有时候我们不需要抢权限只需要让应用扮演系统里的“默认角色”系统就会自动赋予相关权限。Android从10开始引入了RoleManager比如默认拨号应用、默认短信应用、默认桌面应用。在AOSP里可以通过XML预置默认角色持有者!-- system/etc/sysconfig/roles.xml -- roles version1 role nameandroid.app.role.SMS alwaysKnowntrue holder packagecom.example.testapp/ /role /roles如果业务App本身需要短信接收、电话状态这类权限把它设为默认短信应用走权限弹窗的次数会少很多。当然这个方案只适用于特定场景别指望所有权限都能靠角色拿到。5. 出厂数据兜底直接操作权限数据库5.1 权限数据都存在哪如果你没有AOSP源码或者你的需求只是在量产镜像里把某些预装应用的权限“预置”好那可以直接修改系统启动时的权限数据库文件。Android的运行时权限状态主要保存在/data/system/users/ /runtime-permissions.xml里。不同版本路径可能有一点点差异但大体一致。这个文件由PackageManagerService在启动时读取把内存中的权限状态和XML里的granted属性同步到一起。文件结构大致是这样的?xml version1.0 encodingutf-8 standaloneyes ? runtime-permissions pkg namecom.example.testapp permission nameandroid.permission.CAMERA grantedtrue flags0/ permission nameandroid.permission.RECORD_AUDIO grantedtrue flags0/ !-- 更多权限 -- /pkg /runtime-permissions如果你能把这个文件在首次开机前放到正确位置系统启动后会认为应用已经被授予过权限从而跳过运行时申请流程。5.2 预置runtime-permissions.xml的两种方式第一种方式是在量产镜像制作阶段直接把/data分区打好包。这适合工厂大批量产线因为每台设备从镜像解压出来时权限数据就已经存在了。第二种方式是通过init脚本在设备首次启动时写入。我一般会把一个shell脚本放到/system/etc/init/目录由init进程在/data分区首次初始化后执行#!/system/bin/sh # /system/etc/init/default_runtime_perms.sh RUNTIME_PERMS_FILE/data/system/users/0/runtime-permissions.xml if [ ! -f $RUNTIME_PERMS_FILE ]; then mkdir -p /data/system/users/0 cat $RUNTIME_PERMS_FILE EOF ?xml version1.0 encodingutf-8 standaloneyes ? runtime-permissions pkg namecom.example.testapp permission nameandroid.permission.CAMERA grantedtrue flags0/ permission nameandroid.permission.RECORD_AUDIO grantedtrue flags0/ /pkg /runtime-permissions EOF chown system:system $RUNTIME_PERMS_FILE chmod 0640 $RUNTIME_PERMS_FILE fi然后在同目录下增加一个.rc文件来触发# /system/etc/init/default_runtime_perms.rc service default_runtime_perms /system/bin/sh /system/etc/init/default_runtime_perms.sh class late_start user root group root oneshot这个方案非常“土”但确实在很多半定制设备上能用。它的主要风险是文件格式跟系统版本的解析规则不完全兼容一旦XML里某个属性写错PMS启动时可能直接忽略整个文件甚至导致系统一直处于“正在启动”状态。所以我强烈建议用这种方式前先在开发板上跑一遍完整开机流程确认没有任何异常。5.3 开机广播后补授权兜底但常见还有一种我在很多方案商代码里见过的做法监听BOOT_COMPLETED广播然后在广播接收器里主动申请权限。这种方式其实并不优雅因为应用要在前台才能弹出权限框而且用户一旦点了拒绝后续再想授予就很麻烦。但如果你整体上无法修改framework只能在普通应用层面做文章这也是唯一可选的路了。做法是public class BootReceiver extends BroadcastReceiver { Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { String[] perms { Manifest.permission.CAMERA, Manifest.permission.RECORD_AUDIO, Manifest.permission.ACCESS_FINE_LOCATION }; // 跳到一个透明的Activity去请求权限 Intent i new Intent(context, PermissionActivity.class); i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); context.startActivity(i); } } }我只能把它定位成“兜底方案”它的问题是弹窗不可控、用户体验差、Android 14上后台启动Activity的限制又多了一条。非到万不得已不建议量产直接这么干。6. 版本差异、常见坑与排查速查6.1 Android 13/14/15适配要点我把自己在项目里整理的适配要点写在下面照着这个表格排查能省不少时间版本关键权限变化对默认授权的影响Android 13新增POST_NOTIFICATIONS媒体权限拆分为图片/视频/音频默认授权要同时覆盖三个媒体权限否则应用只能拿到部分文件Android 14新增READ_MEDIA_VISUAL_USER_SELECTED后台Activity启动更严格授权照片权限时可能需要额外处理“部分授权”的情况Android 15对后台权限和通知权限管控更严预装应用targetSdk要求提高部分旧权限名被废弃需要同步更新授权白名单另外Android 13以上权限授权与用户ID绑定更紧密。如果你的设备支持多用户或工作资料默认授权操作必须按userId分别执行否则主用户里授权成功副用户里该没权限还是没权限。6.2 高频问题排查速查现象常见原因解决思路pm grant报SecurityException请求的不是危险权限或者权限被系统标记为signature级别用adb shell pm list permissions -c确认权限类型换一种授权方式改了DefaultPermissionGrantPolicy但权限没有生效设备已经创建过用户方法不会重复执行恢复出厂设置清除/data或者手动删除用户后重新创建privapp-permissions报“Signatureprivileged not in allowlist”应用没有放在priv-app目录或者没有平台签名授予了READ_MEDIA_IMAGES但应用读不到图片应用没有同时声明READ_MEDIA_VISUAL_USER_SELECTED或者targetSdkVersion太低检查manifest权限声明同步适配新权限名无障碍权限写入了但系统没有开启开关AccessibilityManagerService缓存没有刷新重启SystemUI或重启整机第三方应用直接改Settings.Secure崩溃缺少WRITE_SECURE_SETTINGS权限改用系统权限或通过adb shell settings写入6.3 安全与合规默认授权也要守住底线最后想聊一聊最小权限原则。做默认授权很容易上头一开始只想给应用授两三个权限结果到了后面把所有危险权限都列进白名单了最后出了问题又很难排查。我的建议是即使你有能力让应用拿到全部权限也一定要按业务需要最小化授权。车机上的地图App授定位、麦克风、电话状态就够了没必要给短信和联系人收银台上的扫码App授相机就够了屏幕录制权限根本不该有。对受控设备来说权限覆盖面越少攻击面越小售后问题也越少。另外默认授权的ROM不建议在公开市场发布。Google的兼容性测试CTS/GTS对默认授权有明确限制如果检测到系统对预装应用批量授予敏感权限很容易卡在安全性测试上。真正适合默认授权的设备永远是那些你完全可控的专用设备。我个人的习惯是在开发阶段先把权限列表写成白名单配置文件放在一个集中管理的地方比如一个config.xml里然后framework层代码只读这个配置。这样每次换项目、换产品线只需要改配置文件不需要动框架代码。这套做法帮我省过很多次重复编译系统的痛苦经历也建议你试试。