提交 41a7d992 编写于 作者: zyjhandsome's avatar zyjhandsome

重构《访问控制授权申请》指南

start build
Signed-off-by: zyjhandsome's avatarzyjhandsome <zyjhandsome@126.com>
上级 e9ad132b
# 访问控制授权申请指导
# 访问控制授权申请
## 场景介绍
以下示例代码基于此场景假设:应用因为应用核心功能诉求,需要申请权限"ohos.permission.PERMISSION1"和权限"ohos.permission.PERMISSION2"
[应用的APL(Ability Privilege Level)等级](accesstoken-overview.md#应用apl等级说明)分为`normal``system_basic``system_core`三个等级,默认情况下,应用的APL等级都为`normal`等级。[权限类型](accesstoken-overview.md#权限类型说明)分为`system_grant``user_grant`两种类型。应用可申请的权限项参见[应用权限列表](permission-list.md)
- 应用的APL等级为normal。
- 权限"ohos.permission.PERMISSION1"的权限等级为normal,权限类型为system_grant。
- 权限"ohos.permission.PERMISSION2"的权限等级为system_basic, 权限类型为user_grant。
本文将从如下场景分别介绍:
> **注意:**
>
> 当前场景下,应用申请的权限包括了user_grant权限,对这部分user_grant权限,可以先通过权限校验,判断当前调用者是否具备相应权限。
>
> 当权限校验结果显示当前应用尚未被授权该权限时,再通过动态弹框授权方式给用户提供手动授权入口。
- [配置文件权限声明](#配置文件权限声明)
- [ACL权限声明](#ACL权限声明)
- [向用户申请授权](#向用户申请授权)
- [user_grant权限预授权](#user_grant权限预授权)
应用可申请的权限,可查询[应用权限列表](permission-list.md)
## 配置文件权限声明
## 接口说明
应用需要在工程配置文件中,对需要的权限逐个声明,未在配置文件中声明的权限,应用将无法获得授权。OpenHarmony提供了两种应用模型,分别为FA模型和Stage模型,更多信息可以参考[应用模型解读](../application-models/application-model-description.md)。不同的应用模型的应用包结构不同,所使用的配置文件不同。
以下仅列举本指导使用的接口,不同模型下使用的拉起权限弹窗的接口有差异,更多说明可以查阅[完整示例](##完整示例)
### FA模型
| 接口名 | 描述 |
| ------------------------------------------------------------ | --------------------------------------------------- |
| requestPermissionsFromUser(permissions: Array&lt;string&gt;, requestCallback: AsyncCallback&lt;PermissionRequestResult&gt;) : void; | 拉起弹窗请求用户授权。 |
> 详细可查阅[API参考](../reference/apis/js-apis-ability-context.md)
配置文件标签说明如下表所示。
| 标签 | 是否必填 | 说明 |
| --------- | -------- | ------------------------------------------------------------ |
| name | 是 | 权限名称。 |
| reason | 否 | 描述申请权限的原因。<br />> 说明:当申请的权限为user_grant权限时,此字段必填。 |
| usedScene | 否 | 描述权限使用的场景和时机。<br />> 说明:当申请的权限为user_grant权限时,此字段必填。 |
| abilities | 否 | 标识需要使用到该权限的Ability,标签为数组形式。<br/>**适用模型:**Stage模型 |
| ability | 否 | 标识需要使用到该权限的Ability,标签为数组形式。<br/>**适用模型:**FA模型 |
| when | 否 | 标识权限使用的时机,值为`inuse/always`<br />- inuse:表示为仅允许前台使用。<br />- always:表示前后台都可使用。 |
### Stage模型
| 接口名 | 描述 |
| ------------------------------------------------------------ | --------------------------------------------------- |
| requestPermissionsFromUser(context: Context, permissions: Array&lt;Permissions&gt;, requestCallback: AsyncCallback&lt;PermissionRequestResult&gt;) : void; | 拉起弹窗请求用户授权。 |
> 详细可查阅[API参考](../reference/apis/js-apis-abilityAccessCtrl.md)
## 权限申请声明
应用需要在工程配置文件中,对需要的权限逐个声明,没有在配置文件中声明的权限,应用将无法获得授权。OpenHarmony提供了两种应用模型,分别为FA模型和Stage模型,更多信息可以参考[应用模型解读](../application-models/application-model-description.md)
不同的应用模型的应用包结构不同,所使用的配置文件不同,请开发者在申请权限时注意区分。
配置文件标签说明如下表。
| 标签 | 说明 |
| --------- | ------------------------------------------------------------ |
| name | 权限名称。 |
| reason | 当申请的权限为user_grant权限时,此字段必填,描述申请权限的原因。 |
| usedScene | 当申请的权限为user_grant权限时,此字段必填,描述权限使用的场景和时机。 |
| ability | 标识需要使用到该权限的Ability,标签为数组形式。 <br/>**适用模型:** FA模型 |
| abilities | 标识需要使用到该权限的Ability,标签为数组形式。 <br/>**适用模型:** Stage模型 |
| when | 标识权限使用的时机,值为"inuse/always",表示为仅允许前台使用和前后台都可使用。 |
### FA模型
使用FA模型的应用,需要在config.json文件中声明权限。
**示例:**
使用Stage模型的应用,需要在[module.json5配置文件](../quick-start/module-configuration-file.md)中声明权限。
```json
{
"module" : {
"reqPermissions":[
// ...
"requestPermissions":[
{
"name" : "ohos.permission.PERMISSION1",
"reason": "$string:reason",
"usedScene": {
"ability": [
"abilities": [
"FormAbility"
],
"when":"inuse"
......@@ -75,7 +49,7 @@
"name" : "ohos.permission.PERMISSION2",
"reason": "$string:reason",
"usedScene": {
"ability": [
"abilities": [
"FormAbility"
],
"when":"always"
......@@ -86,21 +60,20 @@
}
```
### Stage模型
使用Stage模型的应用,需要在module.json5文件中声明权限。
### FA模型
**示例:**
使用FA模型的应用,需要在config.json配置文件中声明权限。
```json
{
"module" : {
"requestPermissions":[
// ...
"reqPermissions":[
{
"name" : "ohos.permission.PERMISSION1",
"reason": "$string:reason",
"usedScene": {
"abilities": [
"ability": [
"FormAbility"
],
"when":"inuse"
......@@ -110,7 +83,7 @@
"name" : "ohos.permission.PERMISSION2",
"reason": "$string:reason",
"usedScene": {
"abilities": [
"ability": [
"FormAbility"
],
"when":"always"
......@@ -121,115 +94,154 @@
}
```
## ACL方式声明
## ACL权限声明
如上述示例所示,权限"ohos.permission.PERMISSION2"的权限等级为system_basic,高于此时应用的APL等级,开发者的最佳做法是使用ACL方式。
在配置文件声明的基础上,应用还需要在Profile文件中声明不满足申请条件部分的权限。Profile文件的字段说明可参考[HarmonyAppProvision配置文件的说明](app-provision-structure.md)
该场景中,开发者应该在字段"acls"中做声明如下:
应用在申请`system_basic`等级权限时,高于应用默认的`normal`等级。当应用需要申请权限项的等级高于应用默认的等级时,需要通过ACL方式进行声明使用。例如应用在申请访问用户公共目录下音乐类型的文件,需要申请` ohos.permission.WRITE_AUDIO`权限,该权限为`system_basic`等级,需要将该权限项配置到[HarmonyAppProvision配置文件](app-provision-structure.md)`acl`字段中。
```json
{
"acls": {
"allowed-acls": [
"ohos.permission.PERMISSION2"
]
}
// ...
"acls":{
"allowed-acls":[
"ohos.permission.WRITE_AUDIO"
]
}
}
```
## 申请授权user_grant权限
在前期的权限声明步骤后,在安装过程中系统会对system_grant类型的权限进行权限预授权,而user_grant类型权限则需要用户进行手动授权。
## 向用户申请授权
所以,应用在调用受"ohos.permission.PERMISSION2"权限保护的接口前,需要先校验应用是否已经获取该权限。
应用需要获取用户的隐私信息或使用系统能力时,例如获取位置信息、访问日历、使用相机拍摄照片或者录制视频等,需要向用户申请授权。此时应用申请的权限包括了`user_grant`类型权限,需要先通过权限校验,判断当前调用者是否具备相应权限。当权限校验结果显示当前应用尚未被授权该权限时,再通过动态弹框授权方式给用户提供手动授权入口。示意效果如下图所示。
<img src="figures/permission-read_calendar.jpeg" width="40%;" />
如果校验结果显示,应用已经获取了该权限,那么应用可以直接访问该目标接口,否则,应用需要通过动态弹框先申请用户授权,并根据授权结果进行相应处理,处理方式可参考[访问控制开发概述](accesstoken-overview.md)
> **说明**:每次访问受目标权限保护的接口前,都需要调用[requestPermissionsFromUser()](../reference/apis/js-apis-abilityAccessCtrl.md#requestpermissionsfromuser9)接口请求权限,用户在动态授予后可能通过设置取消应用的权限,因此不能把之前授予的授权状态持久化
> **注意:**
>
> 不能把之前授予的状态持久化,每次访问受目标权限保护的接口前,都应该调用requestPermissionsFromUser接口请求权限,因为用户在动态授予后可能通过设置取消应用的权限。
### Stage模型
## 完整示例
以允许应用读取日历信息为例进行说明。
1. 申请`ohos.permission.READ_CALENDAR`权限,配置方式请参见[访问控制授权申请](#Stage模型)
2. 可以在UIAbility的onWindowStageCreate()回调中调用[requestPermissionsFromUser()](../reference/apis/js-apis-abilityAccessCtrl.md#requestpermissionsfromuser9)接口动态申请权限,也可以根据业务需要在UI界面中向用户申请授权。根据[requestPermissionsFromUser()](../reference/apis/js-apis-abilityAccessCtrl.md#requestpermissionsfromuser9)接口返回值判断是否已获取目标权限,如果当前已经获取权限,则可以继续正常访问目标接口。
在UIAbility中动态申请授权。
```typescript
import UIAbility from '@ohos.app.ability.UIAbility';
import Window from '@ohos.window';
import abilityAccessCtrl from '@ohos.abilityAccessCtrl';
import { Permissions } from '@ohos.abilityAccessCtrl';
export default class EntryAbility extends UIAbility {
// ...
onWindowStageCreate(windowStage: Window.WindowStage) {
// Main window is created, set main page for this ability
let context = this.context;
let AtManager = abilityAccessCtrl.createAtManager();
// requestPermissionsFromUser会判断权限的授权状态来决定是否唤起弹窗
const permissions: Array<Permissions> = ['ohos.permission.READ_CALENDAR'];
AtManager.requestPermissionsFromUser(context, permissions).then((data) => {
console.info(`[requestPermissions] data: ${JSON.stringify(data)}`);
let grantStatus: Array<number> = data.authResults;
if (grantStatus[0] === -1) {
// 授权失败
} else {
// 授权成功
}
}).catch((err) => {
console.error(`[requestPermissions] Failed to start request permissions. Error: ${JSON.stringify(err)}`);
})
// ...
}
}
```
在UI界面中向用户申请授权。
```typescript
import abilityAccessCtrl from '@ohos.abilityAccessCtrl';
import { Permissions } from '@ohos.abilityAccessCtrl';
import common from '@ohos.app.ability.common';
@Entry
@Component
struct Index {
reqPermissions() {
let context = getContext(this) as common.UIAbilityContext;
let AtManager = abilityAccessCtrl.createAtManager();
// requestPermissionsFromUser会判断权限的授权状态来决定是否唤起弹窗
const permissions: Array<Permissions> = ['ohos.permission.READ_CALENDAR'];
AtManager.requestPermissionsFromUser(context, permissions).then((data) => {
console.info(`[requestPermissions] data: ${JSON.stringify(data)}`);
let grantStatus: Array<number> = data.authResults;
if (grantStatus[0] === -1) {
// 授权失败
} else {
// 授权成功
}
}).catch((err) => {
console.error(`[requestPermissions] Failed to start request permissions. Error: ${JSON.stringify(err)}`);
})
}
// 页面展示
build() {
// ...
}
}
```
请求用户授权权限的开发步骤为:
### FA模型
1. 获取ability的上下文context。
2. 调用requestPermissionsFromUser接口请求权限。运行过程中,该接口会根据应用是否已获得目标权限决定是否拉起动态弹框请求用户授权。
3. 根据requestPermissionsFromUser接口返回值判断是否已获取目标权限。如果当前已经获取权限,则可以继续正常访问目标接口。
通过调用[requestPermissionsFromUser()](../reference/apis/js-apis-inner-app-context.md#contextrequestpermissionsfromuser7)接口向用户动态申请授权。
### FA模型下的示例代码
```js
//ability的onWindowStageCreate生命周期
onWindowStageCreate() {
var context = this.context
// Ability的onWindowStageCreate()生命周期
onWindowStageCreate() {
let context = this.context;
let array:Array<string> = ["ohos.permission.PERMISSION2"];
//requestPermissionsFromUser会判断权限的授权状态来决定是否唤起弹窗
context.requestPermissionsFromUser(array).then(function(data) {
console.log("data type:" + typeof(data));
console.log("data:" + data);
console.log("data permissions:" + data.permissions);
console.log("data result:" + data.authResults);
console.log("data:" + JSON.stringify(data));
console.log("data permissions:" + JSON.stringify(data.permissions));
console.log("data result:" + JSON.stringify(data.authResults));
}, (err) => {
console.error('Failed to start ability', err.code);
console.error('Failed to start ability', err.code);
});
}
}
```
> **说明:**
> FA模型的动态授权申请接口的使用详见[API参考](../reference/apis/js-apis-ability-context.md)。
### stage 模型下的示例代码
```js
import abilityAccessCtrl from '@ohos.abilityAccessCtrl';
//ability的onWindowStageCreate生命周期
onWindowStageCreate() {
var context = this.context
var AtManager = abilityAccessCtrl.createAtManager();
//requestPermissionsFromUser会判断权限的授权状态来决定是否唤起弹窗
AtManager.requestPermissionsFromUser(context, ["ohos.permission.MANAGE_DISPOSED_APP_STATUS"]).then((data) => {
console.log("data type:" + typeof(data));
console.log("data:" + data);
console.log("data permissions:" + data.permissions);
console.log("data result:" + data.authResults);
}).catch((err) => {
console.error('Failed to start ability', err.code);
})
}
## user_grant权限预授权
应用在申请`user_grant`类型的权限默认未授权,需要通过拉起弹框由用户确认是否授予该权限。对于一些预制应用,不希望出现弹窗申请`user_grant`类型的权限,例如系统相机应用需要使用麦克风` ohos.permission.MICROPHONE`等权限,需要对麦克风等权限进行预授权,可以通过预授权的方式完成`user_grant`类型权限的授权。[预置配置文件](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/preinstall-config/install_list_permissions.json)在设备上的路径为`/system/etc/app/install_list_permission.json`,设备开机启动时会读取该配置文件,在应用安装会对在文件中配置的`user_grant`类型权限授权。预授权配置文件字段内容包括`bundleName``app_signature``permissions`
```
> **说明:**
> stage模型的动态授权申请接口的使用详见[API参考](../reference/apis/js-apis-abilityAccessCtrl.md)
- `bundleName`字段配置为应用的Bundle名称。
- `app_signature`字段配置为应用的指纹信息。指纹信息的配置参见[应用特权配置指南](../../device-dev/subsystems/subsys-app-privilege-config-guide.md#install_list_capabilityjson中配置)
- `permissions`字段中name配置为需要预授权的`user_grant`类型的权限名;`permissions`字段中`userCancellable`表示为用户是否能够取消该预授权,配置为true,表示支持用户取消授权,为false则表示不支持用户取消授权
## user_grant权限预授权
当前正常情况下,user_grant类型的权限默认不授权,需要时应通过拉起弹框由用户确认是否授予。对于一些预置应用,比如截屏应用,不希望出现弹框,则可以通过预授权的方式完成user_grant类型权限的授权。[预置配置文件](https://gitee.com/openharmony/vendor_hihope/blob/master/rk3568/preinstall-config/install_list_permissions.json)在设备上的路径为system/etc/app/install_list_permission.json,设备开机启动时会读取该配置文件,在应用安装会对在文件中配置的user_grant类型权限授权。当前仅支持预置应用配置该文件。
预授权配置文件字段内容包括bundleName、app_signature、permissions。
1. 这里的权限仅对user_grant类型的权限生效[查看权限等级和类型](permission-list.md)
2. userCancellable配置为true,表示支持用户取消授权,为false则表示不支持用户取消授权。
> 说明:当前仅支持预置应用配置该文件。
```json
[
// ...
{
"bundleName": "com.ohos.myapplication", // Bundle名称
"app_signature":[], // 指纹信息
"bundleName": "com.example.myapplication", // Bundle名称
"app_signature": ["****"], // 指纹信息
"permissions":[
{
"name":"xxxx", // 权限名,不可缺省
"userCancellable":false // 用户不可取消授权,不可缺省
"name": "ohos.permission.PERMISSION_X", // user_grant类型预授权的权限名
"userCancellable": false // 用户不可取消授权
},
{
"name":"yyy", // 权限名,不可缺省
"userCancellable":true // 用户可取消授权,不可缺省
"name": "ohos.permission.PERMISSION_Y", // user_grant类型预授权的权限名
"userCancellable": true // 用户可取消授权
}
]
}
]
```
## 相关实例
针对访问控制,有以下相关实例可供参考:
- [`AbilityAccessCtrl`:访问权限控制(ArkTS)(API8)(Full SDK)](https://gitee.com/openharmony/applications_app_samples/tree/master/Safety/AbilityAccessCtrl)
- [AbilityAccessCtrl:访问权限控制(ArkTS)(API8)(Full SDK)](https://gitee.com/openharmony/applications_app_samples/tree/master/Safety/AbilityAccessCtrl)
- [为应用添加运行时权限(ArkTS)(API 9)](https://gitee.com/openharmony/codelabs/tree/master/Ability/AccessPermission)
\ No newline at end of file
# HarmonyAppProvision配置文件说明
# HarmonyAppProvision配置文件说明
在应用的开发过程中,应用的权限、签名信息等需要在HarmonyAppProvision配置文件(该文件在部分文档中也称为profile文件)中声明。
## 配置文件的内部结构
......@@ -16,7 +16,7 @@ HarmonyAppProvision文件包含version-code对象、version-name对象、uuid对
| acls | 表示授权的acl权限信息。参考[acls对象内部结构](#acls对象内部结构)。 | 对象 | 可选 | 可缺省 |
| permissions | 表示允许使用的受限敏感权限信息。参考[permissions对象内部结构](#permissions对象内部结构)。 | 对象 | 可选 | 可缺省 |
| debug-info | 表示应用调试场景下的额外信息。参考[debug-info对象内部结构](#debug-info对象内部结构)。 | 对象 | 可选 | 可缺省 |
| app-privilege-capabilities | 表示应用包所需要的特权信息。可以参考[应用特权配置指南](../../device-dev/subsystems/subsys-app-privilege-config-guide.md) | 字符串数组 | 可选 | 可缺省 |
| app-privilege-capabilities | 表示应用包所需要的特权信息。可以参考[应用特权配置指南](../../device-dev/subsystems/subsys-app-privilege-config-guide.md) | 字符串数组 | 可选 | 可缺省 |
HarmonyAppProvision文件示例:
```json
......@@ -74,14 +74,14 @@ HarmonyAppProvision文件示例:
### acls对象内部结构
acls对象包含已授权的[ACL权限](accesstoken-overview.md)。需要指出的是,开发者仍然需要在[应用包配置文件](../quick-start/module-configuration-file.md#requestpermissions标签)将acls权限信息填写到reqPermissions属性中。
acls对象包含已授权的[ACL权限](accesstoken-overview.md)。需要指出的是,开发者仍然需要在[应用包配置文件](../quick-start/module-configuration-file.md#requestpermissions标签)将acls权限信息填写到requestPermissions属性中。
| 属性名称 | 含义 | 数据类型 | 是否必选 | 是否可缺省 |
| ------------------------ | ------------------------------- | ------- | ------- | --------- |
| allowed-acls | 表示已授权的[acl权限](accesstoken-overview.md)列表。 | 字符串数组 | 可选 | 不可缺省 |
### permissions对象内部结构
permissions对象包含允许使用的受限敏感权限。不同于acls对象,permissions对象中的权限仅代表应用允许使用该敏感权限,权限最终由用户运行时授权。需要指出的是,开发者仍然需要在[应用包配置文件](../quick-start/module-configuration-file.md#requestpermissions标签)将permissions权限信息填写到reqPermissions属性中。
permissions对象包含允许使用的受限敏感权限。不同于acls对象,permissions对象中的权限仅代表应用允许使用该敏感权限,权限最终由用户运行时授权。需要指出的是,开发者仍然需要在[应用包配置文件](../quick-start/module-configuration-file.md#requestpermissions标签)将permissions权限信息填写到requestPermissions属性中。
| 属性名称 | 含义 | 数据类型 | 是否必选 | 是否可缺省 |
| ------------------------ | ------------------------------- | ------- | ------- | --------- |
......
......@@ -4,7 +4,7 @@
OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单独配置的应用特权。当签名证书中配置的特权与白名单(install_list_capability.json)中特权相同时,以白名单的配置为主。
:应当注意不要滥用应用特权,避免造成用户反感甚至对用户造成侵权。
> 说明:应当注意不要滥用应用特权,避免造成用户反感甚至对用户造成侵权。
## 通用应用特权
......@@ -14,22 +14,22 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
| 权限 | 描述 |
| ---------------- | ------------------------------------------------------------ |
| AllowAppDataNotCleared | 是否允许应用数据被删除 |
| AllowAppDesktopIconHide | 是否允许隐藏桌面图标 |
| AllowAbilityPriorityQueried | 是否允许Ability配置查询优先级 |
| AllowAbilityExcludeFromMissions | 是否允许Ability不在任务栈中显示 |
| AllowAppDataNotCleared | 是否允许应用数据被删除 |
| AllowAppDesktopIconHide | 是否允许隐藏桌面图标 |
| AllowAbilityPriorityQueried | 是否允许Ability配置查询优先级 |
| AllowAbilityExcludeFromMissions | 是否允许Ability不在任务栈中显示 |
### 配置方式
1.[HarmonyAppProvision文件](../../application-dev/security/app-provision-structure.md)中添加字段”app-privilege-capabilities“,按需配置通用权限能力。
2. 使用签名工具对HarmonyAppProvision文件重新签名,生成p7b文件
3. 使用p7b文件签名hap
2. 使用签名工具对[HarmonyAppProvision文件](../../application-dev/security/app-provision-structure.md)重新签名,生成p7b文件。
3. 使用p7b文件签名HAP。
参考:[应用签名](https://gitee.com/openharmony/developtools_hapsigner#hap%E5%8C%85%E7%AD%BE%E5%90%8D%E5%B7%A5%E5%85%B7 )
参考:[应用签名](https://gitee.com/openharmony/developtools_hapsigner#hap%E5%8C%85%E7%AD%BE%E5%90%8D%E5%B7%A5%E5%85%B7 )
### 示例
```
```json
{
"version-name": "1.0.0",
...
......@@ -42,8 +42,6 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
}
```
## 可由设备厂商配置的特权
### 简介
......@@ -52,19 +50,19 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
| 权限 | 类型 | 默认值 | 描述 |
| --------------------- | -------- | ------ | ------------------------------------------------- |
| removable | bool | true | 是否允许应用被卸载,仅预置应用生效 |
| keepAlive | bool | false | 是否允许应用常驻 |
| singleton | bool | false | 是否允许应用安装到单用户下(U0) |
| allowCommonEvent | string[] | - | 是否允许静态广播拉起 |
| associatedWakeUp | bool | false | 是否允许FA模型应用被关联唤醒 |
| runningResourcesApply | bool | false | 是否允许应用运行资源申请(CPU、事件通知、蓝牙等) |
| allowAppDataNotCleared | bool | false|是否允许应用数据被删除 |
| allowAppMultiProcess | bool | false| 是否允许应用多进程 |
| allowAppDesktopIconHide | bool | false| 是否允许隐藏桌面图标 |
| allowAbilityPriorityQueried | bool | false| 是否允许Ability配置查询优先级 |
| allowAbilityExcludeFromMissions | bool | false| 是否允许Ability不在任务栈中显示 |
| allowAppUsePrivilegeExtension | bool | false|是否允许应用使用ServiceExtension、DataExtension |
| allowFormVisibleNotify | bool | false| 是否允许桌面卡片可见 |
| removable | bool | true | 是否允许应用被卸载,仅预置应用生效 |
| keepAlive | bool | false | 是否允许应用常驻 |
| singleton | bool | false | 是否允许应用安装到单用户下(U0) |
| allowCommonEvent | string[] | - | 是否允许静态广播拉起 |
| associatedWakeUp | bool | false | 是否允许FA模型应用被关联唤醒 |
| runningResourcesApply | bool | false | 是否允许应用运行资源申请(CPU、事件通知、蓝牙等) |
| allowAppDataNotCleared | bool | false|是否允许应用数据被删除 |
| allowAppMultiProcess | bool | false| 是否允许应用多进程 |
| allowAppDesktopIconHide | bool | false| 是否允许隐藏桌面图标 |
| allowAbilityPriorityQueried | bool | false| 是否允许Ability配置查询优先级 |
| allowAbilityExcludeFromMissions | bool | false| 是否允许Ability不在任务栈中显示 |
| allowAppUsePrivilegeExtension | bool | false|是否允许应用使用ServiceExtension、DataExtension |
| allowFormVisibleNotify | bool | false| 是否允许桌面卡片可见 |
### 配置方式
......@@ -74,7 +72,7 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
#### install_list_capability.json中配置
```
```json
{
"install_list": [
{
......@@ -83,7 +81,7 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
"keepAlive": true, // 应用常驻
"runningResourcesApply": true, // 运行资源申请(CPU、事件通知、蓝牙等)
"associatedWakeUp": true, // FA模型应用被关联唤醒
"app_signature" : [“8E93863FC32EE238060BF69A9B37E2608FFFB21F93C862DD511CBAC”], // 当配置的证书指纹和hap的证书指纹一致才生效
"app_signature" : ["****"], // 当配置的证书指纹和hap的证书指纹一致才生效
"allowCommonEvent": [“usual.event.SCREEN_ON”, “usual.event.THERMAL_LEVEL_CHANGED”],
"allowAppDataNotCleared": true, // 不允许应用数据被删除
"allowAppMultiProcess": true, //允许应用多进程
......@@ -98,64 +96,59 @@ OpenHarmony提供通用的应用特权和可由设备厂商针对不同设备单
**证书指纹获取**
**步骤一、证书存放在HarmonyAppProvision文件的distribution-certificate字段下,新建profile.cer文件,将证书的内容拷贝到profile.cer文件中**
示例
```
{
...
"bundle-info": {
"distribution-certificate": "-----BEGIN CERTIFICATE----\nMIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMk..." /证书的内容
...
}
...
}
```
**步骤二、将profile.cer内容换行和去掉换行符**
示例
```
-----BEGIN CERTIFICATE-----
MIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMGMxCzAJBgNVBAYTAkNO
MRQwEgYDVQQKEwtPcGVuSGFybW9ueTEZMBcGA1UECxMQT3Blbkhhcm1vbnkgVGVh
bTEjMCEGA1UEAxMaT3Blbkhhcm1vbnkgQXBwbGljYXRpb24gQ0EwHhcNMjEwMjAy
MTIxOTMxWhcNNDkxMjMxMTIxOTMxWjBoMQswCQYDVQQGEwJDTjEUMBIGA1UEChML
T3Blbkhhcm1vbnkxGTAXBgNVBAsTEE9wZW5IYXJtb255IFRlYW0xKDAmBgNVBAMT
H09wZW5IYXJtb255IEFwcGxpY2F0aW9uIFJlbGVhc2UwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAATbYOCQQpW5fdkYHN45v0X3AHax12jPBdEDosFRIZ1eXmxOYzSG
JwMfsHhUU90E8lI0TXYZnNmgM1sovubeQqATo1IwUDAfBgNVHSMEGDAWgBTbhrci
FtULoUu33SV7ufEFfaItRzAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFPtxruhl
cRBQsJdwcZqLu9oNUVgaMAwGCCqGSM49BAMDBQADaAAwZQIxAJta0PQ2p4DIu/ps
LMdLCDgQ5UH1l0B4PGhBlMgdi2zf8nk9spazEQI/0XNwpft8QAIwHSuA2WelVi/o
zAlF08DnbJrOOtOnQq5wHOPlDYB4OtUzOYJk9scotrEnJxJzGsh/
-----END CERTIFICATE-----
```
**步骤三、使用keytool工具打印对应的证书指纹**
示例
```
keytool -printcert -file profile.cer
result:
所有者: CN=OpenHarmony Application Release, OU=OpenHarmony Team, O=OpenHarmony, C=CN
发布者: CN=OpenHarmony Application CA, OU=OpenHarmony Team, O=OpenHarmony, C=CN
序列号: 68e0bfcc
生效时间: Tue Feb 02 20:19:31 CST 2021, 失效时间: Fri Dec 31 20:19:31 CST 2049
证书指纹:
SHA1: E3:E8:7C:65:B8:1D:02:52:24:6A:06:A4:3C:4A:02:39:19:92:D1:F5
SHA256: 8E:93:86:3F:C3:2E:E2:38:06:0B:F6:9A:9B:37:E2:60:8F:FF:B2:1F:93:C8:62:DD:51:1C:BA:C9:F3:00:24:B5 // 证书指纹,去掉冒号,最终结果为8E93863FC32EE238060BF69A9B37E2608FFFB21F93C862DD511CBAC9F30024B5
...
```
1. 证书存放在[HarmonyAppProvision文件](../../application-dev/security/app-provision-structure.md)的distribution-certificate字段下,新建profile.cer文件,将证书的内容拷贝到profile.cer文件中。
```json
{
...
"bundle-info": {
"distribution-certificate": "-----BEGIN CERTIFICATE----\nMIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMk..." /证书的内容
...
}
...
}
```
2. 将profile.cer内容换行和去掉换行符。
```
-----BEGIN CERTIFICATE-----
MIICMzCCAbegAwIBAgIEaOC/zDAMBggqhkjOPQQDAwUAMGMxCzAJBgNVBAYTAkNO
MRQwEgYDVQQKEwtPcGVuSGFybW9ueTEZMBcGA1UECxMQT3Blbkhhcm1vbnkgVGVh
bTEjMCEGA1UEAxMaT3Blbkhhcm1vbnkgQXBwbGljYXRpb24gQ0EwHhcNMjEwMjAy
MTIxOTMxWhcNNDkxMjMxMTIxOTMxWjBoMQswCQYDVQQGEwJDTjEUMBIGA1UEChML
T3Blbkhhcm1vbnkxGTAXBgNVBAsTEE9wZW5IYXJtb255IFRlYW0xKDAmBgNVBAMT
H09wZW5IYXJtb255IEFwcGxpY2F0aW9uIFJlbGVhc2UwWTATBgcqhkjOPQIBBggq
hkjOPQMBBwNCAATbYOCQQpW5fdkYHN45v0X3AHax12jPBdEDosFRIZ1eXmxOYzSG
JwMfsHhUU90E8lI0TXYZnNmgM1sovubeQqATo1IwUDAfBgNVHSMEGDAWgBTbhrci
FtULoUu33SV7ufEFfaItRzAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0OBBYEFPtxruhl
cRBQsJdwcZqLu9oNUVgaMAwGCCqGSM49BAMDBQADaAAwZQIxAJta0PQ2p4DIu/ps
LMdLCDgQ5UH1l0B4PGhBlMgdi2zf8nk9spazEQI/0XNwpft8QAIwHSuA2WelVi/o
zAlF08DnbJrOOtOnQq5wHOPlDYB4OtUzOYJk9scotrEnJxJzGsh/
-----END CERTIFICATE-----
```
3. 使用keytool工具,执行以下命令获取对应的证书指纹。
> 说明:keytool工具可以在DevEco Studio安装后的`\tools\openjdk\bin`目录中获取。
```shell
keytool -printcert -file profile.cer
# 运行结果举例
# result:
# 所有者: CN=OpenHarmony Application Release, OU=OpenHarmony Team, O=OpenHarmony, C=CN
# 发布者: CN=OpenHarmony Application CA, OU=OpenHarmony Team, O=OpenHarmony, C=CN
# 序列号: 68e0bfcc
# 生效时间: Tue Feb 02 20:19:31 CST 2021, 失效时间: Fri Dec 31 20:19:31 CST 2049
# 证书指纹:
# SHA1: E3:E8:7C:65:B8:1D:02:52:24:6A:06:A4:3C:4A:02:39:19:92:D1:F5
# SHA256: 8E:93:86:3F:C3:2E:E2:38:06:0B:F6:9A:9B:37:E2:60:8F:FF:B2:1F:93:C8:62:DD:51:1C:BA:C9:F3:00:24:B5 // 证书指纹,去掉冒号,最终结果为8E93863FC32EE238060BF69A9B37E2608FFFB21F93C862DD511CBAC9F30024B5
# ...
```
#### install_list.json中配置
```
```json
{
"install_list" : [
{
......@@ -165,6 +158,3 @@ result:
]
}
```
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册