直接说结论：**鸿蒙上不是所有「看起来像受限」的权限都要申请 ACL；真正要走 ACL 的只有 3 项，我一次申请、全部通过。**但在这之前，我差点因为「凭印象申请」，把一批根本不用交的权限白交上去。

如果你也准备鸿蒙上架、正在为「这个权限到底要不要申请 ACL」发愁，这篇值得看完——判定规则、差点白交的清单、3 项一次通过的申请原因文案和提交细节，全都给你，照抄就能用。

## 一、先解上篇的扣子：根子就在 ACL

上篇结尾我留了个扣子：「随包自带 Node、npm、pnpm、Python、pip、uv 等运行时和工具」这条路走不通。根子，就在这篇要讲的 ACL。

这个坎我在更早的文章里就埋过伏笔，当时叫它「第二层难点」——**二进制证书，个人开发者不可得**。

当时我想得很美：插件市场要「一键安装」，最省事的做法是把完整工具链随包带上，用户装完应用，Node、pnpm 全都有。结果一查鸿蒙的分发规则，发现这事不是「申请个权限」那么简单，而是一整套权限 + 证书的组合门槛。这篇把它彻底讲透。

## 二、判定规则：什么才需要 ACL

踩坑的起点，是搞清一个反直觉的判定规则：

> **受限开放权限（需 ACL）⟺ `provisionEnable == true` 且 `availableLevel ∈ {system_basic, system_core}`。**

翻译一下：只有「需要开通（provision）」且「级别是 system_basic 或 system_core」的权限，才需要走 ACL 申请。第一手判定依据就是 SDK 自带的权限定义目录，每条权限的 level、provisionEnable 都写得明明白白。

`provisionEnable == false` 的，不管名字多唬人，都是**开放权限**——写进 `requestPermissions` 声明即可，把它们提交 ACL 就是浪费配额。

这里有两个最常见的误判，我差点就栽在第一个上：

1. **名字带 `kernel.` 前缀 ≠ 受限**。像 `kernel.IGNORE_LIBRARY_VALIDATION`，听起来像内核级权限，实际是开放权限，声明即可。
2. **`grantMode: system_grant` ≠ 不用申请**。受限权限绝大多数也是 system_grant——安装即授予，但**前提是发布 Profile 里有它**；没进 Profile，照样不生效。

这一条规则值回整篇文章：**先查 `provisionEnable`，再查 `availableLevel`，两个条件都满足才动手申请。**

## 三、最大的坎：二进制证书，个人不可得

我最初的目标很「完整」：随包自带 Node / npm / pnpm / Python / pip / uv，让插件市场的「一键安装」开箱即用。

结果第一道坎就过不去：**随包分发 ELF（比如 Node 运行时）需要「二进制证书」（AGC `certType: 4`），而华为不授予个人开发者**——它要求企业名称与资质，只能走在线工单系统申请，不是自助操作。

这意味着「随包自带完整工具链」这条路，对个人开发者直接封死。

更坑的是连带效应：那批为「自有 ELF」服务的 native 权限——`ohos.permission.ALLOW_EXTERNAL_NATIVE_CODE`、`ohos.permission.kernel.LOAD_INDEPENDENT_LIBRARY`——也一并失去意义。**我差点把这批权限白交上去。**ELF 过不了签名闸门，这两项建议暂缓提交。

不过路没有完全堵死，有两条不需要证书的替代路线：① 复用设备自带工具链（应用 PATH 已含系统 hnp 目录）；② 进程内 JS 跑 pnpm（不落 ELF、不 spawn）。这里不展开，先把权限侧讲完。

## 四、差点白交：6 项里只有 3 项需要 ACL

痛定思痛后，我按判定规则重新盘了一遍上架真正需要的权限。清单里 6 项，**只有 3 项需要 ACL**：

