权限管理系统（PackageManagerService）
权限管理系统所做的事情大体可以分为管理声明的权限、管理App使用的权限、权限的授予/撤销、资源使用记录这四类。
权限管理系统大体分为权限控制器App、管理类、服务类三大模块
- 权限控制器App它的“英文名”是PermissionController，它是一个App是一个独立运行的进程，它的主要作用就是权限的授予/撤销。
- 管理类的作用就是为App提供访问各种服务的能力，访问各种服务是通过binder通信访问的。管理类是属于framework.jar，而framework.jar在zygote进程中就已经被预加载了，因此在App被zygote孵化成功后，就已经拥有了各种管理类了，因此每个App都是可以直接使用自己进程内的管理类的。
权限管理系统的管理类主要有PackageManager、PermissionManager、PermissionCheckerManager、AppOpsManager。
PackageManager是属于PackageManagerService服务，为啥出现在权限管理系统呢？其主要原因是PackageManagerService与权限管理之间是没有明显的界限划分的，它们是“你中有我，我中有你的”一个互相服务的关系。权限管理系统会使用到PackageManagerService中的一小部分功能。权限控制器App会使用到该类。
PermissionManager和PermissionCheckerManager主要与PermissionManagerService进行交互，而AppOpsManager与AppOpsService进行交互。
管理类的作用就是把访问各种服务的能力封装了起来，这样App就可以直接使用了，比如App想要检查某个权限是否被授予了，就可以使用PermissionCheckerManager进行检查，进而PermissionManagerService会把检查结果返回
- 服务类
A. 权限管理服务 (PermissionManagerService)
PermissionManagerService它负责了权限管理系统中大部分的功能，凡是声明权限的管理、App使用权限的管理、权限的授予/撤销都归该服务负责，当然这里面要排除一点就是不管是App声明权限还是App使用的权限的存储可是不归它负责，而是归PackageManagerService负责。
B. AppOpsService就诞生了，它的权限控制是指它结合了App的状态 (如App前后台)来对已经授予的运行时权限再次重新计算，给出一个真正的权限状态，比如某App的录音权限已经授予了，AppOpsService会结合当前App的前后台状态，如果App位于前台则会告知App录音权限真正的被授予，可以开启录音功能；如果App位于后台，则会告知App录音权限被拒绝了，不能开启录音功能。
C. 包管理服务 (PackageManagerService)
PackageManagerService它会为权限管理系统中的权限 (App声明的权限和使用的权限) 提供权限存储的功能。当Android设备重新启动的时候，会把存储的这些信息读取出来。
权限的整个流程
打开app申请：
//先检查某个权限是否授予
if (ContextCompat.checkSelfPermission(this, 权限) != PackageManager.PERMISSION_GRANTED) {//没有授予则调用requestPermissions方法ActivityCompat.requestPermissions(this, 请求权限, REQUEST_PERMISSION_CODE);
}- ActivityCompat.requestPermissions方法来请求权限
- 通过ActivityTaskManagerService处理后，PermissionController中的授权Activity被启动。
- AppOpsService服务也起到权限访问控制的功能，因此它有必要知道App使用的权限的状态，AppOpsService服务根据包名、uid、请求的权限、权限状态，做一些检查操作，修改相应状态值。并且把修改的值更新到/data/system/appops.xml文件中。
- 返回授权结果，在App进程的Activity的onRequestPermissionsResult
权限的授予，涉及到了PermissionController、PermissionManagerService服务、AppOpsService服务，其中PermissionController会负责展示一个权限授予的Activity，当用户选择了允许后，就会通知PermissionManagerService服务和AppOpsService服务更新相应权限的状态。权限的拒绝流程和授予也是一样的。
APK的分类：
https://mp.weixin.qq.com/s/Nvgf2fyXH229ZHT9x6F-lQ
系统Apk可以存放于/system、/system_ext、/product、/vendor、/odm、/oem、/apex这几个目录下面的子目录中，而系统Apk的分类又可以按根目录分类也可以按按子目录分类
按根目录分类
系统Apk根据存放的根目录可以划分为vendor Apk、product Apk、systemExt Apk、system Apk、odm Apk、oem Apk
按子目录分类
系统Apk一般主要存放于各自根目录下的/app、/priv_app、/overlay这三个子目录中，为啥这里用了一般这个词呢，因为对于system根目录来说，它的framework子目录也是可以存放系统Apk的，比如framework-res.apk就存放于此。
存放于/priv-app子目录的系统Apk又被称为privileged Apk (特权Apk)，存放于/overlay子目录的系统Apk又被称为overlay Apk，既不是privileged Apk也不是overlay Apk的系统Apk，是存放于/app子目录的。那就来介绍下privileged Apk和overlay Apk
权限的分类
https://mp.weixin.qq.com/s/W8lbkgNA9rsHNvFVeILsSA
如上图列出了Android权限的各种类型，大类型上主要分为：
- normal权限，该类型权限对用户隐私或系统安全影响较小，因此在Apk安装后就自动授予了该类型的权限。正因如此一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户没有关系的。
- dangerous权限，该类型权限是指可能会侵犯用户隐私或设备安全的权限，因此应用在使用这些权限之前必须获得用户的明确授权。一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户有关系的。该类型权限可以包含的子权限有instant、appop、runtime。
- signature权限，该类型权限要不满足权限使用者签名信息与权限声明者签名信息兼容或者一样，要不满足它的子权限符合一定条件，这两个条件中的任意一个条件，即可在Apk安装后就会授予该权限，一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户没有关系的。可以使用signature权限的Apk分为两类与权限声明者签名信息兼容或者一样的Apk和系统Apk，它的子权限有很多。
- internal权限，该类型权限是signature权限的子集，只要它的子权限符合一定条件，即可在Apk安装后就会授予该权限。一个Apk使用该类型的权限，该类型权限的权限状态可是与Android设备的用户没有关系的。可以使用该权限的Apk主要是系统Apk，它与signature权限拥有相同的子权限。
