【时光清单|20】HarmonyOS ArkTS AppGallery 发布复查实战:核对包名、版本、设备、素材和离线声明

【时光清单|20】HarmonyOS ArkTS AppGallery 发布复查实战:核对包名、版本、设备、素材和离线声明

唯一核验标记:CSDN-SERIES:ALL-163210769
证据口径:本文严格区分当前源码事实、2026-05-20 历史 APP/HAP 证据和建议发布流程。本轮未构建新包、未执行设备测试、未操作 AGC,也未读取任何平台审核结果;上传、绑定、提交、审核通过与上架始终是不同状态。

AppGallery 发布复查不是把后台表单从上到下看一遍,而是确认源码、候选包、运行行为、商店字段和展示素材都在描述同一个版本。只要其中一层仍指向旧状态,就可能出现"上传的是新包,绑定的是旧包""包只支持手机,后台却勾选了平板""源码没有联网,隐私材料却写了云端同步"等问题。

"时光清单"的当前源码给出了很清楚的发布基线:Bundle Name 为 com.jiaweikan.one8,版本名 1.0.0,版本号 1000000,模块只声明 phone;入口采用 Stage 模型,主页面从 pages/Index 加载;工程没有声明网络权限,也没有检索到 HTTP、Web、推送、广告或统计 SDK 的调用。与此同时,资源复查发现 AppScope 与 entry 模块使用了视觉明显不同的分层图标,这比一般的表单遗漏更值得在构建候选包前处理。

本文基于 D:\huawei\one8 的真实源码、资源文件和历史产物元数据,给出一套可重复执行的发布复查方法。文章只讨论本地可核验事实和建议流程,不声称已经完成新的 release 构建、设备测试、AGC 提交、审核或上架,也不会展示任何签名、账号或会话秘密。

零、先把三类证据分开

发布复查最怕把"源码里写了什么""历史上生成过什么"和"现在建议做什么"混成一句话。本文按下面三类证据叙述:

类型 本轮可复核内容 不能外推的结论
当前事实 AppScope/app.json5module.json5、EntryAbility、Preferences、卡片、备份声明和图标资源 当前 release 包已经构建或测试通过
历史证据 2026-05-20 的 APP/HAP 文件及其时间、大小 这些产物包含 2026-08-24 的当前源码
建议实现 重新构建、包回读、安装启动卸载、素材对账、AGC 上传绑定与 fresh readback AGC 已保存、已提交、已审核或已上架

本地源码当前明确给出 com.jiaweikan.one81.0.01000000phone 声明;定向扫描没有命中 INTERNET 权限、HTTP、Web、socket、运行依赖或请求权限代码。这个结果只能支持"当前扫描范围内未发现",不能替代对最终 APP/HAP 的权限、依赖和运行流量审计。

资源证据则更直接:AppScope 前景是带"时光清单"文字的山水亭台图,entry 分层图标和 startIcon.png 是蓝底四宫格。两套资源在本轮逐张目视检查中明显不同,因此文章把它列为当前风险,而不是写成已经修复。备份方面也只确认 allowToBackupRestore=true 和扩展声明;当前 onBackuponRestore 只记录日志并返回,不能声称业务数据备份恢复已经完成验证。

一、先定义"发布候选版本"

发布复查必须围绕一个不可含糊的候选版本展开。至少记录:

复制代码
source revision
bundleName
versionName
versionCode
build mode
package path
package size
package hash
build timestamp
target device types

若复查期间又修改了代码、资源、版本号或权限,原候选包立即失效,需要重新构建、重新计算哈希并重新执行冒烟。否则测试报告与最终上传包不是同一份交付物。

当前工程目录中可以找到 2026 年 5 月生成的 HAP,但文件时间明显早于本次源码复查。旧产物只能证明历史上构建过,不能证明当前源码已经形成可提交的 release 候选包。因此本文不会把它写成"最新包验证通过"。

二、AppScope 决定应用级身份

真实 AppScope/app.json5 的核心内容如下:

复制代码
{
  "app": {
    "bundleName": "com.jiaweikan.one8",
    "vendor": "example",
    "versionCode": 1000000,
    "versionName": "1.0.0",
    "icon": "$media:layered_image",
    "label": "$string:app_name"
  }
}

