Tag Archives: privacy

Simple and secure sign-in on Android with Credential Manager and passkeys

Posted by Diego Zavala, Product Manager

We are excited to announce that the public release of Credential Manager will be available starting on November 1st. Credential Manager brings the future of authentication to Android, simplifying how users sign in to their apps and websites, and at the same time, making it more secure.

Signing in can be challenging - passwords are widely used, and often forgotten. They are reused, phished, and washed, making them less secure. Furthermore, there is a proliferation of ways to log in to apps; passwords, email links, OTP, ‘Sign in with…’, and users carry the burden of remembering what to use where. And for developers, this adds complexity - they need to support multiple sign-in methods, increasing integration and maintenance costs.

To address this, Android is rolling out Credential Manager, which brings support for passkeys, a new passwordless authentication, together with traditional sign-in methods, such as passwords and federated identity, in a unified interface.

Let’s take a look at how it can help make users’ and developers’ lives easier.

1.    Passkeys enable passwordless authentication

Passkeys are the future of online authentication - they are more secure and convenient than passwords. With a passkey, signing in is as simple as selecting the right account and confirming with a device face scan, fingerprint or PIN - that’s it. No need to manually type username or passwords, copy-paste a one-time code from SMS, or tap a link in an email inbox. This has resulted in apps reducing the sign-in time by 50% when they implemented passkeys. Logging in with passkeys is also more secure, as they provide phishing-resistant protection.

Image showing step-by-step passwordless authentication experience to sign in to Shrine app from an Android device

Several apps are already integrated with Credential Manager and support passkeys, including Uber and Whatsapp.

“Passkeys add an additional layer of security for WhatsApp users. Simplifying the way users can securely get into their account will help our users, which is why the Credential Manager API is so important.” – Nitin Gupta, Head of Engineering, WhatsApp

“At Uber, we are relentless in our push to create magical experiences without compromising user safety. Passkeys simplify the user experience and promote accessibility, while enhancing the security that comes from reducing the dependency on traditional passwords. Ultimately this is a win-win for Uber and Uber’s customers.

The Credential Manager offers a developer-friendly suite of APIs that enable seamless integration with our apps, eliminating concerns about device fragmentation. We’ve seen great results from launching passkeys across our apps and encourage all users to adopt passkeys.”– Ramsin Betyousef, Sr. Director of Engineering at Uber

2.    All accounts available in a single tap, in a simplified interface

Users often end up with different sign-in methods for the same account - they may use a password on their phone, and a “Sign in with…” on a browser, and then be offered a passkey on their desktop. To simplify users’ lives, Credential Manager lets them choose the account they want, and use smart defaults to pick the best technology to do it (e.g. a passkey, password, or federated identity). That way, users don’t need to think whether they want to sign-in with a password or a passkey; they just choose the account, and they are in.

Let’s take a look at how it works. Imagine that Elisa has 2 accounts on the Shrine app

  • a personal account for which she had a password and just created a new passkey
  • a shared family account with just a password.

To facilitate her experience, Credential Manager shows her 2 accounts and that’s it. Credential Manager uses a password for her family account and a passkey for her personal account (because it’s simpler and safer). Elisa doesn’t need to think about it.

Image showing Credential Manager on an Android device allowing user to choose a saved sign in from list of two accounts

3.    Open to the ecosystem

One of the reasons why users prefer Android is because they are able to customize their experience. In the case of authentication, some users prefer to use the password manager that’s shipped with their device, and others prefer to use a different one. Credential Manager gives users the ability to do so, by being open to any credential provider and allowing multiple enabled at the same time.

Image showing Credential Manager in app allowing user to choose a saved sign in from list of two accounts

Several leading credential providers already integrated with Credential Manager.

"We're at an inflection point in the history of authentication as passkeys represent the perfect balance between ease and security. Since 1Password launched support for passkeys earlier this year, we’ve had over 230,000 passkeys created and see thousands added each day. The data indicates strong user demand but we must continue to prioritize support for apps and services, making it simpler for developers to integrate passkey authentication." – Anna Pobletts, Head of Passwordless at 1Password

“At Enpass, we quickly recognized the potential of passkeys. Thanks to the Android Credential Manager framework, Enpass is fully prepared to serve as a passkey provider for Android 14. This integration empowers our customers to embrace a secure alternative to traditional passwords wherever it's available.” – Vinod Kumar, Chief Technology Officer at Enpass.

How to integrate with Credential Manager?

To get started, take a look at the resources below:

Simple and secure sign-in on Android with Credential Manager and passkeys

Posted by Diego Zavala, Product Manager

We are excited to announce that the public release of Credential Manager will be available starting on November 1st. Credential Manager brings the future of authentication to Android, simplifying how users sign in to their apps and websites, and at the same time, making it more secure.

Signing in can be challenging - passwords are widely used, and often forgotten. They are reused, phished, and washed, making them less secure. Furthermore, there is a proliferation of ways to log in to apps; passwords, email links, OTP, ‘Sign in with…’, and users carry the burden of remembering what to use where. And for developers, this adds complexity - they need to support multiple sign-in methods, increasing integration and maintenance costs.

To address this, Android is rolling out Credential Manager, which brings support for passkeys, a new passwordless authentication, together with traditional sign-in methods, such as passwords and federated identity, in a unified interface.

Let’s take a look at how it can help make users’ and developers’ lives easier.


1.    Passkeys enable passwordless authentication

Passkeys are the future of online authentication - they are more secure and convenient than passwords. With a passkey, signing in is as simple as selecting the right account and confirming with a device face scan, fingerprint or PIN - that’s it. No need to manually type username or passwords, copy-paste a one-time code from SMS, or tap a link in an email inbox. This has resulted in apps reducing the sign-in time by 50% when they implemented passkeys. Logging in with passkeys is also more secure, as they provide phishing-resistant protection.

Image showing step-by-step passwordless authentication experience to sign in to Shrine app from an Android device

Several apps are already integrated with Credential Manager and support passkeys, including Uber and Whatsapp.

“Passkeys add an additional layer of security for WhatsApp users. Simplifying the way users can securely get into their account will help our users, which is why the Credential Manager API is so important.” 
– Nitin Gupta, Head of Engineering, WhatsApp

 

“At Uber, we are relentless in our push to create magical experiences without compromising user safety. Passkeys simplify the user experience and promote accessibility, while enhancing the security that comes from reducing the dependency on traditional passwords. Ultimately this is a win-win for Uber and Uber’s customers.

The Credential Manager offers a developer-friendly suite of APIs that enable seamless integration with our apps, eliminating concerns about device fragmentation. We’ve seen great results from launching passkeys across our apps and encourage all users to adopt passkeys.” 

– Ramsin Betyousef, Sr. Director of Engineering at Uber


2.    All accounts available in a single tap, in a simplified interface

Users often end up with different sign-in methods for the same account - they may use a password on their phone, and a “Sign in with…” on a browser, and then be offered a passkey on their desktop. To simplify users’ lives, Credential Manager lets them choose the account they want, and use smart defaults to pick the best technology to do it (e.g. a passkey, password, or federated identity). That way, users don’t need to think whether they want to sign-in with a password or a passkey; they just choose the account, and they are in.

