Author Archives: Android Developers

Listening to Developer Feedback to Improve Google Play

Posted by Sameer Samat, Vice President, Product Management

Developers are our partners and by pairing their creativity and innovation with our platforms and tools, together we create delightful experiences for billions of people around the world. Listening carefully to their feedback is an important part of how we continue to make Android better with each release and improve how mobile app stores work. In an April 2019 blog post we shared some updates we made to Android APIs and Play Policies based on developer feedback. And today, we wanted to share some additional insights we’ve gained from developer feedback and how we’re taking that input to improve Google Play and Android. Some of the key themes we’ve heard include:

  • Supporting developers’ ability to choose how they distribute their apps through multiple app stores on different platforms (mobile, PC, and console), each with their own business model competing in a healthy marketplace;
  • Clarifying our policies regarding who needs to use Google Play’s billing system and who does not;
  • Ensuring equal treatment for all apps, including first-party and third-party apps, on our platforms;
  • Allowing developers to connect and communicate directly with their customers;
  • Enabling innovation and ensuring our policies embrace new technologies that can help drive the consumer experience forward.

We’d like to share our perspective on each of these points.

Choice of stores

We believe that developers should have a choice in how they distribute their apps and that stores should compete for the consumer’s and the developer’s business. Choice has always been a core tenet of Android, and it’s why consumers have always had control over which apps they use, be it their keyboard, messaging app, phone dialer, or app store.

Android has always allowed people to get apps from multiple app stores. In fact, most Android devices ship with at least two app stores preinstalled, and consumers are able to install additional app stores. Each store is able to decide its own business model and consumer features. This openness means that even if a developer and Google do not agree on business terms the developer can still distribute on the Android platform. This is why Fortnite, for example, is available directly from Epic's store or from other app stores including Samsung's Galaxy App store.

That said, some developers have given us feedback on how we can make the user experience for installing another app store on their device even better. In response to that feedback, we will be making changes in Android 12 (next year’s Android release) to make it even easier for people to use other app stores on their devices while being careful not to compromise the safety measures Android has in place. We are designing all this now and look forward to sharing more in the future!

Clarity on billing policies

As we mentioned, each Android app store is able to decide its own business model and consumer features. For Google Play, users expect a safe, secure and seamless experience, and developers come to Play for powerful tools and services that help them build and grow their businesses. Our developer policies are designed to help us deliver on these expectations and Google Play's billing system is a cornerstone of our ongoing commitment. Consumers get the benefit of a trusted system that allows them to safely, securely, and seamlessly buy from developers worldwide. Google protects consumers’ payment info with multiple layers of security, using one of the world’s most advanced security infrastructures. For developers, Google Play’s billing system provides an easy way for billions of Android users to transact with them using their local, preferred method of payment.

We’ve always required developers who distribute their apps on Play to use Google Play’s billing system if they offer in-app purchases of digital goods, and pay a service fee from a percentage of the purchase. To be clear, this policy is only applicable to less than 3% of developers with apps on Google Play. We only collect a service fee if the developer charges users to download their app or they sell in-app digital items, and we think that is fair. Not only does this approach allow us to continuously reinvest in the platform, this business model aligns our success directly with the success of developers.

But we have heard feedback that our policy language could be more clear regarding which types of transactions require the use of Google Play’s billing system, and that the current language was causing confusion. We want to be sure our policies are clear and up to date so they can be applied consistently and fairly to all developers, and so we have clarified the language in our Payments Policy to be more explicit that all developers selling digital goods in their apps are required to use Google Play’s billing system.

Again, this isn’t new. This has always been the intention of this long standing policy and this clarification will not affect the vast majority of developers with apps on Google Play. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. But for those who already have an app on Google Play that requires technical work to integrate our billing system, we do not want to unduly disrupt their roadmaps and are giving a year (until September 30, 2021) to complete any needed updates. And of course we will require Google’s apps that do not already use Google Play’s billing system to make the necessary updates as well.

Equal treatment

Our policies apply equally to all apps distributed on Google Play, including Google’s own apps. We use the same standards to decide which apps to promote on Google Play, whether they're third-party apps or our own apps. In fact, we regularly promote apps by Google’s competitors in our Editors Choice picks when they provide a great user experience. Similarly, our algorithms rank third-party apps and games using the same criteria as for ranking Google's own apps.

Communicating with customers

Developers have told us it is very important to be able to speak directly with their customers without significant restrictions. As app developers ourselves, we agree wholeheartedly and our policies have always allowed this.

That said, developers have asked whether they can communicate with their customers directly about pricing, offers, and alternative ways to pay beyond their app via email or other channels. To clarify, Google Play does not have any limitations here on this kind of communication outside of a developer’s app. For example, they might have an offering on another Android app store or through their website at a lower cost than on Google Play.

We understand the importance of maintaining the customer relationship. As such, we have also always allowed developers to issue refunds to their customers and provide other customer support directly.

Enabling innovation

Developers are coming up with cool things all the time. Using their feedback, we are always trying to adjust our approach to ensure that we continue to help enable new forms of innovation. For example, recent innovations in game streaming have generated new game experiences that are available on Google Play, including Microsoft’s recent launch of Xbox cloud gaming in the Xbox Game Pass Android app.

Keep the feedback coming

We really appreciate all the feedback we have received from our developer community and believe the Android ecosystem has never been a more exciting place to be.

