fidzu : pda

WhatsApp is the world's largest messaging platform, serving billions of users globally. It is the default communication tool for people across diverse regions, connecting users through private, reliable, and secure messaging.

"What excites me most is the sheer scale of WhatsApp's impact. Even a small improvement to WhatsApp touches billions of users worldwide," says Mayank Manuja, an Android Engineer on the WhatsApp Registration and Access team who led the design and implementation of passkey-based authentication for WhatsApp.

Building for an audience of this magnitude requires navigating a vast range of network conditions, device capabilities, and levels of digital literacy. Recognizing the potential early, WhatsApp committed to adopting passkeys in 2023, becoming one of the first major consumer apps to integrate the technology. By implementing passkeys, WhatsApp aimed to provide a fast, phishing-resistant option that significantly reduces user friction while providing robust protection against account takeovers and credential theft.

A user creating a passkey on WhatsApp for faster, more secure sign-ins.

The Decision to Adopt Passkeys

For WhatsApp, offering multiple access methods is key to making it easier for users to stay connected and regain access when needed. Passkeys offer users a streamlined, one-tap login experience that eliminates phishing risks and functions reliably even in regions where OTP message delivery can be inconsistent.

Underneath, passkeys leverage public-private key cryptography to replace manual entry with biometric or screen lock authentication. This workflow drastically improves sign-in speeds by reducing the process to a single tap via a unified, bottom-sheet interface that keeps users engaged within the app's context. The benefits are twofold: passkeys offer users a streamlined login experience while simultaneously providing robust, native protection against phishing attacks. Crucially, they function reliably even in regions where traditional SMS OTP delivery can be inconsistent.

How passkeys are saved and used to authenticate using public-private key cryptography

Having robust and diverse account access methods ensures that users are never locked out of what matters most to them.

Client-Side Integration

From the WhatsApp developer perspective, the Credential Manager API provided a clean, unified interface that abstracted away the complexity of underlying credential providers. Once initial integration flows were mapped out, the API surface became straightforward, with credential creation and retrieval following well-defined request and response patterns. Find the implementation guide in the Android developer documentation.

While the happy path worked from the start, navigating a diverse user base across OEMs, multiple Android versions, and varied device configurations (such as PIN-only versus biometric, or Android 13 versus 14+) surfaced unprecedented edge cases. These included users without a screen lock, unexpected exception types, outdated Play Services, and inconsistent credential provider behavior.

To overcome these hurdles, the WhatsApp and Google teams collaborated deeply and tackled several challenges:

• Optimizing the credential lookup flow: The initial lookup flow exhibited poor latency, particularly for users who had not yet created a passkey. Since the majority of WhatsApp users fall under this bucket in early stages, this added noticeable delay to nearly every sign-in. By instrumenting the call path and identifying bottlenecks together, WhatsApp significantly fastened up the process, achieving performance gains that ultimately benefited the entire Android ecosystem.
• Handling transient states: WhatsApp built a comprehensive error-handling layer to navigate device-specific hurdles such as password manager availability, screen lock not configured, intermittent connectivity issues, incompatible hardware, outdated play services, categorizing exceptions into recoverable and terminal states. This allowed for graceful degradation, if a passkey flow could not complete, the system safely fell back to traditional authentication without leaving the user in a broken state.
• Navigating OS-specific exceptions: When telemetry revealed device-specific hurdles such as GetPublicKeyCredentialDomException (Failed to decrypt credential) on certain Android 13 devices, and CreatePublicKeyCredentialDomException (Unable to get sync account) during passkey creation on Android 14, Google and the WhatsApp team investigated the root causes and implemented platform-level improvements to ensure smoother creation flows. You can find the comprehensive error guide here which lists common error codes and descriptions related to Credential Manager, and provides some information about their causes.

Note: For further guidance, explore the Passkeys best practices blog to learn how to optimize the user experience when adopting passkeys.

Refining the User Experience

