工具和性能

在 Google Play 上驾驭多设备质量,发布移动设备以外的应用

扬声器

关于

演讲简介

随着 Android 生态系统扩展到腕部、客厅、车辆和 XR,通过新屏幕触达用户的机会也在不断增加。不过,在 Wear OS、Android TV、Android Auto、Android Automotive OS 或 Android XR 上分发应用时,需要考虑测试、商品详情和应用审核方面的不同要求。

本课程将探讨如何针对非移动设备规格有效利用 Google Play 管理中心,从而帮助简化可预测的多设备发布流程。我们将介绍关键的分发决策,包括如何构建轨道策略和软件包名称、配置有针对性的测试轨道以及量身定制商品详情。您将获得有关设备外形规格应用质量指南的实用演示,以帮助您避免常见的审核陷阱,并更有信心地在 Google Play 上发布应用。

摘要

  • 模块化 app bundle 可将外形规格版本与移动应用隔离开来。如果外形规格审核失败,系统只会屏蔽该特定 bundle,而移动版本仍会按预期发布。
  • Play 管理中心轨道提供灵活的发布路径,但 Wear OS 和 Android Auto 除外。Wear OS 需要专用轨道,而 Android Auto 必须使用标准移动轨道。
  • 内部测试轨道可将 build 分发给最多 100 名测试人员,而不会触发 Play 审核。封闭式和开放式测试轨道会触发审核,帮助您在发布前解决问题。
  • 外形规格审核遭拒通常是因为未满足设备要求,例如超出汽车应用类别限制或缺少屏幕截图。如果您的应用需要登录,请在 Play 管理中心内提供有效的演示账号凭证。

资源

Gemini Notebook

主题

  • google-play
  • 多设备
  • android-tv
  • android-auto
  • wear-os
  • android-xr
  • app-quality

转写文稿

简介

  • 欢迎大家。

  • 非常感谢大家参加本次研讨会,了解如何提升多设备应用质量,以及如何在 Google Play 上发布适用于移动设备以外其他设备规格的应用。

  • 我是 Jan Kleinert,Android for Cars 团队的开发技术推广工程师。

  • 我是 Faustine Liao,Google Play 信任与安全团队的运营主管。

  • 很高兴今天能和大家相聚在这里。

  • 多年来,当我们提到 Android 开发时,大多数人脑海中浮现的都是移动设备,但 Android 生态系统早已超越了智能手机的范畴。

  • 如今,用户可以在客厅通过 Android TV 与应用互动,也可以在拼车排队或给汽车充电时通过 Android Auto 或 Automotive OS 与应用互动,还可以在手腕上通过 Wear OS 与应用互动,甚至越来越多地通过 Android XR 在沉浸式 3D 空间中与应用互动。

  • 这是一个巨大的增长机会,但扩展到这些设备规格意味着您在发布策略中需要考虑一些细微事项。

  • 从构建应用到在 Google Play 上发布和上架的整个流程与您习惯的移动版本发布流程基本相同。

  • 构建并准备好应用,然后在 Play 管理中心内创建商品详情、测试应用、上传并提交正式版,最后等待审核和批准。

  • 不过,在发布适用于移动设备以外设备类型的应用时,有一些独特的注意事项。

  • 今天,我们将为您提供一个清晰的框架,帮助您为更顺畅、更可预测的多设备发布流程做好准备。

  • 我们先从基础知识开始:如何设计和打包应用。