It is exciting to see developers such as Duolingo, Truecaller, Hyperconnect, Any.do, and Viber be so successful and grow their business on Android and reach a diverse audience. These kinds of services delight consumers and we are thrilled to have built a platform that can support them.

We’ve also published some additional frequently asked developer questions here.

Answering your FAQs about Google Play billing

Posted by Mrinalini Loew, Group Product Manager

We are committed to providing powerful tools and services to help developers build and grow their businesses while ensuring a safe, secure and seamless experience for users. Today we are addressing some of the most common themes we hear in feedback from developers. Below are a few frequently asked developer questions that we thought would also be helpful to address.

Q: Can I distribute my app via other Android app stores or through my website?

A: Yes, you can distribute your app however you like! As an open ecosystem, most Android devices come preinstalled with more than one store - and users can install others. Android provides developers the freedom and flexibility to distribute apps through other Android app stores, directly via websites, or device preloads, all without using Google Play’s billing system.

Q: What apps need to use Google Play's billing system?

A: All apps distributed on Google Play that are offering in-app purchases of digital goods need to use Google Play’s billing system. Our payments policy has always required this. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. For those few developers that need to update their apps, they will have until September 30, 2021 to make those changes. New apps submitted after January 20, 2021 will need to be in compliance.

Q: Many businesses have needed to move their previously physical services online (e.g. digital live events). Will these apps need to use Google Play’s billing?

A: We recognize that the global pandemic has resulted in many businesses having to navigate the challenges of moving their physical business to digital and engaging customers in a new way, for example, moving in-person experiences and classes online. For the next 12 months, these businesses will not need to comply with our payments policy, and we will continue to reassess the situation over the next year. For developers undergoing these changes, we're eager to hear from you and work with you to help you reach new users and grow your online businesses, while enabling a consistent and safe user experience online.

Q: Do Google’s apps have to follow this policy too?

A: Yes. Google Play’s developer policies - including the requirement that apps use Google Play’s billing system for in-app purchases of digital goods - apply to all apps on Play, including Google’s own apps.

Q: Can I communicate with my users about alternate ways to pay?

A: Yes. Outside of your app you are free to communicate with them about alternative purchase options. You can use email marketing and other channels outside of the app to provide subscription offers and even special pricing.

Q: Can I communicate with my users about promotions on other platforms?

A: Of course. We're an app developer too, and we know how important it is not to restrict your ability to communicate with your users. You can email them or otherwise communicate outside of the app information about your offerings, even if they are different on Google Play than in other places.

Q: Can I have different app features, prices and experience depending on the platform?

A: Yes. It is your service and business, it is up to you. We do not require parity across platforms. You can create different versions of your app to support different platforms, features and pricing models.

Q: Can I offer a consumption-only (reader) app on Play?

A: Yes. Google Play allows any app to be consumption-only, even if it is part of a paid service. For example, a user could login when the app opens and the user could access content paid for somewhere else.

Q: Does your billing policy change depending on what category my app is in?

A: No. Business or consumer apps, and verticals like music or email are all treated the same on Google Play.

Q: Can I offer my customers refunds directly?

A: Yes. We understand the importance of maintaining the relationship with your customers. You can continue to issue refunds to your customers and other customer support directly.

Q: Will Google Play allow cloud gaming apps?

A: Yes. Cloud game streaming apps that comply with Play’s policies from any developer are welcome on Google Play.

For more examples and best practices for in-app purchases, visit this Play Academy course and watch this video.

Answering your FAQs about Google Play billing

Posted by Mrinalini Loew, Group Product Manager

We are committed to providing powerful tools and services to help developers build and grow their businesses while ensuring a safe, secure and seamless experience for users. Today we are addressing some of the most common themes we hear in feedback from developers. Below are a few frequently asked developer questions that we thought would also be helpful to address.

Q: Can I distribute my app via other Android app stores or through my website?

A: Yes, you can distribute your app however you like! As an open ecosystem, most Android devices come preinstalled with more than one store - and users can install others. Android provides developers the freedom and flexibility to distribute apps through other Android app stores, directly via websites, or device preloads, all without using Google Play’s billing system.

Q: What apps need to use Google Play's billing system?

A: All apps distributed on Google Play that are offering in-app purchases of digital goods need to use Google Play’s billing system. Our payments policy has always required this. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. For those few developers that need to update their apps, they will have until September 30, 2021 to make those changes. New apps submitted after January 20, 2021 will need to be in compliance.

Q: Many businesses have needed to move their previously physical services online (e.g. digital live events). Will these apps need to use Google Play’s billing?

A: We recognize that the global pandemic has resulted in many businesses having to navigate the challenges of moving their physical business to digital and engaging customers in a new way, for example, moving in-person experiences and classes online. For the next 12 months, these businesses will not need to comply with our payments policy, and we will continue to reassess the situation over the next year. For developers undergoing these changes, we're eager to hear from you and work with you to help you reach new users and grow your online businesses, while enabling a consistent and safe user experience online.

Q: Do Google’s apps have to follow this policy too?

A: Yes. Google Play’s developer policies - including the requirement that apps use Google Play’s billing system for in-app purchases of digital goods - apply to all apps on Play, including Google’s own apps.

Q: Can I communicate with my users about alternate ways to pay?

