有一次做提交前自查权限声明看起来没有问题module.json5里写了相机权限页面也有隐私说明测试机器上拍照流程通了。可一旦换成从未授权的新用户问题就冒出来他打开首页时为什么已经出现权限对话框拒绝以后为什么手动录入按钮也灰掉了审核方问“相机在哪个操作触发、拒绝以后能否继续使用”时开发团队手头只有一张授权成功的截图。这类问题不一定能靠删掉一行权限配置解决。真正需要检查的是页面行为、权限申请、用户选择、功能降级和取证之间有没有一致的时间线。这轮做了一个小型演示工程AuditTraceLab票据录入有“拍摄票据”和“手动录入”两条路径前者使用ohos.permission.CAMERA后者不需要相机。我们为隐私声明版本v1.4建立审核自检任务audit_20261009_02将相机授予与拒绝、麦克风拒绝后的文字模式、系统选图器替代广泛媒体授权、位置能力不触发以及启动前无业务采集请求拆成相互独立的测试场景。图 03 呈现的是权限矩阵的综合结果相机GRANTED、麦克风DENIED、媒体PICKER_ONLY、位置NOT_REQUIRED而下面CAM-001的相机拒绝则是另一条专门复现的分支两者不应混作同一次系统弹窗结果。一、审核材料难的不是截图而是解释操作次序很多项目把合规做成一张静态勾选表权限已声明、隐私政策已填写、SDK 名录已更新就认为可以提交。问题是系统弹窗出现的时机来自运行时操作截图只有一个时间切片不能解释弹窗前做过什么更不能证明拒绝授权后的分支可用。开发人员一旦用已授权的老设备测试首次运行的真实路径也被绕过去了。因此这次把复现输入写死卸载后重新安装、清除或确认授权状态启动 Demo不主动点击相机入口随后点击“拍摄票据”在系统弹窗选择拒绝再返回“手动录入”。验收中期望看到三个可验证条件启动前业务敏感采集请求为0CAMERA的演示授权结果是DENIEDMANUAL_ENTRY仍然为AVAILABLE。在这个单独的拒绝子场景里业务敏感采集请求为0、相机请求结果为DENIED、手动录入保持AVAILABLE综合截图则显示权限矩阵4/4项检查通过。这些演示结果不表示平台自动确认合规或保证审核通过。这次我没有选“添加更多隐私文案”作为第一步。文案要准确但如果点击路径错误文案写得再漂亮也不能修复。先把场景边界画清楚应用启动可以加载与隐私无关的资源需要相机的动作由用户明确点击拒绝相机后只能关闭相机相关能力不应该一并禁用与其无关的功能退出或重启后要能再次从可靠的系统权限状态恢复 UI。二、把权限配置视为代码而不是表单演示工程的结构很小pages/AuditHomePage.ets提供入口services/PermissionGate.ets负责授权请求services/AuditRecorder.ets记录业务事件pages/EvidenceDetailPage.ets展示可读证据model/AuditEvent.ets负责字段契约。和功能开发一样权限声明应进代码评审不仅看“有没有相机权限”也看reason文案是否准确描述拍摄票据、usedScene是否对应真实的使用 Ability。// entry/src/main/module.json5仅展示相关字段 { module: { requestPermissions: [ { name: ohos.permission.CAMERA, reason: $string:camera_for_receipt, usedScene: { abilities: [EntryAbility], when: inuse } } ] } }资源文案建议是“用于拍摄票据并提取金额信息”而不是“需要使用相机”这种无法说明业务目的的句子。配置中的reason只解决静态声明对user_grant权限还必须在用户进入相机相关功能时执行运行时请求。更需要注意不同能力可能有不同的最小权限或替代方案例如能通过 Picker 完成的选图功能不应为了图方便顺带扩大公共媒体目录权限。超出普通开放范围的权限还可能涉及额外资格与审核不能照着旧示例直接堆字段。这里刻意不用一个布尔变量hasAllPermission来代表整个应用的权限状态。相机拒绝不意味着手动输入也不安全另一个权限正常也不代表相机可以直接使用。每个功能入口应该有自己的依赖集合然后再由页面组合出可用能力避免把局部失败升级成全局故障。三、给权限申请增加“因果编号”现在需要解决的是重复弹窗与不可解释的回调。假设用户快速点击两次“拍摄票据”第一次权限窗口尚未结束第二次又走入相同流程。即使系统自身有保护应用也不应该把两次点击解释成两次独立采集任务。我在业务服务里加入请求中的状态门闩并把用户动作和授权结果写成同一个attemptId便于回放。// services/PermissionGate.ets精简示意 import { abilityAccessCtrl, common } from kit.AbilityKit; export class PermissionGate { private requesting: boolean false; async requestCamera(context: common.UIAbilityContext, attemptId: string): Promiseboolean { if (this.requesting) { console.info([AuditTraceLab] ${attemptId} duplicate_request_ignored); return false; } this.requesting true; console.info([AuditTraceLab] ${attemptId} request CAMERA); try { const manager abilityAccessCtrl.createAtManager(); const result await manager.requestPermissionsFromUser( context, [ohos.permission.CAMERA]); const granted result.authResults.length 0 result.authResults[0] 0; console.info([AuditTraceLab] ${attemptId} result${granted ? GRANTED : DENIED}); return granted; } finally { this.requesting false; } } }这段服务只返回“能否继续当前相机动作”不擅自打开相机也不在业务启动时调用。真实工程还应捕获BusinessError向 UI 返回明确的异常分支并在用户拒绝、系统不再弹窗或上下文失效时区分处理不要把所有异常都打印为DENIED否则排查时无法区分用户决策和接口错误。result.authResults的顺序要与请求权限数组对应多权限请求尤其不能默认第一个就是你想要的权限。门闩也不是权限状态的永久缓存。用户可以从系统设置里修改授权页面重新进入或应用恢复时应重新查询真实权限状态。它只用于阻止短时重复发起同一请求。我们的事件示例使用attemptIdCAM-001和任务audit_20261009_02关联审核证据可清楚看到tap_camera → request_CAMERA → DENIED → fallback_manual的顺序。四、页面降级不能偷偷改变功能语义用户拒绝授权后界面常见的两种错误都很糟糕一是无限循环弹窗直到同意二是把整个“新增票据”页面锁住让用户误以为必须开放相机。演示中的产品规则很明确相机扫描是一条效率较高的路径手动录入才是底线。因此页面状态应该反映功能粒度而不是整页一个authorized开关。// pages/AuditHomePage.ets按钮与状态要点 Entry Component struct AuditHomePage { State cameraStage: string IDLE; State manualStage: string AVAILABLE; private gate: PermissionGate new PermissionGate(); async onCaptureTap(): Promisevoid { this.cameraStage REQUESTING; const ctx this.getUIContext().getHostContext() as common.UIAbilityContext; try { const allowed await this.gate.requestCamera(ctx, CAM-001); this.cameraStage allowed ? READY_TO_CAPTURE : DENIED; // 仅 allowedtrue 时才创建相机会话 } catch (err) { this.cameraStage REQUEST_ERROR; console.error([AuditTraceLab] camera request error ${JSON.stringify(err)}); } } build() { Column({ space: 16 }) { Text(票据录入).fontSize(24) Button(拍摄票据).onClick(() { this.onCaptureTap(); }) Button(手动录入).onClick(() { this.manualStage AVAILABLE; }) Text(相机${this.cameraStage} / 手动${this.manualStage}) } .padding(20) } }这段代码展示的是入口边界完整工程仍需要导入服务类、补齐异常类型以及相机资源的生命周期管理。真正进入相机预览后页面离开时必须释放对应采集会话不得因为 UI 上写着DENIED就假定所有设备资源自动关闭。应用还要解释拒绝后的替代流程避免用户以为资料无法添加。对于审核复现一条无歧义的“拒绝后返回手动录入并成功提交模拟数据”比单纯显示权限拒绝消息更有说服力。另外用户点击“同意隐私声明”和系统弹框授予相机是两件不同的事。若应用使用平台托管的隐私声明服务应根据实际托管状态规划后续权限请求若自行维护隐私流程也要确保正式告知、同意记录和功能触发顺序一致。不能把系统权限授权当成对全部数据处理行为的一揽子同意也不应把手动录入随意设计成隐私说明的绕过通道。五、日志必须能还原“没有发生的事”正向日志很容易写点击相机、弹窗、结果拒绝。审核和安全自测还需要证明本该不发生的事情没有发生例如启动后尚未操作时有没有读取相机、上传图片或访问与该功能有关的数据。这里的“业务敏感采集请求数 0”是我们自定义埋点范围内的统计它只证明被仪表化的调用路径没有触发不能自动证明应用或第三方 SDK 完全没有任何数据行为。// services/AuditRecorder.ets业务事件协议 export interface AuditEvent { taskId: string; attemptId: string; action: string; outcome: string; at: string; } export class AuditRecorder { private events: AuditEvent[] []; append(event: AuditEvent): void { this.events.push({ ...event }); console.info([AuditTraceLab] task${event.taskId} attempt${event.attemptId} action${event.action} outcome${event.outcome}); } exportLines(): string[] { return this.events.map((event: AuditEvent) ${event.at}|${event.taskId}|${event.attemptId}| ${event.action}|${event.outcome}); } }日志不应存储票据正文、真实照片、用户身份证明或完整设备标识。审核取证的目标是解释行为边界因此使用任务 ID、结果类别、事件时间、配置版本等足够定位问题的字段即可。导出前还要检查第三方日志、错误堆栈和文件路径里是否带有敏感内容。生产版本与调试版本的日志开关需有明确差异不能为了自测长期开启过度详细的收集。本轮模拟执行日志包含taskaudit_20261009_02、buildv1.4、preConsentSensitiveCalls0、attemptCAM-001、permissionDENIED、manualAVAILABLE。这里没有凭空假设相机硬件已经拍到了图片也没有在拒绝权限后调用相机 API。这样的记录更容易映射回页面从而解释为什么拒绝分支仍然满足产品可用性。六、证据包不是随手复制三张截图我给每个自检任务创建独立目录用audit_20261009_02作为目录键避免测试人员把上个版本的截图混进本轮。包内至少保留三种内容permissions.json是静态声明和检查结果flow-log.txt是脱敏事件链evidence-index.md是人工可读的证据索引注明版本、测试入口、操作步骤和界面图编号。截图不是全部证据日志也不是单独的真相二者必须能靠 ID 对齐。目录路径演示为/data/storage/el2/base/files/audit/audit_20261009_02/。这是应用沙箱中的示例位置正式导出方式还要遵守文件访问和分享规范不能默认任意第三方应用能直接读取此路径。为避免影响发布包体积长时间积累的证据应有保留周期和清理策略尤其不要把真实用户的敏感数据留在开发测试目录里。图 03 展示的是自检页面的四种权限相关结果CAMERAGRANTED、MICROPHONEDENIED、PHOTOPICKER_ONLY、LOCATIONNOT_REQUIRED四项行为校验显示4/4已通过。注意它是任务audit_20261009_02的综合场景矩阵与前文CAM-001的相机拒绝子场景并不是同一次点击。权限测试并不要求用户把所有权限都授予在麦克风拒绝场景下正确切到文字记录模式在选图场景下使用系统 Picker同样可以构成通过的验收结果。为了防止结果误读我会在截图旁写出规则首次启动不请求相机点击“拍摄票据”时请求用户拒绝后保留手动录入系统设置后重新检查实际权限申请失败应显示操作性提示脱敏日志与截图可以追踪同一任务。假如用户选择了“不再询问”不要用无限弹窗或遮挡手动入口的方式强迫授权而应在确需使用相机时给出清晰说明并让用户自主决定后续操作。七、详情页把“系统结果”和“自测结论”分开图 04 是EvidenceDetailPage用来回答审核复现最常问的三个问题到底请求了什么权限系统实际返回什么拒绝之后业务做了什么页面把CAMERA / DENIED放在系统结果栏把MANUAL_ENTRY / AVAILABLE放在业务结果栏再把18/18 PASS放在自测判定栏。这三个层级必须分开不能把业务自测通过画成系统已授权更不能把自测通过写成平台审核已经通过。图 04 是证据归档后的结果页状态READY_FOR_SUBMISSION、归档名audit_pkg_20261009_02.zip界面汇总了6张操作截图、18条日志、隐私声明版本v1.4并记录麦克风拒绝证明mic_denied_proof.jpg及照片选择器降级标记PHOTO_PICKER_USED。它是按本文场景设计的演示数据不代表实机上已经发生过平台提审。导出的索引同时记录场景编号CAM-001、任务audit_20261009_02和正文示例的三类逻辑证据文件清单、日志、索引这三类文件不同于界面统计的六张截图。在实际提审前我会用空白安装、升级安装、拒绝后再次进入、撤销权限后返回页面、离线条件、系统语言变更和 SDK 异常至少跑一轮。不同路径可能暴露不同的首次启动行为尤其是一些第三方 SDK 的初始化动作不能因 Demo 页面没有主动发起请求就忽略 SDK 的真实行为。项目里还应给截图增加自检版本和时间但不要在正常用户可见的生产页面上放这些调试信息。研发版可通过开关进入审核验证面板正式版则将证据保存和导出工具剥离或严格限制入口这既减少非必要功能暴露也避免调试日志长期驻留。证据生成时应当判断写盘成功、记录文件大小与校验结果否则按钮显示“导出成功”却没有文件是另一类典型的假阳性。八、把静态扫描、运行回放与人工审查接起来从工程实施角度我把 18 个自测项分成几组声明字段和用途文案检查首次启动与点击路径检查拒绝、允许、取消和系统改权后的状态检查手动降级检查日志脱敏和证据导出检查。每项都有输入、期望、观测和结论不允许一个“已测”复选框同时代表几类不同问题。版本迭代以后对配置差异和 SDK 升级做增量回归避免完整流程被测试习惯替代。这套小工具不是一个能替代 AppGallery Connect 审核的检测器。官方审核指南、市场政策、隐私保护规则可能调整不同应用涉及的资质、数据处理场景与三方 SDK 差异也很大。Demo 展示的是可迁移的工程方法把权限的请求原因、运行时触发点、用户结果与业务降级用统一 ID 连起来并保留足够让其他人复现的证据。对正式产品还要逐一核对集成 SDK 的数据收集目的、方式和范围是否在隐私政策中明示。八点一、把 18 项测试拆成“行为契约”自检项目越多越需要防止分数形式化。我给每项都写四个字段触发操作、允许发生的系统能力调用、禁止发生的业务行为以及可以复核的证据。例如AT-01的操作是冷启动允许渲染本地首页却禁止未点击时发起相机授权请求AT-07的操作是点击拍摄并拒绝权限允许页面显示拒绝提示却禁止继续创建相机会话AT-12的操作是转到手动录入必须保持输入框可编辑。这比一句“权限申请正常”更能发现版本回归。自动化能检查事件顺序、UI 按钮状态、权限配置差异和导出文件是否存在但文案是否充分告知、SDK 实际的数据收集范围和用户是否被诱导授权仍需要人工审阅。因此汇总页虽然显示18/18 PASS索引文件还会注明检查范围与未覆盖项。测试计划中至少要明确本次没有进行平台审核、没有使用真实用户票据也没有评估应用之外第三方服务的所有行为。自测结论越明确限定边界越不容易在团队流转时被误当成最终合规证明。八点二、升级包与首次安装必须分开跑研发测试常用已经反复安装的设备很容易把授权状态带进下一轮。新版已经删掉了某个使用入口但旧系统设置里可能还留着历史许可反过来首次安装时的新隐私说明也可能改变整个启动流程。我的习惯是准备两套独立脚本一套从干净安装开始关注首次告知和首次触发另一套按真实用户升级路径运行关注旧授权状态、持久化数据和 SDK 配置迁移。对“拒绝后改为允许”的回归要观察页面重新进入时是否查询最新系统状态而不是继续读缓存中的DENIED对“允许后在设置中撤销”的回归则要确认应用在下次访问相机前重新检查不能继续使用已失效的会话。还要在日志中把权限系统返回值、业务是否继续执行分开记录。只要出现两者不一致就应让检查失败而不是用一次弹窗成功截图掩盖状态同步问题。九、这次最值得留下的工程约束回头看团队原先以为“有权限声明、有授权成功截图”就是完成权限接入后来才意识到合规验收关注的是整个使用过程。现在AuditTraceLab的任务audit_20261009_02有明确的隐私声明版本v1.4、综合矩阵4/4项通过、相机拒绝子场景CAM-001的DENIED和手动路径AVAILABLE以及audit_pkg_20261009_02.zip的演示归档状态归档页另展示六张截图和十八条运行日志。这个结果只适用于本文设计的演示检查项不能外推到真实 App 的全部合规条款。更重要的不是这 18 项而是以后有人修改相机入口、接入 OCR SDK、引入新的文件选择能力能马上问出几个具体问题新功能多请求了什么权限用户在什么时点看见说明拒绝以后剩下哪些功能证据是否还覆盖新路径这些问题能提前在提交前被回答就减少了靠最后一天补截图、补文案、临时拆 SDK 的被动局面。参考资料提交前请重新核对最新版政策和 SDKHarmonyOS 权限声明https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/declare-permissions向用户申请授权相关权限与分类https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-v5/permissions-for-all-V5隐私管理服务https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-v5/store-privacy-V5提交 HarmonyOS 应用https://developer.huawei.com/consumer/cn/app/submit/说明上述18/18 PASS、日志、手机与 IDE 配图均为同一演示用例的仿真数据不是平台审核结论也不是真机实测留证。权限、用户授权、文件保存和发布流程需在目标 SDK、设备和正式审核环境重新确认。