Posted by Garan Jenkin – Developer Relations Engineer

A few months ago we relaunched Androidify as an app for generating personalized Android bots. Androidify transforms your selfie photo into a playful Android bot using Gemini and Imagen.

However, given that Android spans multiple form factors, including our most recent addition, XR, we thought, how could we bring the fun of Androidify to Wear OS?

An Androidify watch face

As Androidify bots are highly-personalized, the natural place to showcase them is the watch face. Not only is it the most frequently visible surface but also the most personal surface, allowing you to represent who you are.

Personalized Androidify watch face, generated from selfie image

Androidify now has the ability to generate a watch face dynamically within the phone app and then send it to your watch, where it will automatically be set as your watch face. All of this happens within seconds!

High-level design

End-to-end flow for watch face creation and installation

In order to achieve the end-to-end experience, a number of technologies need to be combined together, as shown in this high-level design diagram.

First of all, the user’s avatar is combined with a pre-existing Watch Face Format template, which is then packaged into an APK. This is validated – for reasons which will be explained! – and sent to the watch.

On being received by the watch, the new Watch Face Push API – part of Wear OS 6- is used to install and activate the watch face.

Let’s explore the details:

Creating the watch face templates

The watch face is created from a template, itself designed in Watch Face Designer. This is our new Figma plugin that allows you to create Watch Face Format watch faces directly within Figma.

An Androidify watch face template in Watch Face Designer

The plugin allows the watch face to be exported in a range of different ways, including as Watch Face Format (WFF) resources. These can then be easily incorporated as assets within the Androidify app, for dynamically building the finalized watch face.

Packaging and validation

Once the template and avatar have been combined, the Portable Asset Compiler Kit (Pack) is used to assemble an APK.

In Androidify, Pack is used as a native library on the phone. For more details on how Androidify interfaces with the Pack library, see the GitHub repository.

As a final step before transmission, the APK is checked by the Watch Face Push validator.

This validator checks that the APK is suitable for installation. This includes checking the contents of the APK to ensure it is a valid watch face, as well as some performance checks. If it is valid, then the validator produces a token.

This token is required by the watch for installation.

Sending the watch face

The Androidify app on Wear OS uses WearableListenerService to listen for events on the Wearable Data Layer.

The phone app transfers the watch face by using a combination of MessageClient to set up the process, then ChannelClient to stream the APK.

Installing the watch face on the watch

Once the watch face is received on the Wear OS device, the Androidify app uses the new Watch Face Push API to install the watch face:

Androidify uses either the addWatchFace or updateWatchFace method, depending on the scenario: Watch Face Push defines a concept of “slots” – how many watch faces a given app can have installed at any time. For Wear OS 6, this value is in fact 1.

Androidify’s approach is to install the watch face if there is a free slot, and if not, any existing watch face is swapped out for the new one.

Setting the active watch face

Installing the watch face programmatically is a great step, but Androidify seeks to ensure the watch face is also the active watch face. 

Watch Face Push introduces a new runtime permission which must be granted in order for apps to be able to achieve this:

com.google.wear.permission.SET_PUSHED_WATCH_FACE_AS_ACTIVE

Once this permission has been acquired, the wfpManager.setWatchFaceAsActive() method can be called, to set an installed watch face to being the active watch face.

However, there are a number of considerations that Androidify has to navigate:

• setWatchFaceAsActive can only be used once.

• SET_PUSHED_WATCH_FACE_AS_ACTIVE cannot be re-requested after being denied by the user.

• Androidify might already be in control of the active watch face.

For more details see how Androidify implements the set active logic.

Get started with Watch Face Push for Wear OS

Watch Face Push is a versatile API, equally suited to enhancing Androidify as it is to building fully-featured watch face marketplaces.

Perhaps you have an existing phone app and are looking for opportunities to further engage and delight your users?

Or perhaps you’re an existing watch face developer looking to create your own community and gallery through releasing a marketplace app?

Take a look at these resources:

• Watch Face Push

• Watch Face Format – Note also the upcoming policy changes relating to watch face publishing.

• Watch Face Designer

• Androidify GitHub repository

• Androidify Play Store listing

And also check out the accompanying video for a greater-depth look at how we brought Androidify to Wear OS!

We’re looking forward to what you’ll create with Watch Face Push!

