Android为何允许第三方应用重定义系统/框架级权限？

权限重复声明的校验规则差异 #

Android系统在应用安装阶段的重复权限校验，对框架内置权限和第三方应用自定义权限采用了完全不同的判定标准：

• 定义在framework/base/core/res/AndroidManifest.xml路径下的系统权限，所有权归属系统本身，不属于任何第三方应用。安装校验时，系统不会将这类权限纳入重复声明拦截的判定范围，因此第三方应用可以在自身Manifest中声明同名权限，甚至修改protectionLevel属性，不会触发安装失败。
• 非框架侧的普通应用自定义权限，所有权归第一个成功安装、且声明该权限的应用所有。后续如果有签名不一致的应用试图声明同名<permission>元素，系统会直接拦截安装，抛出INSTALL_FAILED_DUPLICATE_PERMISSION错误，典型报错信息如下：

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_DUPLICATE_PERMISSION
List of apks:
[0] 'E:\AndroidProjects\testing\app\build\outputs\apk\debug\app-debug.apk'
Installation failed due to: 'Failed to commit install session 128835007 with command cmd package install-commit 128835007. Error: INSTALL_FAILED_DUPLICATE_PERMISSION: Package com.example.permcheck attempting to redeclare permission com.my.prm.external.lib.permission.SDK_API_ACCESS already owned by com.example.app.testapp'

需要明确的是，第三方应用对框架权限的重定义属于完全无效的声明：系统所有权限校验逻辑都以框架侧存储的权限基准配置为准，不会读取第三方应用中声明的同名权限配置，因此第三方应用不可能通过这种方式获取signature级别的系统权限，修改保护等级的操作也不会产生实际效果。这套校验逻辑的核心实现位于系统PackageManagerService的安装权限处理分支，和实际测试的现象完全吻合。

框架权限重定义不做安装拦截的设计意图 #

这套逻辑是Android系统刻意设计的，核心考量有三点：

• 保障历史版本兼容性：Android历次版本迭代中，有大量系统权限是在后续版本才被纳入框架内置范围，这些权限最早可能由第三方应用、厂商应用提前自定义实现。如果系统对框架权限的重定义加安装拦截，所有提前声明了同名权限的旧应用在升级到新版系统后都会无法安装，会造成大面积的兼容性故障。
• 无实际安全风险：由于第三方重定义的框架权限配置完全不参与系统权限校验流程，无论第三方怎么修改权限属性，都无法绕过系统的权限管控逻辑，不会产生权限泄露、越权授权的安全问题，额外增加拦截逻辑没有实际安全收益，反而会增加安装流程的校验开销。
• 降低厂商适配成本：各Android定制厂商通常会在ROM中扩展大量自定义框架权限，如果AOSP原生增加框架权限重定义拦截规则，厂商预置应用如果提前声明了后续原生版本新增的同名权限，会直接出现预置应用安装失败、系统编译异常的问题，大幅提升系统版本适配的复杂度。

内容的提问来源于stack exchange，提问作者Bajrang Hudda