A: Yes. Outside of your app you are free to communicate with them about alternative purchase options. You can use email marketing and other channels outside of the app to provide subscription offers and even special pricing.

Q: Can I communicate with my users about promotions on other platforms?

A: Of course. We're an app developer too, and we know how important it is not to restrict your ability to communicate with your users. You can email them or otherwise communicate outside of the app information about your offerings, even if they are different on Google Play than in other places.

Q: Can I have different app features, prices and experience depending on the platform?

A: Yes. It is your service and business, it is up to you. We do not require parity across platforms. You can create different versions of your app to support different platforms, features and pricing models.

Q: Can I offer a consumption-only (reader) app on Play?

A: Yes. Google Play allows any app to be consumption-only, even if it is part of a paid service. For example, a user could login when the app opens and the user could access content paid for somewhere else.

Q: Does your billing policy change depending on what category my app is in?

A: No. Business or consumer apps, and verticals like music or email are all treated the same on Google Play.

Q: Can I offer my customers refunds directly?

A: Yes. We understand the importance of maintaining the relationship with your customers. You can continue to issue refunds to your customers and other customer support directly.

Q: Will Google Play allow cloud gaming apps?

A: Yes. Cloud game streaming apps that comply with Play’s policies from any developer are welcome on Google Play.

For more examples and best practices for in-app purchases, visit this Play Academy course and watch this video.

All developers will get the new Google Play Console on November 2, 2020

Posted by Tom Grinsted, Product Manager, Google Play Console

We hope you’re enjoying the new Google Play Console. With over 350,000 people now using it as their default experience and thousands more providing feedback, the new Play Console is ready to come out of beta. Thank you to everyone who has helped to get it here. This means that the old Play Console will be discontinued starting November 2, 2020. After this date, you’ll be automatically directed to the new Play Console when you log into your account.

If you haven't tried it already, we recommend that you switch to the new version now. To get started, visit play.google.com/console.

The new Play Console’s responsive design means that you can use it across all of your devices. The new navigation makes it easier to find and understand important features, and we’ve added areas to help you better understand your release status, acquisition performance, and guidance on policy changes.

Thanks to your feedback, we’ve already made a lot of improvements:

  • We reorganized the releases area of the navigation. Production is now at the top level, and we've grouped all testing tracks together. Internal app sharing has moved to Setup.
  • Speed and performance on different browsers have increased, and we’ve made UI tweaks such as making text boxes resizable, introducing unread notices for messages, and refining headers on mobile so they use space more efficiently.
  • We launched Inbox, your personalized messaging area featuring helpful information, policy updates, feature recommendations, and more.
  • The new Publishing overview page lets you see what changes are in review. Managed publishing gives you control over your launch by allowing you to decide when approved changes are actually published.
  • Acquisition reports have been completely overhauled to help you understand your performance over time. This includes discontinuing some cohort-based metrics. These will not be available in the new console. If you want to keep a record of this data, please download it from the old Play Console before November 2. Find out more
  • You can still link to your Google Ads account for conversion tracking and remarketing lists, but Google Ads campaign reporting and account notifications will now be available exclusively in Google Ads.
  • You can now search across Play Console, making it easier to find pages and features quickly.
  • And lastly, we announced that later this year, all Play Console users will need to use 2-Step Verification.

To learn more about the new Play Console, you can:

  • Get a high-level overview of what’s new in this blog post.
  • Watch these videos for more in-depth information about the biggest changes.
  • Take a course on the Academy for App Success to become an expert on the new experience.
  • Dive into key features and find supporting information in the new education pages.

Thank you for being a part of our community, and we hope you enjoy the new Play Console!

How useful did you find this blog post?

All developers will get the new Google Play Console on November 2, 2020

Posted by Tom Grinsted, Product Manager, Google Play Console

We hope you’re enjoying the new Google Play Console. With over 350,000 people now using it as their default experience and thousands more providing feedback, the new Play Console is ready to come out of beta. Thank you to everyone who has helped to get it here. This means that the old Play Console will be discontinued starting November 2, 2020. After this date, you’ll be automatically directed to the new Play Console when you log into your account.

If you haven't tried it already, we recommend that you switch to the new version now. To get started, visit play.google.com/console.

The new Play Console’s responsive design means that you can use it across all of your devices. The new navigation makes it easier to find and understand important features, and we’ve added areas to help you better understand your release status, acquisition performance, and guidance on policy changes.

Thanks to your feedback, we’ve already made a lot of improvements:

  • We reorganized the releases area of the navigation. Production is now at the top level, and we've grouped all testing tracks together. Internal app sharing has moved to Setup.
  • Speed and performance on different browsers have increased, and we’ve made UI tweaks such as making text boxes resizable, introducing unread notices for messages, and refining headers on mobile so they use space more efficiently.
  • We launched Inbox, your personalized messaging area featuring helpful information, policy updates, feature recommendations, and more.
  • The new Publishing overview page lets you see what changes are in review. Managed publishing gives you control over your launch by allowing you to decide when approved changes are actually published.
  • Acquisition reports have been completely overhauled to help you understand your performance over time. This includes discontinuing some cohort-based metrics. These will not be available in the new console. If you want to keep a record of this data, please download it from the old Play Console before November 2. Find out more
  • You can still link to your Google Ads account for conversion tracking and remarketing lists, but Google Ads campaign reporting and account notifications will now be available exclusively in Google Ads.
  • You can now search across Play Console, making it easier to find pages and features quickly.
  • And lastly, we announced that later this year, all Play Console users will need to use 2-Step Verification.

