Google Play多设备发布指南：模块化架构与审核避坑

Android 生态早已不局限于手机。用户正在客厅的 Android TV、车机上的 Android Auto 与 Automotive OS、手腕上的 Wear OS，以及逐渐兴起的 Android XR 空间里与应用交互。对开发者而言这是增长机会，但把应用发布到这些形态，需要在常规流程之外多做几件事。Google Play 团队在开发者关系工程师 Jan Kleiner 与 Play 信任与安全运营负责人 Faustine Liao 的分享中，给出了一套可操作的框架。

整体流程不变，但细节决定成败

从构建应用到在 Google Play 上线，主线仍是：准备应用、在 Play Console 创建商品详情、测试、上传并提交正式版、等待审核通过。多设备发布的差异不在流程本身，而在架构选择、轨道策略与审核合规这三个环节。

据两位讲者介绍，最大的分水岭出现在动手打开 Play Console 之前——你如何打包应用。

模块化架构：为什么单一 App Bundle 风险更高

发布多形态应用时，第一个架构决策是：做一个包含所有形态的统一 App Bundle，还是按形态拆分模块、分别生成 AAB。

讲者明确推荐模块化方案，并给了一个直观例子：假设应用同时支持手机与 Android TV，如果提交单个 App Bundle 到标准手机轨道，而 TV 部分未通过审核检查，整个发布都会被卡住——即便手机端本身没有问题，你也必须先修复 TV 的审核问题并重新提交，用户才能拿到更新。反之，若手机与 TV 各有独立模块与独立 AAB，TV 审核受阻时只影响 TV 发布，手机版本照常上线。

模块化本身有多种实现方式。讲者以一款同时支持手机与 Android Automotive OS 的有声书应用为例：顶层是每个形态一个 app 模块，用于隔离平台相关依赖；中间是功能模块，对应应用的独立功能块；再往下是数据模块；最底层是核心/公共模块，被其他模块频繁复用。项目 Gradle 配置中引入对应的多模块结构即可支撑这种组织方式。所有 app 模块与 bundle 继续沿用同一个包名（application ID）。

App Bundle（AAB）是 Google Play 自 2021 年起主推的发布格式，它把应用按设备配置（如屏幕密度、CPU 架构、语言）拆分成多个模块，由 Play 在分发时按用户设备动态组装 APK，从而减小下载体积。对多形态应用而言，AAB 的"按需分发"能力恰好可以配合形态拆分：每个 app 模块可独立生成自己的 AAB，各自携带对应的 manifest、资源与依赖，Play Console 会将它们视为同一包名下的不同发布单元。这也解释了为什么讲者强调所有 app 模块必须沿用同一 application ID——包名是 Play 识别"这是同一个应用"的唯一依据，形态拆分不能改变它。若把所有形态塞进一个 AAB，Play 无法在审核层面区分形态，任一形态的合规问题都会作用于整个发布。

轨道策略：哪些形态必须独立发布

模块化直接决定了 Play Console 中的轨道安排。标准手机轨道之外，Google Play 为 Android TV、Android XR 和 Android Automotive OS 提供专用形态轨道——你可以选择与手机一同发布，也可以走专用轨道。

有两个例外必须记住：Wear OS 只能使用专用的 Wear OS 轨道；Android Auto 本质上是手机应用投射到车机屏幕的延伸，唯一选择是标准手机轨道。

多轨道并行时，版本管理是关键。讲者建议把版本号前几位分配给形态标识，例如 01 代表手机、02 代表 Wear OS、03 代表 Android Automotive OS，其余位数留给应用版本。版本号长度建议至少七位，以避免 Play Console 中出现版本号冲突。

三层测试通道：在正式发布前跑通审核

形态适配需要充分测试，Google Play 提供内部测试、封闭测试和开放测试三条通道。使用专用形态轨道时，测试轨道还能与形态组合，获得更细粒度的控制。例如手机应用在标准轨道做封闭测试，Android TV 应用在专用 TV 轨道做另一组封闭测试，测试人群可以完全不同。

内部测试适合起步：最多可分发给 100 名测试者，且不会触发 Play 审核，因此可以快速在模拟器或真实电视、手表上验证体验，并获得一个可分享的专属链接。

封闭测试面向更广的测试人群，通过邮箱列表或 Google Groups 管理测试组，获取针对性反馈。开放测试则在 Google Play 上公开可见，任何人无需邀请即可加入，并可直接向开发者发送私密反馈。

讲者特别强调，封闭与开放测试会触发审核——这恰恰是优势：你可以在正式发布前就演练一遍审核流程，把潜在障碍提前清除。

审核关注什么：从通用质量到形态专属规则