复查时要分别回答五个问题:

  1. AGC 当前应用的 Bundle Name 是否确实为 com.jiaweikan.one8
  2. 最终候选包解析出的 Bundle Name 是否一致;
  3. versionCode 是否高于已发布版本,而不是只修改展示用的 versionName
  4. 应用名称资源是否仍解析为"时光清单";
  5. vendor 仍为示例值是否符合项目的正式发布约定。

vendor: "example" 不一定直接造成审核失败,但它明显是模板痕迹,应在发布冻结前由项目负责人确认。发布文章不能擅自把它改写成正式厂商值,更不能把未确认的信息填入 AGC。

三、版本名与版本号必须双重递增

versionName 面向用户,versionCode 面向系统和商店。常见失配包括:

  • 更新说明写了 1.0.1,包内仍是 1.0.0;
  • versionName 已变化,versionCode 没有递增;
  • About 页面显示旧版本;
  • 上传了多个同名包,AGC 版本页仍绑定较早的一条;
  • 测试用包与提交包签名或构建模式不同。

正确做法是从最终候选包读取版本,不以源码编辑器中的文字作为最终证据。上传后还要回到版本页重新打开包选择区域,核对版本、上传时间、文件大小并保存,再回读当前绑定结果。

四、模块范围决定商店设备范围

真实 entry/src/main/module.json5 只声明:

复制代码
"deviceTypes": [
  "phone"
]

因此当前源码中的设备声明只有 phone;本轮没有登录 AGC,不能确认平台当前选择。AGC 的支持设备、截图素材组、审核测试范围应与最终候选包回读结果对齐。不能因为页面看起来可以拉宽,就直接勾选 tablet 或 2in1;响应式布局能力不等于包元数据已经声明支持,也不等于这些设备上的交互、状态栏、导航栏和安全区已经验证。

若未来扩展设备类型,应同时完成:

  • 修改模块设备声明;
  • 检查各页面自适应布局;
  • 验证横竖屏和窗口缩放;
  • 准备对应设备截图;
  • 在真实设备或云测试中完成核心流程;
  • 更新 AGC 支持设备与材料。

五、安装方式与扩展能力也要对账

模块配置还表明:

复制代码
"deliveryWithInstall": true,
"installationFree": false

这说明 entry 随应用安装,不是免安装形态。后台产品类型、介绍文案和审核备注都不应把它描述成元服务或免安装体验。

同一模块包含三个重要能力入口:

  • EntryAbility:应用主页入口,exported: true
  • EntryBackupAbility:备份扩展,exported: false
  • CountdownFormAbility:桌面卡片能力,exported: true

发布复查不能只点开主页面。桌面卡片与备份扩展声明都会影响隐私说明、测试路径和异常恢复;但当前备份回调只记录日志并返回,本轮不能把业务数据备份恢复写成已实现或已验证。

六、启动链路要从真实代码确认

EntryAbility.etsonCreate 中初始化 DataStore、读取心情背景,并触发 AppStore 的启动与水合;窗口阶段加载:

复制代码
windowStage.loadContent('pages/Index')

随后设置全屏布局、安全区和系统栏主题。pages/Index.ets 使用:

复制代码
Navigation(this.pathStack) {
  MainTabShell()
}
.navDestination(appRouter)
.mode(NavigationMode.Stack)

这条链路给发布测试提供了明确的首屏契约:

复制代码
安装 -> 首次启动 -> 本地初始化 -> pages/Index
     -> MainTabShell -> Navigation 路由

复查重点不是"能看到一个页面",而是同步初始化不能长时间阻塞首帧,水合失败要有可恢复状态,系统栏文字与背景要保持可读,返回导航不能失效。

七、页面清单与入口声明要一致

main_pages.json 当前只登记 pages/Index。这与 Navigation 容器统一承载二级目的地的结构相符。发布前仍要确认:

  • 冷启动始终能找到 Index;
  • 路由表中的目的地都可达;
  • 二级页面支持系统返回;
  • 不存在只在调试入口可达的核心功能;
  • 审核人员不需要隐藏手势或特殊数据才能体验主要能力。