To learn more about the new Play Console, you can:

  • Get a high-level overview of what’s new in this blog post.
  • Watch these videos for more in-depth information about the biggest changes.
  • Take a course on the Academy for App Success to become an expert on the new experience.
  • Dive into key features and find supporting information in the new education pages.

Thank you for being a part of our community, and we hope you enjoy the new Play Console!

How useful did you find this blog post?

Lockscreen and authentication improvements in Android 11

Android graphic

As phones become faster and smarter, they play increasingly important roles in our lives, functioning as our extended memory, our connection to the world at large, and often the primary interface for communication with friends, family, and wider communities. It is only natural that as part of this evolution, we’ve come to entrust our phones with our most private information, and in many ways treat them as extensions of our digital and physical identities.

This trust is paramount to the Android Security team. The team focuses on ensuring that Android devices respect the privacy and sensitivity of user data. A fundamental aspect of this work centers around the lockscreen, which acts as the proverbial front door to our devices. After all, the lockscreen ensures that only the intended user(s) of a device can access their private data.

This blog post outlines recent improvements around how users interact with the lockscreen on Android devices and more generally with authentication. In particular, we focus on two categories of authentication that present both immense potential as well as potentially immense risk if not designed well: biometrics and environmental modalities.

The tiered authentication model

Before getting into the details of lockscreen and authentication improvements, we first want to establish some context to help relate these improvements to each other. A good way to envision these changes is to fit them into the framework of the tiered authentication model, a conceptual classification of all the different authentication modalities on Android, how they relate to each other, and how they are constrained based on this classification.

The model itself is fairly simple, classifying authentication modalities into three buckets of decreasing levels of security and commensurately increasing constraints. The primary tier is the least constrained in the sense that users only need to re-enter a primary modality under certain situations (for example, after each boot or every 72 hours) in order to use its capability. The secondary and tertiary tiers are more constrained because they cannot be set up and used without having a primary modality enrolled first and they have more constraints further restricting their capabilities.

  1. Primary Tier - Knowledge Factor: The first tier consists of modalities that rely on knowledge factors, or something the user knows, for example, a PIN, pattern, or password. Good high-entropy knowledge factors, such as complex passwords that are hard to guess, offer the highest potential guarantee of identity.

    Knowledge factors are especially useful on Android becauses devices offer hardware backed brute-force protection with exponential-backoff, meaning Android devices prevent attackers from repeatedly guessing a PIN, pattern, or password by having hardware backed timeouts after every 5 incorrect attempts. Knowledge factors also confer additional benefits to all users that use them, such as File Based Encryption (FBE) and encrypted device backup.

  2. Secondary Tier - Biometrics: The second tier consists primarily of biometrics, or something the user is. Face or fingerprint based authentications are examples of secondary authentication modalities. Biometrics offer a more convenient but potentially less secure way of confirming your identity with a device.

    We will delve into Android biometrics in the next section.

  3. The Tertiary Tier - Environmental: The last tier includes modalities that rely on something the user has. This could either be a physical token, such as with Smart Lock’s Trusted Devices where a phone can be unlocked when paired with a safelisted bluetooth device. Or it could be something inherent to the physical environment around the device, such as with Smart Lock’s Trusted Places where a phone can be unlocked when it is taken to a safelisted location.

    Improvements to tertiary authentication

    While both Trusted Places and Trusted Devices (and tertiary modalities in general) offer convenient ways to get access to the contents of your device, the fundamental issue they share is that they are ultimately a poor proxy for user identity. For example, an attacker could unlock a misplaced phone that uses Trusted Place simply by driving it past the user's home, or with moderate amount of effort, spoofing a GPS signal using off-the-shelf Software Defined Radios and some mild scripting. Similarly with Trusted Device, access to a safelisted bluetooth device also gives access to all data on the user’s phone.

    Because of this, a major improvement has been made to the environmental tier in Android 10. The Tertiary tier was switched from an active unlock mechanism into an extending unlock mechanism instead. In this new mode, a tertiary tier modality can no longer unlock a locked device. Instead, if the device is first unlocked using either a primary or secondary modality, it can continue to keep it in the unlocked state for a maximum of four hours.

A closer look at Android biometrics

Biometric implementations come with a wide variety of security characteristics, so we rely on the following two key factors to determine the security of a particular implementation:

  1. Architectural security: The resilience of a biometric pipeline against kernel or platform compromise. A pipeline is considered secure if kernel and platform compromises don’t grant the ability to either read raw biometric data, or inject synthetic data into the pipeline to influence an authentication decision.
  2. Spoofability: Is measured using the Spoof Acceptance Rate (SAR). SAR is a metric first introduced in Android P, and is intended to measure how resilient a biometric is against a dedicated attacker. Read more about SAR and its measurement in Measuring Biometric Unlock Security.

We use these two factors to classify biometrics into one of three different classes in decreasing order of security:

  • Class 3 (formerly Strong)
  • Class 2 (formerly Weak)
  • Class 1 (formerly Convenience)

Each class comes with an associated set of constraints that aim to balance their ease of use with the level of security they offer.