应用架构和打包

  • 因此,在您开始使用 Google Play 管理中心之前,您需要做出一个重要的架构决策。

  • 您是构建一个包含所有支持设备类型所需内容的单一、统一 app bundle,还是将应用拆分为针对特定设备类型的模块,并为每个模块生成 Android App Bundle (AAB)?

  • 因此,我所说的模块或模块化,只是指一种行之有效的代码库构建方法,可帮助改善可维护性。

  • 模块化有许多方法,但一般来说,您要做的是将代码库整理成松散耦合、独立的部分,其中每个部分都是一个模块。

  • 因此,虽然统一的 Android App Bundle 方法可能听起来更易于管理,但我们实际上建议采用模块化方法。

  • 以下示例说明了我们为何建议采用这种模块化方法。

  • 假设您有一款应用,同时支持移动设备和 Android TV。

  • 如果您在标准移动发布轨道上提交单个 Android app bundle,而您的 Android TV 应用未通过审核检查,则整个发布流程都会停止。

  • 因此,这会同时影响 Android TV 应用和移动应用的发布。

  • 因此,即使您的移动应用本身没有问题,您也需要解决导致 Android TV 审核失败的问题,并重新提交应用进行审核,然后才能向用户发布该版本。

  • 另一方面,针对每种设备规格的模块化 Android App Bundle 可让您进行更精细的控制,并帮助您将这些设备规格的版本与移动版本隔离开来。

  • 因此,如果您有单独的移动应用模块和电视应用模块,则可以为每个模块生成单独的 Android App Bundle。

  • 如果您的电视应用在审核过程中出现问题,那么只有该应用的发布会被阻止,直到您解决问题为止。

  • 移动应用的版本将按预期发布。

  • 正如我之前提到的,模块化有许多方法。

  • 下面是一个示例,展示了如何对具有移动体验和 Android Automotive OS 体验的有声读物应用进行模块化。

  • 在顶部,我们用绿色标出了每个设备规格的应用模块,这有助于分离特定于平台的依赖项。

  • 然后,黄色部分是功能模块,对应于应用功能的独立部分。

  • 数据模块为蓝色,底部是核心模块或通用模块,通常用于包含其他模块经常使用的代码。

  • 然后,在项目的 Gradle 设置文件中,您可以添加并设置此多模块 Gradle 配置,以支持这种模块化。

    ...
    
    rootProject.name = "MultiFormFactorApp"
    
    // Define modules for each form factor
    include(":app:automotive")
    include(":app:mobile")
    include(":core:network")
    include(":data:books")
    include(":data:reviews")
    include(":feature:home")
    include(":feature:player")
    include(":feature:reviews")
  • 因此,您需要为每个应用模块和 app bundle 继续使用相同的软件包名称或应用 ID。

在 Google Play 管理中心内跟踪策略

  • 这种模块化方法与您在 Play 管理中心内的轨道策略直接相关。

  • 发布应用时,您可以使用标准移动轨道,但我们也提供专用设备规格轨道。

  • 对于 Android TV、Android XR 和 Android Automotive OS,您可以选择。

  • 您可以与移动应用一起发布,也可以使用其专用的设备类型轨道。

  • 不过,有两种例外情况。

  • 对于 Wear OS,您必须使用专用的 Wear OS 轨道。

  • 对于 Android Auto,由于它本质上是投射到车载屏幕上的移动应用扩展,因此唯一的选择是标准移动轨道。

  • 如果您要管理多个轨道,版本控制至关重要。

  • 一种方法是将版本代码的前几位数字分配给设备规格。

  • 例如,01 表示移动设备,02 表示 Wear OS,03 表示 Android Automotive OS,以此类推。

  • 我们通常建议您将版本代码设置为至少 7 位数,以便将剩余的位数用于应用版本。

  • 这有助于防止 Play 管理中心内出现版本代码冲突。

  • 应用打包完成后,就可以开始测试了。

  • 针对不同设备规格开发应用需要进行全面测试,Google Play 为您提供了三种不同的渠道,让您可以在发布正式版之前进行测试:内部测试、封闭式测试和开放式测试。

  • 如果您使用的是专用设备类型轨道,还可以将这些测试轨道与设备类型结合使用,从而更精细地控制测试流程。

  • 例如,您可以为移动应用在标准轨道上发布封闭式测试版本,并为 Android TV 应用在专用 Android TV 设备规格轨道上发布单独的封闭式测试版本,并根据需要为这两个版本设置不同的测试人员。

  • 因此,内部测试是一个很好的起点。

  • 您可以快速将应用分发给最多 100 名测试人员,而且最重要的是,这不会触发 Play 审核。

  • 因此,您和您的测试人员可以在设备上快速安装应用,并在模拟器或真实的电视、手表或其他设备上验证体验。

  • 进行内部测试时,您会获得一个可与测试人员分享的唯一网址。

  • 如果您对内部测试的结果感到满意,就可以进入封闭式测试和开放式测试阶段。

  • 您可以通过封闭式测试版本扩大测试范围,让更多测试人员测试应用的预发布版本,从而收集有针对性的反馈。

  • 您可以通过邮箱名单或 Google 群组来管理封闭式测试群组。

  • 而开放式测试则可帮助您在 Google Play 上进行更大范围的测试。

  • 您的应用将在 Google Play 上显示,任何人都可以加入开放式测试计划。

  • 无需邀请,他们就可以与您分享有关应用的反馈和私密反馈。

  • 这些开放式和封闭式测试轨道会触发审核。

  • 这其实是一个巨大的优势。

  • 这样,您就可以测试审核流程本身,并在备受期待的发布日之前扫清所有障碍。

