相机权限最容易被写成一个二选一：同意就继续，拒绝就提示“无法使用”。这种处理在演示里能跑，放到真实业务里却会留下三处断点：首次请求前没有把用途说清楚；用户拒绝后继续重复调用首次授权接口；业务没有准备不依赖相机的替代路径。

本文用一个可复核的示例工程说明怎样把这三处断点收口。工程名是 PermissionLane，页面名是 CaptureConsentPage，本次演示编号固定为 PERM-0208。页面时间为 20:18，状态链为 NOT_DETERMINED → EXPLAINING → REQUESTING → DENIED → SETTINGS_GUIDE → FALLBACK_PICKER。所有界面、代码和日志都围绕同一组字段展开。

这里讨论的是授权流程设计，不是某次真实上架审核经历。文中的结果是 Demo 场景输出，用来验证状态机与降级分支；不同 API 版本、设备形态和权限组仍应以当前官方文档与实机行为为准。

一、真正的问题不在“有没有权限”

一开始看页面，用户只是点了“拍摄凭证”。开发者很容易在点击回调里直接调用 requestPermissionsFromUser()，拿到授权就启动相机，拿不到就弹一条 Toast。问题是系统权限并不是普通业务开关，它有自己的历史状态。

NOT_DETERMINED 表示用户尚未对当前权限做出明确选择；GRANTED 表示允许；已经拒绝则不能继续把首次申请当作可反复弹出的业务对话框。HarmonyOS 官方文档明确给出了后续路径：首次拒绝后，可使用 requestPermissionOnSetting() 打开权限设置弹框。另一方面，系统级 Picker 已完成相应授权，应用可以通过 PhotoViewPicker 获取用户主动选择的媒体资源，而不必把“必须打开相机”当成唯一入口。

这意味着页面至少要回答四个问题。

第一，当前权限事实是什么，而不是上次页面内存里记住了什么。第二，这次操作是首次申请，还是已经拒绝后的再次引导。第三，用户不愿授权时，核心任务能否通过图库选择完成。第四，异步授权结果返回时，这个页面和这次请求是否仍然有效。

PermissionLane 没把权限按钮写成“再试一次”，而是把动作拆成“了解用途”“请求相机权限”“去设置授权”和“从图库选择”。这几个动作看起来多了一步，实际上减少了重复弹框、按钮连点和页面返回后的错位状态。

二、先把权限声明和使用场景对齐

权限流程的第一层不是 ArkTS，而是模块声明。页面如果要启动自定义相机预览，需要在 module.json5 的 requestPermissions 中声明相机权限，并给出面向用户的用途文案。声明只是资格，不代表应用已经获得授权，也不代表启动页面时就应该立刻申请。

这段代码解决什么问题：把相机权限限定到 EntryAbility 的拍摄场景，并让系统授权弹框能够显示业务理由。

{
  "module": {
    "requestPermissions": [
      {
        "name": "ohos.permission.CAMERA",
        "reason": "$string:permission_camera_reason",
        "usedScene": {
          "abilities": ["EntryAbility"],
          "when": "inuse"
        }
      }
    ]
  }
}

这段声明不负责触发授权。reason 应说明“拍摄凭证”需要相机，而不是写成笼统的“为了更好的体验”。usedScene 也要和真实 Ability 对齐，避免配置存在、运行路径却不一致。实际项目还要检查是否真的需要长期访问相机；如果业务只是让用户提交已有图片，Picker 往往比申请相机权限更克制。

另一个易错点是把调试机已有授权当成默认状态。开发时多次安装覆盖，权限状态可能被保留；新用户、清数据用户和从设置页撤销权限的用户看到的是不同分支。因此，页面每次进入关键动作前都应读取系统事实，不能只用一个本地布尔值 hasCameraPermission。

三、首次申请只走一次

页面的协调器把系统状态转换成业务状态。本文不把某个枚举数字硬编码为“拒绝”或“允许”，而是比较 abilityAccessCtrl.PermissionStatus。这样代码表达的是官方类型语义，也避免把不同版本中的返回值细节扩散到 UI。

