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:
We’d like to share our perspective on each of these points.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A: No. Business or consumer apps, and verticals like music or email are all treated the same on Google Play.
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.
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.
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:
To learn more about the new Play Console, you can:
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?
★ ★ ★ ★ ★
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.
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.
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.
We will delve into Android biometrics in the next section.
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.
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:
We use these two factors to classify biometrics into one of three different classes in decreasing order of security:
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
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.
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.
BiometricPrompt
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.
androidx.biometric
FingerprintManager
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.
BiometricManager
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.
BiometricManager.Authenticators
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.
Posted by Wolfram Klein, Product Manager, Android TV
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!
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 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).
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.
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.
The top compression formats in Android are ETC1, ETC2, and ASTC.
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.
When experimenting with ASTC on Asphalt Xtreme Gameloft found that they could reduce the size of their game by up to 30%
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).
[assetpackname]/textures
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:
build.gradle
// 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.
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.
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.
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.
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: 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
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
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.
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.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