审核备注应给出最短可复现路线,例如"启动后在首页创建纪念日,再进入桌面卡片预览",而不是只写"功能丰富,请自行体验"。

八、商店描述必须能映射到源码能力

工程资源中的商店标题为"时光清单 - 倒计时纪念日",副标题为"记录重要时刻,遇见更好的自己"。描述覆盖倒计时、生日、恋爱天数、发薪日、主题、心情背景、日记、习惯、情侣、相册、桌面卡片和每日一句。

复查方法不是判断文案是否好听,而是给每个声明找到实际入口:

商店声明 需要的可核验证据
倒计时与纪念日 创建、编辑、删除、排序和首页展示
日记与心情 本地保存、返回刷新、空状态
习惯记录 新建、打卡、统计与清除
情侣空间 真实可达页面及本地数据行为
相册 Photo Picker 选择、取消和读取失败路径
桌面卡片 三种卡片规格的添加、刷新和兜底
每日一句 数据来源、更新规则与断网行为

尤其要避免"自动提醒""云同步""永久保存""全设备同步"等源码无法直接证明的强承诺。若提醒依赖系统通知能力,需单独核对权限、授权拒绝路径和触发条件;若没有云端,就不能把本地保存包装成云同步。

九、离线声明要建立在多层证据上

本次对源码、清单和依赖做了定向检索,未发现:

