权限不是“想要就给”：鸿蒙系统权限控制的底层逻辑与实战解析

—— By Echo_Wish（一个坚持相信“权限越大，责任越大”的技术人）

一、引子：为什么权限管理永远是系统设计的“深水区”？

你有没有遇到过这种情况：

• 装了个 App，它上来就要定位、相册、麦克风 全家桶权限？
• 某些软件不给权限就罢工，一副“不给就不干”的样子？
• 或者你曾经写过业务代码，结果因为一个“没声明权限”导致系统直接拒绝执行？

这些是不是很熟悉？

说句大实话：
权限管理是系统安全的第一道门，也是最容易被拿来滥用的能力。
一个权限划分不清的系统，要么成了“地狱模式”，要么成了“野生动物园”。
—— 不是用户危险，就是开发危险。

而在鸿蒙（HarmonyOS）这套体系中，权限机制不是 Android 那种“声明 + 弹窗”那么简单，它要同时满足：

• 多设备协同
• 多模态服务组件
• 多进程模型
• 分布式任务迁移
• 跨设备能力调用

权限控制不仅是“本机安全”，还肩负着跨设备可信任体系。

今天我们就来聊聊：
鸿蒙的系统权限机制到底怎么玩？用什么理念？怎么写代码？怎么落地在真实场景？

我保证，看完你会对“权限”两个字有全新的理解。

二、原理讲解（通俗版）：鸿蒙权限机制到底长啥样？

如果一句话总结鸿蒙权限体系：

能力不是谁想用就能用，每个能力都需要“声明 + 授权 + 校验 + 隔离”四步走。

鸿蒙的权限体系大致分 3 类：

① 自由权限（无感）Free Permissions

• 不涉及隐私
• 不会危害系统安全
  例如：震动、轻量访问网络

特点：不需要弹窗、不需要用户确认

② 用户授权权限（Sensitive Permissions）

例如：

• 位置
• 麦克风
• 相册
• 通讯录
• 摄像头
  等涉及隐私的能力。

用户必须授权，否则拒绝执行。

③ 系统权限（System Permissions）

例如：

• 修改系统配置
• 管理跨设备协同
• 系统服务能力（如分布式数据）

只有系统应用或经过特殊签名的应用才能用。

普通应用？别想。

鸿蒙权限机制最核心的三个理念：

（1）权限声明（Declarative）

App 想用什么能力，必须事先写在 module.json5 里。
你不声明系统就假装你不用。

（2）动态授权（Runtime Grant）

涉及隐私的权限，系统会动态弹窗询问用户。

而且鸿蒙支持：

• 一次性授权
• 每次询问
• 永久拒绝
• 限制后台使用

更细粒度，安全性更高。

（3）能力校验（AccessToken）

鸿蒙最关键的安全机制：

每个应用、每个能力，都有独立的 令牌（token）
系统根据 token 决定是否放行。

如果把权限比作门禁卡：

• 你有卡（声明） → 才能申请授权
• 授权后（用户允许） → 才能进入
• 但能不能到机房（系统权限） → 还得看卡等级是否够

是不是很直观？

三、实战代码：鸿蒙应用如何正确申请和使用权限？

下面我们来一个最常用的权限：相机访问权限

鸿蒙里相机属于隐私权限，需要：

• 声明
• 请求授权
• 调用前再次校验

来，直接上代码。

① 在 module.json5 内声明权限

{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.CAMERA",
        "reason": "用于扫描二维码和拍照上传",
        "usedScene": {
          "abilities": ["MainAbility"],
          "when": "inuse"
        }
      }
    ]
  }
}

几点说明：

• name：权限名称
• reason：告诉用户为什么需要
• usedScene：指定哪个 Ability 会用到

② 在应用逻辑中检查授权状态

import abilityAccessCtrl from '@ohos.abilityAccessCtrl';
import common from '@ohos.app.ability.common';