These constraints reflect the length of time before a biometric falls back to primary authentication, and the allowed application integration. For example, a Class 3 biometric enjoys the longest timeouts and offers all integration options for apps, while a Class 1 biometric has the shortest timeouts and no options for app integration. You can see a summary of the details in the table below, or the full details in the Android Android Compatibility Definition Document (CDD).

1 App integration means exposing an API to apps (e.g., via integration with BiometricPrompt/BiometricManager, androidx.biometric, or FIDO2 APIs)

2 Keystore integration means integrating Keystore, e.g., to release app auth-bound keys

Benefits and caveats

Biometrics provide convenience to users while maintaining a high level of security. Because users need to set up a primary authentication modality in order to use biometrics, it helps boost the lockscreen adoption (we see an average of 20% higher lockscreen adoption on devices that offer biometrics versus those that do not). This allows more users to benefit from the security features that the lockscreen provides: gates unauthorized access to sensitive user data and also confers other advantages of a primary authentication modality to these users, such as encrypted backups. Finally, biometrics also help reduce shoulder surfing attacks in which an attacker tries to reproduce a PIN, pattern, or password after observing a user entering the credential.

However, it is important that users understand the trade-offs involved with the use of biometrics. Primary among these is that no biometric system is foolproof. This is true not just on Android, but across all operating systems, form-factors, and technologies. For example, a face biometric implementation might be fooled by family members who resemble the user or a 3D mask of the user. A fingerprint biometric implementation could potentially be bypassed by a spoof made from latent fingerprints of the user. Although anti-spoofing or Presentation Attack Detection (PAD) technologies have been actively developed to mitigate such spoofing attacks, they are mitigations, not preventions.

One effort that Android has made to mitigate the potential risk of using biometrics is the lockdown mode introduced in Android P. Android users can use this feature to temporarily disable biometrics, together with Smart Lock (for example, Trusted Places and Trusted Devices) as well as notifications on the lock screen, when they feel the need to do so.

To use the lockdown mode, users first need to set up a primary authentication modality and then enable it in settings. The exact setting where the lockdown mode can be enabled varies by device models, and on a Google Pixel 4 device it is under Settings > Display > Lock screen > Show lockdown option. Once enabled, users can trigger the lockdown mode by holding the power button and then clicking the Lockdown icon on the power menu. A device in lockdown mode will return to the non-lockdown state after a primary authentication modality (such as a PIN, pattern, or password) is used to unlock the device.

BiometricPrompt - New APIs

In order for developers to benefit from the security guarantee provided by Android biometrics and to easily integrate biometric authentication into their apps to better protect sensitive user data, we introduced the BiometricPrompt APIs in Android P.

There are several benefits of using the BiometricPrompt APIs. Most importantly, these APIs allow app developers to target biometrics in a modality-agnostic way across different Android devices (that is, BiometricPrompt can be used as a single integration point for various biometric modalities supported on devices), while controlling the security guarantees that the authentication needs to provide (such as requiring Class 3 or Class 2 biometrics, with device credential as a fallback). In this way, it helps protect app data with a second layer of defenses (in addition to the lockscreen) and in turn respects the sensitivity of user data. Furthermore, BiometricPrompt provides a persistent UI with customization options for certain information (for example, title and description), offering a consistent user experience across biometric modalities and across Android devices.

As shown in the following architecture diagram, apps can integrate with biometrics on Android devices through either the framework API or the support library (that is, androidx.biometric for backward compatibility). One thing to note is that FingerprintManager is deprecated because developers are encouraged to migrate to BiometricPrompt for modality-agnostic authentications.

Improvements to BiometricPrompt

Android 10 introduced the BiometricManager class that developers can use to query the availability of biometric authentication and included fingerprint and face authentication integration for BiometricPrompt.

In Android 11, we introduce new features such as the BiometricManager.Authenticators interface which allows developers to specify the authentication types accepted by their apps, as well as additional support for auth-per-use keys within the BiometricPrompt class.

More details can be found in the Android 11 preview and Android Biometrics documentation. Read more about BiometricPrompt API usage in our blog post Using BiometricPrompt with CryptoObject: How and Why and our codelab Login with Biometrics on Android.

Lockscreen and authentication improvements in Android 11

Android graphic

As phones become faster and smarter, they play increasingly important roles in our lives, functioning as our extended memory, our connection to the world at large, and often the primary interface for communication with friends, family, and wider communities. It is only natural that as part of this evolution, we’ve come to entrust our phones with our most private information, and in many ways treat them as extensions of our digital and physical identities.

This trust is paramount to the Android Security team. The team focuses on ensuring that Android devices respect the privacy and sensitivity of user data. A fundamental aspect of this work centers around the lockscreen, which acts as the proverbial front door to our devices. After all, the lockscreen ensures that only the intended user(s) of a device can access their private data.

This blog post outlines recent improvements around how users interact with the lockscreen on Android devices and more generally with authentication. In particular, we focus on two categories of authentication that present both immense potential as well as potentially immense risk if not designed well: biometrics and environmental modalities.

The tiered authentication model

Before getting into the details of lockscreen and authentication improvements, we first want to establish some context to help relate these improvements to each other. A good way to envision these changes is to fit them into the framework of the tiered authentication model, a conceptual classification of all the different authentication modalities on Android, how they relate to each other, and how they are constrained based on this classification.