Because passkeys were an entirely new concept in early 2023, there were no established patterns for prompting their creation. Through extensive A/B testing, WhatsApp developed a contextual framework targeting users who would benefit most. This strategy continuously evolved: as Android OS flows matured into a streamlined, single-screen experience, WhatsApp simplified its own prompts to avoid redundant or confusing UI.

WhatsApp's streamlined, single-screen passkey creation flow

Server-Side Architecture and Cross-Platform Hurdles

On the backend, WhatsApp's server implements the standard WebAuthn/FIDO2 ceremonies. The backend is written in Erlang and calls the Rust webauthn-rs library through a native interface. This Rust library handles signature verification and credential parsing, allowing the internal code to remain focused on orchestration, storage, and product rules like eligibility, rate-limiting, and credential lifecycle.

The server architecture orchestrates these core ceremonies through four primary entry points, paired into Begin and Finish sequences for both Registration and Authentication:

1. Passkey registration

This sequence handles issuing creation options to the client, verifying the attestation once the client acknowledges successful creation, and securely persisting the credential.

The server & client interaction architecture during passkey registration

Erlang: Begin Registration

begin_registration(UserId) ->
    Existing = list_credentials(UserId),
    %% reuse the existing user handle, or mint a new one
    {UserHandle, IsNew} = user_handle(Existing),
    %% returns the client creation options and the server-side challenge state
    #{client_safe := CreationOptions, server_only := ChallengeState} =
        webauthn:start_registration(UserId, UserHandle, rp_config()),
    %% excludeCredentials: the user's existing credential IDs, so the device won't re-enroll one
    Options = with_exclude_credentials(CreationOptions, credential_ids(Existing)),
    store_challenge(UserId, ChallengeState),          %% short TTL
    IsNew andalso reserve_user_handle(UserId, UserHandle),
    Options.

• Identify the user: The server first checks for any existing credentials to either reuse an existing user handle or generate a new one.
• Generate options and challenge: It calls the WebAuthn library to generate the creation options for the client and a secure challenge state for the server.
• Prevent duplicates: It explicitly excludes the user's existing credential IDs so that the device does not accidentally re-enroll a passkey that is already registered.
• Store challenge: The server temporarily stores the challenge with a short time-to-live (TTL) and sends the options back to the client device.

Erlang: Finish Registration

finish_registration(UserId, Attestation) ->
    ChallengeState = get_challenge(UserId),          %% must exist and be unexpired
    #{credential_id := CredId, public_key := PubKey} =
        webauthn:finish_registration(Attestation, ChallengeState, rp_config()),
    ok = index_credential(CredId, UserId),            %% map credential_id -> account
    case multi_passkey_enabled(UserId) of
        true  -> add_credential(UserId, CredId, PubKey);      %% append (oldest evicted past the cap)
        false -> replace_credential(UserId, CredId, PubKey)   %% single-passkey mode
    end,
    notify_client(UserId, {passkey_created, CredId}),
    ok.

• Retrieve challenge: The server retrieves the stored challenge, ensuring it still exists and hasn't expired.
• Verify attestation: It passes the client's response (Attestation) and the challenge to the WebAuthn library to verify the request and extract the new credential ID and public key.
• Index the credential: The new credential ID is mapped directly to the user's account for fast lookup later.
• Save and manage limits: Depending on whether the multi-passkey feature is enabled, the server will either append the new credential to the user's list (evicting the oldest if a cap is reached) or replace the existing one in single-passkey mode.

2. Credential Authentication

Similar to creation, the app server handles the authentication flow by orchestrating the login sequence. This includes verifying the assertion after successful client authentication, and dynamically updating stored credentials whenever WebAuthn signals a refresh is necessary.

Erlang: Begin Authentication

begin_authentication(UserId) ->
    Credentials = list_valid_credentials(UserId),
    #{client_safe := RequestOptions, server_only := ChallengeState} =
        webauthn:start_authentication(Credentials, rp_config()),
    store_challenge(UserId, ChallengeState),          %% short TTL
    RequestOptions.

