安卓 / 华为版上架记：一个人怎么伺候四个应用商店

App Store 一套、Google Play 一套、华为一套、侧载又一套。

同一个 App，我写了四套支付。

准确说是三套支付加一套「不支付」，但心累程度是四套。这篇把四条渠道的差异、代码怎么分叉不打架、各家的坑逐条写下来。华为的坑最多，占一半篇幅。

工具文，不抒情。

一、四条渠道，一张表

最后两行不是我大方，是技术现实：侧载包连不上任何商店结算，锁功能等于把用户关在门外。既然收不到钱，那就干脆当引流渠道用，全放开。

AppStore.isPro 在非收费渠道恒真。这带来一个顺手的好处：本地开发和自动化测试天然是解锁状态，不用为了测个功能去 mock 内购。

二、代码怎么分叉不打架

核心原则一句话：渠道判定收口到一个文件，支付分叉收口到一个文件，其余代码一律不知道自己跑在哪个商店里。

渠道判定：lib/services/store_channel.dart

整个文件就六十行，全是 getter：

abstract final class StoreChannel {  static const _store = String.fromEnvironment('STORE');  static bool get isGooglePlay =>      !kIsWeb &&      defaultTargetPlatform == TargetPlatform.android &&      _store == 'googleplay';  static bool get isHuawei =>      !kIsWeb &&      defaultTargetPlatform == TargetPlatform.android &&      _store == 'huawei';  /// 本包是否真实收费（付费墙生效 + 内购管线初始化）  static bool get billed => _isIOS || isGooglePlay || isHuawei;  static String get storeName => isGooglePlay      ? 'Google Play'      : isHuawei ? '华为应用市场' : 'App Store';  static String get accountName =>      isGooglePlay ? 'Google' : isHuawei ? '华为' : 'Apple';  /// 商店没连上时的占位价  static String get fallbackPrice => isGooglePlay ? 'US\$2.99' : '¥18';}

几个设计上的取舍，值得说：

渠道标记走 --dart-define，不走运行时探测。 判定条件是「Android 平台」且「构建期标记匹配」，缺一不可。理由：运行时探测（比如查有没有 HMS Core）会误判——装了 GMS 的老华为机、刷机的、模拟器，全是坑。构建期标记是死的，死的最可靠。

storeName 和 accountName 也在这里。 付费墙上要说「在 App Store 购买」还是「在华为应用市场购买」，「恢复购买」找不到记录时要提示用户检查「Apple 账号」还是「华为账号」。这些文案全部读这两个 getter，加渠道时只改这一处。

为什么独立成小文件：付费墙判定在 AppStore 里，内购管线在 PurchaseService 里，两边都要用渠道判定。抽出来，避免这俩互相 import 打成环。

支付管线：lib/services/purchase_service.dart

对外接口固定不变：init / buyPro / buySkill / restore / supported / proPrice。调用方永远只调这几个，不知道底下发生了什么。

内部按渠道分叉：华为走 huawei_iap 的 IapClient，iOS 和 Google Play 走官方 in_app_purchase 插件（这俩共用一套，是插件本身在底层分的）。

API 对应关系大致是这样：

最大的不同在于回调模型：in_app_purchase 是流式的，你监听 purchaseStream 等它推；HMS 是请求-响应的，你调完自己解析返回。所以华为分支多一个「冷启动对账」——启动时主动拉一次已购列表，落解锁态。

HMS 里 priceType：0 消耗型 / 1 非消耗型 / 2 订阅。我全是非消耗型，一律 priceType = 1。非消耗品别去调 consumeOwnedPurchase，那是消耗品的活，调了会出事。

构建：三个脚本

tool/build_play.sh      # flutter build appbundle --dart-define=STORE=googleplaytool/build_huawei.sh    # flutter build apk      --dart-define=STORE=huaweitool/build_release.sh   # web + Android APK，默认包，全功能免费

build_release.sh 里我做了件小事但很值：把构建号注入「设置 → 关于」页。局域网分发的时候，对方装完念一下那串号，我就知道他装的是不是最新包。没有这个，「你重装一下试试」这种对话能来回五轮。

build_huawei.sh 会在打包前检查 key.properties 和 agconnect-services.json 在不在。缺文件就报错，别等打完包上传了才发现支付初始化不了。

三、Google Play 的坑：一个，但很致命

Google Play 本身比国内商店简单得多——$25 一次性（不是年费），不要 ICP 备案，不要软著，个人可注册。

唯一的卡点是这个：

新个人开发者账号，生产发布前必须先跑封闭测试——至少 12 名测试者、连续 14 天。

这是 2023 年 11 月起的政策。不是建议，是硬门槛。

两个连锁后果：

一、安卓可用性天然晚于 iOS。 你 iOS 上架当天，安卓还在攒测试员。这个时间差是结构性的，规划的时候就得算进去。

二、宣传 CTA 必须分阶段。 我在内容规划里给自己定了条纪律：安卓/华为没正式放量前，绝对不喊「安卓可下」。喊早了，一堆人去搜搜不到，白白消耗信任。

现在的状态：【待填：Google Play 封测进度 / 是否已正式发布】。

其他几条顺手记一下：

• Google Play 只收 AAB，不收 APK。
• 签名走 Play App Signing——你用自己的 keystore 当 upload key 签 AAB，Google 托管最终签名密钥。
• 商品要关联付款资料之后才能激活。
• 有付费内购就触发欧盟 DSA「交易商」申报，个人申报要在欧盟商店页公开住址和电话。我的处理是初期直接把欧盟剔出销售范围。

四、华为的坑：一次说完

华为是四家里最费劲的，因为它的强制项不写在显眼处，你得被打回才知道。

4.1 支付必须换，没得商量

华为自 2019 年起的新机没有 GMS。Google Play Billing 初始化直接失败——不是报错，是付费墙永远打不开、商品永远拉不到。

所以必须换成 HMS IAP Kit。这不是「适配一下」，是接一套新的支付 SDK。

4.2 应用内版本更新检查，是上架强制项

这条是我被打回才知道的。

审核意见原文：

「请集成华为 HMS 版本更新（checkUpdate）。如已集成，可能是 HMS SDK 被混淆导致，请核对混淆配置。」

意思是：AppGallery 强制要求你集成「应用内版本更新」——出新版时，通过华为应用市场弹窗提示用户更新。不做不给过。

我的 release 没开混淆（isMinifyEnabled = false），所以不属于第二种情形，就是纯粹没集成。补法是在 MainActivity.onCreate 里接原生 HMS：

val client = JosApps.getAppUpdateClient(this)client.checkAppUpdate(this, object : CheckUpdateCallBack {    override fun onUpdateInfo(intent: Intent?) {        val info = intent?.getSerializableExtra(UpdateKey.INFO)        if (info is ApkUpgradeInfo)            client.showUpdateDialog(this@MainActivity, info, false)    }    // 其余回调空实现})

外层包 try/catch 兜底：非华为设备、无 HMS Core 时静默忽略，不影响启动。

渠道开关用 BuildConfig.IS_HUAWEI，由 --dart-define=STORE=huawei 注入，只有华为包为 true。

如果你将来开 R8 混淆，记得加 -keep class com.huawei.** { *; }，否则就会命中审核意见里说的第二种情形——集成了但被混淆掉，一样被打回。

4.3 AGC 拒收 debug 签名

必须用正式签名 keystore。debug 包传上去直接被挡。

顺带：release keystore 的 SHA-256 指纹要填进 AGC「项目设置 → 常规」，否则 IAP 鉴权失败。

再顺带一句血泪提醒：keystore 丢了，这个包名就永远无法更新。我的 keystore 和口令文件都 gitignore 了，另外在两个地方做了备份。这不是谨慎，这是及格线。

4.4 SkuId 一经创建永久不可改

这条在三家都成立，但华为的后果最直接：SkuId 和代码常量对不上，真机上就是拉不到商品，购买按钮点了提示「稍后再试」，你还以为是网络问题。

建商品前，把代码里的常量复制出来，逐字对。

4.5 商品创建后必须「激活」

创建 ≠ 生效。商品建完不激活，购买接口直接报「商品不存在」。

这条我觉得是华为后台交互的问题，但骂它没用，记住就行。

4.6 agconnect-services.json 必须就位

从 AGC 后台下载，放进 android/app/。里面的 package_name 必须和你的 applicationId 一致，否则 AGConnect 编译期校验就过不去。

这文件含密钥，别入库。

4.7 沙盒测试只能在无 GMS 的华为真机上做

本地测不了，模拟器测不了，非华为设备测不了。

流程是：AGC 加沙盒测试账号 → 出正式签名的 STORE=huawei 包 → 上传到 AGC 版本轨道 → 真机登录沙盒账号 → 走购买、恢复购买、卸载重装恢复三条。

没有华为真机就别接华为渠道，你连验都验不了。

4.8 鸿蒙是另一条路

这个要分清楚：

所以「华为版」目前覆盖的是前者——存量装机大头。纯血鸿蒙要出 .hap，Flutter 得走 flutter_ohos 分支、用 DevEco Studio 打包，连 IAP 都要换鸿蒙原生 kit。

那是 独立的一条工作量线，不是加个编译开关。我 V1 不做。

五、商品 ID 命名规范

全渠道同名 SkuId。 这是我做得最对的一个决定。

top.chihaofan.app.pro              进阶版top.chihaofan.app.skill.<id>       技能top.chihaofan.app.outfit.<id>      皮肤

三家后台建同名商品，代码里一套常量，判断解锁态时按前缀匹配就行，不用为每家维护一张映射表。

9 个内购商品，全部非消耗型：

价格档：国内 ¥18 / ¥6，Google Play 走 $2.99 / $0.99。

另有 2 个免费技能（节气食养官、剩菜改造师），不走内购，不需要在任何后台建商品。

顺带说明：涉及减脂、控糖、孕期、慢病的技能，全部是饮食建议，不是医疗建议。这句话在 App 里和商品描述里都有。

六、我欠的两笔债

一、HMS 的 SDK 现在打进了所有安卓包。

huawei_iap 和 AppGallery 的 appservice SDK，目前编进了每一个安卓产物，包括要传 Google Play 的那个 AAB。Play 包里它们休眠不调，功能上没问题。

但这是偷懒。规范做法是用 product flavor 把 HMS 从 Play 包里排除掉——Google Play 对「非 Play 的更新机制」是有政策风险的，哪怕你不调。

这笔债我记着，还没还。

二、我把安卓包名改了两次。

第一次是 iOS 那边 com.chihaofan.app 撞车，被迫改成 top.chihaofan.app。第二次是发现安卓这边没跟着改，跟华为 AGC 里注册的包名对不上，又改一次。

纯属自己没规划好。如果我一开始就把「iOS / Google Play / 华为 / 侧载 / 未来的鸿蒙原生」这五个产物的标识符列成一张表，一次定死，就不会有第二次。

所以下面这张表，是我用两次返工换来的：

七、给后来者的 checklist

动工之前

• 把所有渠道的产物列成一张表，标识符一次定死
• 确认每条渠道你都有对应的真机（华为渠道尤其，没真机验不了）
• Google Play 的 12 人 / 14 天封测尽早启动，它是关键路径上最长的一段

代码结构

• 渠道判定收口到一个文件，走构建期 --dart-define，不做运行时探测
• 支付管线对外接口保持一致，差异全部收在内部
• 面向用户的商店名 / 账号名文案统一读渠道 getter
• 商店连不上时有占位价，别让付费墙空着
• 每条渠道一个构建脚本，脚本里检查必需文件是否就位
• 构建号注入 App 内可见处（分发时能确认版本）

商品

• 全渠道同名 SkuId，前缀规范化
• 建商品前逐字核对代码常量（建后永久不可改）
• 华为：商品建完记得激活
• Google Play：关联付款资料后商品才能激活
• 免费内容不建商品

华为专项

• agconnect-services.json 放进 android/app/，package_name 对上
• release keystore 的 SHA-256 指纹填进 AGC
• 集成 checkAppUpdate（强制项）
• 若开混淆，-keep class com.huawei.** { *; }
• 正式签名打包，AGC 拒收 debug

验收（每条收费渠道都要跑）

• 购买 → 立即解锁
• 卸载重装 → 恢复购买 → 解锁态回来
• 付费墙文案显示的是对的商店名和账号名
• 侧载包依旧全功能免费、设置页不出现付费卡片
• 解锁态不进导出/同步数据（防止同步码变破解码）

写完发现，四条渠道里真正花时间的从来不是写代码。代码分叉那部分，加起来不到两百行。

费时间的是：等封测、等审核、找一台能测的真机、以及在四个后台里把同一个商品建四遍还不能建错。

一个人做这件事，最大的技能不是编程，是 把重复的事情整理成表格。

吃好饭 iOS 已上架，App Store 搜「吃好饭 AI冰箱」。这个系列会一直写下去，欢迎在留言区骂我。