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

fellow99

28人浏览 · 2026-10-03 11:37:38

fellow99 · 2026-10-03 11:37:38 发布

直接说结论：**鸿蒙上不是所有「看起来像受限」的权限都要申请 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 就是浪费配额。

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

名字带 kernel. 前缀 ≠ 受限。像 kernel.IGNORE_LIBRARY_VALIDATION，听起来像内核级权限，实际是开放权限，声明即可。
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：仅访问用户主动选择/授权的桌面目录，不批量扫描磁盘。

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

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

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

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