这段代码解决什么问题：在 PERM-0208 请求中查询当前相机权限，只在 NOT_DETERMINED 时发起首次申请，并用请求代次拒绝迟到回调。

import { abilityAccessCtrl, common, PermissionRequestResult, Permissions } from '@kit.AbilityKit';

const CAMERA: Permissions = 'ohos.permission.CAMERA';

export class PermissionCoordinator {
  private atManager = abilityAccessCtrl.createAtManager();
  private generation: number = 0;

  getStatus(): abilityAccessCtrl.PermissionStatus {
    return this.atManager.getSelfPermissionStatus(CAMERA);
  }

  async requestFirst(
    context: common.UIAbilityContext,
    onState: (state: string, detail: string) => void
  ): Promise<void> {
    const token = ++this.generation;
    const status = this.getStatus();
    if (status !== abilityAccessCtrl.PermissionStatus.NOT_DETERMINED) {
      onState('SETTINGS_GUIDE', `PERM-0208 status=${status}`);
      return;
    }

    onState('REQUESTING', 'PERM-0208 attempt=1');
    const result: PermissionRequestResult =
      await this.atManager.requestPermissionsFromUser(context, [CAMERA]);
    if (token !== this.generation) {
      return;
    }

    const granted = result.authResults[0] === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED;
    onState(granted ? 'GRANTED' : 'DENIED',
      `PERM-0208 authResult=${result.authResults[0]}`);
  }

  invalidate(): void {
    this.generation++;
  }
}

这里的状态变化很明确：点击前是 EXPLAINING，系统弹框出现时是 REQUESTING，回调后只能落到 GRANTED 或 DENIED。generation 不是权限 API 的要求，而是页面自己的并发门禁。如果用户在弹框期间退出页面，invalidate() 会让旧回调失效，避免返回后继续启动已销毁页面的相机预览。

实际项目要注意三点。其一，授权回调和页面生命周期不是同一个时钟；异步结果晚到很常见。其二，不能凭 authResults 数组位置随意扩展到多权限申请，批量申请时应同时核对 permissions 与结果索引。其三，授权成功也不等于相机一定可用，后面仍要处理设备占用、会话创建失败和预览流异常。

完成协调器后，DevEco Studio 中左侧是 PermissionLane 工程目录，中间是 PermissionCoordinator.ets，右侧模拟器停在 CaptureConsentPage 的拒绝态，底部 HiLog 记录同一编号与状态。这张图是场景演示配图，不冒充真实设备测试证据。

四、拒绝之后，不再伪装成“首次申请”

用户已经拒绝时，再次点击主按钮，页面不应该无条件重复执行 requestPermissionsFromUser()。官方文档给出的后续入口是 requestPermissionOnSetting()。这个动作的语义也应在页面上说清楚：它不是强制打开权限，而是把用户带到可以重新决定的设置弹框。

PermissionLane 在拒绝态显示两条并行路径。第一条是“去设置授权”，适合用户仍希望现场拍摄；第二条是“从图库选择”，适合用户不愿开放相机权限，但仍希望完成凭证提交。两条路径都能到达业务结果，权限不再成为整页死锁。

这段代码解决什么问题：把二次授权与无相机权限的 Picker 降级分开处理，并在页面退出时释放协调器代次。

import { abilityAccessCtrl, common, Permissions } from '@kit.AbilityKit';
import { photoAccessHelper } from '@kit.MediaLibraryKit';

const CAMERA: Permissions = 'ohos.permission.CAMERA';

export class PermissionRecovery {
  private atManager = abilityAccessCtrl.createAtManager();

  async openSetting(context: common.UIAbilityContext): Promise<boolean> {
    const results = await this.atManager.requestPermissionOnSetting(context, [CAMERA]);
    return results[0] === abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED;
  }