Posted by Garan Jenkin – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring the wonderful world of watch faces.

At Google I/O ‘25 we launched Watch Face Push, a new API aimed at enabling watch face marketplaces for watch and phone. Watch Face Push is now available to develop with and use on Wear OS 6 on devices such as the recently-launched Pixel Watch 4.

In this blog post, we’ll show how Watch Face Push (WFP) can be used in a whole host of other ways, including:

• Dynamically theming a watch face from a photo
• Presenting rich data or photos from online or connected data sources
• Complementing a phone app to drive engagement

The first example we’ll focus on is building a watch face with an accompanying phone app. It can apply a color theme based on a photo taken on the phone – perfect for matching your watch face to your outfit! And it’s perfect for demonstrating how Watch Face Push allows developers to bring dynamic data to the watch face.

Let’s go through some of the main techniques which combine together to make this possible:

The default watch face – bringing components together

A powerful feature of Watch Face Push is the default watch face feature. This allows the developer to provide a watch face that’s installed onto the Wear OS device at the same time as the overall app. This watch face is bundled as an APK and placed in the assets directory in the app.

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

This enables you to deliver a single package that contains both the watch face and app components, whether that’s a full Wear OS app, where the app is the primary focus, or app components such as complication providers, where the watch face is the primary focus.

In our project structure, we define two modules, wear and watchface. By using a unified versionCode across both, we can keep the app and watch face versions in sync. We use Gradle to build the watch face and generate the validation token. This makes it easy to treat the watch face and the app as part of the same project.

Complication data sources – pipelines for data

Now that we’ve successfully supplied both watch face and app components together, we need a way to provide data.

The watch face is now able to rely on the presence of complication data sources provided by the app. For example, a surfing watch face could bundle with a water temperature complication. This can be set as the default on the watch face using DefaultProviderPolicy and is guaranteed to be present.

Taking it a step further, we can configure the complication to be non-customizable, so that the complication becomes more of a custom data source. We can then use the complication however the watch face may need:

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

   <!-- Rest of complication goes here -->

</ComplicationSlot>

In the case of our watch face, we define a SHORT_TEXT complication service PaletteComplicationService, which sends the following data:

TEXT: <space-delimited list of RGB hex values>
TITLE: CONFIGURED | NOT_CONFIGURED

By using two of the fields on SHORT_TEXT, we’re able to send our color palette to the watch face, along with an indicator of whether the app has been configured (more on why that is important later).

Extracting and manipulating complication data

We’ve demonstrated how using the guaranteed presence of the PaletteComplicationService allows us to ensure the watch face can receive our data, but we still need to define how to use and show the data within watch face elements.

Within the ComplicationSlot element on the watch face, these data items can be accessed as COMPLICATION.TEXT and COMPLICATION.TITLE respectively. The various functions such as abs() and subText() can be used to extract parts of these strings, or convert them into numeric types.

We combine this with the use of REFERENCE to define colors. We can retrieve these colors everywhere on the watch, including outside of the ComplicationSlot:

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

    <!-- Complication data source sends 3 RGB hex values, extract the first: -->
    <PartDraw x="0" y="0" width="1" height="1">
      <Transform target="tintColor" value="extractColorFromColors([COMPLICATION.TEXT], false, 0.0)" />
      <Reference source="tintColor" defaultValue="#000000" name="primary_color" />
      <Line startX="0" startY="0" endX="1" endY="1">
        <Stroke color="#000000" thickness="1" />
      </Line>
    </PartDraw>

    ...
  </Complication>
</ComplicationSlot>

This snippet illustrates creating a very small ComplicationSlot, which will simply serve as a pipeline for our data:

Within the complication, a placeholder PartDraw is created, and the extractColorFromColors() function is used to transform the PartDraw to the first color supplied by the complication. Using the Reference element, this color value is then available to the rest of the watch face as [REFERENCE.primary_color].

In the full example, two more PartDraw elements are used to provide the secondary_color and tertiary_color, simply providing the 0.5 and 1.0 index to the extractColorFromColors function instead of the 0.0 value.

Some of the samples illustrate how you can share different data types beyond just colors, such as numeric values.

Referencing complication data in the watch face

The primary_color, secondary_color and tertiary_color values can now be used elsewhere on the watch face, both in expressions and in transforms. In our example, we use the colors on the watch face hands:

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