复制代码
ohos.permission.INTERNET
NetworkKit
http.createHttp
fetch(
Web(
PushKit
analytics
AdsKit
AccountKit
requestPermissions

oh-package.json5 也没有运行时三方依赖,仅保留 Hypium 和 Hamock 开发依赖。这些事实支持"当前源码以本地能力为主、未见主动网络访问"的判断。

但这还不是最终包的网络审计结论。正式发布仍需:

  1. 解析 release 候选包的权限与依赖;
  2. 断网启动并走完核心流程;
  3. 观察运行期是否出现域名访问或 SDK 初始化;
  4. 检查动态资源、Web 内容、统计和更新逻辑;
  5. 确认 AGC 隐私标签与实际行为一致。

因此严谨表述应是"基于当前源码扫描未发现联网实现",而不是在没有包级与运行期证据时断言"绝对不会产生任何网络请求"。

十、系统能力不等于网络服务

本地应用仍可能调用系统能力。相册通过 Photo Picker 由系统提供选择界面,桌面卡片通过 FormExtensionAbility 工作,备份扩展通过系统备份机制工作。它们与自建服务器、账号体系或远程 API 不是同一概念,但仍需在用户说明和隐私材料中准确交代。

特别是 backup_config.json 当前允许备份恢复:

复制代码
{
  "allowToBackupRestore": true
}

如果产品文案声称"数据只存在当前设备、绝不参与任何备份",就会与配置发生冲突。更准确的做法是说明应用不自建服务器上传数据,同时按系统备份机制的真实行为描述可备份范围。

十一、权限复查不能只看弹窗

当前 module.json5 没有 requestPermissions。这意味着:

  • AGC 权限说明不应罗列源码不存在的敏感权限;
  • 隐私政策不应套用位置、通讯录、麦克风等模板条款;
  • 相册选择应通过 Picker 而不是广泛存储权限;
  • 若后续加入通知或其他权限,需同步修改清单、运行时授权、拒绝路径和政策。

还应检查最终包,因为构建变体、依赖或其他模块可能引入源码人工浏览时遗漏的声明。源码、包、运行弹窗与 AGC 隐私标签四处必须一致。

十二、图标一致性是当前最明确的发布风险

AppScope 和 entry 都把图标资源命名为 $media:layered_image,但"资源名相同"不代表"渲染结果相同"。

本次目视检查发现:

  • AppScope 背景是浅米色;
  • AppScope 前景是粉橙色山水亭台图案,并带"时光清单"文字;
  • entry 背景是蓝色;
  • entry 前景是四个浅色圆角方块;
  • startIcon.png 也呈现蓝底四宫格。

也就是说,商店/应用级资源与 EntryAbility/启动资源存在明显视觉分裂。用户可能在商店看到山水图标,安装后却看到蓝色四宫格,启动页又继续使用另一套视觉。这不是轻微像素差异,而是需要在候选包构建前确认并统一的发布阻断项。

处理时应明确唯一设计源,再同步:

复制代码
AppScope layered_image
entry layered_image
EntryAbility icon
startIcon
应用内关于页图标
AGC 商店图标
宣传截图中的图标

完成后检查透明通道、前景安全区、浅色/深色桌面、安装界面和启动窗口。最终判断以打包后的真实渲染为准。

十三、文字直接放进图标要谨慎

AppScope 前景图中包含"时光清单"四个汉字。小尺寸桌面图标经过裁切、缩放和分层蒙版后,文字可能变得拥挤或难读。图标还需验证:

  • 文字是否进入系统安全区;
  • 圆角蒙版后是否裁断;
  • 深浅色桌面是否仍有足够对比;
  • 低分辨率显示是否糊成色块;
  • 是否与商店名称产生重复视觉负担。

这并不直接判定该设计不合格,而是说明必须用最终包在实际显示表面检查,不能只看 1024 像素原图。

十四、截图必须来自同一候选版本

当前设备范围只有 phone,因此截图至少要满足:

  • 来自最新候选包;
  • 不含调试菜单、测试账号、个人隐私数据;
  • 展示真实页面,不用概念稿替代;
  • 分辨率、比例和数量符合当前 AGC 要求;
  • 文案与界面版本一致;
  • 状态栏、导航栏和底部安全区完整;
  • 深浅色行为与应用实际策略一致。

建议覆盖首页、创建纪念日、记录详情、日记或习惯、桌面卡片预览等核心路径。若截图中出现尚未实现的按钮或云同步标志,会直接制造审核与用户预期风险。

十五、桌面卡片需要单独的发布证据

form_config.json 配置了 2×2、2×4、4×4 三种卡片规格,colorModeauto,并设置定时更新时间。复查时应分别确认:

  • 三种规格都能添加;
  • 空数据时有合理兜底;
  • 删除主记录后卡片不会显示幽灵数据;
  • 系统深浅色切换后文字可读;
  • 更新时间和商店描述一致;
  • 主应用卸载后卡片正确移除。

桌面卡片是公开能力,不应只靠主应用启动成功来代替验证。

十六、备份恢复需要验证边界与失败路径

备份开启后,至少检查:

  • 哪些 Preferences 或文件进入备份;
  • 数据模型升级后能否兼容旧备份;
  • 损坏或缺字段数据如何处理;
  • 恢复后首页、日记、习惯和卡片是否同步刷新;
  • 用户清除数据后是否仍有意外残留;
  • 隐私政策是否说明系统备份可能性。

备份成功不是只看接口返回。恢复后的页面状态、计数、排序和卡片内容都必须重新读取验证。

十七、release 包需要独立于 debug 验证

调试预览正常不能替代 release 候选包。正式包可能在签名、混淆、资源裁剪、权限、调试开关和构建变量上与 debug 不同。最小验证链路应是:

复制代码
clean release build
-> 记录包哈希
-> 解析包名/版本/设备/权限
-> 标准安装
-> 首次启动
-> 创建纪念日
-> 编辑并返回
-> 添加卡片
-> 重启验证持久化
-> 卸载

如果任一步未执行,就在记录中写"未执行",不要写"默认通过"。

十八、Guideline 3.1 要落到可观察结果

HarmonyOS 应用市场审核指南 3.1 关注兼容性和运行稳定性。对"时光清单"而言,至少要覆盖:

  • 冷启动无崩溃、白屏和长时间无响应;
  • 首次没有数据时仍可操作;
  • 日期边界、空标题和重复点击不会破坏状态;
  • 页面返回后数据即时刷新;
  • 系统深浅色和系统栏保持可读;
  • 卡片无数据、数据损坏时不崩溃;
  • 安装、更新安装和卸载均正常。

测试结论应记录设备、系统版本、包哈希、步骤和结果。只写"已测试"无法复核。

十九、Guideline 2.19 要检查行为而非口号

审核指南 2.19 的核心是不能滥用系统、网络或设备机制干扰正常体验。当前源码未见隐藏网络、悬浮窗、无障碍控制、强制跳转或后台拉活等实现,这是正向信号。正式复查仍要检查:

  • FormExtension 是否只在声明场景更新;
  • 是否有不透明的后台任务;
  • 是否存在未说明的跨应用调用;
  • 日志是否泄露用户记录;
  • 依赖是否包含动态加载或未披露行为;
  • 权限申请是否由明确用户动作触发。

"离线"不是豁免词。任何系统能力都应有明确场景、透明界面和可撤销结果。

二十、深浅色与系统栏必须按候选包验证

EntryAbility 会根据配置更新系统栏主题,卡片配置又使用 colorMode: auto。因此发布截图和真机测试需要覆盖:

  • 系统浅色模式启动;
  • 系统深色模式启动;
  • 前后台切换;
  • 配置变化后的状态栏与导航栏;
  • 首页、弹窗、底部栏和卡片的文本对比度。

正文文字与背景建议达到 4.5:1,对关键图标和按钮至少检查 3:1。低对比灰字、透明遮罩和粉色背景上的浅色文字都应重点抽查。

二十一、AGC 表单只能复述已验证事实

AGC 中常见字段可以按证据来源分组:

字段 首要证据
包名、版本、设备 最终候选包解析结果
应用名称、图标 AppScope 与打包渲染
功能描述、更新说明 当前版本真实可达功能
权限、隐私标签 包权限、运行行为、存储与 SDK
登录要求 核心流程是否需要账号
费用、广告、内购 实际商业能力与 SDK
国家和地区 产品计划与合规范围
内容分级 实际内容和交互
截图 同一候选包真实界面

字段没有证据就先留待确认,不能为了让页面"看起来填满"而猜测。

二十二、离线应用的 AGC 填写边界

若最终包审计和断网测试继续确认无服务端依赖,可按真实情况描述:

  • 核心功能无需登录;
  • 不使用自建服务器同步;
  • 用户记录主要保存在本地;
  • 不含广告、支付、订阅和社交 UGC;
  • 使用系统 Photo Picker 选择内容;
  • 可能使用系统备份恢复机制;
  • 桌面卡片读取应用本地数据。

不能写成"不会处理任何数据",因为倒计时、日记、习惯、相册引用和心情本身就是用户数据。离线只说明处理位置,不等于没有数据处理。

二十三、上传完成后仍需重新绑定候选包

AGC 版本页可能保存多次上传记录。正确流程是:

  1. 上传候选包;
  2. 等待平台解析完成;
  3. 打开包选择区域;
  4. 按版本、时间、大小核对目标包;
  5. 选中目标包并保存;
  6. 离开页面后重新进入;
  7. 回读当前绑定包;
  8. 再继续材料和提交操作。

只看到"上传成功"提示不能证明版本已绑定新包。自动化记录也必须区分 uploadedbound

二十四、发布状态名称必须准确

建议统一状态词:

复制代码
source reviewed
release package built
package locally verified
package uploaded
version bound
materials saved
submitted
pre-reviewing
under review
rejected
approved
published

其中任何一步都不能自动推导下一步。尤其不能把"草稿保存""包上传""预审中"写成"已上架",也不能在没有公开 URL 时向腾讯文档填写发布链接。

二十五、当前工程的风险矩阵

优先级 风险 本次真实线索 发布动作
阻断 图标视觉不一致 AppScope 山水文字图,entry 蓝色四宫格 统一资源并验证打包渲染
候选包过旧 现有 HAP 时间早于本次复查 重新构建 release 候选包
设备范围误选 module 仅声明 phone AGC 与截图保持 phone
离线描述过度 源码未见网络,但未做包与运行审计 包解析、断网和流量复查
备份声明遗漏 allowToBackupRestore 为 true 核对备份范围与隐私文案
vendor 模板值 AppScope 为 example 发布前确认正式配置
卡片测试不足 三种规格且自动适配颜色 分规格、空态、深浅色验证

这张表描述的是发布前风险,不代表已经发生审核拒绝,也不代表修复已经完成。

二十六、可复用的发布证据模型

可以把复查结果保存成结构化对象:

复制代码
interface ReleaseReviewEvidence {
  bundleName: string
  versionName: string
  versionCode: number
  packageSha256: string
  packageBuiltAt: string
  deviceTypes: string[]
  permissions: string[]
  iconVariantMatched: boolean
  offlinePackageAuditPassed: boolean
  offlineRuntimeAuditPassed: boolean
  installLaunchSmokePassed: boolean
  agcPackageBound: boolean
  agcPackageReadBackPassed: boolean
  publicUrl?: string
}

布尔值只有在对应动作真实完成后才写 true。没有公开 URL 时保持空值,不生成占位链接。

二十七、提交前最终检查清单

  • 冻结源码版本和唯一候选包;
  • 从包内回读 com.jiaweikan.one8
  • 核对 versionName 与递增的 versionCode
  • 确认 AGC 当前 APP ID 对应正确应用;
  • 确认设备范围仅为 phone;
  • 统一 AppScope、entry、启动页和 AGC 图标;
  • 检查图标不依赖透明背景且小尺寸可读;
  • 截图全部来自同一候选包;
  • 功能描述逐项对应可达页面;
  • 解析最终包权限和运行依赖;
  • 断网完成核心流程并审计网络行为;
  • 隐私政策说明本地数据、Picker、卡片和系统备份;
  • 三种桌面卡片规格完成空态与深浅色验证;
  • release 包完成安装、启动、核心流、重启和卸载;
  • 上传后选择最新目标包并保存;
  • 重新进入 AGC 页面回读绑定结果;
  • 只有真实公开后才记录公开 URL。

二十八、参考官方资料

总结

"时光清单"的发布复查不能停在"包名和版本看起来没错"。源码已经给出了可验证的身份:com.jiaweikan.one81.0.01000000、phone、Stage 模型入口、桌面卡片和系统备份;定向扫描也没有发现网络权限、HTTP、Web、广告、统计或账号依赖。但旧 HAP 不能代表当前源码,离线结论还需要候选包与运行审计,AGC 字段也必须保存后回读。

更关键的是,本次目视检查确认 AppScope 山水文字图标与 entry 蓝色四宫格图标明显不一致。它应在构建正式候选包前先统一,然后再完成包解析、断网核心流、卡片测试、安装启动卸载以及 AGC 最新包绑定。发布质量来自这条证据链,而不是来自一个"提交成功"的按钮提示。

AI 辅助声明:本文由 AI 辅助整理结构与配图;包名、版本、设备声明、入口、卡片、备份配置、离线扫描边界、历史产物时间和图标差异均依据本地文件复核。release 构建、包解析、设备测试、AGC 绑定、审核与上架均未声称成功。

相关推荐
lilian2333 小时前
HarmonyOS 7 新特性(二十三)|hiprofiler + hidumper:跨堆内存分析
华为·harmonyos
嵌入之梦4 小时前
鸿蒙OS IoT设备开发之基础 —— 外设驱动
物联网·华为·harmonyos
贾伟康4 小时前
【时光清单|12】HarmonyOS ArkTS 单页复杂状态实战:拆分 Index 中的导航、弹层和编辑草稿
harmonyos·arkts·状态管理·arkui·navigation
用户0934077735145 小时前
HarmonyOS WPS Open SDK 实践:OpenFileRequest 打开链路与沙箱拷贝
android·typescript·harmonyos
木子雨廷6 小时前
第 01 天|心智模型:iOS/Flutter 开发者学鸿蒙,第一步该换什么思路?
harmonyos
lilian2336 小时前
HarmonyOS 7 新特性(二十一)|FAST Kit:自然排序与向量计算
华为·harmonyos
tsqtsqtsq03097 小时前
鸿蒙系统 Call Service Kit 功能详解与开发适配指南
华为·harmonyos
贾伟康7 小时前
【时光清单|17】HarmonyOS ArkTS 亮暗色与视觉令牌实战:集中颜色、间距和交互状态避免页面割裂
harmonyos·arkts·arkui·深色模式·设计系统
贾伟康8 小时前
【时光清单|15】HarmonyOS ArkTS 本地状态持久化实战:让保存、删除和页面返回后的数据即时一致
harmonyos·arkts·状态管理·preferences·arkdata