审核的核心是应用质量。高质量应用为用户创造价值、体验愉悦、充分利用高端设备能力，并且在设计上保障安全。Google Play 发布了两套基础文档：适用于所有应用的核心应用质量指南，定义最低质量门槛；以及自适应应用质量指南，确保应用在不同形态、屏幕尺寸与显示模式下都有良好体验。此外还有各形态专属的质量指南，审核人员会在真机与模拟器上按这些标准实测。

Android TV 的三个高频拒审原因

一是缺少主屏横幅图。应用支持的每种语言都需要一张 320×180 像素、包含本地化文字标识的横幅图。二是 D-pad 导航与焦点支持不到位——多数电视用户通过遥控器的方向键交互，至少要支持最低限度的 D-pad 控制。三是 Android manifest 中缺少 leanback launcher intent filter，这个过滤器用于标识应用已适配 TV，也决定用户在主屏选中应用时启动哪个 Activity。

leanback launcher intent filter 是写在 AndroidManifest.xml 中 <activity> 节点下的一组 <intent-filter>，其 category 为 android.intent.category.LEANBACK_LAUNCHER。它的作用有两个：一是向 Play 与 TV 系统声明该应用具备电视端启动入口，缺少它应用不会出现在 TV 主屏；二是决定用户在主屏选中图标时启动哪个 Activity。与手机端的 LAUNCHER category 不同，TV 端要求 Activity 支持 D-pad 焦点导航，因此通常需要为电视单独声明一个入口 Activity，或复用已适配遥控器的 Activity。安卓 TV 应用还常配合 android.software.leanback 的 <uses-feature> 声明，标识应用为电视优化。

Android XR：性能与渲染是硬指标

面向 Android XR 头显与眼镜的应用，要重点关注性能、渲染与稳定性。使用 Jetpack XR SDK 构建的应用可用 Perfetto 做性能剖析，确认满足最低帧率要求；基于 Unity 等实时引擎的项目，则可用引擎内置的性能分析工具核对渲染要求。

车机：品类准入、截图规格与驾驶安全

Android Auto 与 Android Automotive OS 有一套独特的品类概念，只有特定品类允许发布到车机。如果提交的品类不受支持，或把仅处于 beta 的品类提交到开放测试或正式版，都会导致拒审。导航、兴趣点等品类已全面可用，任何开发者都可发布正式版；而 Android Auto 的通讯通话类等品类仍处 beta，只能发布到内部测试或封闭测试轨道，除非被对应的早期访问计划接纳。相关细节与申请入口在 Android for Cars 开发者指南中。

Android Automotive OS 的截图规格是另一个高频拒审点：至少两张竖屏、两张横屏截图，尺寸须符合规定。Android Automotive OS 模拟器可以直接截出符合要求的图片。

安全在车机场景优先级最高。不符合驾驶分心指南的应用会被拒审——例如视频类应用在车辆行驶中必须暂停播放且不可见。

Android Auto 的"品类"并非应用商店的分类标签，而是 Google 为车机场景设定的功能准入模型。由于驾驶场景对注意力占用极为敏感，Google 只允许导航、媒体、通讯、兴趣点等有限品类接入车机投射界面，且每个品类对应一套模板化 UI（如导航模板、媒体模板），开发者不能自由绘制界面。品类在 Play Console 提交时声明，审核会核对其与 Manifest 中的 Car App Library 声明、实际功能是否一致；若品类仍处于 beta，则只能出现在内部或封闭测试轨道。Android Automotive OS 则是直接运行在车机上的完整系统，应用为独立安装，不受投射模板限制，但仍须遵守驾驶分心指南，并按品类接受审核。

Wear OS：小圆屏适配与截图

Wear OS 应用常见拒审原因是未针对小尺寸圆形屏幕优化与排版。建议使用最新稳定版 Compose for Wear OS，避免内容在不同尺寸设备边缘被裁切，并确保可滚动内容出现滚动条。另一常见原因是缺少或使用了不准确的 Wear OS 截图——至少要提交一张展示应用运行在 Wear OS 设备上的截图，例如 Androidify 示例应用的商店截图就符合要求。

提交前的几条硬性提醒

• 登录凭据：应用若需要登录，必须在 Play Console 的 app access 部分提供可用的演示账号与有效凭据。审核人员无法登录就无法测试，会直接拒审。
• 截图要真实对应形态：支持 Wear OS 和 Android TV，就为这些形态分别上传高质量截图，不要拿手机截图充数。
• 描述要具体：清楚说明应用做什么、价值在哪，以及用户在各类型设备上安装后能期待什么。

小结

把应用带到用户所在的每一块屏幕，是实实在在的增长机会。模块化架构让各形态发布彼此隔离，专用轨道与版本号规划让多线并行可控，三层测试通道让审核风险提前暴露，而吃透各形态的质量指南则是通过审核的最短路径。这套组合拳的价值在于：把多设备发布从一次赌博，变成一套可预测的工程流程。