| 权限 | level | 是否需 ACL | 用途 |
|---|---|---|---|
| `kernel.ALLOW_WRITABLE_CODE_MEMORY` | system_basic | ✅ 需要 | 内置 V8/Electron 引擎 JIT 编译 |
| `READ_PASTEBOARD` | system_basic | ✅ 需要 | 剪贴板文本/图片粘贴 |
| `READ_WRITE_DESKTOP_DIRECTORY` | system_basic | ✅ 需要 | 读写用户桌面目录 |
| `READ_WRITE_DOCUMENTS_DIRECTORY` | normal | ❌ 开放权限 | 文档目录 |
| `READ_WRITE_DOWNLOAD_DIRECTORY` | normal | ❌ 开放权限 | 下载目录 |
| `FILE_ACCESS_PERSIST` | normal | ❌ 开放权限 | 文件选择器授权持久化 |

后 3 项是 `normal` 级开放权限，写进 `requestPermissions` 即生效（首次访问弹窗授权），**在 AGC 的 ACL 列表里通常都无法勾选**——提交它们就是「白交」。

## 五、这类权限根本不存在：执行 /system/bin/sh

还有个高价值冷知识：**在鸿蒙上执行 `/system/bin/sh`，没有任何权限可申请。**

我把 SDK 的权限目录翻遍了：`ohos.permission.EXECUTE_CMD` **不存在**，也不存在任何以「执行 shell / 启动进程」为语义的权限。

原因在于：**进程执行根本不由权限体系管辖**，而由 SELinux 域 + seccomp 管辖，叠加强制代码签名门禁。

所以如果你做鸿蒙应用，想着「我要执行 shell，去申请个权限」，这是方向性错误——这个权限不存在，申请都不知道往哪填。

## 六、看名字唬人、实则与你无关：这些别申请

ACL 有配额、有审核节奏，别把额度浪费在看名字唬人、实则与你无关的权限上：

- `CUSTOM_SANDBOX`：仅华为内部可得，上架不可得；
- `RUN_ANY_CODE`：无第三方正当用途，申请了反而会**降低整批权限的可信度**；
- 四个 `*PLUGIN*` 权限：只有分发「鸿蒙插件包」才需要，而本工程插件是 Node 包，一律不申请。

一句话：**先问自己「这个权限服务我的什么功能」，答不上来就别申请。**

## 七、申请原因怎么写：3 项一次通过的文案

ACL 审核的关键在「申请原因」（≤256 字）。我的写法就一条主线：**说清楚「用于什么、不用来干什么」。**

以最硬的 `kernel.ALLOW_WRITABLE_CODE_MEMORY` 为例，申请原因里我死死咬住三句话：

- 仅用于内置 V8/Node 引擎的 **JavaScript JIT 编译**，保障 AI 对话与工具调用性能；
- **不用于应用热更新、不下载执行外部代码**；
- 已适配**坚盾模式（JShield）**且该模式下不崩溃；仅平板 / 2in1 设备。

这三点正好命中官方对该权限的约束（JIT 编译专用、禁热更新、适配坚盾模式），所以一次过。

另外两项同理：

- `READ_PASTEBOARD`：仅在用户主动粘贴时读取，不在后台读取、不上传；
- `READ_WRITE_DESKTOP_DIRECTORY`：仅访问用户主动选择/授权的桌面目录，不批量扫描磁盘。

发现没有？每一条都是「正面用途 + 明确排除」。审核方要的不是你多会写，而是**你清楚地知道边界在哪**。

## 八、提交与落地：几个别踩的细节

申请本身不难，细节坑不少：

1. **提交路径**：AGC → 开发与服务 → 项目 → 应用 → 项目设置 → ACL权限 → 勾「我已知晓」→ 选权限 → 填申请原因/使用场景 → 申请。
2. **配额与节奏**：单次最多 **30 个权限**，结果一起返回；**上一批未审完，不能提交新一批**。
3. **获批落点**：获批权限在**创建发布 Profile 时自动写入**。
4. ⚠️ **若 ACL 在 Profile 创建后发生变更，必须重建 Profile**——这个坑本工程真实踩过，不重建，构建出来的包就是不带新权限的。
5. **区域**：中国大陆账号正常支持；海外账号仅支持亚太与欧洲。
6. 另存在「试用调试 Profile」：5 天有效期、每应用最多 5 个，可在正式 ACL 下来前先验证可行性。

