1. 项目概述为什么我们需要关注APP默认权限在Android开发与安全审查的日常工作中我们经常遇到一个棘手的问题一个APP在安装后甚至在用户首次启动前就已经拥有了某些系统权限。用户打开应用商店点击安装然后发现这个新应用已经可以读取通讯录、访问位置信息而自己从未点击过“允许”。这背后就是“默认赋予权限”机制在起作用。对于开发者而言这可能是为了提升用户体验确保核心功能无缝运行但对于用户和安全研究者来说这无疑是一个巨大的隐私黑洞和潜在的安全风险。“Android APP 默认赋予权限”这个主题直指Android权限系统的核心设计之一。它不仅仅是AndroidManifest.xml文件里的一行声明更涉及到系统签名、特权应用、预置应用、以及从Android 6.0API 23引入的动态权限模型Runtime Permissions的边界问题。理解它意味着你能更好地开发合规的应用也能更深入地分析系统应用的行为甚至在定制ROM时管控预装软件的权限。本文将从一个实践者的角度拆解默认权限的授予原理、实现方式、潜在风险以及我们如何在开发和逆向中应对它。2. 权限体系基础与默认权限的定位2.1 Android权限模型演进简述要理解默认权限必须先理清Android权限模型的演变。在Android 5.1及更早版本采用的是“安装时授权”模型。用户在安装APP时需要一次性同意应用声明的所有权限否则无法安装。这种“霸王条款”模式饱受诟病。Android 6.0是一个分水岭它引入了运行时权限模型。权限被分为两类普通权限涉及隐私风险较低的操作如网络访问、震动等。这些权限在AndroidManifest.xml中声明后系统会在安装时自动授予。危险权限涉及用户隐私和敏感数据的操作如通讯录、位置、相机、麦克风等。这些权限不仅需要在清单文件中声明还必须在运行时向用户弹窗申请由用户决定是否授予。而“默认赋予权限”机制则是在这两种模型之上一个更高优先级的“绿色通道”。它允许特定应用绕过运行时弹窗在安装时即静默获得危险权限。2.2 什么是“默认赋予权限”简单说就是应用在无需用户明确交互点击“允许”的情况下自动获得某些危险权限。这通常发生在以下几种场景系统应用/特权应用作为Android系统镜像一部分的应用如设置、拨号器、系统UI等。它们被预先授予了大量权限以保障系统正常运行。预置应用手机厂商或运营商在出厂时预装的应用。这些应用可能通过与厂商的合作关系被赋予某些默认权限。通过android:protectionLevel标记为signature或signatureOrSystem的权限这类权限的授予规则是只有当申请该权限的应用与定义该权限的应用使用相同的证书签名时才会被自动授予。这常用于系统组件间的互信通信。通过android:defaultPermissions属性声明这是Android 8.0API 26引入的、在AndroidManifest.xml中更明确声明默认权限的方式。默认权限的核心逻辑在于信任边界。系统信任那些用平台证书签名的应用或者信任在设备出厂时即被固化在系统分区的应用。这种信任是设备功能的基础但也可能被滥用。2.3 默认权限的风险与争议默认权限是一把双刃剑。对用户体验的积极面对于系统核心应用如果每次启动都要申请电话、短信权限用户体验将是灾难性的。默认权限确保了系统的流畅性。对隐私和安全的消极面隐私泄露用户对权限授予过程无感知预装应用可能在后台持续收集数据。供应链攻击如果预装应用被植入恶意代码它将利用默认权限为所欲为。权限滥用一些非核心的预装应用如厂商自家的浏览器、音乐APP也可能被过度授予权限形成不公平竞争。因此对于安全研究人员和注重隐私的用户查看和管理应用的默认权限是一项关键技能。3. 实现方式深度解析从清单文件到系统编译默认权限的授予发生在应用安装过程PackageManagerService处理中。其实现方式多样我们从开发者可接触到的层面到系统底层逐一拆解。3.1 传统方式protectionLevel与共享签名这是最经典的方式。假设我们有两个应用App A系统服务和App B第三方服务。在App A中定义自定义权限!-- App A的 AndroidManifest.xml -- permission android:namecom.example.appa.CUSTOM_PERMISSION android:protectionLevelsignature /将protectionLevel设置为signature或signatureOrSystem。在App B中声明并使用该权限!-- App B的 AndroidManifest.xml -- uses-permission android:namecom.example.appa.CUSTOM_PERMISSION /签名验证当App B被安装时系统会检查其签名是否与最初定义此权限的App A的签名一致。如果一致则静默授予App B这个CUSTOM_PERMISSION权限如果不一致则拒绝授予App B无法使用该权限保护的功能。这种方式广泛用于系统套件应用如GMS套件中的各个应用之间安全地共享数据和功能。实操心得在逆向分析预装应用时如果发现它声明了一个protectionLevel为signature的陌生权限可以尝试在系统镜像中搜索定义该权限的APK这往往是理清应用间关联的关键线索。3.2 Android 8.0 的显式声明android:defaultPermissionsAndroid 8.0 在application标签下引入了android:defaultPermissions属性让默认权限的声明更加清晰和模块化。manifest ... application android:defaultPermissionstrue ... !-- 声明需要被默认授予的权限 -- uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION/ uses-permission android:nameandroid.permission.RECORD_AUDIO/ ... /application /manifest关键点在于android:defaultPermissionstrue。这个属性告诉系统“本应用请求将其声明的所有危险权限在安装时默认授予”。但是这并不意味着任何应用都能用。生效条件该属性仅对预装在系统分区如/system/app,/system/priv-app的应用有效。对于从应用商店下载安装的普通应用设置这个属性是无效的系统会忽略它依然走运行时权限申请流程。用途这主要是为OEM厂商和ROM开发者提供一种规范化的方式来声明其预装系统应用所需的默认权限替代过去可能通过其他配置文件如privapp-permissions.xml进行配置的方式。3.3 系统级配置privapp-permissions.xml对于Android 9.0API 28及更高版本Google进一步加强了特权应用安装在/system/priv-app目录下的应用的权限管理引入了白名单机制。这就是privapp-permissions.xml文件。位置该文件通常位于/system/etc/permissions/目录下也可能在厂商自定义的路径中。作用它明确列出了每个特权应用被允许默认拥有的危险权限列表。即使一个特权应用在AndroidManifest.xml中声明了android.permission.READ_SMS如果这个权限没有在对应的privapp-permissions.xml白名单中它也无法在安装时获得。文件结构示例?xml version1.0 encodingutf-8? permissions !-- 针对特定包名的权限授予 -- privapp-permissions packagecom.android.phone permission nameandroid.permission.CALL_PHONE/ permission nameandroid.permission.READ_PHONE_STATE/ permission nameandroid.permission.MODIFY_PHONE_STATE/ /privapp-permissions privapp-permissions packagecom.android.settings permission nameandroid.permission.WRITE_SECURE_SETTINGS/ !-- ... -- /privapp-permissions /permissions编译时集成这个文件是在ROM编译阶段由系统集成商如手机厂商根据预装应用的需求配置的并打包进系统镜像。这是控制预装应用权限泛滥的最重要关口。注意事项在定制或编译AOSP时如果你将自己开发的应用放入priv-app目录务必记得在对应的privapp-permissions.xml中添加其所需的权限白名单否则应用可能会因权限不足而崩溃。3.4 底层基石Android.bp与系统编译集成对于AOSPAndroid开源项目开发者和ROM定制者Android.bp是Soong构建系统使用的蓝图文件它定义了模块的构建规则。一个系统应用的Android.bp文件会指定其编译输出路径。// 示例一个系统特权应用的Android.bp android_app { name: MySystemApp, srcs: [src/**/*.java], resource_dirs: [res], // 关键属性声明为特权应用并指定证书 privileged: true, certificate: platform, // 使用平台证书签名 // 指定安装到系统分区 system_ext_specific: true, // 或 vendor: true, product: true 取决于分区 }privileged: true这个标记告诉构建系统该应用是特权应用应被安装到/system/priv-app目录下。certificate: platform使用Android平台的核心证书进行签名。这是获得signature级权限信任的基础。分区属性system_ext_specific,vendor,product等属性决定了应用被安装到哪个系统分区/system_ext,/vendor,/product这些分区下的应用通常也具备某种程度的特权。一个应用只有通过Android.bp正确配置编译后放入正确的系统分区并使用正确的证书签名它才有可能被privapp-permissions.xml机制管理从而获得默认权限。这是从源码到镜像的完整链条。4. 实操如何查看与管理默认权限作为开发者或高级用户我们如何探查和应对默认权限呢4.1 通过ADB命令查看权限授予状态Android Debug Bridge (ADB) 是我们最强大的命令行工具。查看设备上所有包名adb shell pm list packages查看特定应用已授予的权限包括默认授予的adb shell pm dump package_name | grep -A 50 granted permissions:例如查看系统设置应用的权限adb shell pm dump com.android.settings | grep -A 50 granted permissions:在输出结果中你会看到一长列权限。那些在“Install Permissions:”或“Runtime Permissions:”之前列出的通常就是安装时即被授予的权限其中包含了默认权限。更精确的查看安装时权限adb shell dumpsys package package_name | grep -E installPermissions:|flags:查看包的标志如果包含SYSTEM、PRIVILEGED等说明它是系统或特权应用。4.2 使用AppOps进行运行时权限控制即使权限被默认授予Android还提供了另一道防线——AppOps应用程序操作。AppOps可以更细粒度地控制权限的实际使用而不仅仅是“拥有”状态。通过ADB使用AppOps查看某个应用的所有AppOps状态adb shell appops get package_name拒绝某个应用的一项权限例如拒绝“相机”权限的实际使用adb shell appops set package_name CAMERA deny改回默认模式adb shell appops set package_name CAMERA default使用图形化工具对于非Root用户可以安装如“AppOps”等第三方管理器应用它们提供了友好的界面来管理AppOps。对于Root用户Magisk模块“App Systemizer”或Xposed模块“XPrivacyLua”能提供更强大的控制能力。重要提示通过AppOps拒绝权限可能会导致应用功能异常或崩溃因为它阻止了应用访问本已被系统授予权限的资源。操作前请明确后果。4.3 逆向分析定位权限授予的源头在安全分析中我们可能需要知道一个预装应用的某个敏感默认权限到底是谁给的。检查AndroidManifest.xml使用apktool反编译APK查看其声明的权限和android:defaultPermissions属性。apktool d -s some_app.apk -o output_dir cat output_dir/AndroidManifest.xml | grep -E uses-permission|defaultPermissions在系统镜像中搜索privapp-permissions.xml# 在解压的系统镜像目录中 find . -name privapp-permissions*.xml -type f | xargs grep -l package_name这能帮你定位是哪个配置文件授予了权限。检查应用签名# 获取APK的签名证书信息 keytool -printcert -jarfile some_app.apk对比其证书与platform等系统核心证书是否一致可以判断其是否为系统签名应用。5. 开发建议与避坑指南5.1 给普通应用开发者的建议对于上架公开应用商店的开发者请彻底放弃让应用获得默认危险权限的想法。Google Play Store的审核政策严格禁止这种行为。你的应用必须遵循标准的运行时权限模型仅在需要时申请权限在用户即将使用相关功能时再弹窗申请并提供清晰的解释shouldShowRequestPermissionRationale。优雅处理拒绝当用户拒绝权限时应有降级方案或友好提示而不是直接崩溃或退出。使用权限组记住授予一个权限组中的某个权限同组的其他权限在申请时会自动被授予用户会收到通知。合理利用这一点可以减少弹窗骚扰。5.2 给系统应用/ROM开发者的建议如果你在为定制ROM开发预装系统应用需要申请默认权限请遵循以下规范路径在AndroidManifest.xml中声明所有需要的权限。在Android.bp中正确配置确保privileged: true和正确的certificate通常是platform或shared。在privapp-permissions.xml中添加白名单这是最关键的一步。在AOSP源码的相应位置如device/vendor/device/permissions/创建或修改该文件将你的应用包名和所需权限明确列出。充分测试在刷机后务必使用adb shell pm dump和adb shell appops get命令验证权限授予状态是否符合预期并测试应用功能是否正常。5.3 常见问题排查实录问题1我把自己开发的应用放到/system/priv-app下了也配置了privapp-permissions.xml为什么还是没有权限检查签名确认你的APK是否使用了正确的平台证书签名。在调试阶段可以使用testkey或dev-keys但在最终发布时需使用厂商私钥。检查文件权限确保privapp-permissions.xml文件在设备上的权限是644 (-rw-r--r--)并且所属用户/组正确。检查SELinux上下文SELinux策略可能会阻止应用访问某些资源。使用adb shell ls -Z查看APK和权限文件的SELinux上下文并使用adb shell dmesg | grep avc查看是否有相关的拒绝日志。清理缓存修改系统分区配置后有时需要清除/data/system下的packages.xml和packages.list缓存文件需重启或者直接恢复出厂设置让PackageManagerService重新解析所有应用。问题2用户报告说我的应用非系统应用一安装就有某个权限但我没有做任何特殊配置。检查权限类型首先确认这个权限是否是“危险权限”。有些权限属于“普通权限”安装时自动授予是正常行为。检查设备厂商定制某些手机厂商的定制系统可能存在“权限白名单”机制为部分流行应用预授权。这属于厂商行为开发者无法控制也无需处理。检查权限继承是否因为用户之前授予了同权限组的另一个权限例如如果用户之前授予了READ_EXTERNAL_STORAGE那么在新版本中申请WRITE_EXTERNAL_STORAGE时系统可能会自动授予。问题3如何安全地移除一个预装应用的默认权限对于想要精简手机的用户或开发者直接删除APK是最粗暴的方式但可能引发系统不稳定。更安全的方法是使用ADB禁用应用adb shell pm disable-user --user 0 package_name。这不会删除应用但会阻止其运行。通过AppOps禁用权限如前所述使用adb shell appops set ... deny来阻止权限使用。修改系统镜像需Root找到对应的privapp-permissions.xml文件从该应用的白名单中移除你不想给的权限条目然后重启。这需要重新挂载系统分区为可写操作有风险。6. 安全与隐私的终极思考默认权限机制是Android系统复杂性和灵活性的一个缩影。它保障了系统底层的顺畅运作也为OEM厂商提供了定制空间但无疑降低了权限控制的透明度。作为开发者理解其原理有助于我们构建更合规、更健壮的应用作为用户或安全从业者掌握探查和管理默认权限的方法则是夺回数字主权、守护隐私边界的重要技能。在Android权限的战场上没有一劳永逸的银弹。从动态权限申请到后台位置访问限制再到Android 13的细粒度媒体权限和Android 14的进一步收紧Google正在不断修补隐私保护的篱笆。然而系统分区内的“特权世界”依然存在。保持对默认权限的警惕定期审计设备上应用的权限状况尤其是在购买新设备或刷入新ROM后应当成为一种数字生活习惯。毕竟在数据即价值的时代那些静默发生的授权可能正决定着你的信息流向何处。