应用里有一个扫描入口，通常很容易把“获取相机权限”写成打开页面后的必经步骤。可在上架前准备演示路径时，真正需要回答的是另一个问题：用户明确拒绝相机授权之后，页面是不是还允许完成不依赖相机的事？如果原本能输入关键词查资料，却被一层“请先开启相机”遮住，权限提示就越过了功能边界。下面用 PermissionLane 做一条窄范围的工程验证路线。它是一款展品导览类应用的示例页，提供扫码识别和文本查找两个入口。这里重点处理用户授权结果与业务能力降级；不会声称已经通过应用市场审核，也不会把合成的拒绝态配图当成真实系统授权弹窗截图。## 一、先让“拒绝”成为一个正常产品状态固定演示数据：任务号 PL-072，关键词“青花瓷”，内置模拟条目命中 3 项。示例时刻 11:12，相机状态 DENIED，页面能力状态 DENIED_TEXT_READY。用户仍可以点击“使用文本查找”，另有一个需要用户主动触发的“按需请求相机”入口。这些状态字符串由应用定义，不是 AbilityAccessCtrl 的平台返回常量。需要把两件事分开。第一是权限事实：相机是否授权，应以当前可用的授权结果为准。第二是业务功能：文本查找不需要相机，本来就不该因为相机被拒而一起不可用。具体到展品导览，拒绝相机不意味着拒绝使用整个 App；只意味着摄像头相关流程应停在入口处，不能尝试预览流初始化。因此，页面不采用“打开时弹一次、返回再弹一次”的循环申请。只有当用户点击扫码入口或专门的授权按钮，才发起明确的权限请求。授权被拒之后，焦点仍留在文本查找区域，可以继续检索本地已准备的数据。这里的“可继续”是业务设计要求，后面给出的是示例实现和验收方式，不能替代真机的拒绝授权测试。## 二、配置声明是入口，不是授权结果官方权限文档将 ohos.permission.CAMERA 列为 user_grant 权限。对于 Stage 模型应用，module.json5 需要声明权限用途，运行时还需要在用户操作后申请授权。配置了 requestPermissions 并不等于用户已经允许；权限说明文案与实际扫码用途也应对应。示例只围绕 CAMERA，不顺手申请麦克风、位置或与文本检索无关的权限。第一段配置解决的问题是让“扫描实物二维码需要摄像头”成为清晰可核对的声明。下列片段应合并到项目现有的 entry/src/main/module.json5，其中 $string:camera_reason 必须在资源文件中真实定义，EntryAbility 应替换为工程实际 UIAbility 名称。json5{ "module": { "requestPermissions": [ { "name": "ohos.permission.CAMERA", "reason": "$string:camera_reason", "usedScene": { "abilities": ["EntryAbility"], "when": "inuse" } } ] }}不要将上述最小片段覆盖整个模块配置。真实项目还必须保留原有设备类型、能力、页面等字段。用途文案也不应写成“优化体验”这类无法解释数据使用场景的句子。这里没有编造新的设备授权 API；具体版本支持范围必须以目标 SDK 的权限文档和审核规范再次检查。## 三、只在用户主动选择时请求相机实际交互的难点不是弹出一次系统对话框，而是处理回调延迟、用户拒绝、页面已销毁和按钮重复点击。以往容易出现的逻辑是每次返回页面就调用申请方法，结果用户连续收到相同请求；还有一种情况是权限对话框尚未结束，第二次点击又发出重复请求。第二段 ArkTS 解决的问题是把权限请求限定为一次在途的显式操作，并在响应完成时核对当前页面提交资格。官方 abilityAccessCtrl.createAtManager() 和 requestPermissionsFromUser(context, permissions) 用于申请用户授权；返回的 permissions 与 authResults 应按相同下标对应，不能假定永远只有一个结果而漏做核对。arktsimport { abilityAccessCtrl, common } from '@kit.AbilityKit';// 以下方法置于 FallbackPage 组件内部private requestInFlight: boolean = false;private requestEpoch: number = 0;private async requestCamera(): Promise<void> { if (this.requestInFlight) { return; } this.requestInFlight = true; const epoch = ++this.requestEpoch; this.mode = 'REQUESTING'; try { const context = getContext(this) as common.UIAbilityContext; const manager = abilityAccessCtrl.createAtManager(); const result = await manager.requestPermissionsFromUser( context, ['ohos.permission.CAMERA']); if (epoch !== this.requestEpoch) { return; } const index = result.permissions.indexOf('ohos.permission.CAMERA'); const allowed = index >= 0 && result.authResults[index] === 0; this.cameraState = allowed ? 'GRANTED' : 'DENIED'; this.mode = allowed ? 'CAMERA_READY' : 'DENIED_TEXT_READY'; } catch (error) { if (epoch === this.requestEpoch) { this.cameraState = 'ERROR'; this.mode = 'DENIED_TEXT_READY'; } console.error(`[PermissionLane] camera request error: ${String(error)}`); } finally { this.requestInFlight = false; }}````0` 在该授权结果约定中表示同意；不把“请求 Promise 返回成功”本身等同于获批。异常分支也不应该默认相机可用，因为请求失败和用户拒绝都不足以确认获得摄像头访问能力。页面使用 `requestEpoch` 是为了阻止迟到结果覆盖新页面状态；这里未尝试以应用代码强制关闭系统权限弹框。上面的片段为核心方法，而不是可单独运行的完整项目。它引用的 `cameraState`、`mode` 在下面的界面结构中声明。`requestInFlight` 是请求重入锁，但页面销毁后，`finally` 仍可能执行；当组件生命周期复杂时，生产实现更应把权限协调逻辑放入有明确所有权的服务，而非长生命周期静态变量。![](https://i-blog.csdnimg.cn/direct/77c22a64c50349be8d0978c755f4bf06.png)## 四、回退不是报错页，而是完整的第二条路PermissionLane 的文本检索不访问摄像头。为了让拒绝态可以复核，示例把三条“青花瓷”条目放在本地模拟数组中。它只能证明页面状态和查询逻辑在示例里没有依赖权限，不是在线搜索的算法效果或召回率数据。**第三段代码要解决的问题**是保持文本功能可用，并对输入和返回结果做最基本的边界处理。空输入不触发查询，查询结果数量在 UI 上可解释，不能因为 `cameraState` 不是 GRANTED 就清空文本内容。arktsprivate runTextSearch(): void { const word = this.query.trim(); if (word.length === 0) { this.resultCount = 0; this.hint = ‘请输入展品名称’; return; } const demoItems: string[] = [‘青花瓷纹样’, ‘青花瓷釉色’, ‘青花瓷年代’]; this.resultCount = demoItems.filter(item => item.includes(word)).length; this.hint = 文本检索完成：${this.resultCount} 条; if (this.cameraState !== ‘GRANTED’) { this.mode = ‘DENIED_TEXT_READY’; }}这里 `resultCount=3` 是固定关键词对应的演示结果，不是模型推理、图片识别或网络搜索返回值。如果要连接真实检索服务，应该再添加加载态、取消资格和错误呈现，不应让权限的状态机顺便吞掉检索网络错误。可以用空词、空结果和非中文字测试文本入口，确认其行为不受相机权限变化影响。**第四段代码处理的是**用户可触达的回退界面：提供两个明确的动作、一个稳定的状态说明。没有调用摄像头，因此不会因没拿到授权而意外开始相机会话。arkts@Entry@Componentstruct FallbackPage { @State query: string = ‘青花瓷’; @State cameraState: string = ‘DENIED’; @State mode: string = ‘DENIED_TEXT_READY’; @State resultCount: number = 3; @State hint: string = ‘文本检索可继续使用’; build() { Column({ space: 12 }) { Text(‘权限拒绝也可查 · PL-072’) Text(CAMERA：${this.cameraState}) Text(页面状态：${this.mode}) TextInput({ text: this.query, placeholder: ‘输入展品名称’ }) .onChange((value: string) => { this.query = value; }) Button(‘使用文本查找’).onClick(() => this.runTextSearch()) Button(‘按需请求相机’).onClick(() => { this.requestCamera(); }) Text(查询：${this.query} · 匹配 ${this.resultCount} 条) Text(this.hint) }.padding(20) }}```如果照示例拆文件，应把第二、三段成员方法并入同一个 FallbackPage，避免重复声明组件；它们在文章里分开只是为了突出两条功能边界。生产项目还应在页面销毁时递增 requestEpoch，拒绝旧回调提交新状态，并在真正获得权限后才创建相机相关资源。扫描会话的启动、停止和硬件资源释放不在本篇模拟范围内。## 五、拒绝态的验收要看能做什么本篇配图里的最终页面是 11:12 / PL-072 / CAMERA DENIED / DENIED_TEXT_READY。文本输入是“青花瓷”，内置示例命中 3 条；两个动作分别是“使用文本查找”和“按需请求相机”。DevEco 示意图底部的目标日志可写成 [PermissionLane] task=PL-072 permission=DENIED mode=DENIED_TEXT_READY，随后是 [PermissionLane] query=青花瓷 results=3。这只是验证时建议观察的字段，不是对真机授权返回的虚构记录。真正做功能验收，至少需要覆盖三类路径。首次点击扫码时允许，确认扫码功能在获得授权后才初始化；首次点击扫码时拒绝，确认界面立即进入文本回退，文本查询按钮仍可操作；从系统设置改动权限再返回，确认业务重新评估当前授权状态，而不是永久信任上一轮缓存结果。若存在多个 UIAbility，还应校验上下文实例和回调归属。最容易被忽略的一个点是文案：不能把“拒绝相机权限”展示成“应用不可使用”，也不能把展示三条本地示例说成“已完成图片搜索”。帮助页和提审说明若引用同一个场景，应明确哪个功能需要权限、哪个功能属于无权限备选。开发自检报告可以记录这些路径，但不替代审核人员对真实功能、隐私政策及 SDK 数据行为的检查。## 六、从审核视角回到产品边界一个权限弹窗看起来只有“允许”和“拒绝”两个按钮，但它背后至少有三份合同：配置里声明什么、系统事实上授予什么、应用拒绝后仍允许做什么。三者不应互相推断。这里的实现优先保证拒绝后的文本搜索可用，减少首次打开页面时的无关打断；并用明确的用户动作控制再次申请。方案边界也要写清楚：本文没有扫描真实二维码，没有进行权限设置页跳转，没有代替系统权限状态检查，也没有证明任何审核结果。对于隐私声明、目标 API 差异和特殊设备行为，仍须按目标环境复核。若产品实际只有扫码一种能力，拒绝后就应给出明确解释和退出路径，不能为了做出“回退成功”而伪造无权限功能。官方参考：华为开发者《对所有应用开放的权限列表》https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-v5/permissions-for-all-V5；《分布式设备管理开发指南》中的 AbilityAccessCtrl 申请示例 https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-v5/devicemanager-guidelines-V5；《上架申请》https://developer.huawei.com/consumer/cn/doc/HMScore-Guides/harmonyos-release-application-0000001181600758。资料核对时间：2026-10-17，未虚构平台政策或测试结论。