async function checkCameraPermission() {
  const context = getContext(this) as common.UIAbilityContext;
  const atManager = abilityAccessCtrl.createAtManager();
  
  const permission = 'ohos.permission.CAMERA';
  const grantStatus = await atManager.checkAccessTokenSync(context.token, permission);
  
  return grantStatus === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED;
}

③ 请求动态授权

async function requestCameraPermission() {
  const context = getContext(this) as common.UIAbilityContext;
  const atManager = abilityAccessCtrl.createAtManager();
  
  const permissions = ['ohos.permission.CAMERA'];
  
  const result = await atManager.requestPermissionsFromUser(context, permissions);
  
  return result.authResults[0] === 0; // 0: granted
}

④ 使用相机前确保权限到位

async function openCamera() {
  if (!(await checkCameraPermission())) {
    const granted = await requestCameraPermission();
    if (!granted) {
      console.error("用户拒绝相机权限");
      return;
    }
  }

  // 这里才能调用相机能力
  console.log("权限到位，开始打开相机……");
}

是不是很简洁？
鸿蒙权限 API 整体偏 declarative，非常契合它的分布式架构。

四、典型应用场景：为什么鸿蒙权限体系“不得不这么设计”？

① 分布式相机：权限必须跟着设备走

在“多设备协同”里，你甚至可以用 平板控制手机拍照。

那请问：

权限授予给谁？
App？设备？还是用户本人？

鸿蒙的做法是：

• 权限基于 AccessToken
• Token 绑定 设备 + 应用 + 用户
• 跨设备访问时，需要双方能力都达标

例如：

用平板控制手机拍照
→ 平板 App 需要相机权限（控制）
→ 手机设备需要允许相机被远程使用（被控）
→ 两端要有可信连接（认证）

否则系统直接拒绝。

这就是 分布式权限控制 的核心。

② 系统能力必须严格限制（否则天下大乱）

比如：

• 清理其它 App 缓存
• 修改系统参数
• 管理设备联接
• 调用系统级服务（如分布式数据）

这些一旦开放给普通 App，相当于让用户手机变成“裸机”。

鸿蒙使用 systemCore/systemBasic 等 token 级别来严格限制。

③ 隐私相关能力必须“按场景授权”

你打开地图应用时授权定位是合理的；
但一个记事本 App 开始后台偷偷定位？不可能被放行。

鸿蒙支持：

• inuse：仅前台可用
• always：前后台均可用
• scene-based：指定 Ability 场景可用

更细更准更安全。

五、Echo_Wish 式思考：权限，不是技术问题，而是“信任问题”

写到这里，我想分享一个多年来做系统开发和安全管理的深刻感悟：

权限机制存在的意义，不是为了限制开发者，而是为了保护用户、保护系统，并最终保护开发者自己。

因为没有明确权限边界的系统：

• 容易被滥用
• 容易被攻击
• 容易出事故
• 一旦出事，全员背锅

我见过太多开发者因为：

• 没声明权限导致关键能力失败
• 滥用权限导致应用下架
• 用户质疑隐私问题导致评分暴跌

但其实，你只要尊重权限机制：

✔ 告诉用户你要什么权限
✔ 告诉用户你为什么要
✔ 在该申请的时候申请
✔ 严格遵循系统约束
✔ 不越界、不滥用、不暗用

不仅不会被用户反感，反而会获得信任。

鸿蒙权限体系让我很喜欢的一点就是：

它不是粗暴的拒绝，而是非常精细的信任构建过程。

跨设备、多场景、多模态系统里，权限不能乱来，
必须坚持最小权限原则（Least Privilege）。

否则，就是一场灾难。

结语：权限，是一个系统最有温度的设计

很多人以为权限是技术策略、是安全机制。
但在我看来，它更像是：

系统和用户之间的“契约”。

一个尊重用户、设计合理、公开透明的权限机制，
不仅让系统更安全，也让用户更安心，让生态更繁荣。