应用质量和审核流程

  • 说到审核流程,我们来简单介绍一下该流程涉及的内容及其重要性。

  • 这些政策和指南的核心在于应用质量。

  • 因此,优质的应用和游戏能为用户带来价值、提供愉悦的使用体验、充分发挥高端设备的优势,还能在设计层面保障用户的安全。

  • 因此,我们来看看如何准备应用,以便尽可能轻松地通过审核。

  • 我认为,最好先查看应用质量指南,其中重点介绍了出色的用户体验是什么样的。

  • 我们发布了适用于所有应用的核心应用质量指南,其中定义了所有应用都应达到的最低质量标准,以及自适应应用质量指南,这些指南将帮助您确保应用在任何设备规格、屏幕尺寸或显示模式下都能提供出色的体验。

  • 这两套准则结合起来,是一个非常好的切入点。

  • 但我们也针对每种设备类型制定了特定于设备类型的应用质量指南。

  • 我们的审核人员将根据这些指南,在真实设备和模拟器上测试您的应用。

  • 因此,请务必确保您的应用遵守这些政策。

  • 接下来,我们快速了解一下应用在各种设备规格上被拒的最常见原因。

  • 但请注意,这些示例并未涵盖所有应用质量指南。

  • 因此,请务必详细查看您所使用的每种设备规格的质量指南,了解更全面的标准。

Android TV 应用质量指南

  • 我们先从 Android TV 开始。

  • 因此,在这些章节幻灯片的底部,您会看到一个短链接,点击该链接即可前往相应设备外形规格的应用质量指南完整列表。

  • Android TV 应用被拒的一个常见原因是,应用缺少针对其支持的每种语言的主屏幕横幅图片。

  • 因此,您应该提供一张 320x180 像素的图片,其中包含用于标识应用的本地化文字。

  • 此幻灯片上的图片展示了一个符合这些标准的主屏幕横幅示例。

  • 其次,在大多数电视上,用户将使用方向键遥控器与设备互动。

  • 因此,正确支持方向键导航和焦点至关重要。

  • 请确保您至少支持最低限度的方向键控制,以免因不符合这些标准而被拒。

  • Android TV 应用被拒的第三个常见原因是,Android 清单文件中缺少 CATEGORY_LEANBACK_LAUNCHER intent 过滤器。

    <application ...>
    ...
    <activity
        android:name="com.example.TvActivity"
        android:label="@string/app_name"
        android:theme="@style/Theme.Leanback">
        <intent-filter>
          <action android:name=
               "android.intent.action.MAIN" />
          <category android:name=
               "Android.intent.category.
                LEANBACK_LAUNCHER" />
        </intent-filter>
      </activity>
    </application>
  • 此过滤器会将您的应用标识为已启用电视功能,并让 Google Play 也将其标识为电视应用,以便用户了解。

  • 这样,当用户在电视主屏幕上选择您的应用时,此 intent 就会识别要启动哪个 activity。

  • 因此,请确保您已在清单中添加该权限。

  • Android XR 紧随其后。

  • 在为搭载 Android XR 的 XR 头戴设备或 XR 眼镜开发应用时,请特别注意应用的性能、渲染和稳定性。

  • 您可以使用 Perfetto 剖析使用 Jetpack XR SDK 构建的应用的性能,以确保应用符合最低帧速率要求。

  • 如果您使用的是 Unity 等实时引擎,则可以使用该引擎内置的性能分析工具,确保符合渲染要求。