// Similar logic for the minute hand and second hand would refer to
// secondary_color and tertiary_color, respectively.

Keeping the watch face package up to date

A challenge with the default watch face approach is that if the app is updated, the watch face doesn’t automatically get updated with it, even if the new app bundle contains an updated watch face. To address that issue, the app uses a BroadcastReceiver to receive the MY_PACKAGE_REPLACED action. On receiving this, the app can then check whether the watch face is installed and is in need of an upgrade, using Watch Face Push to perform the upgrade if necessary.

For the MY_PACKAGE_REPLACED action to be received, the app must have been run at least once. For this reason, the sample watch faces include an example of ensuring the user launches the app: A “launch app” button is shown on the watch face if the app has not been launched before. This is achieved by using a Condition on the CONFIGURED or NOT_CONFIGURED status described earlier.

For many watch faces, this has an additional purpose: it allows the user to enable additional components, such as a photo downloader in the Photo Album example shown here. You can also use the “first launch” experience to prompt the user to grant permissions or to sign in.

Working with other app components

While the complication data source is the conduit for data, and is the common component in all the examples, the following Android APIs work with complications to achieve the desired functionality:

• WearableListenerService – both the PaletteWatchFace and the FootballWatchFace have phone companion apps, and the Data Layer is used to send data to the watch. Once received by the WearableListenerService, you can proactively update the data on the watch face using ComplicationDataSourceUpdateRequester.
• WorkManager – the PhotoAlbumWatchFace example demonstrates how to retrieve photos from an online photo service. WorkManager is used for this, using Constraints to only download images while the device is being charged.
• ForegroundService – the DeviceDataWatchFace illustrates using a ForegroundService to obtain data from a connected Bluetooth device which is then visualized on the watch face.

Check out the full source for these examples. We look forward to seeing what you can create!

Posted by Anoushka Mazumdar – Product Manager, and Adam Soutar – Software Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring the wonderful world of watch faces.

Create simple no code watch faces or build complex ones quickly with this Figma plugin

We’re thrilled to introduce Watch Face Designer, a new design tool that can empower everyone, from seasoned designers to passionate enthusiasts, to craft watch faces directly in Figma. This Figma plugin works seamlessly on devices running Wear OS 4 or higher. Say goodbye to complex coding and hello to seamless design!

Watch Face Designer is built from the ground up to integrate with the Watch Face Format for Wear OS. It’s not only for designers looking to bring their visions to life without a single line of code; it’s also a powerful tool for developers who want to rapidly prototype and mock up watch faces before diving into more intricate functionality, such as animations, in Android Studio.

Design at the speed of thought with Watch Face Designer

This initial version of Watch Face Designer has plenty of features to kickstart your watch face design journey:

• Supports core Watch Face Format features: digital and analog time, interactive and ambient mode, custom fonts, complications, automatic theme creation from your Figma styles, and more.
• Intuitive plugin window: The plugin window provides a streamlined interface to preview your designs in real-time and effortlessly edit individual elements to support watch face functionality.
• Flexible export options: Once your design is complete, you can export your design in several ways:
• Direct to Play Store (recommended for designers): Publish your watch face directly to the Google Play Store.
• Export to Android Studio (recommended for developers) or Watch Face Studio: For developers or those seeking to add advanced functionality, seamlessly export your design to Android Studio or Watch Face Studio to build upon your foundation.
• View on device: See your watch face come to life on your actual Wear OS device for a true-to-life preview.

The Watch Face Designer UI displaying a list of export options

Get started today

Ready to start designing your next favorite watch face? Get started with the Watch Face Designer plugin. It can be found on the @androiddesign page on Figma’s Community tab. There you can also find our Playground file featuring sample watch faces, and handy complication templates. We’ve also included a comprehensive overview guide that walks you through the process, from concept to completion.

We can’t wait to see the incredible watch faces you’ll create with Watch Face Designer! Stay tuned for more updates and exciting new features coming soon.

Posted by Garan Jenkin – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re exploring how Amoledwatchfaces successfully migrated to Watch Face Format, improving customization, extending battery life, and increasing development speed.

