表盘推送

Wear OS 6 引入了一个新的 API，即“表盘推送”(Watch Face Push)，为更高级的表盘发布用例创造了机会。

确定何时使用表盘推送

表盘推送是 Wear OS 上的一个 API，允许开发者直接添加、更新或移除表盘。标准表盘开发不需要它。

与表盘推送一起使用的表盘必须使用表盘格式编写。这可以包括使用 Watch Face Studio 或任何其他生成使用表盘格式的表盘的工具设计的表盘。

虽然表盘推送 API 可以有多种用途，但下表应作为主要用例的指南

用例 推荐的解决方案 复杂程度
我想创建并发布单个表盘。 直接或通过 Watch Face Studio 等工具使用表盘格式，并将其发布到 Google Play。 低
我想创建一个手机应用，允许用户从精选的表盘合集中选择表盘，或者设计和自定义表盘，然后直接安装到他们的 Wear OS 手表上。 为手表和手机创建应用，并在手表上使用表盘推送 API。 高

目的

表盘推送 API 的典型用例是创建应用商店应用。通过此应用，用户可以在手机上从精选的表盘合集中选择表盘，并直接控制将这些表盘安装到他们连接的手表上。

注意事项

有关构建表盘的详细信息，请参阅表盘格式指南：使用表盘推送部署的表盘是常规的表盘格式表盘。

构建表盘时，请注意以下事项。

软件包名称

使用表盘推送安装的表盘必须符合以下约定

<app name>.watchfacepush.<watchface name>

…其中 <app name> 是调用表盘推送 API 的应用的软件包名称。

例如，对于软件包名称为 com.example.mymarketplace 的应用，以下是有效的表盘软件包名称

  • com.example.mymarketplace.watchfacepush.watchface1
  • com.example.mymarketplace.watchfacepush.watchface2
  • com.example.mymarketplace.watchfacepush.another_watchface

不符合此约定的表盘将被 API 拒绝。

软件包内容

APK 内容受到严格限制。需要注意确保表盘格式符合以下约束：从技术上讲，可以生成包含无害元数据文件和其他工件的表盘格式 APK，这些 APK 可能被 Google Play 接受，但无法通过表盘推送验证（见下文）。

每个表盘 APK 中只允许包含以下文件/路径

  • /AndroidManifest.xml
  • /resources.arsc
  • /res/**
  • /META-INF/**

此外，AndroidManifest.xml 文件中只允许使用以下标签

  • <manifest>
  • <uses-feature>
  • <uses-sdk>
  • <application>
  • <property>
  • <meta-data>

最后，软件包应指定至少为 33 的 minSdk，并且 <application> 标签应指定属性 android:hasCode="false"。

验证

与通过 Google Play 分发的常规表盘不同，表盘推送的检查（用于确保每个表盘格式良好且性能良好）由应用商店应用负责。

Google Play 使用以下验证检查来验证每个使用表盘推送的表盘的质量

  1. 通过表盘推送 API 安装或更新的所有表盘都必须通过表盘推送验证工具的检查。
  2. 只有官方验证工具才能用于生成供 API 使用的验证令牌。
  3. 所使用的验证工具在运行验证时必须是最新的。

  4. 无需重新验证未更改的 APK。令牌不会过期，即使所使用的验证工具版本已被取代。

    同时，我们建议您时不时地重新运行验证，因为验证器会定期更新。

运行验证器

要在表盘 APK 上运行验证器，请按照以下步骤操作

  1. 从 Google 的Maven 代码库获取验证器。

  2. 按如下方式运行该工具

    java -jar validator-push-cli-1.0.0-alpha02.jar \
    --apk_path=youwatchface.apk \
    --package_name=<your marketplace package name>

    如果成功，输出中将包含一个验证令牌，您在添加或更新表盘时必须将其提供给表盘推送 API。

    如果发生错误，输出中将包含有关哪个特定检查失败的详细信息。

    有关将验证器 CLI 工具集成到 Gradle 构建中的示例，请参阅 GitHub 上的表盘推送示例。

APK 大小

使用表盘推送的表盘应特别注意将 APK 大小保持在最小：表盘 APK 很可能通过蓝牙从手机应用传输到手表应用，这可能会很慢。

过大的 APK 可能需要相当长的时间传输，这既影响用户体验又消耗电池电量。

  • 使用合适的库，例如 pngquant，将图像文件大小保持在最小
    • 将其包含在您的表盘合集构建过程中
    • 检查图像尺寸是否适合其将要使用的比例。
    • 确保图像经过适当裁剪，以移除任何周围的背景。
  • 减小字体文件的大小

请参阅优化内存使用指南，了解关于将 APK 大小保持在最小的更多建议。

APK 签名

作为常规 APK，您的所有表盘都需要签名。为主应用使用不同的密钥，并为所有表盘使用不同的密钥。

架构

考虑系统的三个主要组件

  1. 基于云的存储：在典型的应用商店应用中，您的表盘在云端构建和存储，供用户使用。这些表盘是
    1. 预构建为常规表盘格式 APK
    2. 每个只包含一个基于表盘格式的表盘
    3. 已使用表盘推送验证过程进行验证，并与关联的验证令牌一起存储。
    4. 可供您的手机应用在需要时检索。
  2. 手机应用：手机应用是用户与您的系统互动的主要方式。它允许用户
    1. 浏览和搜索您的表盘目录
    2. 在手表上安装或替换表盘
  3. 手表应用：手表应用通常没有显著的用户界面。它主要是手机应用和表盘推送 API 之间的桥梁，具有以下功能
    1. 使用表盘推送 API 安装/更新或替换表盘
    2. 请求必要的权限并提示用户
    3. 提供默认表盘
    4. 提供最少的表盘缓存
  4. 手机-手表通信：手机和手表应用之间的通信对于整体体验的成功至关重要。使用 Wear OS 数据层 API，可实现
    1. 安装检测：使用 Capabilities 和 CapabilityClient，手机应用可以检测手表应用是否缺失，反之亦然。之后可以向 Play 商店启动 intent 来安装缺失的外形尺寸。
    2. 状态管理：使用 DataClient 或 MessageClient，手机可以与手表的当前状态保持同步，例如，确保手机知道设置了哪个表盘。
    3. APK 传输：使用 ChannelClient 或 MessageClient，可以将 APK 从手机发送到手表
    4. 远程调用：使用 MessageClient，手机可以指示手表调用表盘推送 API，例如安装表盘。

有关详细信息，请参阅数据层 API 指南。