Android Auto 和 Android Automotive OS 准则

  • 接下来是汽车,包括 Android Auto 和 Android Automotive OS。

  • 对于 Android Auto 和 Android Automotive OS,有一个“类别”的概念,这对此特定设备规格来说有点独特。

  • 并且只有特定类别的应用才能发布到汽车上。

  • 因此,如果您将应用提交到我们不支持的类别,或者将应用提交到仅处于 Beta 版阶段的类别的开放式测试轨道或正式版轨道,都会导致应用被拒。

  • 下面我来详细说明一下。

  • 在这里,您可以看到每个平台上的汽车支持的应用类别概览,以及这些应用的可用性。

  • 因此,无论它是处于 Beta 版、公开版(即正式版),还是尚不支持(此处显示为“敬请期待”),

  • 因此,导航或地图注点应用等一些类别已正式版,这意味着任何人都可以将这些类别中的应用发布到汽车正式版。

  • 但其他类别(例如 Android Auto 通话应用)仍处于 Beta 版阶段。

  • 因此,对于这些类别,您可以发布到内部测试轨道或封闭式测试轨道,但除非您已获准加入我们针对该类别的抢先体验计划,否则无法发布到正式版轨道。

  • 如需详细了解此功能及其他功能,请参阅我们的 Android for Cars 开发者指南。

  • 您可以在该页面中找到相关链接,以便自荐加入这些抢先体验计划。

  • Android Automotive OS 屏幕截图缺少或不符合规格,也是应用被拒的常见原因。

  • 因此,在提供 Android Automotive OS 屏幕截图时,您需要确保至少包含两张纵向屏幕截图和两张横向屏幕截图,且尺寸符合此处列出的要求。

  • 您可以使用 Android Automotive OS 模拟器来帮助您截取这些屏幕截图。

  • 该工具经过专门设置,可以截取您需要的尺寸恰到好处的屏幕截图。

  • 最后,对于车载应用来说,安全性至关重要。

  • 因此,如果您的应用不符合我们的驾驶员分心指南,将会被拒绝。

  • 例如,视频应用必须在车辆行驶时暂停播放,并且不能显示。

Wear OS 应用质量指南

  • 最后,我们来介绍一下 Wear OS。

  • 因此,如果 Wear OS 应用未针对小型圆形显示屏进行优化和格式设置,可能会被拒绝。

  • 因此,我们建议使用最新稳定版 Compose for Wear OS,以确保内容不会在不同尺寸的设备边缘被截断,或者确保在有可滚动内容时显示滚动条。

    @Composable
    fun MyText() {
      Text(
        text = stringResource(R.string.compose_for_wear_os),
        modifier = Modifier.fillMaxWidth(),
        textAlign = TextAlign.Center,
        style = MaterialTheme.typography.titleLarge
      )
    }
  • 与 Android Automotive OS 类似,Wear OS 应用也可能因缺少 Wear OS 屏幕截图或屏幕截图不准确而被拒。

  • 下面是一个很好的示例,展示了 Androidify 示例应用的 Google Play 商店商品详情中的屏幕截图,该屏幕截图符合相关要求。

  • 因此,请务必提交至少一张展示您的应用在 Wear OS 设备上运行的屏幕截图。

应用提交的重要提示

  • 要点总结:

  • 请阅读适用于您特定设备类型的应用质量指南,并在提交前对照这些指南进行测试。

  • 此外,还有一些重要提示。

  • 如果您的应用需要登录,您必须在 Play 管理中心的“应用访问权限”部分提供有效的演示账号和有效凭据。

  • 如果我们的审核人员无法登录,我们将无法测试您的应用,您的应用也会自动被拒。

  • 此外,请务必兑现承诺。

  • 不要只使用移动设备屏幕截图。

  • 如果您的应用适用于 Wear OS 和 Android TV,请务必在 Play 管理中心内上传针对这些特定设备规格的高画质屏幕截图。

  • 最后但同样重要的是,要提供描述性信息。

  • 请清楚描述应用的功能和价值,以及用户在每种类型的设备上安装应用后可以获得怎样的体验。

结论和总结

  • 最后总结一下,触达用户几乎无处不在的场景是一个绝佳的机会。通过采用模块化架构、利用内部测试进行快速迭代、遵循设备外形规格质量指南进行设计,以及优化商品详情,您将能够为应用做好准备,使其顺利通过发布和审核流程。

  • 非常感谢大家今天抽出宝贵时间。

  • 我们迫不及待地想看到您在 Google Play 上推出精彩的多设备体验。

代码

代码段

“应用架构和打包”中 04:12 处的 Kotlin 脚本代码段
...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")
“Android TV 应用质量指南”中 10:02 处的 XML 代码段
<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>
“Wear OS 应用质量指南”中 13:22 处的 Kotlin 代码段
@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}