本文旨在深入探讨华为鸿蒙HarmonyOS Next系统（截止目前 API12）在开发多语言电商平台方面的技术细节，基于实际开发实践进行总结。主要作为技术分享与交流载体，难免错漏，欢迎各位同仁提出宝贵意见和问题，以便共同进步。本文为原创内容，任何形式的转载必须注明出处及原作者。
在鸿蒙 Next 系统的权限管理体系中，除了常规的系统授权和用户授权外，受限开放权限与 ACL（访问控制列表）申请为开发者在特定场景下提供了更高级别的权限获取途径。合理运用这两种方式，能够满足一些特殊功能需求，同时确保系统的安全性和稳定性。今天，我们就深入探究这两个重要的权限申请机制。
一、受限开放权限：特殊场景下的权限获取
（一）受限开放权限的概念
受限开放权限是指那些通常情况下不向第三方应用开放，但在某些特殊场景下，经过严格审核后可允许应用申请的权限。这些权限涉及到系统的一些敏感功能或用户的重要数据，因此需要谨慎管理，以防止权限滥用。可以将其想象为系统中的“高级机密区域”，只有满足特定条件的应用才能获得进入的许可。
（二）常见受限开放权限及特殊场景
-
读取音频文件权限（ohos.permission.READ_AUDIO）
- 特殊场景：当应用需要克隆、备份或同步音频类文件时，可能需要申请此权限。例如，一款音乐编辑应用可能需要读取用户音频文件进行编辑和处理，或者音乐播放应用需要读取本地音频文件进行播放列表的管理。
- 替代方案：在其他非特殊场景下，应优先考虑使用“AudioPicker”来访问用户音频文件。这种方式可以在不申请受限权限的情况下，实现对音频文件的访问，降低了权限获取的难度和风险。
-
修改音频文件权限（ohos.permission.WRITE_AUDIO）
- 特殊场景：与读取音频文件权限类似，当应用涉及音频文件的克隆、备份或同步操作，且需要对音频文件进行修改时，可申请此权限。比如，音频格式转换应用需要修改音频文件的编码格式。
- 替代方案：使用“AudioPicker”保存用户音频文件，避免直接申请修改权限，减少对系统的潜在风险。
-
读取剪贴板权限（ohos.permission.READ_PASTEBOARD）
- 特殊场景：在 2in1 设备上的应用通常可以申请此权限，此外，银行类应用在需要读取剪贴板中的银行卡号自动生成卡片、应用需要读取剪贴板中特定格式口令自动打开应用内对应页面以及文档编辑类应用等场景下，也可申请。例如，银行应用为了方便用户快速输入银行卡号，可读取剪贴板中的卡号信息。
- 替代方案：对于大多数应用，建议使用“粘贴控件”来读取剪贴板数据，这种方式无需申请受限权限，同时提供了便捷的用户体验。
（三）受限开放权限申请流程
- 审核前置准备 开发者在申请受限开放权限之前，必须仔细审视应用是否确实符合相关的特殊场景需求。这需要对应用的功能和业务逻辑进行深入分析，确保申请的必要性和合理性。同时，应优先探索是否存在其他替代方案，如使用系统提供的相关组件或控件来实现相同功能，以避免不必要的权限申请。
-
AGC 申请与审核
- 提交申请材料：若确定需要申请受限开放权限，开发者需提供详细的申请材料到应用市场（AppGallery Connect，简称为 AGC）。这些材料包括应用的使用场景说明、功能描述、申请权限的原因等，务必确保信息准确、完整且真实。例如，若申请读取音频文件权限，需详细说明在音频克隆、备份或同步过程中的具体操作流程和用户价值。
- 审核过程与注意事项：AGC 将根据提交的材料对应用的使用场景进行严格审核。审核过程中，会重点评估申请权限是否与应用的实际功能紧密相关，是否符合受限开放权限的使用规范。开发者应密切关注审核结果，如有需要，及时补充或修正申请材料。
（四）受限开放权限申请场景与替代方案表格展示
| 权限名称 | 可申请特殊场景 | 替代方案 |
|---|---|---|
| ohos.permission.READ_AUDIO | 应用需要克隆、备份或同步音频类文件 | 使用“AudioPicker”访问用户音频文件 |
| ohos.permission.WRITE_AUDIO | 应用需要克隆、备份或同步音频类文件 | 使用“AudioPicker”保存用户音频文件 |
| ohos.permission.READ_PASTEBOARD | 银行类应用读取剪贴板中的银行卡号自动生成卡片、应用读取剪贴板中特定格式口令自动打开应用内对应页面、文档编辑类应用等 | 使用“粘贴控件”读取剪贴板数据 |
二、ACL 申请：突破权限等级限制
（一）ACL 申请的作用
ACL 申请为低等级应用提供了一种获取高级别权限的特殊途径。在鸿蒙 Next 系统中，权限等级与应用的 APL（Ability Privilege Level）等级密切相关，原则上低 APL 等级的应用无法申请更高等级的权限。然而，通过 ACL 申请机制，在满足特定条件下，应用可以跨越权限等级限制，访问到更高级别的系统资源。这就像是为有特殊需求的应用搭建了一座临时的“权限桥梁”，使其能够在安全可控的前提下获取所需权限。
（二）ACL 申请流程
-
AGC 侧申请 Profile 文件
- 重要性与用途：Profile 文件在 ACL 申请过程中起着关键作用，它用于后续的应用签名信息配置。开发者必须在 AGC 侧申请 Profile 文件时，明确申请使用相应的受限权限。这一步骤就像是为应用获取“通行证”的申请过程，只有在申请中注明了所需的权限，后续的操作才能顺利进行。
- 申请步骤与注意事项：在申请 Profile 文件时，开发者需按照 AGC 的要求填写准确的应用信息和权限使用场景描述。确保所提供的信息与实际应用功能和权限需求相符，否则可能导致申请被驳回。例如，若应用需要通过 ACL 申请访问系统硬件信息的权限，在申请 Profile 文件时应详细说明应用如何使用该硬件信息以及对用户的价值。
-
代码工程中声明权限
- 配置文件声明：在 AGC 侧完成 Profile 文件申请后，开发者需要在代码工程的配置文件中声明所需权限。与普通权限声明类似，在“module.json5”配置文件的“requestPermissions”标签中进行声明。例如：
{
"module": {
"requestPermissions":[
{
"name": "ohos.permission.SOME_ADVANCED_PERMISSION",
"reason": "$string:reason_for_advanced_permission",
"usedScene": {
"abilities": [
"MainAbility"
],
"when":"inuse"
}
}
]
}
}
其中，“name”为要申请的高级权限名称，“reason”需详细说明申请该权限的原因，遵循权限使用理由的文案规范，“usedScene”指定权限使用的场景。
- 用户授权相关（如有）：如果申请的高级权限属于 user_grant 类型，还需要按照用户授权的流程，在应用运行时通过弹窗向用户申请权限，并处理用户的授权结果。这确保了即使是通过 ACL 申请的高级权限，也遵循用户知情权和选择权的原则。
（三）示例代码：使用 ACL 申请读取音频文件权限
以下是一个使用 ACL 申请读取音频文件权限（ohos.permission.READ_AUDIO）的示例代码：
import { abilityAccessCtrl, bundleManager, Permissions } from '@kit.AbilityKit';
import { BusinessError } from '@kit.BasicServicesKit';
// 定义要申请的受限开放权限（这里以读取音频文件权限为例）
const advancedPermission: Permissions = 'ohos.permission.READ_AUDIO';
// 检查应用当前是否已被授予该高级权限
async function checkAdvancedPermissionGrant(): Promise<abilityAccessCtrl.GrantStatus> {
let atManager: abilityAccessCtrl.AtManager = abilityAccessCtrl.createAtManager();
let grantStatus: abilityAccessCtrl.GrantStatus = abilityAccessCtrl.GrantStatus.PERMISSION_DENIED;
// 获取应用程序的 accessTokenID
let tokenId: number = 0;
try {
let bundleInfo: bundleManager.BundleInfo = await bundleManager.getBundleInfoForSelf(bundleManager.BundleFlag.GET_BUNDLE_INFO_WITH_APPLICATION);
let appInfo: bundleManager.ApplicationInfo = bundleInfo.appInfo;
tokenId = appInfo.accessTokenId;
} catch (error) {
const err: BusinessError = error as BusinessError;
console.error(`Failed to get bundle info for self. Code is ${err.code}, message is ${err.message}`);
}
// 校验应用是否被授予高级权限
try {
grantStatus = await atManager.checkAccessToken(tokenId, advancedPermission);
} catch (error) {
const err: BusinessError = error as BusinessError;
console.error(`Failed to check access token for advanced permission. Code is ${err.code}, message is ${err.message}`);
}
return grantStatus;
}
// 申请高级权限的主函数
async function requestAdvancedPermission(): Promise<void> {
let grantStatus: abilityAccessCtrl.GrantStatus = await checkAdvancedPermissionGrant();
if (grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED) {
// 已获得高级权限，可以进行读取音频文件的操作
console.log('已成功获取读取音频文件权限，可以进行相关操作。');
// 在这里添加读取音频文件的具体代码逻辑
} else {
// 申请高级权限
reqAdvancedPermissionFromUser();
}
}
// 使用 API 动态请求用户授权（如果权限为 user_grant 类型）
function reqAdvancedPermissionFromUser(): void {
let atManager: abilityAccessCtrl.AtManager = abilityAccessCtrl.createAtManager();
atManager.requestPermissionsFromUser(globalThis.context as common.UIAbilityContext, [advancedPermission]).then((data) => {
let grantStatus: Array<number> = data.authResults;
let length: number = grantStatus.length;
for (let i = 0; i < length; i++) {
if (grantStatus[i] === 0) {
// 用户授权，可以继续访问目标操作，进行读取音频文件的操作
console.log('用户已授权读取音频文件权限，可以进行相关操作。');
// 在这里添加读取音频文件的具体代码逻辑
} else {
// 用户拒绝授权，提示用户必须授权才能访问相关功能，并引导用户到系统设置中打开相应权限
console.log('用户拒绝授权读取音频文件权限，请前往系统设置中手动授予权限。');
return;
}
}
// 授权成功
}).catch((err: BusinessError) => {
console.error(`Failed to request advanced permission from user. Code is ${err.code}, message is ${err.message}`);
});
}
// 在应用启动或需要使用该高级权限的地方调用 requestAdvancedPermission() 函数来启动权限申请流程
requestAdvancedPermission();
在上述示例代码中，首先定义了要申请的读取音频文件权限（ohos.permission.READ_AUDIO）。然后通过“checkAdvancedPermissionGrant()”函数检查应用当前是否已获得该权限。如果未获得权限，则调用“reqAdvancedPermissionFromUser()”函数向用户发起授权请求（如果该权限属于 user_grant 类型）。根据用户的授权结果，应用会在控制台输出相应的提示信息，并在授权成功后可以执行读取音频文件的相关操作。
总之，受限开放权限和 ACL 申请为鸿蒙 Next 应用开发提供了在特殊场景下获取高级别权限的途径。我们在使用过程中，必须严格遵循申请流程和规范，充分考虑用户隐私和系统安全，确保权限的合理使用。通过合理运用这些权限申请机制，开发者能够为用户打造功能更强大、体验更优质的应用，同时也为鸿蒙 Next 生态系统的安全与稳定贡献力量。希望本文能够帮助各位同行者更好地理解和运用受限开放权限与 ACL 申请，在鸿蒙 Next 应用开发的道路上迈出更加坚实的步伐。
Top comments (0)