  async pickOnePhoto(): Promise<string | undefined> {
    const picker = new photoAccessHelper.PhotoViewPicker();
    const option = new photoAccessHelper.PhotoSelectOptions();
    option.MIMEType = photoAccessHelper.PhotoViewMIMETypes.IMAGE_TYPE;
    option.maxSelectNumber = 1;
    const result = await picker.select(option);
    return result.photoUris.length > 0 ? result.photoUris[0] : undefined;
  }
}

openSetting() 返回后要重新读取权限事实，不能仅依据“设置弹框正常关闭”推断授权成功。Picker 分支拿到的是用户主动选择资源的 URI，业务后续读取时仍要处理空结果、用户取消和临时访问范围。页面销毁后不要继续使用旧 URI 做后台长任务；如果需要长期持有，应按当前媒体访问规则完成复制或持久化，而不是假设 Picker 返回值永久有效。

这部分还有一个产品判断：降级路径不能被故意做得很隐蔽。用户拒绝相机权限不代表拒绝提交任务。把“从图库选择”做成可见按钮，比在 Toast 里提示“请到设置开启权限”更尊重用户选择，也更容易形成可验收的审核路径。

运行页在 20:18 显示 PERM-0208、权限 ohos.permission.CAMERA、状态 DENIED、尝试次数 1/2，并同时提供“去设置授权”和“从图库选择”。红色标注只解释拒绝后不应重复首次申请，以及 Picker 是可完成任务的降级路径。

五、按钮防重比弹框更早发生

权限弹框是异步交互。用户快速连续点击，或页面从后台恢复时再次触发点击，都可能生成并发请求。即使系统最终只展示一个弹框，业务日志、Loading 状态和后续相机启动也可能重复执行。

因此，页面状态不能只由系统权限决定，还要有操作状态。REQUESTING 和 SETTINGS_GUIDE 期间禁用同类按钮；Picker 正在显示时也要阻止再次打开。状态机的价值不是让代码显得复杂，而是让每个按钮在每个阶段只有一个含义。

这段代码解决什么问题：通过单一 reducer 收敛点击、授权回调、设置返回与 Picker 结果，避免多个回调直接改 UI。

type ViewState = 'IDLE' | 'EXPLAINING' | 'REQUESTING' | 'DENIED' |
  'SETTINGS_GUIDE' | 'PICKING' | 'GRANTED' | 'FALLBACK_PICKER';

interface PermissionEvent {
  type: 'START' | 'REQUEST' | 'DENY' | 'OPEN_SETTING' |
    'OPEN_PICKER' | 'PICKED' | 'GRANT' | 'CANCEL';
  uri?: string;
}

function reduce(state: ViewState, event: PermissionEvent): ViewState {
  if (state === 'REQUESTING' && event.type === 'REQUEST') return state;
  if (state === 'PICKING' && event.type === 'OPEN_PICKER') return state;
  if (event.type === 'START') return 'EXPLAINING';
  if (event.type === 'REQUEST') return 'REQUESTING';
  if (event.type === 'DENY') return 'DENIED';
  if (event.type === 'OPEN_SETTING') return 'SETTINGS_GUIDE';
  if (event.type === 'OPEN_PICKER') return 'PICKING';
  if (event.type === 'PICKED' && event.uri) return 'FALLBACK_PICKER';
  if (event.type === 'GRANT') return 'GRANTED';
  return 'IDLE';
}

这里特意没有把所有未知事件都“尽量继续”。权限流程出现意外组合时，退回 IDLE 比在错误状态下启动相机更安全。正式项目可以记录非法转移并上报，但不要把完整 URI、用户媒体名称或其他敏感内容直接写入日志。PERM-0208 是演示请求编号，不包含用户身份信息。

六、用诊断页证明降级链路真的闭环

最终的验收不是“弹框出现过”，而是各分支都能产生稳定结果。本文的示例诊断页记录：首次状态 NOT_DETERMINED；请求后得到 DENIED；随后没有再次调用首次请求；用户选择图库分支；Picker 返回一条演示 URI；业务状态变为 FALLBACK_PICKER；页面结果为 RECOVERED_WITHOUT_CAMERA。

这张详情图和上一张运行页明显不同。上一张回答“用户现在能做什么”，这一张回答“状态是怎样变化的”。完整日志为：

