1# 应用权限管控概述
2
3## 简介
4
5系统提供了一种允许应用访问系统资源（如：通讯录等）和系统能力（如：访问摄像头、麦克风等）的通用权限访问方式，来保护系统数据（包括用户个人数据）或功能，避免它们被不当或恶意使用。
6
7应用权限保护的对象可以分为数据和功能：
8
9- 数据包括个人数据（如照片、通讯录、日历、位置等）、设备数据（如设备标识、相机、麦克风等）。
10
11- 功能包括设备功能（如访问摄像头/麦克风、打电话、联网等）、应用功能（如弹出悬浮窗、创建快捷方式等）。
12
13## 权限使用的基本原则
14
15合理的使用场景有助于应用权限申请和使用。开发应用时权限申请需要满足如下原则：
16
17- 应用（包括应用引用的三方库）所需权限必须在应用的配置文件中严格按照权限开发指导逐个声明。参考[声明权限](declare-permissions.md)。
18
19- 权限申请满足最小化原则，禁止申请非必要的、已废弃的权限。应用申请过多权限，会引起用户对应用安全性的担忧以及使用体验变差，从而也会影响到应用的安装率和留存率。
20
21- 应用申请敏感权限时，必须填写权限使用理由字段，敏感权限通常是指与用户隐私密切相关的权限，包括地理位置、相机、麦克风、日历、健身运动、身体传感器、音乐、文件、图片视频等权限。参考[向用户申请授权](request-user-authorization.md)。
22
23- 应用敏感权限须在对应业务功能执行前动态申请，满足隐私最小化要求。
24
25- 用户拒绝授予某个权限后，应用与此权限无关的其他业务功能应允许正常使用。
26
27## 授权方式
28
29根据授权方式的不同，权限类型可分为system_grant（系统授权）和user_grant（用户授权）。
30
31### system_grant（系统授权）
32
33system_grant指的是系统授权类型，在该类型的权限许可下，应用被允许访问的数据不会涉及到用户或设备的敏感信息，应用被允许执行的操作对系统或者其他应用产生的影响可控。
34
35如果在应用中申请了system_grant权限，那么系统会在用户安装应用时，自动把相应权限授予给应用。
36
37### user_grant（用户授权）
38
39user_grant指的是用户授权类型，在该类型的权限许可下，应用被允许访问的数据将会涉及到用户或设备的敏感信息，应用被允许执行的操作可能对系统或者其他应用产生严重的影响。
40
41该类型权限不仅需要在安装包中申请权限，还需要在应用动态运行时，通过发送弹窗的方式请求用户授权。在用户手动允许授权后，应用才会真正获取相应权限，从而成功访问操作目标对象。
42
43例如，在[应用权限列表](permissions-for-all-user.md)中，麦克风和摄像头对应的权限都是属于用户授权权限，列表中给出了详细的权限使用理由。应用需要在应用商店的详情页面，向用户展示所申请的user_grant权限列表。
44
45## 权限组和子权限
46
47为了尽可能减少系统弹出的权限弹窗数量，优化交互体验，系统将逻辑紧密相关的user_grant权限组合在一起，形成多个权限组。
48
49当应用请求权限时，同一个权限组的权限将会在一个弹窗内一起请求用户授权。权限组中的某个权限，称之为该权限组的子权限。
50
51权限组和权限的归属关系并不是固定不变的，一个权限所属的权限组有可能发生变化。当前系统支持权限组请查阅[应用权限组列表](app-permission-group-list.md)。
52
53## 权限机制中的基本概念
54
55- **TokenID**
56
57  系统采用TokenID（Token identity）作为应用的唯一标识。权限管理服务通过应用的TokenID来管理应用的AT（Access Token）信息，包括应用身份标识APP ID、子用户ID、应用分身索引信息、应用APL、应用权限授权状态等。在资源使用时，系统将通过TokenID作为唯一身份标识映射获取对应应用的权限授权状态信息，并依此进行鉴权，从而管控应用的资源访问行为。
58
59  值得注意的是，系统支持多用户特性和应用分身特性，同一个应用在不同的子用户下和不同的应用分身下会有各自的AT，这些AT的TokenID也是不同的。
60
61- **APL等级**
62
63  为了防止应用过度索取和滥用权限，系统基于APL（Ability Privilege Level，元能力权限等级）等级，配置了不同的权限开放范围。
64
65  元能力权限等级APL指的是应用的权限申请优先级的定义，不同APL等级的应用能够申请的权限等级不同。
66
67- **应用APL等级**
68
69  应用的等级可以分为以下三个等级，等级依次提高。
70
71  | APL级别 | 说明 |
72  | -------- | -------- |
73  | normal | 默认情况下，应用的APL等级都为normal等级。 |
74  | system_basic | 该等级的应用服务提供系统基础服务。 |
75  | system_core | 该等级的应用服务提供操作系统核心能力。<br/>应用APL等级不允许配置为system_core。 |
76
77- **权限APL等级**
78
79  根据权限对于不同等级应用有不同的开放范围，权限类型对应分为以下三个等级，等级依次提高。
80
81  | APL级别 | 说明 | 开放范围 |
82  | -------- | -------- | -------- |
83  | normal | 允许应用访问超出默认规则外的普通系统资源，如配置Wi-Fi信息、调用相机拍摄等。<br/>这些系统资源的开放（包括数据和功能）对用户隐私以及其他应用带来的风险低。 | APL等级为normal及以上的应用。 |
84  | system_basic | 允许应用访问操作系统基础服务（系统提供或者预置的基础功能）相关的资源，如系统设置、身份认证等。<br/>这些系统资源的开放对用户隐私以及其他应用带来的风险较高。 | <!--RP1-->APL等级为system_basic及以上的应用。<!--RP1End--> |
85  | system_core | 涉及开放操作系统核心资源的访问操作。这部分系统资源是系统最核心的底层服务，如果遭受破坏，操作系统将无法正常运行。 | - APL等级为system_core的应用。<br/>- 仅对系统应用开放。 |
86
87- **访问控制列表（ACL）**
88
89  如上所述，权限APL等级和应用APL等级是一一对应的。原则上，拥有低APL等级的应用默认无法申请更高等级的权限。访问控制列表ACL（Access Control List）提供了解决低等级应用访问高等级权限问题的特殊渠道。
90
91  系统权限均定义了“ACL使能”字段，当该权限的ACL使能为TRUE，应用可以使用ACL方式跨级别申请该权限。具体单个权限的定义，可参考<!--RP2-->[系统应用可用的权限](permissions-for-system-apps.md)<!--RP2End-->。
92
93  场景举例：如开发者正在开发APL等级为normal的A应用，由于功能场景需要，A应用需要申请等级为system_basic的P权限。在P权限的ACL使能为TRUE的情况下，A应用可以通过ACL方式跨级申请权限P。
94