The model itself is fairly simple, classifying authentication modalities into three buckets of decreasing levels of security and commensurately increasing constraints. The primary tier is the least constrained in the sense that users only need to re-enter a primary modality under certain situations (for example, after each boot or every 72 hours) in order to use its capability. The secondary and tertiary tiers are more constrained because they cannot be set up and used without having a primary modality enrolled first and they have more constraints further restricting their capabilities.

  1. Primary Tier - Knowledge Factor: The first tier consists of modalities that rely on knowledge factors, or something the user knows, for example, a PIN, pattern, or password. Good high-entropy knowledge factors, such as complex passwords that are hard to guess, offer the highest potential guarantee of identity.

    Knowledge factors are especially useful on Android becauses devices offer hardware backed brute-force protection with exponential-backoff, meaning Android devices prevent attackers from repeatedly guessing a PIN, pattern, or password by having hardware backed timeouts after every 5 incorrect attempts. Knowledge factors also confer additional benefits to all users that use them, such as File Based Encryption (FBE) and encrypted device backup.

  2. Secondary Tier - Biometrics: The second tier consists primarily of biometrics, or something the user is. Face or fingerprint based authentications are examples of secondary authentication modalities. Biometrics offer a more convenient but potentially less secure way of confirming your identity with a device.

    We will delve into Android biometrics in the next section.

  3. The Tertiary Tier - Environmental: The last tier includes modalities that rely on something the user has. This could either be a physical token, such as with Smart Lock’s Trusted Devices where a phone can be unlocked when paired with a safelisted bluetooth device. Or it could be something inherent to the physical environment around the device, such as with Smart Lock’s Trusted Places where a phone can be unlocked when it is taken to a safelisted location.

    Improvements to tertiary authentication

    While both Trusted Places and Trusted Devices (and tertiary modalities in general) offer convenient ways to get access to the contents of your device, the fundamental issue they share is that they are ultimately a poor proxy for user identity. For example, an attacker could unlock a misplaced phone that uses Trusted Place simply by driving it past the user's home, or with moderate amount of effort, spoofing a GPS signal using off-the-shelf Software Defined Radios and some mild scripting. Similarly with Trusted Device, access to a safelisted bluetooth device also gives access to all data on the user’s phone.

    Because of this, a major improvement has been made to the environmental tier in Android 10. The Tertiary tier was switched from an active unlock mechanism into an extending unlock mechanism instead. In this new mode, a tertiary tier modality can no longer unlock a locked device. Instead, if the device is first unlocked using either a primary or secondary modality, it can continue to keep it in the unlocked state for a maximum of four hours.

A closer look at Android biometrics

Biometric implementations come with a wide variety of security characteristics, so we rely on the following two key factors to determine the security of a particular implementation:

  1. Architectural security: The resilience of a biometric pipeline against kernel or platform compromise. A pipeline is considered secure if kernel and platform compromises don’t grant the ability to either read raw biometric data, or inject synthetic data into the pipeline to influence an authentication decision.
  2. Spoofability: Is measured using the Spoof Acceptance Rate (SAR). SAR is a metric first introduced in Android P, and is intended to measure how resilient a biometric is against a dedicated attacker. Read more about SAR and its measurement in Measuring Biometric Unlock Security.

We use these two factors to classify biometrics into one of three different classes in decreasing order of security:

  • Class 3 (formerly Strong)
  • Class 2 (formerly Weak)
  • Class 1 (formerly Convenience)

Each class comes with an associated set of constraints that aim to balance their ease of use with the level of security they offer.

These constraints reflect the length of time before a biometric falls back to primary authentication, and the allowed application integration. For example, a Class 3 biometric enjoys the longest timeouts and offers all integration options for apps, while a Class 1 biometric has the shortest timeouts and no options for app integration. You can see a summary of the details in the table below, or the full details in the Android Android Compatibility Definition Document (CDD).

1 App integration means exposing an API to apps (e.g., via integration with BiometricPrompt/BiometricManager, androidx.biometric, or FIDO2 APIs)

2 Keystore integration means integrating Keystore, e.g., to release app auth-bound keys

Benefits and caveats

Biometrics provide convenience to users while maintaining a high level of security. Because users need to set up a primary authentication modality in order to use biometrics, it helps boost the lockscreen adoption (we see an average of 20% higher lockscreen adoption on devices that offer biometrics versus those that do not). This allows more users to benefit from the security features that the lockscreen provides: gates unauthorized access to sensitive user data and also confers other advantages of a primary authentication modality to these users, such as encrypted backups. Finally, biometrics also help reduce shoulder surfing attacks in which an attacker tries to reproduce a PIN, pattern, or password after observing a user entering the credential.

However, it is important that users understand the trade-offs involved with the use of biometrics. Primary among these is that no biometric system is foolproof. This is true not just on Android, but across all operating systems, form-factors, and technologies. For example, a face biometric implementation might be fooled by family members who resemble the user or a 3D mask of the user. A fingerprint biometric implementation could potentially be bypassed by a spoof made from latent fingerprints of the user. Although anti-spoofing or Presentation Attack Detection (PAD) technologies have been actively developed to mitigate such spoofing attacks, they are mitigations, not preventions.

One effort that Android has made to mitigate the potential risk of using biometrics is the lockdown mode introduced in Android P. Android users can use this feature to temporarily disable biometrics, together with Smart Lock (for example, Trusted Places and Trusted Devices) as well as notifications on the lock screen, when they feel the need to do so.