Amoledwatchfaces is a leading creator of watch faces for Wear OS using the Watch Face Format (WFF), known for a distinctive information-rich and crisp style. Now well-established on the platform with over 190 watch faces, we talked to Tomáš Marcinčin, owner of Amoledwatchfaces about their successful migration using the format, and the benefits he’s seen in development velocity and performance as a result.

Creating high-quality watch faces without complex code

In previous years, developing watch faces “took a lot of time,” says Tomáš Marcinčin, owner of Amoledwatchfaces. The AndroidX libraries allowed developers to create watch faces, but Tomáš, like others, was left looking for an “easier way to create watch faces,” and crucially one that shifted the focus from coding and onto design.

“My main motivation was to bring users watch faces that are of the same quality as those that are pre-installed. Users were looking for designs that were not too complicated, yet customizable and looked as if they had been designed for that watch.”

Expressing interest in a customized experience

Like many creators, Tomáš started using Watch Face Studio, Samsung’s watch face creation tool, giving designers and developers an easy way to build watch faces for Wear OS quickly.

While successful, as a developer, he found himself wanting more control, and a solution that was somewhere in between Watch Face Studio and full code – this led him to working directly with the format.

Migrating to Watch Face Format

Amoledwatchfaces already had a significant back catalog of watch faces, and took on the dual task of both converting all his existing watch faces and producing new ones directly in the format. “I wanted to have every old and new watch face design in WFF.” This would ensure that all Amoledwatchfaces’ watch faces would be available to current and future users.

Tomáš started working directly in Android Studio, gradually refining his build process. Android Studio has recently added support for syntax validation – a feature Tomáš fed directly into and helped test as an early adopter.

Once up and running, Tomáš found that some of the most time-consuming tasks of AndroidX were extremely simple in the format. Notably, adding the level of user customization he – and users – wanted “is very easy.”

As an example, some of Amoledwatchfaces’ users wanted different Always-On Display (AOD) styles – some preferred a dimmed view of the active state, whereas others wanted only the digital clock. Using Variant, and configuration options such as ListConfiguration and BooleanConfiguration, it was straightforward for Tomáš to give users the ability to customize their watch face – something which would have required a significant investment using legacy libraries.

<Variant mode="AMBIENT" target="alpha" value="[CONFIGURATION.aod] == 0
    ? 255 : [CONFIGURATION.aod] == 1 ? 165 : 0" />

Overcoming Watch Faces quality and versioning challenges

To shorten the debug cycle and minimize errors, Tomáš uses the WFF validator and memory footprint tools in his Gradle scripts. He also incorporates tools such as PNGQuant into his Gradle builds so that resource usage remains optimized.

However, the biggest challenge is creating different versions of the watch face for the different format versions that devices support. To help solve this issue, Tomáš took advantage of product flavors, which let him define a different build configuration for each version. This way, he was able to support the widest range of users while still using the latest and greatest format features on the most recent devices:

/** Set up flavors for different format versions **/


flavorDimensions += "wff_version"
productFlavors{
   // Wear OS 4
   create("wff1"){
       dimension = "wff_version"
       manifestPlaceholders["wff_version"] = "1"
       versionNameSuffix = "-wff1"
       versionCode = 10000 + (android.defaultConfig.versionCode ?: 0)
       minSdk = 33
       targetSdk = 33
   }


   // … other flavors defined here!


   // Wear OS 6
   create("wff4"){
       dimension = "wff_version"
       manifestPlaceholders["wff_version"] = "4"
       versionCode = 40000 + (android.defaultConfig.versionCode ?: 0)
       versionNameSuffix = "-wff4"
       minSdk = 36
       targetSdk = 36
   }
}

Improving velocity and battery life

Amoledwatchfaces is now seeing their investment in this journey to future-proof their watch faces paying off: “Our watch faces are now simply more customizable and more battery friendly. With 8 custom complication slots where you can combine all different complication types, users can have every possible combination of relevant data at a glance.”

User feedback has been great, according to Tomáš, “people mostly refer to battery life improvements after the switch to Watch Face Format.”

And the format has also had a positive effect on development velocity: “I’m developing watch faces faster and cleaner. Updating projects to newer WFF versions is very easy. Fixing bugs is easy too.”

Making the switch to the format

As announced recently, all developers must migrate to Watch Face Format by January 2026. Amoledwatchfaces has benefitted from being an early adopter and recommends that other developers make the switch early too.

