Additional explorations with Watch Face Push

Posted by Garan Jenkin – Developer Relations Engineer

This put up is a part of Put on OS Highlight Week. At the moment, we’re exploring the great world of watch faces.

At Google I/O ‘25 we launched Watch Face Push, a brand new API geared toward enabling watch face marketplaces for watch and telephone. Watch Face Push is now out there to develop with and use on Put on OS 6 on units such because the recently-launched Pixel Watch 4.

On this weblog put up, we’ll present how Watch Face Push (WFP) can be utilized in a complete host of different methods, together with:

• Dynamically theming a watch face from a photograph
• Presenting wealthy knowledge or pictures from on-line or related knowledge sources
• Complementing a telephone app to drive engagement

The primary instance we’ll concentrate on is constructing a watch face with an accompanying telephone app. It will possibly apply a colour theme based mostly on a photograph taken on the telephone – excellent for matching your watch face to your outfit! And it’s excellent for demonstrating how Watch Face Push permits builders to carry dynamic knowledge to the watch face.

Let’s undergo among the predominant methods which mix collectively to make this doable:

The default watch face – bringing elements collectively

A robust characteristic of Watch Face Push is the default watch face characteristic. This enables the developer to supply a watch face that’s put in onto the Put on OS machine similtaneously the general app. This watch face is bundled as an APK and positioned within the property listing within the app.

The system checks for the presence of this APK because the app is being put in, and it checks for the validation key within the app’s manifest.

This allows you to ship a single package deal that comprises each the watch face and app elements, whether or not that’s a full Put on OS app, the place the app is the first focus, or app elements reminiscent of complication suppliers, the place the watch face is the first focus.

In our venture construction, we outline two modules, put on and watchface. By utilizing a unified versionCode throughout each, we are able to hold the app and watch face variations in sync. We use Gradle to construct the watch face and generate the validation token. This makes it straightforward to deal with the watch face and the app as a part of the identical venture.

Complication knowledge sources – pipelines for knowledge

Now that we’ve efficiently equipped each watch face and app elements collectively, we’d like a method to supply knowledge.

The watch face is now in a position to depend on the presence of complication knowledge sources offered by the app. For instance, a browsing watch face might bundle with a water temperature complication. This may be set because the default on the watch face utilizing DefaultProviderPolicy and is assured to be current.

Taking it a step additional, we are able to configure the complication to be non-customizable, in order that the complication turns into extra of a customized knowledge supply. We will then use the complication nonetheless the watch face may have:

<ComplicationSlot isCustomizable="FALSE" ... >
    <DefaultProviderPolicy
        defaultSystemProvider="NEXT_EVENT"
        defaultSystemProviderType="SHORT_TEXT"
        primaryProvider=""
        primaryProviderType="SHORT_TEXT" />

   

ComplicationSlot>

Within the case of our watch face, we outline a SHORT_TEXT complication service PaletteComplicationService, which sends the next knowledge:

TEXT: <area-delimited record of RGB hex values>
TITLE: CONFIGURED | NOT_CONFIGURED

By utilizing two of the fields on SHORT_TEXT, we’re in a position to ship our colour palette to the watch face, together with an indicator of whether or not the app has been configured (extra on why that’s vital later).

Extracting and manipulating complication knowledge

We’ve demonstrated how utilizing the assured presence of the PaletteComplicationService permits us to make sure the watch face can obtain our knowledge, however we nonetheless have to outline use and present the info inside watch face parts.

Inside the ComplicationSlot component on the watch face, these knowledge gadgets may be accessed as COMPLICATION.TEXT and COMPLICATION.TITLE respectively. The varied features reminiscent of abs() and subText() can be utilized to extract components of those strings, or convert them into numeric varieties.

We mix this with using REFERENCE to outline colours. We will retrieve these colours in every single place on the watch, together with outdoors of the ComplicationSlot:

<ComplicationSlot ...
    isCustomizable="FALSE"
    x="0" y="0" width="1" top="1">
  <DefaultProviderPolicy
      defaultSystemProvider="NEXT_EVENT"
      defaultSystemProviderType="SHORT_TEXT"
    primaryProvider="com.instance.palette/com.instance.palette.complication.PaletteComplicationService"
      primaryProviderType="SHORT_TEXT" />
  <BoundingBox top="1" width="1" x="0" y="0" />
  <Complication> 

    
    <PartDraw x="0" y="0" width="1" top="1">
      <Remodel goal="tintColor" worth="extractColorFromColors([COMPLICATION.TEXT], false, 0.0)" />
      <Reference supply="tintColor" defaultValue="#000000" identify="primary_color" />
      <Line startX="0" startY="0" endX="1" endY="1">
        <Stroke colour="#000000" thickness="1" />
      Line>
    PartDraw>

    ...
  Complication>
ComplicationSlot>

This snippet illustrates creating a really small ComplicationSlot, which can merely function a pipeline for our knowledge:

Inside the complication, a placeholder PartDraw is created, and the extractColorFromColors() perform is used to remodel the PartDraw to the primary colour equipped by the complication. Utilizing the Reference component, this colour worth is then out there to the remainder of the watch face as [REFERENCE.primary_color].

Within the full instance, two extra PartDraw parts are used to supply the secondary_color and tertiary_color, merely offering the 0.5 and 1.0 index to the extractColorFromColors perform as an alternative of the 0.0 worth.

A few of the samples illustrate how one can share completely different knowledge varieties past simply colours, reminiscent of numeric values.

Referencing complication knowledge within the watch face

The primary_color, secondary_color and tertiary_color values can now be used elsewhere on the watch face, each in expressions and in transforms. In our instance, we use the colours on the watch face fingers:

<HourHand useful resource="hour" x="210" y="75" width="30" top="180" pivotX="0.5"
    pivotY="0.8333" tintColor="[REFERENCE.primary_color]">
HourHand>

// Comparable logic for the minute hand and second hand would discuss with
// secondary_color and tertiary_color, respectively.

Conserving the watch face package deal updated

A problem with the default watch face strategy is that if the app is up to date, the watch face doesn’t robotically get up to date with it, even when the brand new app bundle comprises an up to date watch face. To deal with that difficulty, the app makes use of a BroadcastReceiver to obtain the MY_PACKAGE_REPLACED motion. On receiving this, the app can then examine whether or not the watch face is put in and is in want of an improve, utilizing Watch Face Push to carry out the improve if needed.

For the MY_PACKAGE_REPLACED motion to be obtained, the app will need to have been run no less than as soon as. Because of this, the pattern watch faces embrace an instance of guaranteeing the person launches the app: A “launch app” button is proven on the watch face if the app has not been launched earlier than. That is achieved through the use of a Situation on the CONFIGURED or NOT_CONFIGURED standing described earlier.

For a lot of watch faces, this has a further function: it permits the person to allow extra elements, reminiscent of a photograph downloader within the Picture Album instance proven right here. You can even use the “first launch” expertise to immediate the person to grant permissions or to sign up.

Working with different app elements

Whereas the complication knowledge supply is the conduit for knowledge, and is the frequent part in all of the examples, the next Android APIs work with problems to attain the specified performance:

• WearableListenerService – each the PaletteWatchFace and the FootballWatchFace have telephone companion apps, and the Knowledge Layer is used to ship knowledge to the watch. As soon as obtained by the WearableListenerService, you possibly can proactively replace the info on the watch face utilizing ComplicationDataSourceUpdateRequester.
• WorkManager – the PhotoAlbumWatchFace instance demonstrates retrieve pictures from an internet photograph service. WorkManager is used for this, utilizing Constraints to solely obtain photographs whereas the machine is being charged.
• ForegroundService – the DeviceDataWatchFace illustrates utilizing a ForegroundService to acquire knowledge from a related Bluetooth machine which is then visualized on the watch face.

Try the full supply for these examples. We sit up for seeing what you possibly can create!