本文同步发表于我的微信公众号，微信搜索 程语新视界 即可关注，每个工作日都有文章更新

一、权限管控

什么是应用权限？

系统提供一种通用权限访问方式，允许应用访问系统资源（如通讯录）和系统能力（如摄像头、麦克风），以保护系统数据（包括用户个人数据）和功能，防止不当或恶意使用。

权限保护的对象

权限保护的对象可以分为两类：

保护类型	具体内容	示例
数据	个人数据	照片、通讯录、日历、位置
	设备数据	设备标识、相机、麦克风
功能	设备功能	访问摄像头/麦克风、打电话、联网
	应用功能	弹出悬浮窗、创建快捷方式

二、权限使用

开发应用时，权限申请需要满足以下原则：

2.1 声明原则

应用（包括应用引用的第三方库）所需权限必须在应用的配置文件中逐个声明。

// module.json5 示例
{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.CAMERA",
        "reason": "$string:reason_camera",
        "usedScene": {
          "abilities": ["CameraAbility"],
          "when": "inuse"
        }
      }
    ]
  }
}

2.2 最小化原则

权限申请满足最小化原则，禁止申请非必要的、已废弃的权限。

过多权限申请会引起用户对应用安全性的担忧以及使用体验变差，从而影响应用的安装率和留存率。

2.3 使用理由

应用申请敏感权限时，必须填写权限使用理由字段。

敏感权限通常是指与用户隐私密切相关的权限，包括：

• 地理位置

• 相机

• 麦克风

• 日历

• 健身运动

• 身体传感器

• 音乐

• 文件

• 图片视频

2.4 动态申请原则

应用敏感权限须在对应业务功能执行前动态申请，满足隐私最小化要求。

2.5 业务连续性原则

用户拒绝授予某个权限后，应用与此权限无关的其他业务功能应允许正常使用。

三、授权方式

根据授权方式的不同，权限类型可分为三种：

3.1 system_grant（系统授权）

定义：系统授权类型，应用被允许访问的数据不会涉及用户个人信息。

授权时机：系统会在用户安装应用时自动授予相应的权限。

特点：

• 无需用户手动确认

• 不涉及用户隐私数据

• 安装即授权

3.2 user_grant（用户授权）

定义：用户授权类型，应用被允许访问的数据将会涉及用户个人信息。

授权时机：需要在应用运行时通过弹窗请求用户授权。

特点：

• 需要用户手动确认

• 涉及用户隐私数据

• 用户可随时在设置中关闭

// 动态申请用户授权示例
import { abilityAccessCtrl } from '@kit.AbilityAccessCtrlKit';

let atManager = abilityAccessCtrl.createAtManager();
let permissions: Array<string> = ['ohos.permission.CAMERA'];

atManager.requestPermissionsFromUser(this.context, permissions)
    .then((data) => {
        console.info('requestPermissionsFromUser success');
    })
    .catch((error) => {
        console.error('requestPermissionsFromUser failed');
    });

3.3 manual_settings（手动设置授权）

引入版本：API 21开始支持

定义：手动设置授权类型，应用被允许访问的数据将会涉及用户个人信息，应用被允许执行的操作可能对系统或者用户产生严重的影响。

授权时机：只能由用户在系统设置应用中授权，无法通过弹窗请求。

特点：

• 无法通过代码弹窗申请

• 必须引导用户去系统设置开启

• 权限级别较高，影响较大

四、权限组和子权限

为了尽可能减少权限弹窗数量并优化交互体验，系统将逻辑紧密相关的user_grant权限组合成多个权限组。

当应用请求权限时，同一个权限组的权限将会在一个弹窗内一起请求用户授权。

权限组中的某个权限，称之为该权限组的子权限。

注意事项

权限组和权限的归属关系不是固定不变的，一个权限所属的权限组可能发生变化。

五、权限机制

5.1 TokenID

定义：系统采用TokenID（Token identity）作为应用的唯一标识。

作用：权限管理服务通过应用的TokenID来管理应用的AT（Access Token）信息，包括：

• 身份标识APP ID

• 子用户信息

• 分身索引信息

• APL等级

• 权限授权状态

特点：系统支持多用户特性和应用分身特性，同一个应用在不同的子用户下和不同的分身应用会有各自的AT，这些AT的TokenID也是不同的。

5.2 APL等级（元能力权限等级）

为了防止应用过度索取和滥用权限，系统基于APL配置了不同的权限开放范围。

应用的等级可以分为以下三个等级，等级依次提高：

APL级别	说明
normal	默认情况下，应用的APL等级都为normal等级
system_basic	该等级的应用服务提供系统基础服务
system_core	该等级的应用服务提供操作系统核心能力。应用APL等级不允许配置为system_core

权限APL等级

根据权限对于不同等级应用有不同的开放范围，权限类型对应分为以下三个等级：

APL级别	说明	开放范围
normal	允许应用访问超出默认规则外的普通系统资源，如配置Wi-Fi信息、调用相机拍摄等。这些系统资源的开放对用户隐私以及其他应用带来的风险较低。	APL等级为normal及以上的应用
system_basic	允许应用访问操作系统基础服务相关的资源，如系统设置、身份认证等。这些系统资源的开放对用户隐私以及其他应用带来的风险较高。	- APL等级为system_basic及以上的应用 - 部分权限对normal级别的应用受限开放
system_core	涉及开放操作系统核心资源的访问操作。这部分系统资源是系统最核心的底层服务，一旦遭受破坏，操作系统将无法正常运行。	- APL等级为system_core的应用 - 仅对系统应用开放

5.3 访问控制列表（ACL）

原则上，低APL等级的应用默认无法申请更高等级的权限。访问控制列表ACL提供了低等级应用访问高等级权限的特殊渠道。

系统权限均定义了"ACL使能"字段。当该字段为TRUE时，应用可以使用ACL方式跨级别申请权限。

场景举例：

开发者正在开发APL等级为normal的A应用，由于功能场景需要，A应用需要跨级申请等级为system_basic的P权限。当P权限的ACL使能为TRUE时，A应用可以通过ACL方式跨级申请权限P。

六、携带数据的权限类型

在传统的权限模型中，权限呈现非是即否的状态，每个权限所包含的内容有限，在逐步精细化的权限管控模型中显得力不从心。

系统引入了可以携带额外信息的权限键值对。这种新的权限类型能够在日益复杂的权限管控模型中展现出更大的灵活性和适应性。

场景举例（以权限ohos.permission.ACCESS_DDK_DRIVERS为例）：

在扩展外设场景中，系统需要管理当前应用能够连接的驱动服务端，而这样的服务端可能有多个，这就要求权限能够携带具体的服务端数据，明确指出应用能够连接哪些外设驱动服务端。

七、申请权限的方式

在申请权限前，需要：

1. 确认权限名称：根据API接口中的"需要权限"或"@permission"字段，确认权限名称

2. 检索权限类型：通过权限列表页面检索确认权限类型

3. 选择操作路径：根据目标权限的开放范围和授权方式，选择相应的操作路径

不同权限类型的申请路径

权限类型	授权方式	操作路径
开放权限（系统授权）	system_grant	声明权限 → 访问接口声明权限
开放权限（用户授权）	user_grant	声明权限 → 向用户申请授权 → 访问接口
受限开放权限（系统授权）	system_grant	申请使用受限权限 → 声明权限 → 访问接口
受限开放权限（用户授权）	user_grant	申请使用受限权限 → 声明权限 → 向用户申请授权 → 访问接口

7.3 具体操作步骤详解

步骤1：声明权限（所有类型都需要）

在module.json5中声明所需权限：