20:18:02 PERM-0208 state=NOT_DETERMINED

20:18:05 PERM-0208 state=REQUESTING attempt=1

20:18:09 PERM-0208 state=DENIED

20:18:14 PERM-0208 action=OPEN_PICKER

20:18:19 PERM-0208 selected=1 state=FALLBACK_PICKER

演示 URI 写成 file://media/Photo/27/IMG_0208.jpg，只是为了保持文图字段一致，不应被理解为任何设备上的真实用户文件。文章也不声称这组数据来自应用市场审核后台。

验收时我会把流程拆成六条用例：首次允许；首次拒绝；拒绝后设置允许；拒绝后设置仍拒绝；拒绝后 Picker 选择成功；Picker 取消。每条都检查按钮可用性、HiLog 状态、页面销毁后的迟到回调和是否重复启动相机。只有六条都能落到可解释状态，权限闭环才算完成。

七、边界与工程取舍

requestPermissionOnSetting() 是二次引导，不是绕过用户决定。页面要在用户主动点击后调用，也要允许用户继续拒绝。把设置弹框做成循环强制出现，会让状态机技术上正确、体验上却失控。

Picker 降级也不是所有相机场景的替代品。需要实时扫码、视频通话或自定义相机参数时，图库选择不能完成同一任务。此时应明确告诉用户功能边界，同时保留返回、稍后处理或浏览其他内容的入口。本文的凭证提交场景适合降级，是因为业务关心的是一张可用图片，而不是图片必须由当前相机实时生成。

不同 API 版本下，权限设置页的呈现与权限状态细节可能调整。官方 2026 年 7 月的 FAQ 还特别说明了 API 23 前后设置页展示权限项的差异。因此，代码不要把“设置页一定已经有开关”当作跨版本事实，测试矩阵要覆盖目标设备与目标 API。

最后，权限状态要按需查询，不要在应用启动时批量申请一组“以后可能用到”的权限。对用户而言，点击拍摄时看到相机权限理由是有上下文的；刚打开应用就看到相机、位置、联系人同时出现，只会让每一次拒绝都更难恢复。

八、把权限事实与页面记忆分开

权限页面经常还会保存一个本地字段，例如 cameraAsked=true。这个字段可以用来控制是否展示业务解释，却不能代替系统权限状态。用户可能在系统设置里撤销权限，也可能清除应用数据；应用升级后，权限组和使用场景还可能发生变化。页面如果只相信本地记录，就会出现“按钮显示已授权，启动相机却失败”或“系统已经允许，页面仍然要求再次解释”的矛盾。

更稳妥的做法是把数据分成三类。第一类是系统事实，通过 getSelfPermissionStatus() 读取，只能由系统决定。第二类是交互记忆，例如用户是否看过用途说明、是否选择过图库降级，这些可以保存在业务存储里。第三类是一次性的运行状态，例如当前是否正在请求、请求代次是多少、页面是否还活着，这些只保留在当前页面或协调器实例中。

三类数据不能互相冒充。cameraAsked=true 不能证明权限被拒绝，GRANTED 也不能证明业务解释已经展示。一次请求的 generation=8 更不应该写进持久化存储，因为新进程里的第八代与旧进程里的第八代没有任何关联。把数据来源标清楚，很多“偶现”会立刻变成可定位的问题。

设置返回也是同样逻辑。requestPermissionOnSetting() 正常结束，只说明设置交互已结束；真正的授权结果仍应再次调用 getSelfPermissionStatus()。如果用户关闭弹框或保持拒绝，页面回到 DENIED，同时保留 Picker 入口。不要根据 Promise 没有抛错就进入 GRANTED，否则后面的相机会话创建才会暴露错误，用户看到的就变成“授权后黑屏”。

九、回归测试要覆盖被打断的路径

权限流程最容易漏测的是中间态。开发者通常测试“点允许”和“点拒绝”，却没有测试弹框出现后切到后台、页面旋转或折叠状态变化、快速返回、进程被系统回收等情况。PermissionLane 的回归清单把这些中断场景单独列出。