Tomáš adds, “Don’t be afraid of switching to a WFF project, managed completely by you. It may seem hard at first sight but when you learn all the attributes, you can define your perfect progress bar arc or gradient digital clock faster than in other tools.”

He also suggests a hybrid workflow, where you work directly in the format and use other tools and editors such as Watch Face Studio. You can first create your watch face in Watch Face Studio, then extract all the resources from the bundle and continue in your preferred IDE.

This week, we’re also announcing Watch Face Designer, which is a Figma-based plugin that you can use in a similar way: start with your design, then export to your preferred format for further refinement.

What’s next for Amoledwatchfaces?

For Tomáš, the journey hasn’t ended, and he’s continuing to strive to delight users even more with each new creation. “There’s always room for improvement. When there’s a new WFF version or feature which could benefit watch faces and thus users, I’ll be adding that.”

We’re looking forward to seeing the next creations from Amoledwatchfaces!

Getting started the with Watch Face Format

• Documentation for developers
• Watch Face Format guidance documentation
• Watch Face Format reference documentation
• Watch Face Format project samples
• Watch Face Format codelab
• Graphical editors for designers
• Watch Face Studio – standalone design tool
• Watch Face Designer – Figma plugin
• Watch Face Designer guidance
• Migration guidance

We hope this story inspires you to take your next steps with the Watch Face Format.

Posted by François Deschênes Product Manager – Wear OS

Today, we are announcing important changes to Wear OS watch face development that will affect how developers publish and update watch faces on Google Play. As part of our ongoing effort to enhance Wear OS app quality, we are moving towards supporting only the Watch Face Format and removing support for AndroidX / Wearable Support Library (WSL) watch faces.

We introduced Watch Face Format at Google I/O in 2023 to make it easier to create watch faces that are customizable and power-efficient. The Watch Face Format is a declarative XML format, so there is no executable code involved in creating a watch face, and there is no code embedded in the watch face APK.

What’s changing?

Developers will need to migrate published watch faces to the Watch Face Format by January 14, 2026. Developers using Watch Face Studio to build watch faces will need to resubmit their watch faces to the Play Store using Watch Face Studio version 1.8.7 or above – see below for more details.

When are these changes coming?

Starting January 27, 2025 (already in effect):

• No new AndroidX or Wearable Support Library (WSL) watch faces (legacy watch faces) can be published on the Play Store. Developers can still publish updates to existing watch faces.

Starting January 14, 2026:

• Availability: Users will not be able to install legacy watch faces on any Wear OS devices from the Play Store. Legacy watch faces already installed on a Wear OS device will continue to work.
• Updates: Developers will not be able to publish updates for legacy watch faces to the Play Store.
• Monetization: The following won’t be possible for legacy watch faces: one-off watch face purchases, in-app purchases, and subscriptions. Existing purchases and subscriptions will continue to work, but they will not renew, including auto-renewals.

What should developers do next?

To prepare for these changes and to continue publishing watch faces to the Play Store, developers using AndroidX or WSL to build watch faces must migrate their watch faces to the Watch Face Format and resubmit to the Play Store by January 14, 2026.

Developers using Watch Face Studio to build watch faces will need to resubmit their watch faces to the Play Store using Watch Face Studio version 1.8.7 or above:

• Be sure to republish for all Play tracks, including all testing tracks as well as production.
• Remove any bundles from these tracks that were created using Watch Face Studio versions prior to 1.8.7.

Benefits of the Watch Face Format

Watch Face Format was developed to support developers in creating watch faces. This format provides numerous advantages to both developers and end users:

• Simplified development: Streamlined workflows and visual design tools make building watch faces easier.
• Enhanced performance: Optimized for battery efficiency and smooth interactions.
• Increased security: Robust security features protect user data and privacy.
• Forward-compatible: Access to the latest features and capabilities of Wear OS.

Resources to help with migration

To get started migrating your watch faces to the Watch Face Format, check out the following developer guidance:

• Watch Face Format getting started guide
• Watch Face Format reference
• Quick-start samples
• Validation tools

We encourage developers to begin the migration process as soon as possible to ensure a seamless transition and continued availability of your watch faces on Google Play.

We understand that this change requires effort. If you have further questions, please refer to the Wear OS community announcement. Please report any issues using the issue tracker.