To use the lockdown mode, users first need to set up a primary authentication modality and then enable it in settings. The exact setting where the lockdown mode can be enabled varies by device models, and on a Google Pixel 4 device it is under Settings > Display > Lock screen > Show lockdown option. Once enabled, users can trigger the lockdown mode by holding the power button and then clicking the Lockdown icon on the power menu. A device in lockdown mode will return to the non-lockdown state after a primary authentication modality (such as a PIN, pattern, or password) is used to unlock the device.

BiometricPrompt - New APIs

In order for developers to benefit from the security guarantee provided by Android biometrics and to easily integrate biometric authentication into their apps to better protect sensitive user data, we introduced the BiometricPrompt APIs in Android P.

There are several benefits of using the BiometricPrompt APIs. Most importantly, these APIs allow app developers to target biometrics in a modality-agnostic way across different Android devices (that is, BiometricPrompt can be used as a single integration point for various biometric modalities supported on devices), while controlling the security guarantees that the authentication needs to provide (such as requiring Class 3 or Class 2 biometrics, with device credential as a fallback). In this way, it helps protect app data with a second layer of defenses (in addition to the lockscreen) and in turn respects the sensitivity of user data. Furthermore, BiometricPrompt provides a persistent UI with customization options for certain information (for example, title and description), offering a consistent user experience across biometric modalities and across Android devices.

As shown in the following architecture diagram, apps can integrate with biometrics on Android devices through either the framework API or the support library (that is, androidx.biometric for backward compatibility). One thing to note is that FingerprintManager is deprecated because developers are encouraged to migrate to BiometricPrompt for modality-agnostic authentications.

Improvements to BiometricPrompt

Android 10 introduced the BiometricManager class that developers can use to query the availability of biometric authentication and included fingerprint and face authentication integration for BiometricPrompt.

In Android 11, we introduce new features such as the BiometricManager.Authenticators interface which allows developers to specify the authentication types accepted by their apps, as well as additional support for auth-per-use keys within the BiometricPrompt class.

More details can be found in the Android 11 preview and Android Biometrics documentation. Read more about BiometricPrompt API usage in our blog post Using BiometricPrompt with CryptoObject: How and Why and our codelab Login with Biometrics on Android.

Introducing Android 11 on Android TV

Posted by Wolfram Klein, Product Manager, Android TV

Android TV graphic

We’ve been turning it up to 11 all summer long, leading up to the launch of Android 11 on mobile. Now, following right behind the mobile release, we are launching Android 11 on Android TV to bring the latest platform features to the big screen.

Android 11 on Android TV introduces performance and privacy improvements, new features tailored for the TV, and updated developer tools, in addition to enabling many of the features we announced during the #11WeeksOfAndroid.

Foundational Improvements

Android TV continues to bring many of the benefits that come with the core Android update to the TV. With Android 11, performance improvements, like enhanced memory management, and privacy features, like one-time permissions, are introduced to make sure TV devices work quickly and securely.

Tailored for the TV

Android 11 emphasizes media by bringing support for Auto Low Latency Mode, and low latency media decoding, along with a new Tuner Framework with updated Media CAS support and extensions to the HAL implementation of HDMI CEC.

With extended gamepad support, silent boot mode for system updates, inactivity prompts, and OEM configurable wake keys, Android 11 allows greater control over TV functions. New framework functionality for managing System LEDs and physical microphone mute buttons also facilitate integrations for far-field microphone enabled devices.

Faster Testing

Testing on the TV is now easier than ever. The addition of test harness mode on Android TV and Play Store support in the Android TV Emulator help you seamlessly inspect your apps as you develop.

Android TV OEM partners will be launching and upgrading devices to Android 11 over the coming months. To help you test your Android TV app implementations for the next generation of devices, Android 11 will be available as a system update to ADT-3 devices today. To learn more about getting your Android TV app ready for Android 11, visit our developers page.

We're looking forward to seeing your apps on Android 11!

Improve Your Game with Texture Compression Format Targeting

Posted by Yafit Becher, Product Manager & Dan Galpin, Developer Advocate

Play Asset Delivery downloads the best supported texture for the device

Google Play Asset Delivery allows you to publish an Android App Bundle to Google Play containing all the resources your game needs. It offers multiple delivery modes, auto-updates, compression, and delta patching, all hosted at no cost to you.

As of today, you can use Google Play Asset Delivery to include textures in multiple texture compression formats in your Android App Bundle and Google Play will automatically deliver the assets with the best supported texture compression format for each device. With Texture Compression Format Targeting, you can start using ASTC for devices that support it while falling back to ETC2/ETC1 to devices that don’t. The Adaptive Scalable Texture Compression (ASTC) format offers advantages, such as improved rendering performance, faster load times, a smaller in-memory footprint, better battery life, and improved visual quality. You can even dramatically reduce your download size and on-device footprint by optimizing the tradeoff between size and quality.

Higher bandwidth version of much of this information

Android App Bundle will be the required publishing format for all new games and apps as of August 2021, which means that Google Play Asset Delivery will be required for new games that want Google Play to host more than 150MB of assets. Texture format targeting provides value even for smaller games due to the advantages of newer texture compression formats.

Texture compression

