第6篇｜上架前最后一道闸：HarmonyOS 相机应用的隐私协议、权限闸门与 AppGallery 审核闭环

本文基于「晨迹相机」这个 HarmonyOS Stage 模型项目继续展开。前几篇我们已经打通了 UIAbilityContext 获取、cameraPicker 系统相机调用、拍摄结果保存、Preferences 极简 JSON 状态库、临时文件持久化和异常 Toast 兜底。到了第 6 篇重点不再是“功能能不能跑”而是“这个相机 App 能不能经得起 AppGallery 的隐私与权限审核”。做移动端应用尤其是相机、录像、定位、水印这类带敏感能力的应用最容易犯的错误是代码已经能拍照构建也能通过于是就觉得可以提交审核了。实际提交时审核会从另一个角度看你的应用- 用户第一次打开 App 时是否已经明确知道你会申请相机、麦克风、定位- 用户不同意隐私政策时是否仍能进入主界面- 是否存在“进入页面就申请权限”的过度打扰- App 内是否能再次查看用户协议和隐私政策- module.json5 里声明的权限、弹窗文案、隐私政策、真实代码行为是否一致这一篇要做的就是给「晨迹相机」补上上架前必须具备的一条闭环首启隐私协议同意流程 敏感权限使用闸门 协议复查入口 权限说明一致性检查。一、为什么相机 App 必须先做隐私闸门「晨迹相机」的核心功能是每日拍照/录像打卡后续还会叠加水印、地点、天气、挑战、回忆等能力。从产品视角看它很简单打开 App- 选择拍照或录像- 调用系统相机- 保存照片/视频 URI- 补充心情和备注- 写入本地记录但从审核视角看它涉及四类敏感能力{name: ohos.permission.CAMERA},{name: ohos.permission.MICROPHONE},{name: ohos.permission.APPROXIMATELY_LOCATION},{name: ohos.permission.LOCATION}如果 App 一启动就展示主界面用户还没有同意协议就已经可以点击相机、录像、位置水印这在上架前属于明显风险。所以我们需要把启动链路改成启动 App- 加载本地状态- 判断 privacyAgreed- 未同意只显示隐私协议弹窗- 同意后进入引导页或主界面- 用户主动点击拍照/录像- 再申请 CAMERA / MICROPHONE- 授权成功后才调用 cameraPicker这里的核心原则是隐私同意是产品入口闸门系统权限申请是功能动作闸门两者不能互相替代。二、本篇改造涉及的文件本次改动不是只加一个弹窗而是把“同意状态”贯穿到模型、存储、页面和文案entry/src/main/ets/common/models/AppModels.etsentry/src/main/ets/common/services/AppDataStore.etsentry/src/main/ets/common/constants/Legal.etsentry/src/main/ets/features/app/CheckInCameraApp.etsentry/src/main/module.json5职责拆分如下| 文件 | 责任 || --- | --- || AppModels.ets | 在 AppState 中增加 privacyAgreed || AppDataStore.ets | 负责读取、合并、保存协议同意状态 || Legal.ets | 集中维护隐私政策、用户协议、首启摘要 || CheckInCameraApp.ets | 控制弹窗展示、同意/拒绝逻辑、协议复查入口 || module.json5 | 声明敏感权限与申请理由 |这样设计的好处是页面不直接读写 Preferences协议文本不散落在 UI 里权限声明也能和隐私政策逐项对齐。三、模型层privacyAgreed 必须进入 AppState隐私协议是否已同意不能只放在页面变量里。页面变量只能控制当前渲染App 重启后就丢失而审核关注的是一个稳定的用户同意状态。因此我把它放进全局应用状态export interface AppState {guideSeen: boolean;privacyAgreed: boolean;records: CheckInRecord[];challenges: Challenge[];watermarks: WatermarkConfig[];ui: AppUiState;}默认值必须是 falseexport function createDefaultAppState(): AppState {return {guideSeen: false,privacyAgreed: false,records: createSeedRecords(),challenges: createSeedChallenges(),watermarks: createSeedWatermarks(),ui: createDefaultUiState()};}这里有一个很容易忽视的迁移问题旧版本本地 JSON 里没有 privacyAgreed 字段。如果直接把旧 JSON 强转成 AppState运行时可能出现privacyAgreed undefined所以合并状态时必须显式归一function mergeState(state: AppState): AppState {return {guideSeen: !!state.guideSeen,privacyAgreed: !!state.privacyAgreed,records,challenges,watermarks,ui: mergeUiState(state.ui, fallback.ui)};}!!state.privacyAgreed 的意义不只是类型转换更是安全默认值只要旧数据、损坏数据、缺失数据无法证明用户已同意就按未同意处理。四、存储层让同意状态走统一服务本项目的状态存储使用 Preferences 保存一个极简 JSONSTORE_NAME check_in_camera_storeSTATE_KEY app_state因此协议同意状态也必须走 AppDataStore而不是在页面里单独开一个 Preferences。新增方法async setPrivacyAgreed(context: common.UIAbilityContext, agreed: boolean): PromiseAppState {this.state.privacyAgreed agreed;await this.save(context);return copyState(this.state);}这段代码很短但边界很清楚- 页面表达“用户点击了同意”- service 修改内存态- service 写入 Preferences- service 返回一份深拷贝后的新状态- 页面再根据新状态决定展示引导页或主界面。不要让 UI 组件直接操作持久化 API。这个规则在小项目里看似啰嗦但到了多页面、多入口、多状态时它能避免非常多的同步问题。五、文案层Legal.ets 集中管理协议文本协议文本最怕散。如果你把隐私政策摘要写在弹窗里把完整政策写在另一个页面里把权限说明又写在 README 或上架后台里后面一旦权限变动很容易漏改。所以我单独新建entry/src/main/ets/common/constants/Legal.ets里面集中导出export const PRIVACY_SUMMARY_TEXT: string ...;export const PRIVACY_POLICY_TEXT: string ...;export const USER_AGREEMENT_TEXT: string ...;首启弹窗使用 PRIVACY_SUMMARY_TEXT用户点击查看完整内容时再展示 PRIVACY_POLICY_TEXT 或 USER_AGREEMENT_TEXT。更重要的是隐私政策里的权限描述要和 manifest 对齐| manifest 权限 | 应用实际用途 | 隐私政策表达 || --- | --- | --- || CAMERA | 拍照/录像打卡 | 仅在用户点击拍照或录像时申请 || MICROPHONE | 录制视频声音 | 仅在录像模式下申请 || APPROXIMATELY_LOCATION | 城市或附近地点水印 | 仅在启用位置水印时使用 || LOCATION | 精确坐标水印 | 仅在需要精确位置水印时使用 |如果隐私政策说“不会收集位置信息”但 module.json5 里声明了 LOCATION这不是文案问题而是审核风险。六、启动层bootstrap 里先判断协议状态在 CheckInCameraApp 里启动流程由 bootstrap() 统一控制。关键逻辑如下private async bootstrap(): Promisevoid {this.pageState loading;try {const state await appDataStore.load(this.getContext());this.appState state;this.applyUiState(state.ui);this.syncCalendarDetail();this.syncDraftsFromState();if (!state.privacyAgreed) {this.showPrivacy true;this.showGuide false;} else {this.showPrivacy false;this.showGuide !state.guideSeen;}this.pageState content;} catch (error) {this.pageState error;this.pageErrorText 本地数据初始化失败请重试。;}}这里有一个顺序细节隐私协议优先级 首次引导页优先级 主界面优先级也就是说- 未同意协议时不展示 GuideOverlay- 未同意协议时不让用户进入五栏主导航- 同意协议后才根据 guideSeen 判断是否展示首次引导- 首次引导完成后才进入完整主界面。这样做的体验也更自然用户先知道应用会用什么数据再了解产品怎么用。七、交互层PrivacySheet 必须有四个动作一个合格的首启协议弹窗至少要有四个动作Button(查看用户协议)Button(查看隐私政策)Button(同意并继续使用)Button(不同意并退出)「同意并继续使用」写入持久化状态private async agreePrivacy(): Promisevoid {try {this.appState await appDataStore.setPrivacyAgreed(this.getContext(), true);} catch (error) {// 持久化失败不阻止进入主界面下次启动会再弹}this.showPrivacy false;this.showGuide !this.appState.guideSeen;}「不同意并退出」结束当前 Abilityprivate async rejectPrivacy(): Promisevoid {try {await this.getContext().terminateSelf();} catch (error) {this.showToast(请手动退出应用未同意协议时无法使用。);}}这里不要做成“不同意但进入首页”。只要用户还能进入首页就仍然可能触发相机、录像、定位入口隐私闸门就失效了。八、叠层顺序InfoSheet 要盖在 PrivacySheet 上面首启协议弹窗里有两个查看按钮查看用户协议查看隐私政策点击后会打开完整文本。如果 Stack 里的渲染顺序写错就会出现“状态变了但完整文本被协议弹窗挡住”的问题。正确顺序是if (this.showPrivacy) {this.PrivacySheet()}if (this.showInfoSheet) {this.InfoSheet()}ArkUI 的 Stack 后绘制内容会覆盖前面的内容所以 InfoSheet 必须在 PrivacySheet 后面。这是一个典型的“编译不会报错但用户看不到”的问题。做弹窗、底部面板、二次确认框时都要特别注意层级顺序。九、功能层权限仍然要在用户动作之后申请同意隐私政策不等于授权系统权限。它只是说明用户理解并接受应用的数据处理规则真正调用相机、麦克风、定位前仍然要走系统权限申请。拍照/录像入口保留触发式申请private async requestPermissions(mode: CaptureMode): Promiseboolean {const result mode video? await cameraPermissionService.requestVideoPermission(this.getContext()): await cameraPermissionService.requestPhotoPermission(this.getContext());if (result.deniedPermissions.length 0) {this.cameraStatusText mode video ? 录像需要相机和麦克风权限。 : 拍照需要相机权限。;this.showToast(this.cameraStatusText);return false;}return true;}完整链路应该是用户同意隐私政策- 用户进入主界面- 用户主动点击拍照/录像- App 申请 CAMERA / MICROPHONE- 用户授权- 调用 cameraPicker位置权限也一样不应该在 App 启动时申请而应该在用户启用位置水印或相关功能时申请。十、「我的」页协议必须可复查首启弹一次不是终点。上架前还要保证用户进入 App 后能再次查看协议。于是我在个人中心菜单中增加{ icon: ic_profile_album, label: 隐私政策, desc: 了解数据使用与权限说明, action: privacy },{ icon: ic_profile_album, label: 用户协议, desc: 查看应用使用条款, action: agreement }点击后复用 openInfo()if (item.action privacy) {this.openInfo(隐私政策, PRIVACY_POLICY_TEXT);}if (item.action agreement) {this.openInfo(用户协议, USER_AGREEMENT_TEXT);}这一步看似很小但对审核材料非常关键应用内必须有用户能再次查看协议的入口而不是只在首启时短暂出现。十一、和 AppGallery 审核相关的自查清单做完这次改造后我建议每次上架前按这张表走一遍| 检查项 | 通过标准 || --- | --- || 首启协议 | 第一次打开 App 必须展示用户协议与隐私政策摘要 || 拒绝路径 | 用户点击不同意后不能进入主功能 || 同意持久化 | 同意后写入本地状态重启不重复弹窗 || 主功能阻断 | 未同意前不能触发相机、麦克风、定位 || 权限触发 | 敏感权限必须在用户主动操作后申请 || 协议复查 | 「我的」或「设置」页能再次查看完整协议 || 文案一致 | 隐私政策、权限 reason、真实代码行为一致 || 本地存储说明 | 明确说明照片、心情、挑战、记录只保存在本地 || 删除说明 | 提供回收站、彻底删除、清空等用户可理解的删除路径 || 构建验证 | 修改后必须执行 hvigorw.bat --no-daemon assembleHap |尤其是相机类、录音类、定位类、文件类 App不要把隐私协议当成最后补的文案。它应该和权限设计一起进入开发计划。十二、这次改造的工程价值这篇改造完成后项目多了几条很重要的工程约束1. 敏感能力不再裸露在首屏之后2. 用户同意状态进入持久化模型3. 协议文本集中维护后续权限变化更容易同步4. 首启协议、首次引导、主界面的优先级清晰5. 系统权限申请仍保持“用户主动触发”6. App 内具备协议复查入口7. 代码行为和上架材料可以互相解释。这就是我理解的高质量 HarmonyOS 项目不是每个页面都堆满功能而是关键链路有边界、有证据、有兜底出了问题能定位上架审核也能说得清楚。十三、本篇小结第 6 篇做的是一个上架前经常被低估的能力隐私协议同意流程。核心代码不复杂真正重要的是顺序和边界AppState 保存 privacyAgreedAppDataStore 统一持久化Legal.ets 集中协议文本bootstrap 先判断协议状态PrivacySheet 提供同意/拒绝/查看完整协议InfoSheet 处理完整协议阅读ProfileTab 提供协议复查入口权限申请仍放在用户主动动作之后对于 HarmonyOS / AppGallery 项目来说构建通过只能证明代码能编译隐私流程完整才能说明产品可以被用户和审核同时理解。下一篇可以继续往“发布前体验修复”走比如签名冲突 install sign info inconsistent、DevEco 缓存包名、安装-启动-卸载烟测以及这些问题如何进入项目错误日志避免下一个项目重复踩坑。高质量补充把这篇文章补成可复查的项目记录这篇文章对应的项目是晨迹相机主题是第6篇上架前最后一道闸HarmonyOS 相机应用的隐私协议、权限闸门与 AppGallery 审核闭环。为了让它达到 CSDN 高质量文章的标准不能只停留在“我遇到了一个问题”或“我写了一段代码”而要把背景、实现、验证和复盘讲完整。读者看完以后应该知道这个问题为什么出现、怎么定位、怎么修复、如何避免下一次再踩坑。1. 场景和目标要先说清楚本篇内容服务的真实场景是HarmonyOS 相机调用、文件授权和异常兜底。如果文章一上来就贴代码读者很难判断代码为什么存在如果先说明用户任务、审核要求或工程目标后面的实现细节就有了上下文。高质量技术文不是代码堆叠而是把“为什么做”和“怎么验证”一起讲清楚。因此这篇文章可以按四步理解第一步说明项目目标第二步列出原始问题第三步拆解实现路径第四步给出验收标准。这样写能让文章从短笔记变成完整复盘也更符合 CSDN 对原创、结构化和可复用经验的判断。2. 实现路径要有工程证据工程证据包括目录结构、关键接口、状态流转、错误处理和最终效果。对于 HarmonyOS 或前端项目来说尤其要避免只写“成功了”。更好的写法是说明输入是什么、处理逻辑在哪里、输出如何展示、失败时如何兜底。读者能够复现文章才真正有价值。输入用户操作、页面参数或审核反馈 处理组件状态、服务层方法、平台 API 或本地规则 输出页面变化、保存结果、打包产物或审核材料 兜底异常提示、空状态、权限失败和回退方案如果是 ArkUI 页面要关注文本是否溢出、按钮是否可点、页面是否可滚动如果是数据保存要说明服务层如何封装读写如果是发布审核要把权限、隐私、版本号、截图和安装启动验证放在同一张清单里。这样文章就不再是零散经验而是能被下一次开发直接复用的流程。3. 常见风险和修复思路这类项目最常见的风险有三类一是页面只在大屏正常小窗口或移动端出现遮挡二是逻辑只覆盖成功路径权限拒绝、空数据、网络失败时没有提示三是发布材料和代码行为不一致例如声明离线却引入网络能力或者截图展示的功能和安装包不一致。文章里主动写出这些风险会让内容更像真实项目复盘。修复时建议把问题拆到最小可验证单元。先确认输入数据再确认状态变化再确认 UI 展示最后跑一次构建或本地冒烟测试。不要只凭“看起来正常”判断完成尤其是涉及 AppGallery、HarmonyOS 权限、文件授权、语音播放、相机调用和本地存储的文章。4. 验收清单验收项检查方式标题和项目名清楚读者第一屏能判断文章属于哪个应用或功能模块正文长度足够不是几百字短记录而是有背景、实现、验证和复盘代码或伪代码存在关键逻辑能被读者复用不只是口头描述异常路径明确说明失败原因、用户提示和回退方式验收结论可检查包含构建、截图、页面状态或发布材料检查点5. 后续优化方向后续如果继续整理这个系列可以把每一篇都统一成“问题背景、核心实现、踩坑记录、验收清单、下一步计划”的结构。对于短文章优先补真实问题和验证过程对于已经有代码的文章优先补截图说明、失败路径和复盘清单。这样不仅能提高单篇质量也能让整个账号的项目文章形成连续沉淀。最终目标不是把文章写得很长而是让每一段都有作用帮助读者理解项目、复现实现、规避风险或者判断这个方案是否适合自己的项目。做到这一点文章才更接近真正的高质量原创技术内容。6. 实操记录建议按这个顺序补充证据第一步先保留原始问题。很多短文之所以质量分低不是因为题目不好而是只写了结论没有写定位过程。可以把当时看到的现象补出来例如页面无响应、构建失败、权限被拒绝、文件无法访问、语音没有声音、发布材料不一致等。现象越具体读者越容易判断自己是否遇到同类问题。第二步补定位思路。定位不要只写“最后发现是某个 API 问题”而要把排查顺序写清楚先看控制台或日志再缩小到页面状态、服务层方法、权限声明、资源路径或构建配置最后用一个最小样例确认原因。这个过程能体现工程经验也是高质量文章最容易拉开差距的部分。第三步补修复方案。修复方案最好包含“改了哪里、为什么这样改、有没有副作用”。例如 ArkUI 页面要解释状态变量如何变化Preferences 要解释读写服务如何封装AppGallery 发布问题要解释 AGC 字段和安装包行为如何保持一致cameraPicker 或 fileIo 要解释授权生命周期和异常退避。第四步补验证结果。验证不能只写“已解决”而要写具体检查页面重新打开是否正常数据刷新是否正确构建命令是否通过发布材料是否一致低权限或无数据场景是否有提示。对于 HarmonyOS 项目至少要说明一次核心流程冒烟测试启动、进入页面、执行操作、返回、退出。7. 可以直接复用的文章结构模板段落应该写什么为什么重要问题背景项目、页面、模块、用户场景避免文章像孤立代码片段复现步骤输入、操作路径、异常表现让读者判断是否同类问题原因分析日志、状态、权限、接口、资源路径体现真实排查过程修复方案关键代码、配置或架构调整提供可迁移经验验收结果构建、截图、功能流、异常兜底证明不是只改了表面8. 和 AppGallery/HarmonyOS 审核相关的补充如果文章涉及 HarmonyOS 或 AppGallery建议额外说明审核风险。比如权限申请是否和实际功能一致隐私说明是否覆盖数据行为深浅色模式下文字是否可读手机、平板和 2in1 窗口下是否存在遮挡发布包是否能安装、启动、运行核心流程并卸载。把这些检查写出来文章会更像一次完整发布复盘。对于离线工具或教育类应用还要特别说明是否联网、是否采集个人信息、是否包含账号、广告、支付或第三方 SDK。很多审核问题不是代码本身而是“描述、权限、截图、实际行为”不一致。文章把这部分写清楚读者能直接借鉴到自己的发布流程。9. 代码片段要服务解释而不是凑格式代码片段不一定要长但必须和文章主题相关。短文可以放伪代码说明输入、处理、输出和异常分支工程文可以放真实函数展示服务层封装、状态更新或错误处理。关键是让读者看到“这段代码解决了什么问题”。async function runCoreFlow() { const input collectUserInput() const result await service.execute(input) if (!result.ok) { showError(result.message) return } updatePageState(result.data) recordSmokeCheck(core flow passed) }这类片段能把文章从经验描述推进到工程实践。即使读者不直接复制也能理解代码组织方式页面只负责收集输入和展示结果业务判断放到服务层错误路径必须有用户可读提示验证结果要能留下记录。10. 复盘结论回到本文主题第6篇上架前最后一道闸HarmonyOS 相机应用的隐私协议、权限闸门与 AppGallery 审核闭环 的价值不只是一个单点技巧而是一次项目质量补强。把短记录补成完整文章本质上是在补齐工程上下文问题从哪里来、为什么这样修、怎么确认修好了、下次怎样避免。这个结构对读者友好也对后续参赛、上架、答辩和项目归档更有用。11. 案例化复盘把一句经验展开成完整闭环以一个常见开发过程为例开发者发现功能在演示时偶尔失败如果文章只写“后来改好了”读者几乎得不到有效信息。更好的写法是把失败现场记录下来是在首次进入页面失败还是返回页面后失败是在真实设备失败还是预览器失败是权限弹窗后失败还是数据为空时失败。这些细节决定了排查方向。然后把排查过程拆成几层。第一层看输入确认页面拿到的参数是否完整第二层看服务确认业务方法有没有返回明确结果第三层看平台能力确认权限、上下文、文件路径或网络状态是否满足要求第四层看 UI确认错误是否被展示给用户。只要这四层写清楚哪怕代码并不复杂文章也会有明显的参考价值。最后补验收。比如重新打开应用、切换页面、清空数据、拒绝权限、重复执行核心流程看系统是否还能给出稳定反馈。高质量文章的结尾不应该只说“完成”而应该说明“我用哪些路径证明它完成”。这个习惯会让项目质量和文章质量一起提升。12. 面向读者的可迁移经验读者真正需要的往往不是一模一样的代码而是可迁移的判断方式。看到本文后他应该能把同样的方法用到自己的页面、服务层或发布流程里先明确用户任务再定位数据来源再把异常路径写出来最后用验收清单收尾。这样的文章即使来自个人项目也能变成团队开发或比赛复盘中的可复用材料。所以补充后的文章会保留原始主题同时加入完整上下文。它既不改变原文方向也不会把内容写成无关的大段空话而是围绕项目、问题、实现和验收补齐证据。对 CSDN 来说这比短句堆砌更像原创高质量内容对项目来说它也更方便日后回头复盘。13. 最终检查发布前还要再看一遍标题、摘要、标签和正文是否一致。标题负责告诉读者主题摘要负责交代价值标签负责帮助检索正文负责提供证据。如果这四者互相脱节文章即使字数足够也会显得松散。补充完成后建议至少检查一次目录层级、代码块显示、表格是否完整、图片是否还在以及结尾是否给出明确复盘。这一轮补充的目标就是让文章从“能看”变成“值得收藏”。读者能按步骤复现作者以后能按清单回顾项目也能留下更完整的技术沉淀。