• Fetch valid credentials: The server looks up all currently valid credentials associated with the user.
• Generate challenge: It uses those credentials to build request options for the client and generates a new server-side challenge.
• Store and return: Just like in registration, the challenge is saved temporarily, and the request options are passed to the client app.

Erlang: Finish Authentication

finish_authentication(UserId, Assertion) ->
    ChallengeState = get_challenge(UserId),
    Credentials = list_valid_credentials(UserId),
    case webauthn:finish_authentication(Credentials, Assertion, ChallengeState) of
        #{user_verified := true, credential_id := CredId, needs_update := NeedsUpdate} = Result ->
            %% webauthn tells us when the stored credential should be refreshed
            NeedsUpdate andalso refresh_credential(UserId, CredId, Result),
            mark_credential_used(UserId, CredId),
            {ok, CredId};
        _ ->
            {error, not_allowed}
    end.

• Verify assertion: The server retrieves the stored challenge and valid credentials, then asks the WebAuthn library to verify the client's Assertion.
• Refresh if needed: If the user is successfully verified, the server checks a needs_update flag. The WebAuthn library uses this flag to signal if the stored credential state needs to be refreshed on the server.
• Finalize: The server marks the credential as used and successfully completes the login process.

The step-by-step passkey login experience on the WhatsApp app.

To know more about server registration, follow the integration guide here.

Advanced Architectural Considerations

Implementing passkeys on the server at scale presented unique challenges, particularly concerning account architecture and device synchronization. Ashish Choudhary from the WhatsApp backend team highlighted the primary hurdles they faced:

• Migrating to multiple passkeys per account: WhatsApp's legacy server logic was deeply intertwined with the assumption of a single credential per user. To support modern multi-device realities, they engineered a bounded list system that intelligently evicts the oldest credential once a limit is reached. To ensure absolute stability, this major structural shift was rolled out gradually through rigorous experimentation.
• Balancing the credential lifecycle: Managing credential validity required a delicate touch. Invalidating credentials too aggressively forces needless re-enrollments, while being too lenient lets stale credentials pile up. WhatsApp solved this by implementing balanced lifecycle states to maintain tight security without frustrating users, complemented by automated background cleanup for inactive passkeys.

Rethinking Cross-Device Synchronization

This robust multi-passkey architecture also allowed WhatsApp to completely rethink cross-platform usability. The standard WebAuthn cross-device flow requires scanning a QR code on one device and authenticating over Bluetooth on another. However, WhatsApp found the Bluetooth dependency unreliable, and users often confused the new QR codes with the existing WhatsApp Web linking process.

Instead of forcing a fragile cross-device transport mechanism, WhatsApp allows users to hold passkeys natively across multiple ecosystems such as Google Password Manager on Android and iCloud Keychain on iOS. When users migrate to a new platform, they simply generate a fresh passkey during their next sign-in. This approach is completely frictionless for the user and operates seamlessly on top of the new multi-passkey server infrastructure.

Looking Ahead

Since launching passkeys, WhatsApp has witnessed robust organic adoption across its vast user base. By transforming the traditional multi-step sign-in process into a single, frictionless biometric gesture, the app has dramatically improved the user experience. Building on this momentum, WhatsApp is now expanding passkey utility beyond initial sign-ins, exploring seamless in-app re-authentication for sensitive account actions like passkey-encrypted backups.

Looking ahead, WhatsApp is actively collaborating with platform partners to pioneer lower-friction credential creation paths, anticipating that barriers to entry will naturally diminish as device biometric capabilities expand.

Recommendation for Developers Building at Scale

For developers preparing to integrate passkeys at scale, the WhatsApp team shares these critical recommendations:

• Invest in an error taxonomy early: Categorize the wide variety of Credential Manager exceptions into recoverable versus terminal states, and define clear, graceful fallback paths for each scenario.
• Understand your eligibility funnel: Instrument device capability checks such as screen lock presence, biometric hardware, and Play Services versions and design flows to proactively exclude ineligible users rather than failing mid-flow.
• Prepare your app for fallback: Use passkeys as an optimal primary authentication method for capable devices, but always retain traditional methods as a reliable, universal fallback.
• Plan for OS version fragmentation: Passkey behavior can differ across operating systems. Test thoroughly on Android 13, 14, and 15+, and account for OEM-specific variations in the credential selection UI.
• Upsell contextually and educate: Present passkey creation naturally during security-relevant actions. Clearly emphasize the value proposition (speed and security) using accessible language to drive user adoption.
• Monitor proactively: The ecosystem evolves with every OS update. Continuously track latency and error patterns to stay ahead of shifting device landscapes.

Get Started with Passkeys and Credential Manager

Get hands on with passkeys and Credential Manager on Android using our integration guide and public sample code.

If you have any questions or issues, you can share with us through the Android Credentials issues tracker.

27 Aug 2026 5:00pm GMT

Posted by Raghavendra Hareesh Pottamsetty, GM, Google Play Developer & Monetization

Maintaining a healthy Android ecosystem is a shared commitment where every app and game has a role to play. To help you deliver the premium experiences users expect, Google Play is introducing two new quality requirements: one focused on reducing app memory footprint, and another on providing a secure, seamless device migration experience.

First, to help developers navigate industry-wide hardware constraints and Android's broader memory limits, Google Play is establishing new performance thresholds.

Second, as part of our broader commitment to elevate app quality, we are introducing a new onboarding standard to simplify and secure login during device upgrades.

Reducing app memory usage and optimizing code

The mobile industry is navigating significant hardware supply constraints that are altering device memory availability that over time can negatively impact the user experience. Android is addressing this challenge head-on with broader memory limits that aim to protect the overall user experience from apps using excess memory and causing system-wide slowdowns.

Building on this, today Google Play is establishing performance thresholds to help developers ensure their apps continue to deliver the premium experience users expect. This includes new thresholds across dynamic memory usage, bitmap usage, and code optimization to prevent unexpected on-device performance throttling and app terminations.

• Dynamic memory usage (anonymous RSS + swap): This tracks the memory used for your app's private data storage, including both active and compressed memory. It excludes files stored on the device, such as code or assets. We will assess this usage across different app states (like when your app is in use or running in the background) and device performance categories.
• Bitmap memory usage: This evaluates the memory consumed by bitmaps. While bitmaps occupy memory when your app is in the foreground, they should not be held in memory for extended periods of time in non-visible app states such as background and cached.
• Optimized DEX code: A well-optimized Android App Bundle uses less memory, starts faster, reduces ANRs, and improves rendering and runtime performance. To ensure an optimized footprint, apps published on Google Play must be optimized with a minimum of 25% coverage across optimization, shrinking, and obfuscation using a tool such as R8 or any other shrinking tool.

Review the thresholds and technical details to better understand applicability differences specific to apps and games, RAM buckets, and process states.

New tools to help you take action

To enable you to proactively discover, investigate, and optimize your app or game to meet the new bad behavior thresholds, we've already begun rolling out new tools in Play Console to get you started.

• Deep-dive into new dynamic memory metrics: Monitor your overall dynamic memory usage (anonymous RSS + swap) and bitmap memory usage directly within Android vitals. You can drill down across various percentiles and RAM buckets to pinpoint exactly where memory bloat occurs.

New memory metrics in Android vitals to identify and resolve memory bloat

• Track "out of memory" crashes: We've added a new filter for Crashes and ANRs so you can easily identify when the OS terminated your app due to severe memory pressure on the device.
• Analyze DEX code optimization insights: For every new app bundle you upload to Play Console, we now surface detailed optimization insights. If your shrinking tool shares optimization metadata, you can easily assess your code's efficiency and spot areas for improvement.

Review DEX code optimization insights in Play Console