Texture compression is a form of lossy image compression that allows the GPU to render directly from the compressed texture using specialized silicon blocks, reducing the texture memory and memory bandwidth required to render the texture. As GPUs have gotten more advanced, more sophisticated texture compression formats have been developed, but not all GPUs can take advantage of them.

ASTC was released in 2012 to give developers more flexibility in trading compression size vs image quality. It compresses using fixed 128-bit block sizes, but allows for variable block footprints from 4x4 (8 bits per texel) to 12x12 (.89 bits per texel).

Texture compression format image  Texture compression format image Texture compression format image

Googleplex from Google Earth at 12x12 (.89 BPT), 6x5 (4.27 BPT), 4x4 (8 BPT)

This allows almost any type of texture to be used in compressed form, and allows for textures to occupy much less space in RAM — up to 36x less space compared to uncompressed 2D textures depending on quality. Smaller textures also take less time to load, making games start faster.

Memory bandwidth

Since the GPU needs to do fewer reads from texture memory in order to render the texture, the memory bandwidth required to render the scene is reduced, often substantially when texture caches are taken into account.

Texture compression formats in Android

The top compression formats in Android are ETC1, ETC2, and ASTC.

texture compression image

Top texture compression formats with device penetration as of September 2020

ETC1 is supported on practically all devices. It has no transparency support; games can use a second texture for the alpha component. It has quality issues with sharp transitions such as edges and text.

ETC2 is supported by all devices that support GLES3. It supports multiple transparency modes and improves quality compared to ETC1.

ASTC is a more recent format that's more flexible; it supports many different kinds of textures, allowing for just about any texture in your game to benefit from compression. In addition, it supports various block sizes with different associated compression ratios. Using this format is a good way to optimize the size, image quality, and performance of your game.

Asphalt Xtreme Gameloft image

When experimenting with ASTC on Asphalt Xtreme Gameloft found that they could reduce the size of their game by up to 30%

Using texture compression format targeting

Once you've implemented Google Play Asset Delivery in your game, adding texture format targeting is an incremental step. Inside your asset packs, make sure you have a directory that holds just your textures, such as [assetpackname]/textures. This directory will be used to hold default textures (probably in ETC1 or ETC2 format).

Then, create additional texture directories with a suffix representing the additional formats you wish to support.

[assetpackname]/textures#tcf_etc2
[assetpackname]/textures#tcf_astc

Finally, update your app build.gradle file to enable texture splits in asset packs:

// In the app build.gradle file:
android {
    ...
    bundle {
        texture {
            enableSplit true
        }
    }
}

Google Play strips off the texture suffixes so your game reads its assets from the default directory, regardless of what textures are delivered to the device.

If you're using Unity, our Play Asset Delivery plugin for Unity is ready to create app bundles with texture-targeted packs.

Texture compression format targeting is available now

We're committed to helping you serve your entire game through Play with customized dynamic delivery and features such as texture compression format targeting. Documentation at d.android.com will walk you through the integration process depending on the game engine you use, and we also have codelabs ready for both C/C++ and Unity games. We have more information on all of our game related developer resources at d.android.com/games and stay up to date with Google Play Asset Delivery and other game developer tools by signing up for the games quarterly newsletter.

Android GPU Inspector Open Beta

Posted by Jay Kong, Gaming and Graphics Product Manager

With the rollout of Android 11 on Pixel, Android GPU Inspector (AGI) has graduated from a limited developer preview to an open beta. During the preview, AGI has been helpful in finding performance bottlenecks for developers we've been working with, and we're looking forward to hearing your feedback.

What is Android GPU Inspector?

AGI is a graphics profiling tool that allows you to look into the GPU of Android devices to better understand graphics bottlenecks and optimize the performance of games and apps that leverage 3D graphics APIs. It shows a timeline of events for your running game or app, which includes system activities, high frequency GPU hardware counters, and, if you are using Vulkan, GPU activity information.

Android

What devices can I use it on?

AGI relies on updated firmware and video drivers to get information it needs; the first devices to support it are the Pixel 4 and 4XL running Android 11. While we are working with device manufacturers and SoC vendors to enable more supported devices, the key insight we’ve learned on our journey is that being able to look into the GPU—even on a single device—creates a lot of value.

Working with Blizzard Entertainment Inc. and NetEase, Inc., AGI helped pinpoint 45% vertex bandwidth savings for the upcoming Diablo Immortal, a dark gothic action RPG game.

Diablo:

Diablo: Immortal

Working with King, AGI helped improve GPU frame time from 11-16ms to a stable 8ms for the upcoming Crash Bandicoot: On the Run!, allowing the game to reduce battery drain and run faster for a smoother experience.

Crash Bandicoot: On the Run

Crash Bandicoot: On The Run

In collaboration with Jam City, AGI helped reduce GPU frametime by 45% on World War Doh: Real Time PvP.

World War Doh: Real Time PvP

World War Doh: Real Time PvP

Optimization tutorials

Stay tuned for more information on how to use the tool and address common issues we’ve seen when working with real games. We’ll begin by demonstrating using AGI to indicate optimizations to make in your game’s textures.

You can also read about this topic on Medium, here.

How do I get started?

You can download AGI here, and the setup instructions are here. AGI is in beta, so there will be issues. Check out the release notes, and let us know if you see any issues here.

To learn about new device support, you can check this page. Stay up to date with AGI and all of our game developer tools by signing up for the games quarterly newsletter.