Let’s take a look at how it works. Imagine that Elisa has 2 accounts on the Shrine app

  • a personal account for which she had a password and just created a new passkey
  • a shared family account with just a password.

To facilitate her experience, Credential Manager shows her 2 accounts and that’s it. Credential Manager uses a password for her family account and a passkey for her personal account (because it’s simpler and safer). Elisa doesn’t need to think about it.

Image showing Credential Manager on an Android device allowing user to choose a saved sign in from list of two accounts

3.    Open to the ecosystem

One of the reasons why users prefer Android is because they are able to customize their experience. In the case of authentication, some users prefer to use the password manager that’s shipped with their device, and others prefer to use a different one. Credential Manager gives users the ability to do so, by being open to any credential provider and allowing multiple enabled at the same time.

Image showing Credential Manager in app allowing user to choose a saved sign in from list of two accounts

Several leading credential providers already integrated with Credential Manager.


"We're at an inflection point in the history of authentication as passkeys represent the perfect balance between ease and security. Since 1Password launched support for passkeys earlier this year, we’ve had over 230,000 passkeys created and see thousands added each day. The data indicates strong user demand but we must continue to prioritize support for apps and services, making it simpler for developers to integrate passkey authentication." 
– Anna Pobletts, Head of Passwordless at 1Password

 

“At Enpass, we quickly recognized the potential of passkeys. Thanks to the Android Credential Manager framework, Enpass is fully prepared to serve as a passkey provider for Android 14. This integration empowers our customers to embrace a secure alternative to traditional passwords wherever it's available.” 
– Vinod Kumar, Chief Technology Officer at Enpass.


How to integrate with Credential Manager?

To get started, take a look at the resources below:

How KAYAK reduced sign in time by 50% and improved security with passkeys

Posted by Kateryna Semenova, Developer Relations Engineer, Android

Introduction

KAYAK is one of the world's leading travel search engines that helps users find the best deals on flights, hotels, and rental cars. In 2023, KAYAK integrated passkeys - a new type of passwordless authentication - into its Android and web apps. As a result, KAYAK reduced the average time it takes their users to sign-up and sign-in by 50%, and also saw a decrease in support tickets.

This case study explains KAYAK's implementation on Android with Credential Manager API and RxJava. You can use this case study as a model for implementing Credential Manager to improve security and user experience in your own apps.

If you want a quick summary, check out the companion video on YouTube.


Problem

Like most businesses, KAYAK has relied on passwords in the past to authenticate users. Passwords are a liability for both users and businesses alike: they're often weak, reused, guessed, phished, leaked, or hacked.

“Offering password authentication comes with a lot of effort and risk for the business. Attackers are constantly trying to brute force accounts while not all users understand the need for strong passwords. However, even strong passwords are not fully secure and can still be phished.” – Matthias Keller, Chief Scientist and SVP, Technology at KAYAK

To make authentication more secure, KAYAK sent "magic links" via email. While helpful from a security standpoint, this extra step introduced more user friction by requiring users to switch to a different app to complete the login process. Additional measures needed to be introduced to mitigate the risk of phishing attacks.


Solution

KAYAK's Android app now uses passkeys for a more secure, user-friendly, and faster authentication experience. Passkeys are unique, secure tokens that are stored on the user's device and can be synchronized across multiple devices. Users can sign in to KAYAK with a passkey by simply using their existing device's screen lock, making it simpler and more secure than entering a password.

“We've added passkeys support to our Android app so that more users can use passkeys instead of passwords. Within that work, we also replaced our old Smartlock API implementation with the Sign in with Google supported by Credential Manager API. Now, users are able to sign up and sign in to KAYAK with passkeys twice as fast as with an email link, which also improves the completion rate" – Matthias Keller, Chief Scientist and SVP, Technology at KAYAK


Credential Manager API integration

To integrate passkeys on Android, KAYAK used the Credential Manager API. Credential Manager is a Jetpack library that unifies passkey support starting with Android 9 (API level 28) and support for traditional sign-in methods such as passwords and federated authentication into a single user interface and API.

Image of Credential Manager's passkey creation screen.
Figure 1: Credential Manager's passkey creation screens.

Designing a robust authentication flow for apps is crucial to ensure security and a trustworthy user experience. The following diagram demonstrates how KAYAK integrated passkeys into their registration and authentication flows:

Flow diagram of KAYAK's registration and authentication processes
Figure 2:KAYAK's diagram showing their registration and authentication flows.

At registration time, users are given the opportunity to create a passkey. Once registered, users can sign in using their passkey, Sign in with Google, or password. Since Credential Manager launches the UI automatically, be careful not to introduce unexpected wait times, such as network calls. Always fetch a one-time challenge and other passkeys configuration (such as RP ID) at the beginning of any app session.

While the KAYAK team is now heavily invested in coroutines, their initial integration used RxJava to integrate with the Credential Manager API. They wrapped Credential Manager calls into RxJava as follows:

override fun createCredential(request: CreateCredentialRequest, activity: Activity): Single<CreateCredentialResponse> { return Single.create { emitter -> // Triggers credential creation flow credentialManager.createCredentialAsync( request = request, activity = activity, cancellationSignal = null, executor = Executors.newSingleThreadExecutor(), callback = object : CredentialManagerCallback<CreateCredentialResponse, CreateCredentialException> { override fun onResult(result: CreateCredentialResponse) { emitter.onSuccess(result) } override fun onError(e: CreateCredentialException) { emitter.tryOnError(e) } } ) } }

This example defines a Kotlin function called createCredential() that returns a credential from the user as an RxJava Single of type CreateCredentialResponse. The createCredential() function encapsulates the asynchronous process of credential registration in a reactive programming style using the RxJava Single class.

For a Kotlin implementation of this process using coroutines, read the Sign in your user with Credential Manager guide.

New user registration sign-up flow

This example demonstrates the approach KAYAK used to register a new credential, here Credential Manager was wrapped in Rx primitives.


webAuthnRetrofitService .getClientParams(username = /** email address **/) .flatMap { response -> // Produce a passkeys request from client params that include a one-time challenge CreatePublicKeyCredentialOption(/** produce JSON from response **/) } .subscribeOn(schedulers.io()) .flatMap { request -> // Call the earlier defined wrapper which calls the Credential Manager UI // to register a new passkey credential credentialManagerRepository .createCredential( request = request, activity = activity ) } .flatMap { // send credential to the authentication server } .observeOn(schedulers.main()) .subscribe( { /** process successful login, update UI etc. **/ }, { /** process error, send to logger **/ } )

Rx allowed KAYAK to produce more complex pipelines that can involve multiple interactions with Credential Manager.

Existing user sign-in

KAYAK used the following steps to launch the sign-in flow. The process launches a bottom sheet UI element, allowing the user to log in using a Google ID and an existing passkey or saved password.

Image of bottom sheet for passkey authentication
Figure 3:Bottom sheet for passkey authentication.

Developers should follow these steps when setting up a sign-in flow:

  1. Since the bottom sheet is launched automatically, be careful not to introduce unexpected wait times in the UI, such as network calls. Always fetch a one-time challenge and other passkeys configuration (such as RP ID) at the beginning of any app session.
  2. When offering Google sign-in via Credential Manager API, your code should initially look for Google accounts that have already been used with the app. To handle this, call the API with the setFilterByAuthorizedAccounts parameter set to true.
  3. If the result returns a list of available credentials, the app shows the bottom sheet authentication UI to the user.
  4. If a NoCredentialException appears, no credentials were found: No Google accounts, no passkeys, and no saved passwords. At this point, your app should call the API again and set setFilterByAuthorizedAccounts to false to initiate the Sign up with Google flow.
  5. Process the credential returned from Credential Manager.
Single.fromSupplier<GetPublicKeyCredentialOption> { GetPublicKeyCredentialOption(/** Insert challenge and RP ID that was fetched earlier **/) } .flatMap { response -> // Produce a passkeys request GetPublicKeyCredentialOption(response.toGetPublicKeyCredentialOptionRequest()) } .subscribeOn(schedulers.io()) .map { publicKeyCredentialOption -> // Merge passkeys request together with other desired options, // such as Google sign-in and saved passwords. } .flatMap { request -> // Trigger Credential Manager system UI credentialManagerRepository.getCredential( request = request, activity = activity ) } .onErrorResumeNext { throwable -> // When offering Google sign-in, it is recommended to first only look for Google accounts // that have already been used with our app. If there are no such Google accounts, no passkeys, // and no saved passwords, we try looking for any Google sign-in one more time. if (throwable is NoCredentialException) { return@onErrorResumeNext credentialManagerRepository.getCredential( request = GetCredentialRequest(/* Google ID with filterByAuthorizedOnly = false */), activity = activity ) } Single.error(throwable) } .flatMapCompletable { // Step 1: Use Retrofit service to send the credential to the server for validation. Waiting // for the server is handled on a IO thread using subscribeOn(schedulers.io()). // Step 2: Show the result in the UI. This includes changes such as loading the profile // picture, updating to the personalized greeting, making member-only areas active, // hiding the sign-in dialog, etc. The activities of step 2 are executed on the main thread. } .observeOn(schedulers.main()) .subscribe( // Handle errors, e.g. send to log ingestion service. // A subset of exceptions shown to the user can also be helpful, // such as user setup problems. // Check out more info in Troubleshoot common errors at // https://developer.android.com/training/sign-in/passkeys#troubleshoot )


“Once the Credential Manager API is generally implemented, it is very easy to add other authentication methods. Adding Google One-Tap Sign In was almost zero work after adding passkeys.” – Matthias Keller

To learn more, follow the guide on how to Integrate Credentials Manager API and how to Integrate Credential Manager with Sign in with Google.


UX considerations

Some of the major user experience considerations KAYAK faced when switching to passkeys included whether users should be able to delete passkeys or create more than one passkey.

Our UX guide for passkeys recommends that you have an option to revoke a passkey, and that you ensure that the user does not create duplicate passkeys for the same username in the same password manager.

Image of KAYAK's UI for passkey management
Figure 4:KAYAK's UI for passkey management.

To prevent registration of multiple credentials for the same account, KAYAK used the excludeCredentials property that lists credentials already registered for the user. The following example demonstrates how to create new credentials on Android without creating duplicates:


fun WebAuthnClientParamsResponse.toCreateCredentialRequest(): String { val credentialRequest = WebAuthnCreateCredentialRequest( challenge = this.challenge!!.asSafeBase64, relayingParty = this.relayingParty!!, pubKeyCredParams = this.pubKeyCredParams!!, userEntity = WebAuthnUserEntity( id = this.userEntity!!.id.asSafeBase64, name = this.userEntity.name, displayName = this.userEntity.displayName ), authenticatorSelection = WebAuthnAuthenticatorSelection( authenticatorAttachment = "platform", residentKey = "preferred" ), // Setting already existing credentials here prevents // creating multiple passkeys on the same keychain/password manager excludeCredentials = this.allowedCredentials!!.map { it.copy(id = it.id.asSafeBase64) }, ) return GsonBuilder().disableHtmlEscaping().create().toJson(credentialRequest) }

And this is how KAYAK implemented excludeCredentials functionality for their Web implementation.

var registrationOptions = { 'publicKey': { 'challenge': self.base64ToArrayBuffer(data.challenge), 'rp': data.rp, 'user': { 'id': new TextEncoder().encode(data.user.id), 'name': data.user.name, 'displayName': data.user.displayName }, 'pubKeyCredParams': data.pubKeyCredParams, 'authenticatorSelection': { 'residentKey': 'required' } } }; if (data.allowCredentials && data.allowCredentials.length > 0) { var excludeCredentials = []; for (var i = 0; i < data.allowCredentials.length; i++) { excludeCredentials.push({ 'id': self.base64ToArrayBuffer(data.allowCredentials[i].id), 'type': data.allowCredentials[i].type }); } registrationOptions.publicKey.excludeCredentials = excludeCredentials; } navigator.credentials.create(registrationOptions);

Server-side implementation

The server-side part is an essential component of an authentication solution. KAYAK added passkey capabilities to their existing authentication backend by utilizing WebAuthn4J, an open source Java library.

KAYAK broke down the server-side process into the following steps:

  1. The client requests parameters needed to create or use a passkey from the server. This includes the challenge, the supported encryption algorithm, the relying party ID, and related items. If the client already has a user email address, the parameters will include the user object for registration, and a list of passkeys if any exist.
  2. The client runs browser or app flows to start passkey registration or sign-in.
  3. The client sends retrieved credential information to the server. This includes client ID, authenticator data, client data, and other related items. This information is needed to create an account or verify a sign-in.

When KAYAK worked on this project, no third-party products supported passkeys. However, many resources are now available for creating a passkey server, including documentation and library examples.


Results

Since integrating passkeys, KAYAK has seen a significant increase in user satisfaction. Users have reported that they find passkeys to be much easier to use than passwords, as they do not require users to remember or type in a long, complex string of characters. KAYAK reduced the average time it takes their users to sign-up and sign-in by 50%, have seen a decrease in support tickets related to forgotten passwords, and have made their system more secure by reducing their exposure to password-based attacks. Thanks to these improvements, ​​KAYAK plans to eliminate password-based authentication in their app by the end of 2023.

“Passkeys make creating an account lightning fast by removing the need for password creation or navigating to a separate app to get a link or code. As a bonus, implementing the new Credential Manager library also reduced technical debt in our code base by putting passkeys, passwords and Google sign-in all into one new modern UI. Indeed, users are able to sign up and sign in to KAYAK with passkeys twice as fast as with an email link, which also improves the completion rate." – Matthias Keller


Conclusion

Passkeys are a new and innovative authentication solution that offers significant benefits over traditional passwords. KAYAK is a great example of how an organization can improve the security and usability of its authentication process by integrating passkeys. If you are looking for a more secure and user-friendly authentication experience, we encourage you to consider using passkeys with Android's Credential Manager API.

Password manager Dashlane sees 70% increase in conversion rate for signing-in with passkeys compared to passwords

Posted by Milica Mihajlija, Technical Writer

This article was originally posted on Google for Developers

Dashlane is a password management 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, iOS, macOS, Windows, and as a web app with an extension for Chrome, Firefox, Edge, and Safari.


The opportunity

Many users choose password managers because of the pain and frustration of dealing with passwords. While password managers help here, the fact remains that one of the biggest issues with passwords are security breaches. Passkeys on the other hand bring passwordless authentication with major advancements in security.

Passkeys are a simple and secure authentication technology that enables signing in to online accounts without entering a password. They cannot be reused, don't leak in server breaches of relying parties, and protect users from phishing attacks. Passkeys are built on open standards and work on all major platforms and browsers.

As an authentication tool, Dashlane’s primary goal is to ensure customers’ credentials are kept safe. They realized how significant the impact of passkeys could be to the security of their users and adapted their applications to support passkeys across devices, browsers, and platforms. With passkey support they provide users a secure and convenient access with a phishing-resistant authentication method.


Implementation

Passkeys as a replacement for passwords is a relatively new concept and to address the challenge of going from a familiar to an unfamiliar way of logging in, the Dashlane team considered various solutions.

On the desktop web they implemented conditional UI support through a browser extension to help users gracefully navigate the choice between using a password and a passkey to log into websites that support both login methods. As soon as the user taps on the username input field, an autofill suggestion dialog pops up with the stored passkeys and password autofill suggestions. The user can then choose an account and use the device screen lock to sign in.

Moving image showing continual UI experience on the web

Note: To learn how to add passkeys support with conditional UI to your web app check out Create a passkey for passwordless logins and Sign in with a passkey through form autofill.

On Android, they used the Credential Manager API which supports multiple sign-in methods, such as username and password, passkeys, and federated sign-in solutions (such as Sign-in with Google) in a single API. The Credential Manager simplifies the development process and it has enabled Dashlane to implement passkeys support on Android in 8 weeks with a team of one engineer.

Moving image showing authentication UI experience in android

Note: If you are a credential provider, such as a password manager app, check out the guide on how to integrate Credential Manager with your credential provider solution.


Results

Data shows that users are more satisfied with the passkey flows than the existing password flows.

The conversion rate is 92% on passkey authentication opportunities on the web (when Dashlane suggests a saved passkey for the user to sign in), compared to a 54% conversion rate on opportunities to automatically sign in with passwords. That’s a 70% increase in conversion rate compared to passwords–a great sign for passkey adoption.

Graph showing evolution of positive actions on passkeys, measuring the rates of authentication with a passkey and registration of a passkey over a six month period

Image showing password sign-in prompt
Password sign-in prompt.

Image showing passkey sign-in prompt
Passkey sign-in prompt.

The conversion rate here refers to user actions when they visit websites that support passkeys. If a user attempts to register or use a passkey they will see a Dashlane dialog appear on Chrome on desktop. If they proceed and create new or use an existing passkey it is considered a success. If they dismiss the dialog or cancel passkey creation, it’s considered a failure. The same user experience flow applies to passwords.

Dashlane also saw a 63% conversion rate on passkey registration opportunities (when Dashlane offers to save a newly created passkey to the user’s vault) compared to only around 25% conversion rate on suggestions to save new passwords. This indicates that Dashlane’s suggestions to save passkeys are more relevant and precise than the suggestions to save passwords.

Image showing save passkey prompt
Save passkey prompt.

Image showing save password prompt
Save password prompt.

Dashlane observed an acceleration of passkey usage with 6.8% average weekly growth of passkeys saved and used on the web.

graph showing % of Active users that performed a passkey related event, out of users having ever interacted with a passkey with a moving average on 7 days over a six month period
Save password prompt.

Takeaways

While passkeys are a new technology that users are just starting to get familiar with, the adoption rate and positive engagement rates show that Dashlane users are more satisfied with passkey flows than the existing password flows. 


“Staying up to date on developments in the market landscape and industry, anticipating the potential impact to your customers’ experience, and being ready to meet their needs can pay off. Thanks in part to our rapid implementation of the Credential Manager API, customers can rest assured that they can continue to rely on Dashlane to store and help them access services, no matter how authentication methods evolve.“ –Rew Islam, Director of Product Engineering and Innovation at Dashlane
 

Dashlane tracks and investigates all passkey errors and says that there haven’t been many. They also receive few questions from customers around how to use or manage their passkeys. This can be a sign of an intuitive user experience, clear help center documentation, a tendency of passkey users today already being knowledgeable about passkeys, or some combination of these factors.

Android 14 is live in AOSP

Posted by Dave Burke, VP of Engineering

Today we're releasing Android 14 and pushing the Android 14 source to the Android Open Source Project (AOSP). Android 14 is designed to improve your productivity as developers while enhancing performance, privacy, security, and customization for users.

Android 14 is rolling out to select Pixel devices starting today, and will be available later this year on some of your favorite devices from Samsung Galaxy, iQOO, Nothing, OnePlus, Oppo, Realme, Sharp, Sony, Tecno, vivo and Xiaomi.

Thank you for taking the time to take Android 14 for an early spin though our developer preview and beta programs, sharing your feedback, and making sure your apps deliver a great experience on Android 14. Making Android work well for each and every one of the billions of Android users is a collaborative process between us, Android hardware manufacturers, and you, our developer community.

This post covers a selection of Android 14 changes that have the most developer impact. For a complete list of all of the Android 14 changes, visit the Android 14 developer site.

Performance and Efficiency

A big focus of Android 14 was on improving the performance and efficiency of the platform.

Freezing cached applications

Prior to Android 14, cached applications were allowed to run somewhat unconstrained. In Android 14, we freeze cached applications after a short period of time, giving them 0 CPU time. In Android 14 Beta populations, we see that cached processes consume up to 50% less CPU cycles as compared to Android 13 public devices. Thus, background work is disallowed outside of conventional Android app lifecycle APIs such as foreground services, JobScheduler, or WorkManager.

Optimized broadcasts

To keep frozen applications frozen longer (i.e. not get CPU time), we adjusted how apps receive context-registered broadcasts once they go into a cached state; they may be queued, and repeating ones, such as BATTERY_CHANGED, may be merged into one broadcast.

Faster app launches

With cached app and broadcast optimizations In Android 14, we were able to increase long-standing limits on the maximum number of cached applications in the platform, leading to a reduction in cold app starts that scales by the RAM present on the device. On 8GB devices, the beta group saw 20% fewer cold app starts, and on 12GB devices it was over 30% fewer. Cold startups are slow compared to warm startups and they are expensive in terms of power. This work effectively improves both power usage and overall app startup times.

Reduced memory footprint

Improving the Android Runtime (ART) has a huge impact on the Android user-experience. Code size is one of the key metrics we look at; smaller generated files are better for memory (both RAM and storage). In Android 14, ART includes optimizations that reduce code size by an average of 9.3% without impacting performance.

Customization

Customization is at the core of Android's DNA, and Android 14 continues our commitment to enabling Android users to tune their experience around their individual needs, including enhanced accessibility and internationalization features.

Bigger fonts with non-linear scaling – Starting in Android 14, users will be able to scale up their font to 200%. Previously, the maximum font size scale on Pixel devices was 130%. A non-linear font scaling curve is automatically applied to ensure that text that is already large enough doesn’t increase at the same rate as smaller text. Learn more here.

Image showing the differences between font with no scaling at 100% on the left, standard scaling at 200% in the middle, and non-linear scaling at 200% on the right

Per-app language preferences – You can dynamically update your app's localeConfig with LocaleManager.setOverrideLocaleConfig to customize the set of languages displayed in the per-app language list in Android Settings. IMEs can now use LocaleManager.getApplicationLocales to know the UI language of the current app to update the keyboard language. Starting with Android Studio Giraffe and AGP 8.1, you can configure your app to support Android 13's per-app language preferences automatically.

Regional preferences – Regional preferences enable users to personalize temperature units, the first day of the week, and numbering systems.

Grammatical Inflection – The Grammatical Inflection API allows you to more easily add support for users who speak languages that have grammatical gender. To show personalized translations, you just need to add translations inflected for each grammatical gender for impacted languages and integrate the API.

New media capabilities


Ultra HDR for images - Android 14 adds support for 10-bit high dynamic range (HDR) images, with support for the Ultra HDR image format. The format is fully backward-compatible with JPEG, allowing apps to seamlessly interoperate with HDR images.

Zoom, Focus, Postview, and more in Camera Extensions - Android 14 upgrades and improves Camera Extensions, allowing apps to handle longer processing times, enabling improved images using compute-intensive algorithms like low-light photography on supported devices.

Lossless USB audio - Android 14 devices can support lossless audio formats for audiophile-level experiences over USB wired headsets.

New graphics capabilities

Custom meshes with vertex and fragment shaders - Android 14 adds support for custom meshes, which can be defined as triangles or triangle strips, and can, optionally, be indexed. These meshes are specified with custom attributes, vertex strides, varying, and vertex/fragment shaders written in AGSL.

Hardware buffer renderer for Canvas - Android 14 introduces HardwareBufferRenderer to assist in using Android's Canvas API to draw with hardware acceleration into a HardwareBuffer, which is particularly helpful when your use case involves communication with the system compositor through SurfaceControl for low-latency drawing.

Developing across form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors including a taskbar supporting enhanced multitasking, large-screen optimized system apps and notification UI, activity embedding, enhanced letterboxing, improved media projection, and more. Our app quality guidance for large screens along with additional learning opportunities around building for large screens and foldables can help optimize your app across all Android surfaces, while the large screen gallery contains design patterns and inspiration for social and communications, media, productivity, shopping, and reading apps.

Improving your productivity

Android 14 contains many updates focused on making your development experience more consistent, fun, and productive. Many of these updates are being made available on older platform releases using a combination of Google Play system updates, Jetpack libraries, and Google Play services, so you can reach more users with them.

OpenJDK 17 Support - Thanks to Google Play system updates (Project Mainline), over 600M devices are enabled to receive the latest Android Runtime (ART) updates that ship with Android 14. Learn more here.

Credential Manager and Passkeys support - Credential Manager is a new Jetpack API that supports multiple sign-in methods, such as username and password, passkeys, and federated sign-in solutions (such as Sign-in with Google) in a single API, simplifying your integration. Using Google Play services, Credential Manager is supported back to Android 4.4 (API level 19). Read more here.

Health Connect - Health Connect is a user controlled on-device repository for user health and fitness data that makes it easier than ever to support an integrated health and fitness experience across apps and connected devices. Health Connect is part of the Android platform and receives updates via Google Play system updates without requiring a separate download, and is available to older devices as an app on the Google Play store. Read about Health Connect and more in What's new in Android Health.

Superior system sharesheets - To make it easy to give your app's users a rich, consistent, sharing experience, the system sharesheets in Android 14 are configurable with custom actions and improved ranking.

More consistent and reliable foreground services- We've collaborated with hardware manufacturers such as Samsung to create both a more consistent developer experience and a more reliable user experience. To this end, Android 14 has a new requirement to declare foreground service types and request type-specific permissions and we have Google Play policies to enforce appropriate use of these APIs. We've also added a new user-initiated data transfer job type, making the experience of managing large user-initiated uploads and downloads smoother by leveraging JobScheduler's constraints (e.g. network constraints such as unmetered WiFi).

User experience

Predictive Back - Android 14 introduces new Predictive Back system animations – cross-activity and cross-task – to join the back-to-home animation introduced in Android 13. The system animations remain behind a developer option to allow time for additional polish and for more apps to opt-into Predictive Back; Material and Jetpack Predictive Back animations are available to users today.

Privacy and security

 
Data sharing updates – Users will see a new section in the location runtime permission dialog that highlights when an app shares location data with third parties, where they can get more information and control the app’s data access.

Partial access to photos and videos – When your app targeting SDK 34 requests any of the visual media permissions introduced in SDK 33 (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO), Android 14 users can now grant your app access to only selected photos and videos. To adapt your app to this change, we recommend following our recent best practices.

Background activity launching – Android 10 (API level 29) and higher place restrictions on when apps can start activities when running in the background. To further reduce instances of unexpected interruptions, apps targeting Android 14 need to grant privileges to start activities in the background when sending a PendingIntent or when binding a service.

Block installation of apps targeting older SDK versions – To protect against malware that targets older API levels to bypass security and privacy protections, apps with a targetSdkVersion lower than 23 cannot be installed on Android 14.

Runtime receivers – Apps targeting Android 14 must indicate if dynamic Context.registerReceiver() usage should be treated as "exported" or "unexported", a continuation of the manifest-level work from previous releases. Learn more here.

Secure full screen Intent notifications – Since full-screen intent notifications are designed for extremely high-priority notifications demanding the user's immediate attention, Android 14 limits the apps granted this permission on app install to those that provide calling and alarms only. Your app can now launch the settings page where users can grant the permission.

Safer dynamic code loading – Apps targeting Android 14 require dynamically loaded files to be marked as read-only. Learn more here.

Safer implicit intents – For apps targeting Android 14, creating a mutable pending intent with an implicit intent will throw an exception, preventing them from being able to be used to trigger unexpected code paths. Apps need to either make the pending intent immutable or make the intent explicit. Learn more here.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in until your app targets SDK version 34 to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

Easier testing and debugging of changes – To make it easier for you to test the opt-in changes that can affect your app, we’ll make many of them toggleable again this year. With the toggles, you can force-enable or disable the changes individually from Developer options or adb. Check out the details here.

image of app compatibility toggles in Developer Options
App compatibility toggles in Developer Options.

Get your apps, libraries, tools, and game engines ready!

Now is the time to finish your final compatibility testing and publish any necessary updates to ensure a smooth app experience.

If you develop an SDK, library, tool, or game engine, it's even more important to release any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please make sure to let your developers know if updates are needed to fully support Android 14.

Testing your app involves installing your production app onto a device running Android 14; you can use Google Play or other means. Work through all the app's flows and look for functional or UI issues. Review the behavior changes to focus your testing. Each release of Android contains changes to the platform that improve privacy, security, and the overall user experience, and these changes can affect your apps. Here are some top changes to test:

Remember to exercise libraries and SDKs that your app is using in your compatibility testing. You may need to update to current SDK versions or reach out to the developer for help.

Once you’ve published the compatible version of your current app, you can start the process to update your app's targetSdkVersion. Review the behavior changes that apply when your app targets Android 14 and use the compatibility framework to help detect issues quickly.

Get started with Android 14

If you have a supported Pixel device, and are not enrolled in the Android Beta program, you will receive the public Android 14 OTA update as it becomes available (it may take a week or longer as this is a phased rollout dependent on device type and carrier). If you are currently enrolled in the Android Beta program running Android 14, you likely have received and installed the beta of the next Android 14 quarterly platform release (QPR1).

System images for Pixel devices are available here for manual download and flash, and you can get the latest 64-bit Android Emulator system images via the Android Studio SDK Manager. If you're looking for the Android 14 source, you'll find it here in the Android Open Source Project repository under the Android 14 branches.

For the best development experience with Android 14, we recommend that you use the latest release of Android Studio Hedgehog. Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility – learn whether your app is affected by default behavior changes in Android 14. Install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes – Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.
  • Update your app with the Android SDK Upgrade Assistant – Android Studio Hedgehog now filters and identifies the specific Android 14 API changes that are relevant to your app, and walks you through the steps to upgrade your targetSdkVersion with the Android SDK Upgrade Assistant.
Screengrab of Android SDK Upgrade Assistant on Google Pixel Fold

Thank you again for participating in our Android developer preview and beta program! We're looking forward to seeing how your apps take advantage of the updates in Android 14.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.

Privacy Sandbox Developer Preview 9: Custom Audience Delegation

Posted by Jon Markoff, Privacy Sandbox Developer Relations

Earlier this year we released the first Privacy Sandbox Beta on Android, with the goal of bringing real-world testing of our private advertising solutions to users' devices.

Since then, we’ve launched several additional Privacy Sandbox releases, each with new features and improvements, in Developer Preview and Beta. This is part of our ongoing commitment to helping developers create privacy-focused apps and tools that keep content open and accessible to everyone. Your feedback has helped us refine and improve these releases and new design proposals, and is greatly appreciated.

Today, we’re announcing Developer Preview 9 for the Privacy Sandbox on Android, including:

  • Protected Audience API: The first release of Custom Audience Delegation, which supports the creation of custom audiences for buyers that do not have an on-device SDK presence. Bidding and Auction services integrations are available to support more complex ad auctions.
  • Attribution Reporting API: Enrollment is no longer required for development and testing purposes. Improvements to debug reporting include supporting additional verbose debug report and app-to-web debug reports.
  • SDK Runtime: With some limitations, SDK Runtime can now launch intents to other apps, and can bind to an allowlist of services.
  • For the full list of released features, see the release notes.

Alongside Developer Preview 9, we’re also announcing Project Flight: a collection of sample apps that demonstrate how the Privacy Sandbox APIs can be used together in end-to-end user journeys. Project Flight includes the following:

  • Advertiser app, to demonstrate a conversion by booking a travel experience
  • Publisher app, to show a relevant ad and register an event
  • SSP library, to demonstrate running ad selection and registering a source
  • MMP library, to demonstrate joining a custom audience and registering a trigger
  • A mock server backend as a companion to the Protected Audience and Attribution Reporting APIs using Firebase

As with all of our releases, we highly encourage developers to share feedback as they continue their journey into the Privacy Sandbox on Android. To get started, read the instructions to set up the SDK and system images on an emulator or supported Pixel device.

For more information on the Privacy Sandbox on Android, visit the developer site, and sign up for our newsletter to receive regular updates.

Expanding our Fully Homomorphic Encryption offering

Posted by Miguel Guevara, Product Manager, Privacy and Data Protection Office

At Google, it’s our responsibility to keep users safe online and ensure they’re able to enjoy the products and services they love while knowing their personal information is private and secure. We’re able to do more with less data through the development of our privacy-enhancing technologies (PETs) like differential privacy and federated learning.

And throughout the global tech industry, we’re excited to see that adoption of PETs is on the rise. The UK’s Information Commissioner’s Office (ICO) recently published guidance for how organizations including local governments can start using PETs to aid with data minimization and compliance with data protection laws. Consulting firm Gartner predicts that within the next two years, 60% of all large organizations will be deploying PETs in some capacity.

We’re on the cusp of mainstream adoption of PETs, which is why we also believe it’s our responsibility to share new breakthroughs and applications from our longstanding development and investment in this space. By open sourcing dozens of our PETs over the past few years, we’ve made them freely available for anyone – developers, researchers, governments, business and more – to use in their own work, helping unlock the power of data sets without revealing personal information about users.

As part of this commitment, we open-sourced a first-of-its-kind Fully Homomorphic Encryption (FHE) transpiler two years ago, and have continued to remove barriers to entry along the way. FHE is a powerful technology that allows you to perform computations on encrypted data without being able to access sensitive or personal information and we’re excited to share our latest developments that were born out of collaboration with our developer and research community to expand what can be done with FHE.

Furthering the adoption of Fully Homomorphic Encryption

Today, we are introducing additional tools to help the community apply FHE technologies to video files. This advancement is important because video adoption can often be expensive and incur long run times, limiting the ability to scale FHE use to larger files and new formats.

This will encourage developers to try out more complex applications with FHE. Historically, FHE has been thought of as an intractable technology for large-scale applications. Our results processing large video files show it is possible to do FHE in previously unimaginable domains.Say you’re a developer at a company and are thinking of processing a large file (in the TBs order of magnitude, can be a video, or a sequence of characters) for a given task (e.g., convolution around specific data points to do a blurry filter on a video or detect object movement), you can now try this task using FHE.

To do so, we are expanding our FHE toolkit in three new ways to make it easier for developers to use FHE for a wider range of applications, such as private machine learning, text analysis, and video processing. As part of our toolkit, we will release new hardware, a software crypto library and an open source compiler toolchain. Our goal is to provide these new tools to researchers and developers to help advance how FHE is used to protect privacy while simultaneously lowering costs.


Expanding our toolkit

We believe—with more optimization and specialty hardware — there will be a wider amount of use cases for a myriad of similar private machine learning tasks, like privately analyzing more complex files, such as long videos, or processing text documents. Which is why we are releasing a TensorFlow-to-FHE compiler that will allow any developer to compile their trained TensorFlow Machine Learning models into a FHE version of those models.

Once a model has been compiled to FHE, developers can use it to run inference on encrypted user data without having access to the content of the user inputs or the inference results. For instance, our toolchain can be used to compile a TensorFlow Lite model to FHE, producing a private inference in 16 seconds for a 3-layer neural network. This is just one way we are helping researchers analyze large datasets without revealing personal information.

In addition, we are releasing Jaxite, a software library for cryptography that allows developers to run FHE on a variety of hardware accelerators. Jaxite is built on top of JAX, a high-performance cross-platform machine learning library, which allows Jaxite to run FHE programs on graphics processing units (GPUs) and Tensor Processing Units (TPUs). Google originally developed JAX for accelerating neural network computations, and we have discovered that it can also be used to speed up FHE computations.

Finally, we are announcing Homomorphic Encryption Intermediate Representation (HEIR), an open-source compiler toolchain for homomorphic encryption. HEIR is designed to enable interoperability of FHE programs across FHE schemes, compilers, and hardware accelerators. Built on top of MLIR, HEIR aims to lower the barriers to privacy engineering and research. We will be working on HEIR with a variety of industry and academic partners, and we hope it will be a hub for researchers and engineers to try new optimizations, compare benchmarks, and avoid rebuilding boilerplate. We encourage anyone interested in FHE compiler development to come to our regular meetings, which can be found on the HEIR website.

Launch diagram

Building advanced privacy technologies and sharing them with others

Organizations and governments around the world continue to explore how to use PETs to tackle societal challenges and help developers and researchers securely process and protect user data and privacy. At Google, we’re continuing to improve and apply these novel data processing techniques across many of our products, and investing in democratizing access to the PETs we’ve developed. We believe that every internet user deserves world-class privacy, and we continue to partner with others to further that goal. We’re excited for new testing and partnerships on our open source PETs and will continue investing in innovations, aiming at releasing more updates in the future.

These principles are the foundation for everything we make at Google and we’re proud to be an industry leader in developing and scaling new privacy-enhancing technologies (PETs) that make it possible to create helpful experiences while protecting our users’ privacy.

PETs are a key part of our Protected Computing effort at Google, which is a growing toolkit of technologies that transforms how, when and where data is processed to technically ensure its privacy and safety. And keeping users safe online shouldn’t stop with Google - it should extend to the whole of the internet. That’s why we continue to innovate privacy technologies and make them widely available to all.

Giving Users More Transparency and Control Over Account Data

Posted by Bethel Otuteye, Senior Director, Product Management, Android App Safety

Google Play has launched a number of recent initiatives to help developers build consumer trust by showcasing their apps' privacy and security practices in a way that is simple and easy to understand. Today, we’re building on this work with a new data deletion policy that aims to empower users with greater clarity and control over their in-app data.

For apps that enable app account creation, developers will soon need to provide an option to initiate account and data deletion from within the app and online. This web requirement, which you will link in your Data safety form, is especially important so that a user can request account and data deletion without having to reinstall an app.

While Play’s Data safety section already lets developers highlight their data deletion options, we know that users want an easier and more consistent way to request them. By creating a more intuitive experience with this policy, we hope to better educate our shared users on the data controls available to them and create greater trust in your apps and in Google Play more broadly.

As the new policy states, when you fulfill a request to delete an account, you must also delete the data associated with that account. The feature also gives developers a way to provide more choice: users who may not want to delete their account entirely can choose to delete other data only where applicable (such as activity history, images, or videos). For developers that need to retain certain data for legitimate reasons such as security, fraud prevention, or regulatory compliance, you must clearly disclose those data retention practices.

Moving image of a accessing account deletion from a mobile device.
Note: Images are examples and subject to change

While we’re excited about the greater control this will give people over their data, we understand it will take time for developers to prepare, especially those without an existing deletion functionality or web presence, which is why we’re sharing information and resources today.

As a first step, we’re asking developers to submit answers to new Data deletion questions in your app’s Data Safety form by December 7. Early next year, Google Play users will begin to see reflected changes in your app’s store listing, including the refreshed data deletion badge in the Data safety section and the new Data deletion area.

Developers who need more time can file for an extension in Play Console until May 31, 2024 to comply with the new policy.

For more information on data deletion and other policy changes announced today:

As always, thank you for your continued partnership in making Google Play a safe and trustworthy platform for everyone.

Privacy Week for Android Developers

Posted by Marcel Pinto , Developer Relations Engineer, Android

Android is secure by default and private by design. The platform is focused on bringing the best experiences and latest innovations to users, while keeping them safe by protecting their security and privacy.

But that’s not enough. As Android developers, we have a unique opportunity to shape the privacy landscape for millions of users. With the increasing importance of data privacy, it's crucial for developers to understand the best practices for protecting user information in their apps while providing a great user experience.

During the Privacy Week for Android Developers, we will focus on the steps that you, the developer, can take to ensure that your apps are secure and privacy-conscious. From coding techniques to data storage and management, we'll explore the essential elements of Android privacy that every developer should know. We’ll also highlight several upcoming changes in Android 14.

What to expect this week?

  • Daily new content with guides, tips, and news
  • Guidance regarding the principles of permissions and how to minimize data and location access
  • Updates about Android 14’s privacy-related changes
  • …and more!

Where?

Let’s start?

First, start by bookmarking the new Design For Safety landing page. This redesigned hub will help you navigate through all the changes and quickly find guides, best practices, and policy updates.

design for safety hub screenshot. The section about the Android changes timeline appears in the screenshot.In addition, to make it easier for developers to follow privacy principles, we have created a cheat-sheet for you:
Privacy cheat-sheet for Android Developers
Click to enlarge

For those who like a more hands-on experience, we recently published a new codelab that covers the major privacy topics and how your app can adapt them.

Android Privacy Codelab screenshot showing the steps and the intro page

And last but not least, don’t forget to check our video resources:

With special highlight to:

Stay tuned, there is more to come this week!

Android 14 Developer Preview 2

Posted by Dave Burke, VP of Engineering

Today, we're releasing the second Developer Preview of Android 14, building on the work of the first developer preview of Android 14 from last month with additional enhancements to privacy, security, performance, developer productivity, and user customization while continuing to refine the large-screen device experience on tablets, foldables, and more.

Android delivers enhancements and new features year-round, and your feedback on the Android 14 developer preview and Quarterly Platform Release (QPR) beta program plays a key role in helping Android continuously improve. The Android 14 developer site has lots more information about the preview, including downloads for Pixel and the release timeline. We’re looking forward to hearing what you think, and thank you in advance for your continued help in making Android a platform that works for everyone.

Working across form factors

Android 14 builds on the work done in Android 12L and 13 to support tablets and foldable form factors. See get started with building for large screens and learn about foldables for a quick jumpstart on how to get your apps ready. Our app quality guidance for large screens contains detailed checklists to review your app. We've also recently released libraries supporting low latency stylus and motion prediction.

The large screen gallery contains design inspiration for social and communications, media, productivity, shopping, and reading app experiences.

Privacy and security

Privacy and security have always been a core part of Android's mission, built on the foundation of app sandboxing, open source code, and open app development. In Android 14, we’re building the highest quality platform for all by providing a safer device environment and giving users more controls to protect their information.

Selected photos access

We recommend that you use the Photo Picker if your app needs to access media that the user selects; it provides a permissionless experience on devices running Android 4.4 onwards, using a combination of core platform features, Google Play system updates, and Google Play services.

If you cannot use Photo Picker, when your app requests any of the visual media permissions (READ_MEDIA_IMAGES / READ_MEDIA_VIDEO) introduced in SDK 33, Android 14 users can now grant your app access to only selected photos and videos.

In the new dialog, the permission choices will be:

  • Allow access to all photos: the full library of all on-device photos & videos is available
  • Select photos: only the user's selection of photos & videos will be temporarily available via MediaStore
  • Don’t allow: access to all photos and videos is denied

Apps can prompt users to select media again by requesting the media permissions again and having the READ_MEDIA_VISUAL_USER_SELECTED permission declared in their app manifest.

Please test this new behavior with your apps and adapt your UX to handle the new permission and the media file reselection flow.

Credential manager

Android 14 adds Credential Manager as a platform API, and we're supporting it back to Android 4.4 (API level 19) devices through a Jetpack Library with a Google Play services implementation. It aims to make sign-in easier for users with APIs that retrieve and store credentials with user-configured credential providers. In addition to supporting passwords, the API allows your app to sign-in using passkeys, the new industry standard for passwordless sign-in. Passkeys are built on industry standards, can work across different operating systems and browser ecosystems, and can be used with both websites and apps. Developer Preview 2 features improvements in the UI styling for the account selector, along with changes to the API based upon feedback from Developer Preview 1. Learn more here.

Safer implicit intents

For apps targeting Android 14, creating a mutable pending intent with an implicit intent will throw an exception, preventing them from being able to be used to trigger unexpected code paths. Apps need to either make the pending intent immutable or make the intent explicit. Learn more here.

Background activity launching

Android 10 (API level 29) and higher place restrictions on when apps can start activities when the app is running in the background. These restrictions help minimize interruptions for the user and keep them more in control of what's shown on their screen. To further reduce instances of unexpected interruptions, Android 14 gives foreground apps more control over the ability of apps they interact with to start activities. Specifically, apps targeting Android 14 need to grant privileges to start activities in the background when sending a PendingIntent or when binding a Service.

Streamlining background work

Android 14 continues our effort to optimize the way apps work together, improve system health and battery life, and polish the end-user experience.

Background optimizations

Developer Preview 2 includes optimizations to Android’s memory management system to improve resource usage while applications are running in the background. Several seconds after an app goes into the cached state, background work is disallowed outside of conventional Android app lifecycle APIs such as foreground services, JobScheduler, or WorkManager. Background work is disallowed an order of magnitude faster than on Android 13.

Fewer non-dismissible notifications

Notifications on Android 14 containing FLAG_ONGOING_EVENT will be user dismissible on unlocked handheld devices. Notifications will stay non-dismissible when the device is locked, and notification listeners will not be able to dismiss these notifications. Notifications that are important to device functionality, like system and device policy notifications, will remain fully non-dismissible.

Improved App Store Experiences

Android 14 introduces several new PackageInstaller APIs which allow app stores to improve their user experience, including the requestUserPreapproval() method that allows the download of APKs to be deferred until after the installation has been approved, the setRequestUpdateOwnership() method that allows an installer to indicate that it is responsible for future updates to an app it is installing, and the setDontKillApp() method that can seamlessly install optional features of an app through split APKs while the app is in use. Also, the InstallConstraints API gives installers a way to ensure that app updates happen at an opportune moment, such as when an app is no longer in use.

If you develop an app store, please give these APIs a try and let us know what you think!

Personalization

Regional Preferences

Regional preferences enable users to personalize temperature units, the first day of the week, and numbering systems. A European living in the United States might prefer temperature units to be in Celsius rather than Fahrenheit and for apps to treat Monday as the beginning of the week instead of the US default of Sunday.

New Android Settings menus for these preferences provide users with a discoverable and centralized location to change app preferences. These preferences also persist through backup and restore. Several APIs and intents grant you read access to user preferences for adjusting app information display (getTemperatureUnit, getFirstDayOfWeek). You can also register a BroadcastReceiver on ACTION_LOCALE_CHANGED to handle locale configuration changes when regional preferences change.

App compatibility

We’re working to make updates faster and smoother with each platform release by prioritizing app compatibility. In Android 14 we’ve made most app-facing changes opt-in to give you more time to make any necessary app changes, and we’ve updated our tools and processes to help you get ready sooner.

Developer Preview 2 is in the period where we're looking for input on our APIs, along with details on how platform changes affect your apps, so now is the time to try new features and give us your feedback.

It’s also a good time to start your compatibility testing and identify any work you’ll need to do. You can test some of them without changing your app's targetSdkVersion using the behavior change toggles in Developer Options. This will help you get a preliminary idea of how your app might be affected by opt-in changes in Android 14.

Image of a partial screen shot of a device showing App compatibility toggles in Developer Options
App compatibility toggles in Developer Options.

Platform Stability is when we’ll deliver final SDK/NDK APIs and app-facing system behaviors. We’re expecting to reach Platform Stability in June 2023, and from that time you’ll have several weeks before the official release to do your final testing. The release timeline details are here.

Get started with Android 14

The Developer Preview has everything you need to try the Android 14 features, test your apps, and give us feedback. For testing your app with tablets and foldables, the easiest way to get started is using the Android Emulator in a tablet or foldable configuration in the latest preview of the Android Studio SDK Manager. For phones, you can get started today by flashing a system image onto a Pixel 7 Pro, Pixel 7, Pixel 6a, Pixel 6 Pro, Pixel 6, Pixel 5a 5G, Pixel 5, or Pixel 4a (5G) device. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.

For the best development experience with Android 14, we recommend that you use the latest preview of Android Studio Giraffe (or more recent Giraffe+ versions). Once you’re set up, here are some of the things you should do:

  • Try the new features and APIs - your feedback is critical during the early part of the developer preview. Report issues in our tracker on the feedback page.
  • Test your current app for compatibility - learn whether your app is affected by default behavior changes in Android 14; install your app onto a device or emulator running Android 14 and extensively test it.
  • Test your app with opt-in changes - Android 14 has opt-in behavior changes that only affect your app when it’s targeting the new platform. It’s important to understand and assess these changes early. To make it easier to test, you can toggle the changes on and off individually.

We’ll update the preview system images and SDK regularly throughout the Android 14 release cycle. This preview release is for developers only and not intended for daily or consumer use, so it will only available by manual download for new Android 14 developer preview users. Once you’ve manually installed a preview build, you’ll automatically get future updates over-the-air for all later previews and Betas. Read more here.

If you intend to move from the Android 13 QPR Beta program to the Android 14 Developer Preview program and don't want to have to wipe your device, we recommend that you move to Developer Preview 2 now. Otherwise, you may run into time periods where the Android 13 Beta will have a more recent build date which will prevent you from going directly to the Android 14 Developer Preview without doing a data wipe.

As we reach our Beta releases, we'll be inviting consumers to try Android 14 as well, and we'll open up enrollment for the Android 14 Beta program at that time. For now, please note that the Android Beta program is not yet available for Android 14.

For complete information, visit the Android 14 developer site.

Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.