第一组是点击节奏：连续点击主按钮五次，只能产生一次 REQUESTING；在 SETTINGS_GUIDE 中再次点击，不得叠加设置弹框；Picker 显示期间返回应用，页面不能自动再次打开 Picker。第二组是生命周期：请求期间退出页面，返回结果被代次门禁丢弃；重新进入页面后重新查询系统事实，不恢复旧的 Loading。

第三组是外部变更：用户在系统设置中授予后回到页面，状态应变为 GRANTED；用户在设置中继续拒绝，页面应回到 DENIED；用户先授权、随后从系统设置撤销，再点击拍摄时应重新进入解释或设置引导，而不是继续使用旧相机会话。第四组是 Picker：选择一张图、取消选择、返回空数组、返回 URI 后页面立即销毁，都要有明确结果。

日志也要随测试设计。建议至少记录请求编号、页面实例代次、权限名称、读取到的系统状态、触发动作、回调结果和最终业务状态。不能记录用户选择图片的完整路径，更不能为了“方便定位”把图片内容转成 Base64 写进日志。对审核和合规而言，排查能力不应建立在扩大数据采集范围之上。

如果业务包含多个需要相机的页面，不建议每个页面各自复制一套授权代码。可以共享协调器和状态定义，但用途说明、降级路径和最终业务结果仍应由具体页面决定。扫一扫页面可能没有图库降级，凭证提交页面则可以有；共用代码不等于把所有产品语义压成一个弹框。

十、对审核路径的克制判断

从工程角度看，最危险的实现不是“用户拒绝后功能不可用”，而是应用不断制造无法退出的授权压力。首次申请前有清楚理由、拒绝后不循环弹框、二次申请由用户主动触发、替代路径不被刻意弱化，这四点共同构成了可解释的交互。

审核前可以录制一条最短验证路径，但本文不把录屏当成技术证据的全部。更重要的是让代码和日志能回答：首次请求发生在哪个用户动作之后；拒绝后是否调用了正确的设置入口；无权限分支是否仍能完成主要任务；页面退出后有没有迟到回调改变状态。只要这些问题依赖人工口述才能回答，流程就还没有真正工程化。

还要避免把“Picker 免申请权限”误解为“可以绕过所有数据访问约束”。Picker 的核心是用户主动选择和临时访问，应用获得的是本次选择结果，不是整个图库的自由读取权。后续若要上传、缓存或长期保存，仍需按照业务隐私声明、数据最小化和当前文件访问规则处理。

最后，权限文案与实际用途必须一致。写着“用于扫码”却把相机用于人像采集，或写着“上传头像”却在后台持续打开预览，都会让状态机再漂亮也失去意义。技术实现只能保证流程可控，不能替代用途真实性。

十一、结语

这次改动没有增加相机能力，改变的是失败后的业务形态。PermissionLane 把首次申请、二次设置和 Picker 降级拆成三条不同路径，再用请求代次和 reducer 收住异步回调。最终页面不再把权限拒绝理解为任务失败，而是把它变成一个可继续、可解释、可验收的状态。

对于上架前自查，最值得保留的不是某个弹框截图，而是四个问题：权限是否在使用时申请；首次与二次申请是否分开；拒绝后是否有非强制的替代路径；生命周期结束后是否还能收到并执行旧回调。把这四项写进回归清单，往往比继续堆提示文案更有效。

十二、参考资料

• 华为开发者：应用权限管理界面的权限跳转到系统设置界面，无对应权限（2026-07-30 更新）
  https://developer.huawei.com/consumer/cn/doc/doccenter-dev-faq/faqs-access-control-16
• 华为开发者：Starting a System Application，包含 Picker 与 requestPermissionOnSetting 的能力说明
  https://developer.huawei.com/consumer/en/doc/harmonyos-guides-V14/system-app-startup-V14
• 华为开发者：自定义相机预览最佳实践，包含相机权限声明与二次申请说明
  https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-custom-camera-preview