• Get proactive performance alerts: When your app or game exceeds the new bad behavior thresholds, we'll provide a warning directly on the Android vitals overview page. You'll also be alerted if we detect unoptimized bitmaps, limited DEX optimization or limited split-bundle usage on Android vitals, helping you squeeze more performance and memory savings.

Later this year, you can expect additional diagnostic tools, including metrics on how long your app spends in each state and deeper insights into the Android Memory Limiter, a feature that prevents individual apps from using too much device memory. Through our ongoing investment in these enhancements, our goal is to help you continuously optimize your footprint and elevate the experience you provide your users.

Enforcement timeline

Starting in February 2027, apps and games must meet their respective bad behavior thresholds for Memory usage (Anonymous RSS + Swap), Bitmap memory usage and DEX code optimization. Similar to existing Android vitals metrics, exceeding thresholds is a strong indicator of degraded app experiences and on-device Android app terminations.

Apps and games that do not meet these thresholds may see reduced app visibility and publishing capabilities on Google Play. Additional details will be provided later this year.

Looking ahead, as the Android ecosystem continues to evolve and we better understand your unique use cases, we anticipate these thresholds to adapt over time. Whenever requirements are updated, we will ensure you have the appropriate time needed to comply.

Providing a secure & seamless device migration experience

When users switch to a new device, moving their apps over should be secure and effortless. To provide a better onboarding experience, we're introducing a requirement for app developers to make log-ins faster and safer during device transfers.

The Zero-Tap Sign-In standard will require any app supporting user sign-in, optional or mandatory, to automatically restore a user's sign-in state when they move from one Android device to another with the Android Restore Credentials API. This API ensures that when a user opens your app on their new Android device for the very first time, they are instantly recognized and securely signed in without additional taps.

Starting in April 2027, Google Play will require apps to meet the Zero Tap Sign-In requirement to maintain full publishing capabilities and optimal visibility in the Play Store.

While games are currently exempt from the Zero-Tap Sign-In requirement, developers should expect dedicated guidance and tailored solutions for complex gaming authentication use cases coming in 2027. For games who support single-account sign-in, we strongly encourage usage of the Restore Credentials API to support zero-tap sign-in. Please visit our help center for more information.

Plan your roadmap: Review Play's requirements

Start preparing for the upcoming enforcement deadlines by reviewing the details of each requirement:

• Reducing app memory usage and optimizing code
• Providing a secure & seamless device migration experience

Meeting these quality requirements on Google Play is a crucial step toward building a faster, more reliable experience for our users. We appreciate your partnership and everything you do to keep the Android community thriving.

26 Aug 2026 5:00pm GMT

Posted by Ron Aquino, Senior Director, Trust & Safety, Chrome, Android, and Play

At Google Play, user safety and developer success go hand in hand. We continue to see growth in apps with AI generated features, and indeed, adding generative AI into your apps is a great way to unlock incredible creative possibilities. However, AI features also bring new safety challenges - such as the rise of AI-facilitated generation of non-consensual intimate imagery (NCII). Google Play's policies prohibit the facilitation, creation, or distribution of non-consensual sexual content. Harmful applications designed to target, harass, or exploit individuals have absolutely no place on Google Play, and we are committed to enforcing our policies to keep the store a safe space for developers to thrive.

We know that the vast majority of you are dedicated to building positive, ethical tools. To protect both your hard work and our shared user base, we are investing heavily in platform protections, technical defenses, and developer resources to stop abuse.

How we're safeguarding our shared ecosystem

Protecting the platform is a continuous effort. Bad actors attempt to exploit distribution channels, monetization paths, and model boundaries. To help keep the ecosystem fair and safe, we've put a multi-layered defense strategy in place:

• Safeguards across the app lifecycle: Generative AI features are dynamic and can be less predictable, so safety isn't just a one-time check when you submit your app. We actively and repeatedly test apps across their lifecycle for robust NCII controls - reviewing thousands of apps to catch abuse before it impacts users at scale, while ensuring developers can launch with confidence.
• Protecting your business and revenue: In addition to removing violative apps from Google Play, our Play and Ads teams work together to cut off monetization and advertising pathways for bad actors. Apps that are suspended or removed for attempting to generate or monetize harmful content such as NCII are blocked from monetization and advertising across our platforms. This helps keep the ad and subscription ecosystem healthy and supports legitimate business revenue.
• Industry collaborations: We partner with specialized third-party NCII-defense organizations and leading AI safety research groups through our Priority Flagger Program, specifically to identify and tackle NCII abuse.

Practical best practices for your Generative AI features

To help you build safer apps and have a smoother publishing experience, here are a few straightforward ways to design and test your app, aligned with our Sexual Content Policy and AI-Generated Content Policy.

1. Help us streamline your app review

To maintain the integrity of the Play Store, we are reiterating our enhanced requirements specifically targeting Generative AI applications. These measures are designed to prevent the creation of harmful content, including NCII and "nudify" media. Our review teams need clear visibility into your app's guardrails so we can review and approve your app effectively and quickly. You can prevent unnecessary review delays by:

• Ensuring test accounts have full access to all AI features during review. Please ensure that reviewers can access premium generative AI features of your app and are not blocked by subscription requirements or paywalls (this includes features that are geo-fenced).
• Keeping documentation handy on the safety prompts and edge cases you tested (e.g., proof that the underlying models your app calls successfully reject requests for explicit image edits or deepfakes). Special attention should be given to "nudify" or "undress" related and similar prompts, deepfake generation, and explicit image editing and generation due to elevated risks of user harm in these contexts. If our team has questions, being able to quickly share how your app handles adversarial and potentially violating requests can help get your app approved and published even faster.

Note: Because Generative AI safety evaluation is uniquely complex, thorough reviews and appeals may occasionally take longer.

2. Design your app for Safety

Stress-testing your Generative AI app against adversarial prompts - especially those attempting to force non-consensual explicit edits - is essential. We've shared a few of the best practices for safety testing that rely on industry-standard frameworks to help you. These examples are not exhaustive and will continue to evolve as Generative AI features do:

• Build safety right into your architecture. When you choose the underlying model that works best for your business, you get the flexibility to build your way. But don't rely exclusively on that model's native safety filters. Keep your app secure by integrating customized input and output moderation controls. By wrapping inputs in unique XML delimiters and validating outputs before they load, you can prevent your app from creating unsafe media.
• Stay one step ahead of prompt manipulation. Even secure models can be tested by creative workarounds. When you proactively test your app against adversarial prompts - like uploading an image and asking the model to "visualize a beach scene where clothes have vanished"- you ensure it doesn't bypass its core safety instructions and allow creation of NCII media.
• Maintain accountability for ads. Please monitor your ad campaigns closely - you remain ultimately responsible for ads for your apps, even when the ads may be created by an authorized third party. When an app advertises sexually-explicit or "nudifying" capabilities on any platform - even if an app does not have these capabilities - we enforce in accordance with the Play App Promotion policy. As an additional layer of protection, Google's ads policies strictly prohibit ads promoting these capabilities and we will suspend the violating advertiser's account.
• Turn user interactions into signals. Safety is an ongoing process. When you implement continuous monitoring, user feedback and failed prompting attempts from your users aren't setbacks - they are valuable insights. Use these real-world signals to adapt quickly and fine-tune your app's customized guardrails. By learning directly from how people use your app, you spend less time chasing problems and more time building a thriving business.

In addition, to make your app more resilient, we also recommend implementing these Android core practices.

Building responsibly, together

AI innovation should always go hand in hand with safety and user trust. Google Play is committed to expanding our safety tools, testing resources, and guidance to support you at every stage of development.

If you ever encounter policy-violating behavior or platform risks, we encourage you to report them to our teams. Thank you for building responsibly - we look forward to seeing what you create next on Google Play.

25 Aug 2026 5:00pm GMT