Posted by Kseniia Shumelchyk – Engineering Manager, Android Developer Relations, and Rastislav Vaško – Head of Android at Doist

Since we expanded Android to smartwatches, Todoist has continually evolved their Wear OS experience. In the latest version of the platform, Wear OS 6, they leveraged Compose for Wear OS to bring Material 3 Expressive best practices to life, refreshing their app’s and tile’s appearance in the process.

Todoist and the Wear OS opportunity

Todoist is a popular task management application designed to help users organize, prioritize, and complete their tasks across their personal and professional lives the moment they come to mind. Its core philosophy embraces a clean, simple interface that provides a robust set of features, making it accessible for casual users while still being effective for power users and teams.

Here, Wear OS comes into frame – a smartwatch isn’t just a smaller phone, it’s an immediate, personal companion. The ability to glance at your wrist for timely information or quickly capture a task is a uniquely powerful experience. With the revitalization of Wear OS, driven by a modern toolkit and a unified platform, the opportunity to create these delightful experiences has never been greater.

Todoist on their Wear OS evolution

The Todoist team has always been committed to being wherever their users are, helping them organize their work and lives with minimal friction.

“We’ve had a Wear OS app ever since Android Wear 1.0 came out in 2014! Since that time, our experience on Wear OS has evolved to become a perfect platform for quick interactions and easy data access,” said Rastislav Vaško, head of Android at Doist.

When Wear OS began its new chapter a few years ago, Todoist saw the chance to do more than just maintain their existing app, and instead completely reimagine what a task manager on your wrist could be. This marked an important milestone when they migrated the whole codebase to Jetpack Compose along with a UX refresh, and saw a solid user base growth rate increase by 50%.

Over the recent months, since Wear OS 6 Developer Preview came out, Todoist developers have been working on both visual and under-the-hood improvements of the Wear OS experience, specifically:

• Material 3 Expressive redesign and Wear OS 6 support, bringing an even more fluid and modern look and feel to the app and tiles.
• Credential Manager migration, enabling a seamless authentication experience for new and existing users.

“This time we didn’t add new experiences, but we wanted the existing ones to get better – through new UI patterns, dynamic theming, and simpler authentication,” Rastislav said.

Implementing Material 3 Expressive redesign

On wearables, a highly-glanceable form factor, developers need to make every tap count, and Todoist’s design philosophy is built on this principle. As the team put it, “On Wear OS, we’re focusing only on the very essential actions. Each screen and each tap should be meaningful and provide value to the user”.

This focus on simplicity allowed Todoist to fully embrace the new design language and APIs that make modern Wear OS development so compelling, so they knew from the start that they wanted to adopt Material 3 Expressive:

“Material 3 Expressive brings a lot of fluid interactions and delight to Wear OS, and we wanted to leverage these new patterns,” notes Rastislav. “It’s more than just a fresh coat of paint; it’s a design system built for the modern wearable experience”.

As a first step, Todoist design team has used Wear Material 3 Expressive Figma design kits and guiding principles to craft an updated UX for Todoist app and tiles that allowed them to understand the new design language and use relevant Material 3 elements.

Implementing the new design language was made significantly easier by the modern developer toolkit, as the Wear Compose Material 3 and Wear Protolayout Material 3 libraries provide updated and extended color schemes, typography, and shapes, as well as a full set of UI components, and layouts that come with built-in support for expressive motion.

Perhaps best of all, Todoist was able to implement an elegant solution that didn’t require lots of complicated code, as Jetpack Compose matched nicely to design elements in Figma kit. According to the team, “That was the best part – we didn’t need to solve any hard challenges… The APIs work, and they’re simple and intuitive!”.

Todoist developers have taken advantage of the new components introduced in the Material 3 library. In particular, a combination of ScreenScaffold, which lays out the structure of a screen and coordinates transitions of the scroll indicator and time text label; EdgeButton, which has a special shape designed for the bottom of the screen; and TransformingLazyColumn for vertically scrolling lists—altogether creates a coherent user experience.