## 九、结果：3 项一次通过

最终这 3 项（JIT 内存 / 剪贴板 / 桌面目录）**一次申请、全部通过**。

复盘下来，通过的原因就一条：**先用判定规则砍掉「白交项」，再把申请原因写到官方约束的靶心上。**名额精准、文案收敛，审核自然痛快。

## 写在最后

以上就是鸿蒙 ACL 权限申请的全过程：**先搞清判定规则，别凭印象申请；二进制证书个人不可得，断了「随包自带运行时」的念想；最后 3 项受限权限一次通过。**如果你也在做鸿蒙上架，这套「先判定、再精准申请、申请原因咬住官方约束」的思路可以直接抄。

下一篇我写 **App 上架合规踩坑**：被 AppGallery 打回 12 条整改，从商标撞名到 ArkWeb 合规，一条条踩过去。**关注公众号并设为星标**，别错过。

**代码已开源**：https://github.com/fellow99/dsh-desktop-hos ，欢迎 **star** 支持。

**相关开源工程：**

- DeepSeek Harness（上游项目）：https://github.com/deepseek-ai/deepseek-harness
- dsh-market（插件市场）：https://github.com/dsh-market/dsh-market
- harmonypc-electron（Electron-on-鸿蒙运行时）：https://atomgit.com/jianguoxu/harmonypc-electron
- deepseek-harness-workspace（工作区总览）：https://github.com/fellow99/deepseek-harness-workspace
- dsh-desktop（桌面端）：https://github.com/fellow99/dsh-desktop
- dsh-desktop-hos（鸿蒙端）：https://github.com/fellow99/dsh-desktop-hos

感谢各位关注，欢迎访问我的 GitHub 主页：https://fellow99.github.io/

直接说结论：鸿蒙上不是所有「看起来像受限」的权限都要申请 ACL；真正要走 ACL 的只有 3 项，我一次申请、全部通过。但在这之前，我差点因为「凭印象申请」，把一批根本不用交的权限白交上去。

鸿蒙 ACL 权限申请踩坑：差点白交一批，最后 3 项一次通过

这是「把 DeepSeek Harness 搬进鸿蒙」系列的第 5 篇。承接上篇「把 DeepSeek Harness 搬进鸿蒙的 8 个坑」：这篇把权限侧讲透——哪些权限才需要申请 ACL、我差点白交的那批长什么样、以及最后 3 项受限权限一次通过的全过程。

操作系统

后端

安全

鸿蒙ACL权限申请全攻略：3项受限权限一次通过。核心判定规则：provisionEnable为true且级别为system_basic或system_core才需申请ACL。避免误判kernel前缀和system_grant类型，二进制证书个人开发者不可得，需放弃随包自带运行时方案。申请原因紧扣官方约束，精准描述用途与排除项，附提交细节与配额注意。

Python

GitHub

pnpm

快速部署LLM、AI绘画等应用,助你玩转AIGC！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

鸿蒙ACL权限申请全攻略：3项受限权限一次通过。核心判定规则：provisionEnable为true且级别为system_basic或system_core才需申请ACL。避免误判kernel前缀和system_grant类型，二进制证书个人开发者不可得，需放弃随包自带运行时方案。申请原因紧扣官方约束，精准描述用途与...

鸿蒙 ACL 权限申请踩坑：差点白交一批，最后 3 项一次通过-腾讯云开发者社区-腾讯云

鸿蒙 ACL 权限申请踩坑：差点白交一批，最后 3 项一次通过

鸿蒙 ACL 权限申请踩坑：差点白交一批，最后 3 项一次通过

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