鸿蒙开发（NEXT/API 12）【访问控制应用权限管控概述】程序访问控制

默认情况下，应用只能访问有限的系统资源。但某些情况下，应用存在扩展功能的诉求，需要访问额外的系统数据（包括用户个人数据）和功能，系统也必须以明确的方式对外提供接口来共享其数据或功能。

系统通过访问控制的机制，来避免数据或功能被不当或恶意使用。当前访问控制的机制涉及多方面，包括应用沙箱、应用权限、系统控件等方案。

应用沙箱

系统上运行的应用程序均部署在受保护的沙箱中，通过沙箱的安全隔离机制，可以限制应用程序的不当行为（如应用间非法访问数据、篡改设备等）。每个程序都拥有唯一的ID（[TokenID]），系统基于此ID识别与限制应用的访问行为。

应用沙箱限定了只有目标受众才能访问应用内的数据，并限定了应用可访问的数据范围。

应用权限

系统根据应用的APL等级设置进程域和数据域标签，并通过访问控制机制限制应用可访问的数据范围，从而实现在机制上消减应用数据泄露的风险。

不同APL等级的应用能够申请的权限等级不同，且不同的系统资源（如：通讯录等）或系统能力（如：访问摄像头、麦克风等）受不同的应用权限保护。通过严格的分层权限保护，有效抵御恶意攻击，确保系统安全可靠。

安全访问机制

HarmonyOS推出安全访问机制，改变应用获取隐私数据的方式，让用户从管理“权限”到管理“数据”，按需授予系统数据。举例而言，当用户想要更换社交平台头像时，应用将无法再获取整个图库的访问权限，用户选择哪张照片，应用就得到哪张照片，将用户的隐私数据与应用之间受控隔离，全面守护用户隐私。

具体来说，安全访问机制主要由系统Picker、安全控件两种系统机制来实现，在特定的场景中，应用无需向用户申请权限也可临时访问受限资源，实现精准化权限管控，更好地保护用户隐私。

[系统Picker]

由系统独立进程实现，在应用拉起Picker，并由用户操作Picker后，应用可以获取Picker返回的资源或结果。举例说明，当应用需要读取用户图片时，可通过使用照片Picker，在用户选择所需要的图片资源后，直接返回该图片资源，而不需要授予应用读取图片文件的权限。
[安全控件]

由系统提供UI控件，应用在界面内集成对应控件，用户点击后，应用将获得临时授权，从而执行相关操作。举例说明，当应用需要分享当前位置时，可使用位置控件，用户点击后，将会在本次前台期间获得精准定位的授权，可以调用位置服务获取精准定位。当发生灭屏、应用切后台、应用退出等任一情况时，临时授权结束。

简介

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

应用权限保护的对象可以分为数据和功能：

数据包括个人数据（如照片、通讯录、日历、位置等）、设备数据（如设备标识、相机、麦克风等）。
功能包括设备功能（如访问摄像头/麦克风、打电话、联网等）、应用功能（如弹出悬浮窗、创建快捷方式等）。

权限使用的基本原则

合理的使用场景有助于应用权限申请和使用。开发应用时权限申请需要满足如下原则：

应用（包括应用引用的三方库）所需权限必须在应用的配置文件中严格按照权限开发指导逐个声明。
权限申请满足最小化原则，禁止申请非必要的、已废弃的权限。应用申请过多权限，会引起用户对应用安全性的担忧以及使用体验变差，从而也会影响到应用的安装率和留存率。
应用申请敏感权限时，必须填写权限使用理由字段，敏感权限通常是指与用户隐私密切相关的权限，包括地理位置、相机、麦克风、日历、健身运动、身体传感器、音乐、文件、图片视频等权限。
应用敏感权限须在对应业务功能执行前动态申请，满足隐私最小化要求。
用户拒绝授予某个权限后，应用与此权限无关的其他业务功能应允许正常使用。

授权方式

根据授权方式的不同，权限类型可分为system_grant（系统授权）和user_grant（用户授权）。

system_grant（系统授权）

system_grant指的是系统授权类型，在该类型的权限许可下，应用被允许访问的数据不会涉及到用户或设备的敏感信息，应用被允许执行的操作对系统或者其他应用产生的影响可控。

如果在应用中申请了system_grant权限，那么系统会在用户安装应用时，自动把相应权限授予给应用。

user_grant（用户授权）

user_grant指的是用户授权类型，在该类型的权限许可下，应用被允许访问的数据将会涉及到用户或设备的敏感信息，应用被允许执行的操作可能对系统或者其他应用产生严重的影响。

该类型权限不仅需要在安装包中申请权限，还需要在应用动态运行时，通过发送弹窗的方式请求用户授权。在用户手动允许授权后，应用才会真正获取相应权限，从而成功访问操作目标对象。

例如，在[应用权限列表]中，麦克风和摄像头对应的权限都是属于用户授权权限，列表中给出了详细的权限使用理由。应用需要在应用商店的详情页面，向用户展示所申请的user_grant权限列表。

权限组和子权限

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

当应用请求权限时，同一个权限组的权限将会在一个弹窗内一起请求用户授权。权限组中的某个权限，称之为该权限组的子权限。

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

权限机制中的基本概念

TokenID

系统采用TokenID（Token identity）作为应用的唯一标识。权限管理服务通过应用的TokenID来管理应用的AT（Access Token）信息，包括应用身份标识APP ID、子用户ID、应用分身索引信息、应用APL、应用权限授权状态等。在资源使用时，系统将通过TokenID作为唯一身份标识映射获取对应应用的权限授权状态信息，并依此进行鉴权，从而管控应用的资源访问行为。

值得注意的是，系统支持多用户特性和应用分身特性，同一个应用在不同的子用户下和不同的应用分身下会有各自的AT，这些AT的TokenID也是不同的。
APL等级

为了防止应用过度索取和滥用权限，系统基于APL（Ability Privilege Level，元能力权限等级）等级，配置了不同的权限开放范围。

元能力权限等级APL指的是应用的权限申请优先级的定义，不同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的应用。- 仅对系统应用开放。

访问控制列表（ACL）

如上所述，权限APL等级和应用APL等级是一一对应的。原则上，拥有低APL等级的应用默认无法申请更高等级的权限。访问控制列表ACL（Access Control List）提供了解决低等级应用访问高等级权限问题的特殊渠道。

系统权限均定义了“ACL使能”字段，当该权限的ACL使能为TRUE，应用可以使用ACL方式跨级别申请该权限。具体单个权限的定义。

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

最后呢

很多开发朋友不知道需要学习那些鸿蒙技术？鸿蒙开发岗位需要掌握那些核心技术点？为此鸿蒙的开发学习必须要系统性的进行。

而网上有关鸿蒙的开发资料非常的少，假如你想学好鸿蒙的应用开发与系统底层开发。你可以参考这份资料，少走很多弯路，节省没必要的麻烦。由两位前阿里高级研发工程师联合打造的《鸿蒙NEXT星河版OpenHarmony开发文档》里面内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、Harmony南向开发、鸿蒙项目实战等等）鸿蒙（Harmony NEXT）技术知识点

如果你是一名Android、Java、前端等等开发人员，想要转入鸿蒙方向发展。可以直接领取这份资料辅助你的学习。下面是鸿蒙开发的学习路线图。

在这里插入图片描述