@Composable
private fun CreateItemLayout(
    state: CreateItemViewModel.Parsed,
    // ...
    scrollState: TransformingLazyColumnState = rememberTransformingLazyColumnState(),
) = ScreenScaffold(
    modifier = Modifier.background(MaterialTheme.colorScheme.background),
    scrollState = scrollState,
    contentPadding = rememberResponsiveColumnPadding(
        first = ColumnItemType.Button,
        last = ColumnItemType.EdgeButtonPadding,
    ),
    edgeButton = {
        EdgeButton(
            text = stringResource(id = R.string.action_home_create_item),
            colors = TodoistButtonDefaults.primaryButtonColors(),
            onClick = onSubmitClick,
            enabled = state.isReadyToSubmit,
        )
    },
) { contentPadding ->
    val transformationSpec = rememberTransformationSpec()
    TransformingLazyColumn(
        modifier = modifier.fillMaxSize(),
        contentPadding = contentPadding,
        verticalArrangement = Arrangement.spacedBy(
            space = 4.dp,
            alignment = Alignment.Top,
        ),
        horizontalAlignment = Alignment.Start,
        state = scrollState,
    ) {
       // ...
    }
}

This seamless integration between design and development extended to tiles, where the library provides a composable-like, declarative approach to building tiles, which made integration feel like a natural extension of the main app: “Technically, the new Tiles API resembles Compose, which we’re big fans of, so it felt very natural to use it right away”.

As an example, for the ‘Day Progress’ Tile, Todoist used one of the standard layouts that use a Slots-based approach:

class DayProgressTileRenderer(
    context: Context,
    private val onClickAction: Action,
) : SingleTileLayoutRenderer<DayProgressTileState, Unit>(context) {
    override fun renderTile(
        state: DayProgressTileState,
        deviceParameters: DeviceParametersBuilders.DeviceParameters,
    ) = materialScope(
        context = context,
        deviceConfiguration = deviceParameters,
        defaultColorScheme = state.theme.toTileColorScheme(context),
    ) {
        primaryLayout(
            titleSlot = { titleSlot(context) },
            mainSlot = { mainSlot(context, state, onClickAction) },
            labelForBottomSlot = { labelForBottomSlot(context) },
            bottomSlot = { bottomSlot(context, state) },
            margins = PrimaryLayoutMargins.MIN_PRIMARY_LAYOUT_MARGIN,
        )
    }

// ...

private fun MaterialScope.mainSlot(...) = graphicDataCard(...)

private fun MaterialScope.labelForBottomSlot(context: Context) = text(
    text = context.getString(R.string.tile_day_progress_goal).layoutString,
    typography = Typography.TITLE_SMALL,
)

The slots extend MaterialScope automatically, which means no extra work is needed for styling.

The protolayout-material3 library provides a large number of components designed according to the Material 3 Expressive specifications and user interface recommendations, which the Todoist team has taken advantage of. An example is the graphicDataCard, which Todoist used for the main slot on this tile.

Todoist’s Tile also supports dynamic color theming, which, implementation-wise, requires no effort from developers as the top-level materialScope function has the allowDynamicTheme flag set to true by default.

Streamlining authentication with Credential Manager

To put the cherry on top of the update, Todoist also implemented a new user authentication experience with the new Credential Manager API on Wear OS.

Credential Manager provides a simplified, standardized user sign-in experience that can be implemented with minimal effort by reusing the same code as the mobile version.

Todoist especially appreciated the standardized UI: “…the [Credential Manager] UI is managed by the [Wear OS] library, which makes the work easy, freeing us up to concentrate on our app’s unique features, rather than reinventing the wheel…”.

Previously, Todoist had implemented its own UI that incorporated supported authentication methods, such as reusing an auth token from an existing mobile sign-in, legacy Google Sign-In, and OAuth 2.0, which allowed users to complete their sign-in on a connected phone.

After the migration, the Todoist authentication flow relies on the Credential Manager UI, which provides a single entry point for available sign-in methods and accounts, including passwords, passkeys, and federated identities like “Sign in with Google.” Users can now enjoy a streamlined experience with a single-tap sign-in on their watch.

For apps migrating to Credential Manager, we recommend keeping at least one backup authentication method in case a user taps “Dismiss.” The Todoist team reused their previous options: OAuth 2.0 and data layer token sharing.

And since they already had a mobile integration, Todoist was able to reuse their mobile code: “We were already using Credential Manager in Todoist for Android, so… it was a no-brainer to adopt it. We’re providing the same seamless experience in both apps while simplifying and reusing code.”

Impact of the transformation

With their revamped experience completed, Todoist was thrilled with the results: “the Edge Hugging Button just feels delightful to use! But seriously, authentication is simpler and faster with Credential Manager”. Rastislav reports excellent user feedback, and the team is now preparing to make the updates available to all users in the coming weeks.

With their robust user base on Wear OS, Todoist expects to continue growing as they invest further and see a strong business case to continue their commitment to wearables.

Rastislav also sums it up well with the final future-looking quote: “We’re invested in Wear! Currently we’re exploring new Tiles, but also AI features.”

Todoist’s recommendations to Android and Wear OS developers

As an active member in the ever-growing Wear OS app ecosystem, Todoist was eager to provide some simple advice for other developers interested in Material 3 Expressive: “Just follow the docs and examples. The samples available for Wear OS are superb and always up-to-date”.

They also recommend embracing Wear OS as a whole: “It’s a mature yet fun platform to develop for! Your designers will need to focus on the essence of your product, your developers have a great testing ground to explore new patterns and APIs, and your users will appreciate having faster and easier access to your product.”

Get started with Material 3 Expressive and Credential Manager

With its new features and modern elegance, Wear OS 6 with Material 3 Expressive provides a smartwatch platform that is delightful for users, and convenient for developers.

Learn more about the Material 3 Expressive for Wear OS design system, and get access to the Material 3 Expressive components and layouts using latest Wear Compose Material 3 and Wear Protolayout Material 3 Jetpack libraries.

For even more resources for developers visit:

• Wear OS samples on Github including dedicated samples for Compose and Tiles
• Migration developer guidance that covers apps and tiles
• Create delightful Wear OS widgets using sample tile layouts in Material 3 Expressive
• Codelabs for Compose on Wear OS and Tiles on Wear OS for hands-on start

To learn more about Credential Manager on Wear OS check out developer guidance and sample app.

Posted by Niharika Arora (X and LinkedIn) – Senior Developer Relations Engineer and Vinisha Athwani – Technical Writer (LinkedIn)

In a world where digital security is becoming increasingly critical, passwords have become a notorious weak link – they’re cumbersome, often insecure, and a source of frustration for users and developers. But there’s good news: passkeys are gaining popularity as the most user-friendly, phishing-resistant, and secure authentication mechanism available. For Android developers, the Credential Manager API helps you guide your users towards using passkeys while ensuring continued support for traditional sign-in mechanisms, such as passwords.

In this blog, we discuss some of the best practices you should follow while encouraging users to transition to passkeys.

Understand authentication with passkeys

Before diving into the recommendations for encouraging the transition to passkeys, here’s an overview of the fundamentals of authentication with passkeys:

• Passkeys: These are cryptographic credentials that replace passwords. Passkeys are associated with device unlocking mechanisms, and are the recommended method of authentication for apps and sites.
• Credential Manager: A Jetpack API that provides a unified API interface for interacting with different types of authentication, including passkeys, passwords, and federated sign-in mechanisms like Sign in with Google.

How do passkeys help your users?

There are several tangible benefits that users experience in apps that allow them to use passkeys to sign in. The highlights of using passkey for users are as follows:

• Improved sign-in experience: Users get the same UI whether they use passwords, passkeys or federated sign-in mechanisms like Sign in with Google.
• Reduced sign-in time: Instead of typing out passwords, users use their phone unlock mechanisms, such as biometrics, resulting in a smooth sign-in experience.
• Improved security: Passkeys use public-key cryptography so that data breaches of service providers don’t result in a compromise of passkey-protected accounts, and are based on industry standard APIs and protocols to ensure they are not subject to phishing attacks. (Read more about syncing and security here).
• Unified experience across devices: With the ability to sync passkeys across devices, users benefit from simplified authentication regardless of the device they’re using.
• No friction due to forgotten passwords!

Underscoring the improved experience with passkeys, we heard from several prominent apps. X observed that login rates improved 2x after adding passkeys to their authentication flows. KAYAK, a travel search engine, observed that the average time it takes their users to sign up and sign in reduced by 50% after they incorporated passkeys into their authentication flows. Zoho, a comprehensive cloud-based software suite focused on security and seamless experiences, achieved 6x faster logins by adopting passkeys in their OneAuth Android app.

What’s in it for you?

When you migrate your app to use passkeys, you’ll be leveraging the Credential Manager API which is the recommended standard for identity and authentication on Android.

Apart from passkeys, the Credential Manager API supports traditional sign-in mechanisms, simplifying the development and maintenance of your authentication flows!

For all of these sign-in mechanisms, Credential Manager offers an integrated bottom-sheet UI, saving you development efforts while offering users a consistent experience.

When should you prompt users to use passkeys?

Now that we’ve established the benefits of passkeys, let’s discuss how you should encourage your users to migrate to passkeys.

The following are a list of UX flows in which you can promote passkeys:

• User account registration: Introduce passkey creation prompts at key moments, such as when your users create their accounts:

Contextual Prompts during account creation
• Sign in: We recommend you encourage users to prompt passkeys in the moment after a user signs in with an OTP, password, or other-sign in mechanisms.

Prompt passkey creation during sign-in
• Account recovery: The critical user journey (CUJ) for account recovery is one that historically presents friction to users. Prompting users to adopt passkeys during account recovery is a recommended path. Users who adopt passkeys experience a familiar account recovery experience as during sign-in.

Account Recovery flow
• Password resets: This is the perfect moment to prompt users to create a passkey; after the frustration of a password reset, users are typically more receptive to the convenience and security passkeys offer.

Create a passkey for faster sign-in next time

How should you encourage the transition to passkeys?

Encouraging users to transition from passwords to passkeys requires a clear strategy. A few recommended best practices are as follows:

• Clear value proposition: Use simple, user-centric prompts to explain the benefits of passkeys. Use messaging that highlights the benefits for users. Emphasize the following benefits:
• Improved security benefits, such as safety from phishing.
• No need to type out a password.
• Ability to use the same passkey across devices/platforms.
• A consistent authentication experience.

Passkey prompt with clear value proposition
• Provide a seamless user experience:
• Use the unified UI provided by Credential Manager to show all available sign-in options, allowing the user to choose their preferred method without having to remember which one they used last.
• Use the official passkey icon to build user familiarity and create a consistent experience.
• Make sure that users can fall back to their traditional sign-in methods or a recovery method, such as a username and password, if a passkey is not available or if they are using a different device.

• Provide users with clarity about credentials within your app’s Settings UI: Make sure your users understand their authentications options by displaying helpful information about each passkey within your app’s settings. To learn more about adding credentials metadata, see the Credential Manager documentation.

Passkey Metadata on App’s Settings screen

• Educate users: Supplement the messaging to adopt passkeys with in-app educational resources or links that explain passkeys in detail.
• Progressive rollout: Consider a phased rollout to introduce passkeys to a subset of your user base to gather feedback and refine the user experience before a broader launch.

Developer Case Studies

Real-world developer experiences often highlight how small design choices—like when and where to surface a passkey prompt—can significantly influence adoption and user trust. To see this in action, let’s explore how top apps have strategically surfaced passkey prompts at key moments in their apps to drive stronger adoption :

Uber

To accelerate passkeys adoption, Uber is proactively promoting passkeys in various user journeys, alongside marketing strategies.

Uber has shared : “90+% of passkey enrollments come from promoting passkey creation at key moments inside the app as compared to onboarding and authentication CUJs“, underscoring the effectiveness of their proactive strategy.

Key learnings and strategies from their implementation:

• Offer passkeys without disrupting the core user experience: Uber added a new account checkup experience in their account settings to highlight passkey benefits, resulting in high passkey adoption rates.

User Account checkup flow

• Proactively bring passkeys to users: They learned not to wait for users to discover passkeys organically because relying on organic adoption would have been slower despite observed benefits like faster sign-ins and increased login success rates for passkey users.
• Use additional mediums to promote passkeys: Uber is also experimenting to promote passkeys through email campaigns or banners on a user’s account screen to highlight the new sign-in method, making their next sign-in easier and more secure.
• Respect your user’s choice: Recognizing that not all users are ready for passkeys, Uber implemented backoff logic in critical flows as sign in, signup screens and, in some contexts, offers passkeys alongside other familiar authentication methods.

Here’s what Uber has to say:

At Uber, we’ve seen users who adopt passkeys enjoy a faster, more seamless, and more secure login experience. To help more users benefit from passkeys, we’ve added nudges to create a passkey at key moments in the user experience: account settings, signup, and login. These proactive outreaches have significantly accelerated our passkey adoption. 

Ryan O’Laughlin

Senior Software Engineer, Uber

Economic Times

Economic Times, part of the Times Internet ecosystem, used a seamless user experience as the primary motivation for users to transition to passkeys.

After introducing targeted nudges, Economic Times observed ~10% improvements in passkey creation completion rate within the initial rollout period.

Key learnings and strategies from their implementation:

• Strategic passkey generation prompts: Initially, Economic Times was aggressively prompting passkey creation in multiple user flows, but it was observed that this approach disrupted business-critical journeys such as subscription purchases or unlocking premium features and was leading to abandoned carts.
• Refined approach: Economic Times made a deliberate decision to remove passkey generation prompts from sensitive flows (such as the subscription checkout flow) to prioritize immediate action completion.
• Targeted prompts: They strategically maintained passkey generation in areas where user intent to sign-in or manage authentication is high, such as initial sign-up flows, explicit sign in pages, or account management sections.
• Positive outcome: This refined deployment resulted in improved passkey generation numbers, indicating strong user adoption, without compromising user experience in critical business flows.

Passkeys Management Screen

Conclusion

Integrating passkeys with Android’s Credential Manager isn’t just about adopting new technology; it’s about building a fundamentally more secure, convenient, and delightful experience for your users. By focusing on intelligent passkey introduction, you’re not just securing accounts–you’re building trust and future-proofing your application’s authentication strategy.

To provide your users the best, optimized and seamless experience, follow the UX guidelines while implementing passkeys authentication with Credential Manager. Check out the docs today!

• Sample with UX best practices
• Sign in your user with Credential Manager
• API Reference – androidx.credentials
• User authentication with passkeys
• Google Safety Center – Passkey
• Google Security Blog: Security of Passkeys in the Google Password Manager

Posted by John Zoeller – Developer Relations Engineer, Loyrn Hairston – Product Marketing Manager, and Jonathan Salamon – Dashlane Staff Software Engineer

Dashlane is a password management and provision tool that provides a secure way to manage user credentials, access control, and authentication across multiple systems and applications.

Dashlane has over 18 million users and 20,000 businesses in 180 countries. It’s available on Android, Wear OS, iOS, macOS, Windows, and as a web app with an extension for Chrome, Firefox, Edge, and Safari.

Recently, they expanded their offerings by creating a Wear OS app with a Credential Provider integration from the Credential Manager API, bringing passkeys to their clients and users on smartwatches.

Streamlining Authentication on Wear OS

Dashlane users have frequently requested a Wear OS solution that provides standalone authentication for their favorite apps. In the past, Wear OS lacked the key APIs necessary for this request, which kept Dashlane from being able to provide the functionality. In their words:

“Our biggest challenge was the lack of a standard credentials API on Wear OS, which meant that it was impossible to bring our core features to this platform.”

This has changed with the introduction of the new Credential Manager API on Wear OS.

Credential Manager provides a simplified, standardized user sign-in experience with built-in authentication options for passkeys, passwords, and federated identities like Sign in with Google. Conveniently, it can be implemented with minimal effort by reusing the same code as the mobile version.

The Dashlane team was thrilled to learn about this, as it meant they could save a lot of time and effort: “[The] CredentialManager API provides the same API on phones and Wear OS; you write the code only once to support multiple form factors.”

After Dashlane had planned out their roadmap, they were able execute their vision for the new app with only a small engineering investment, reusing 92% of the Credential Manager code from their mobile app. And because the developers built Dashlane’s app UI with Jetpack Compose for Wear OS, 60% of their UI code was also reused.

Developing for Wear OS

To provide credentials to other apps with Credential Manager, Dashlane needed to implement the Credential Provider interface on Wear OS. This proved to be a simple exercise in calling their existing mobile code, where Dashlane had already implemented behavior for credential querying and credential selection.

For example, Dashlane was able to reuse their logic to handle client invocations of CredentialManager.getCredential. When a client invokes this, the Android framework propagates the client’s getCredentialRequest to Dashlane’s CredentialProviderService.onBeginGetCredentialRequest implementation to retrieve the credentials specified in the request.

Dashlane delegates the logic for onBeginGetCredentialRequest to their handleGetCredentials function, below, which is shared between their mobile and Wear OS implementations.

// When a Credential Manager client calls 'getCredential', the Android
// framework invokes `onBeginGetCredentialRequest`. Dashlane
// implemented this `handleGetCredentials` function to handle some of
// the logic needed for `onBeginGetCredentialRequest`
override fun handleGetCredentials(
    context: Context,
    request: BeginGetCredentialRequest):
List<CredentialEntry> =
  request.beginGetCredentialOptions.flatMap { option ->
    when (option) {
      // Handle passkey credential
      is BeginGetPublicKeyCredentialOption -> {
        val passkeyRequestOptions = Gson().fromJson(
            option.requestJson, PasskeyRequestOptions::class.java)

        credentialLoader.loadPasskeyCredentials(
          passkeyRequestOptions.rpId,
          passkeyRequestOptions.allowCredentials ?: listOf()
        ).map { passkey ->
          val passkeyDisplayName = getSuggestionTitle(passkey, context)

          PublicKeyCredentialEntry.Builder(
            context,
            passkeyDisplayName,
            pendingIntentForGet(context, passkey.id),
            option
          )
          .setLastUsedTime(passkey.locallyViewedDate)
          .setIcon(buildMicroLogomarkIcon(context = context))
          .setDisplayName(passkeyDisplayName)
          .build()
// Handle other credential types

Reusing precise logic flows like this made it a breeze for Dashlane to implement their Wear OS app.

“The Credential Manager API is unified across phones and Wear OS, which was a huge advantage. It meant we only had to write our code once.”

Impact and Improved Growth

The team is excited to be among the first credential providers on wearables: “Being one of the first on Wear OS was a key differentiator for us. It reinforces our brand as an innovator, focusing on the user experience, better meeting and serving our users where they are.”

As an early adopter of this new technology, Dashlanes Wear OS app has already shown early promise, as described by Dashlane software engineer, Sebastien Eggenspieler: “In the first 3 months, our Wear OS app organically grew to represent 1% of our active device install base.”

With their new experience launched, Wear OS apps can now rely on Dashlane as a trusted credential provider for their own Credential Manager integrations, using Dashlane to allow users to log in with a single tap; and users can view details about their credentials right from their wrist.

Dashlane’s Recommendations to Wear OS Developers

With their implementation complete, the Dashlane team can offer some advice for other developers who are considering the Credential Manager API. Their message is clear: “the future is passwordless… and passkeys are leading the way, [so] provide a passkey option.”

As a true innovator in their field, and the preferred credential provider for so many users, we are thrilled to have Dashlane support Credential Manager. They truly inspired us with their commitment to providing Wear OS users with the best experience possible:

“We hope that in the future every app developer will migrate their existing users to the Credential Manager API.”

Get Started with Credential Manager

With its elegant simplicity and built-in secure authentication methods, the Credential Manager API provides a simple, straightforward authentication experience for users that changes the game in Wear OS.

Want to find out more about how Dashlane is driving the future of end-user authentication? Check out our video blog with their team in Paris, and read about how they found a 70% in sign-in conversion rates with passkeys.

To learn more about how you can implement Credential Manager, read our official developer and UX guides, and be sure to check out our brand new blog post and video blog as part of Wear OS Spotlight week!

We’ve also expanded our existing Credential Manager sample to support Wear OS, to help guide you along the way, and if you’d like to provide credentials like Dashlane, you can use our Credential Provider sample.

Finally, explore how you can start developing additional experiences for Wear OS today with our documentation and samples.

Posted by John Zoeller – Developer Relations Engineer

This post is part of Wear OS Spotlight Week. Today, we’re focusing on implementing Credential Manager on Wear OS, aiming to streamline the authentication experience.

For all software developers, crafting a fast and secure authentication flow is paramount, and this is equally important on Wear OS.

The traditional Wear OS methods require users to have their phone nearby to complete authentication, often with a separate mobile flow or 2-factor auth code.

Credential Manager‘s arrival simplifies this process, allowing for authentication directly from a user’s watch with no need for a nearby phone.

As a unified API, Credential Manager enables you to reuse your mobile app’s code on Wear OS, streamlining development across form factors. With a single tap, users can authenticate with passwords, federated identities like Sign in with Google, or passkeys, the new industry standard for security.

The power of passkeys

Passkeys are built on the principle of asymmetric encryption. During creation, a system authenticator generates a unique, mathematically linked pair of keys: a public key that is securely stored online with the service, and a private key that remains exclusively on the user’s device.

When signing in, the device uses the private key to cryptographically prove to the service that it possesses the key.

This process is highly secure because the private key never leaves the device during authorization (only during syncs from credential providers) and can only be used with the user’s explicit permission. This makes passkeys resistant to server breaches, as a breach could only ever expose the public half of the key pair. Additionally, since there is no passphrase to steal, passkeys are virtually phishing-proof.

The user experience of passkeys is seamless: to log in, a user confirms their presence with their device’s lock (e.g., biometric credential or PIN), and they are signed in. This eliminates the need to remember complex passphrases and provides a faster, more secure method of authentication that works seamlessly across devices.

Designing authentication with Credential Manager

Credential Manager should be the base of a Wear app’s authentication flow. Developers should decide which of its built-in methods to implement based on what is implemented in their mobile experiences, and based on the variety of authentication methods their users need.

Passkeys are the preferred built-in solution due to their inherent security and simplicity, but the other built-in options Credential Manager provides can also be implemented. Passwords are valuable because of their familiarity to users, and federated identities like Sign in with Google provide users with the comfort of a trusted provider.

Developers should maintain at least one of their existing authentication options as a backup as they transition their users to Credential Manager. If Credential Manager is dismissed by a user, or if all of its methods fail, or if credentials are not available, developers can present their backup options.

The Wear Authentication developer guide includes details on supported Wear OS backup authentication options. These include solutions like OAuth 2.0, which has traditionally been a popular choice on Wear OS; and data layer token sharing, which can be used to automatically authenticate users at app launch time if their phone is nearby to sync a signed in account.

Read the full Wear sign-in design guidance to learn about all the best practices for designing your authentication flow, including our special guidance around data layer token sharing.

Implementing Credential Manager on Wear OS

Basic GetCredential setup

At its core, Credential Manager consolidates multiple authentication methods into a single, unified API call: getCredential. By configuring a GetCredentialRequest with your authentication options, you can use the response to validate a user’s identity with your app’s server that contains the credentials, like so:

val request = GetCredentialRequest(getCredentialOptions())
val getCredentialResponse = credentialManager.getCredential(activity, request)

login(getCredentialResponse.credential)

Sync Credentials with Digital Asset Links

For a truly seamless experience, a user’s credentials must sync effortlessly from their other devices to their watch, since it is currently not possible to create credentials on Wear OS.

To enable this, you must add an entry for Wear OS in your Digital Asset Links to associate your Wear OS app with other versions of your app. Be sure to precisely fill out the asset link entry, including your app’s applicationId and the SHA-256 cryptographic hash from your application’s digital signature. You can test them out with our app link verification guide.

Furnishing getCredential with built-in credentials

To allow users to sign in with Credential Manager, provide getCredential with options for the three built-in authentication types: passkeys, passwords, and federated identities like Sign in With Google.

// Adding options is part of creating the credential request
GetCredentialRequest(getCredentialOptions()))

// Furnish list of CredentialOptions for the request
suspend fun getCredentialOptions(): List<CredentialOption> {
  return listOf(
    // Passkey: Furnish a GetPublicKeyCredentialOption with public key
    // data from your authentication server
    GetPublicKeyCredentialOption(authServer.getPublicKeyRequestOptions()),
    // Password: Add the provided GetPasswordOption type in your list
    GetPasswordOption(),
    // Federated Identity: Add your desired option type (GetGoogleIdOption, below)
    // to orchestrate a token exchange with the federated identity server.
    GetGoogleIdOption.Builder().setServerClientId(SERVER_CLIENT_ID).build(),
  )
}

When getCredential is called, Credential Manager will use the options developers provide to present users with a UI to choose how they want to log in.

Handling built-in Credential types

After a user selects their desired credential in the Credential Manager UI, use the result of getCredential (which contains the selected credential) to route to your authentication handlers.

// getCredential returns the selected credential
login(getCredentialResponse.credential)

// Route to your credential handling functions to login
suspend fun login(credential: Credential): LoginResult {
  when (credential) {
    is PublicKeyCredential -> {
      return authHandler.loginWithPasskey(credential.authenticationResponseJson)
    }
    is PasswordCredential -> {
      return authHandler.loginWithPassword(credential.id, credential.password)
    }
    is CustomCredential -> {
      return authHandler.loginWithCustomCredential(
          credential.type, credential.data)
    }
    // ‘else’ case, etc…

The handling logic for each of the above loginWith’x’ methods is slightly different, although they all set up network calls to dedicated authentication endpoints. Below are simplified versions of these methods which demonstrate network calls to authenticate users based on their selected method.

Passkeys require the signed passkey JSON data. Your server will use this data to cryptographically verify the user.

suspend fun loginWithPasskey(passkeyResponseJSON: String): LoginResult {
  val validatedPasskey = httpClient.post(
      "myendpoint/passkey", passkeyResponseJSON, /*other args*/)

  return LoginResult(validatedPasskey)
}

Passwords require network logic to validate the username and password, our example uses subsequent calls to validate the username first. Your backend will validate these against its user database.

suspend fun loginWithPassword(userName: String, password: String): LoginResult {
  val validatedUserName = httpClient.post(
      "myendpoint/username", userName, /*other args*/)
  val validatedPassword = httpClient.post(
      "myendpoint/password", password, validatedUserName, /*other args*/)

  return LoginResult(ValidatedPassword)
}

Federated identities like Sign in with Google require that a secure connection is established between your server and your app. Our sample shows a challenge-response flow initiated from the server, but a client generated nonce works as well.

Our sample server provides a challenge to our app on request (federatedSessionId, below) which is subsequently used to validate the federated token to authenticate the user.

suspend fun loginWithCustomCredential(type: String, data: Bundle): LoginResult {
  if (type == GoogleIdTokenCredential.TYPE_GOOGLE_ID_TOKEN_CREDENTIAL) {
    token = GoogleIdTokenCredential.createFrom(data).idToken
  }

  // Establish a federated session for with your server and obtain its info
  val federatedSessionId = httpClient.post("myendpoint/ObtainFederatedSession",
      /*federated backend address=*/"https://accounts.google.com")

  // Validate the token with the established federated session.
  val validatedCustomCredential = httpClient.post(
      "myendpoint/verifyToken", token, federatedSessionID,
      /*federated backend address=*/"https://accounts.google.com")

  return LoginResult(validatedCustomCredential)
}

Handling secondary Credential types

If a user taps dismiss, or swipes back from Credential Manager, a GetCredentialCancellationException will be thrown for developers to use to navigate to their backup login screens, which will provide secondary authentication options to users. These options are detailed in the Designing Authentication with Credential Manager section, above.

// Catch the user dismissal
catch (e: GetCredentialCancellationException) {
  // Trigger event that navigates to ‘BackupLoginScreen’
  uiEvents.send(UiEvent.NavigateToBackupLogin)
}

Special Note: The version of Google Sign in that exists outside of Credential Manager is now deprecated and will be removed, and should not be provided as a secondary option to avoid presenting two buttons for the same purpose.

See the Wear OS transition guide for more details.

Get started with Credential Manager on Wear OS

Implementing Credential Manager on Wear OS is a straightforward process that delivers significant benefits. By adopting this API, you can provide your users with a secure, seamless, and efficient way to authenticate. To begin implementation, explore our developer documentation and official sample app.

To learn how apps have migrated to Credential Manager on Wear OS, check out our case study with Todoist, who were able to streamline their authentication whilst reusing their mobile implementation.

For a look at how passkeys can improve login success rate, you can read all about how X adopted passkeys to achieve a more secure and user-friendly authentication experience.

Finally, you can watch the new credential manager video blog on YouTube to reinforce everything you’ve learned here.

Happy coding!