Android Developers Blog

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

24 September 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

22 September 2020

Posted by Haining Chen, Vishwath Mohan, Kevin Chyn and Liz Louis, Android Security Team

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.

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.

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.

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:

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.

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).

¹ App integration means exposing an API to apps (e.g., via integration with BiometricPrompt/BiometricManager, androidx.biometric, or FIDO2 APIs) ² 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

22 September 2020

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!

Improve Your Game with Texture Compression Format Targeting

21 September 2020

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).

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.

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% 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

14 September 2020

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.

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: 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 PvPOptimization 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.

Turning it up to 11: Android 11 for developers

08 September 2020

Posted by Stephanie Cuthbertson, Director, Product Management

Android 11 is here! Today we’re pushing the source to the Android Open Source Project (AOSP) and officially releasing the newest version of Android. We built Android 11 with a focus on three themes: a People-centric approach to communication, Controls to let users quickly get to and control all of their smart devices, and Privacy to give users more ways to control how data on devices is shared. Read more in our Keyword post. For developers, Android 11 has a ton of new capabilities. You’ll want to check out conversation notifications, device and media controls, one-time permissions, enhanced 5G support, IME transitions, and so much more. To help you work and develop faster, we also added new tools like compatibility toggles, ADB incremental installs, app exit reasons API, data access auditing API, Kotlin nullability annotations, and many others. We worked to make Android 11 a great release for you, and we can’t wait to see what you’ll build! Watch for official Android 11 coming to a device near you, starting today with Pixel 2, 3, 3a, 4, and 4a devices. To get started, visit the Android 11 developer site. People, Controls, PrivacyPeople Android 11 is people-centric and expressive, reimagining the way we have conversations on our phones, and building an OS that can recognize and prioritize the most important people in our lives. For developers, Android 11 helps you build deeper conversational and personal interactions into your apps.

Conversation notifications appear in a dedicated section at the top of the shade, with a people-forward design and conversation specific actions, such as opening the conversation as a bubble, creating a conversation shortcut on the home screen, or setting a reminder.

Bubbles - Bubbles help users keep conversations in view and accessible while multitasking on their devices. Messaging and chat apps should use the Bubbles API on notifications to enable this in Android 11.

Consolidated keyboard suggestions let Autofill apps and Input Method Editors (IMEs) securely offer users context-specific entities and strings directly in an IME’s suggestion strip, where they are most convenient for users.

Bubbles and people-centric conversations.Controls Android 11 lets users quickly get to and control all of their smart devices in one space. Developers can use new APIs to help users surface smart devices and control media:

Device Controls make it faster and easier than ever for users to access and control their connected devices. Now, by simply long pressing the power button, they’re able to bring up device controls instantly, and in one place. Apps can use a new API to appear in the controls. More here.

Media Controls make it quick and convenient for users to switch the output device for their audio or video content, whether it be headphones, speakers or even their TV. More here.

Device controls and media controls.Privacy In Android 11, we’re giving users even more control and transparency over sensitive permissions and working to keep devices more secure through faster updates. One-time permission - Now users can give an app access to the device microphone, camera, or location, just for one time. The app can request permissions again the next time the app is used. More here.

One-time permission dialog in Android 11. Background location - Background location now requires additional steps from the user beyond granting a runtime permission. If your app needs background location, the system will ensure that you first ask for foreground location. You can then broaden your access to background location through a separate permission request, and the system will take the user to Settings to complete the permission grant. Also note that in February we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021. Permissions auto-reset - if users haven’t used an app for an extended period of time, Android 11 will “auto-reset” all of the runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. More here. Scoped storage - We’ve continued our work to better protect app and user data on external storage, and made further improvements to help developers more easily migrate. More here. Google Play system updates - Launched last year, Google Play system updates help us expedite updates of core OS components to devices in the Android ecosystem. In Android 11, we more than doubled the number of updatable modules, including 12 new modules that will help improve privacy, security, and consistency for users and developers. BiometricPrompt API - Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. For backward compatibility, we’ve just added these capabilities to the Jetpack Biometric library. We’ll share further updates as the work progresses. Identity Credential API - This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for digital-first identity experiences. You can read about all of the Android 11 privacy features here. Helpful innovation Enhanced 5G support - Android 11 includes updated developer support to help you take advantage of the faster speeds and lower latency of 5G networks. You can learn when the user is connected to a 5G network, check whether the connection is metered, and get an estimate of the connection bandwidth. To help you build experiences now for 5G, we’ve also added 5G support in the Android Emulator. To get started with 5G on Android, visit the 5G developer page.

Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses. New screen types - Device makers are continuing to innovate by bringing exciting new device screens to market, such as hole-punch and waterfall screens. Android 11 adds support for these in the platform, with APIs to let you optimize your apps. You can manage both hole-punch and waterfall screens using the existing display cutout APIs. You can set a new window layout attribute to use the entire waterfall screen, and a new waterfall insets API helps you manage interaction near the edges. Call screening support - Android 11 helps call-screening apps do more to manage robocalls. Apps can verify an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of the call details, and they can report a call rejection reason. Apps can also customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts. Polish and quality OS resiliency - In Android 11 we’ve made the OS more dynamic and resilient as a whole by fine-tuning memory reclaiming processes, such as forcing user-imperceptible restarts of processes based on RSS HWM thresholds. Also, to improve performance and memory, Android 11 adds Binder caching, which optimizes highly used IPC calls to system services by caching data for those that retrieve relatively static data. Binder caching also improves battery life by reducing CPU time. Synchronized IME transitions - New APIs let you synchronize your app’s content with the IME (input method editor, or on-screen keyboard) and system bars as they animate on and offscreen, making it much easier to create natural, intuitive and jank-free IME transitions. For frame-perfect transitions, a new WindowInsetsAnimation.Callback API notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, you can use a new WindowInsetsAnimationController API to control system UI types like system bars, IME, immersive mode, and others. More here.

Synchronized IME transition through insets animation listener.

App-driven IME experience through WindowInsetsAnimationController.

HEIF animated drawables - The ImageDecoder API now lets you decode and render image sequence animations stored in HEIF files, so you can make use of high-quality assets while minimizing impact on network data and APK size. HEIF image sequences can offer drastic file-size reductions for image sequences when compared to animated GIFs. Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples of how to use the APIs. Low-latency video decoding in MediaCodec - Low latency video is critical for real-time video streaming apps and services like Stadia. Video codecs that support low latency playback return the first frame of the stream as quickly as possible after decoding starts. Apps can use new APIs to check and configure low-latency playback for a specific codec. Variable refresh rate - Apps and games can use a new API to set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some support multiple refresh rates, such as 90Hz as well as 60Hz, with runtime switching. On these devices, the system uses the app’s preferred frame rate to choose the best refresh rate for the app. The API is available in both the SDK and NDK. See the details here. Dynamic resource loader - Android 11 includes a new public API to let apps load resources and assets dynamically at runtime. With the Resource Loader framework you can include a base set of resources in your app or game and then load additional resources, or modify the loaded resources, as needed at runtime. Neural Networks API (NNAPI) 1.3 - We continue to add ops and controls to support machine learning on Android devices. To optimize common use-cases, NNAPI 1.3 adds APIs for priority and timeout, memory domains, and asynchronous command queue. New ops for advanced models include signed integer asymmetric quantization, branching and loops, and a hard-swish op that helps accelerate next-generation on-device vision models such as MobileNetV3. Developer friendliness App compatibility tools - We worked to minimize compatibility impacts on your apps by making most Android 11 behavior changes opt-in, so they won’t take effect until you change the apps’ targetSdkVersion to 30. If you are distributing through Google Play, you’ll have more than a year to opt-in to these changes, but we recommend getting started testing early. To help you test, Android 11 lets you enable or disable many of the opt-in changes individually. More here.
App exit reasons - When your app exits, it’s important to understand why the app exited and what the state was at the time -- across the many device types, memory configurations, and user scenarios that your app runs in. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits. Data access auditing - data access auditing lets you instrument your app to better understand how it accesses user data and from which user flows. For example, it can help you identify any inadvertent access to private data in your own code or within any SDKs you might be using. More here. ADB Incremental - Installing very large APKs with ADB (Android Debug Bridge) during development can be slow and impact your productivity, especially those developers working on Android Games. With ADB Incremental in Android 11, installing large APKs (2GB+) from your development computer to an Android 11 device is up to 10x faster. More here. Kotlin nullability annotations - Android 11 adds nullability annotations to more methods in the public API. And, it upgrades a number of existing annotations from warnings to errors. These help you catch nullability issues at build time, rather than at runtime. More here. Get your apps ready for Android 11 With Android 11 on its way to users, now is the time to finish your compatibility testing and publish your updates.

Flow chart steps for getting your apps ready for Android 11.

Here are some of the top behavior changes to watch for (these apply regardless of your app’s targetSdkVersion):

One-time permission - Users can now grant single-use permission to access location, device microphone and camera. More here.

External storage access - Apps can no longer access other apps’ files in external storage. More here.

Scudo hardened allocator - Scudo is now the heap memory allocator for native code in apps. More here.

File descriptor sanitizer - Fdsan is now enabled by default to detect file descriptor handling issues for native code in apps. More here.

Android 11 also includes opt-in behavior changes - these affect your app once it’s targeting the new platform. We recommend assessing these changes as soon as you’ve published the compatible version of your app. For more information on compatibility testing and tools, check out the resources we shared for Android 11 Compatibility week and visit the Android 11 developer site for technical details. Enhance your app with new features and APIs Next, when you're ready, dive into Android 11 and learn about the new features and APIs that you can use. Here are some of the top features to get started with. We recommend these for all apps:

Dark theme (from Android 10) - Make sure to provide a consistent experience for users who enable system-wide dark theme by adding a Dark theme or enabling Force Dark.

Gesture navigation (from Android 10) - Support gesture navigation by going edge-to-edge and ensure that custom gestures work well with gestures. More here.

Sharing shortcuts (from Android 10) - Apps that want to receive shared data should use the sharing shortcuts APIs to create share targets. Apps that want to send shared data should make sure to use the system share sheet.

Synchronized IME transitions - Provide seamless transitions to your users using the new WindowInsets and related APIs. More here.

New screen types - for devices with hole-punch or waterfall screens, make sure to test and adjust your content for these screens as needed. More here.

We recommend these if relevant for your app:

Conversations - Messaging and communication apps can participate in the conversation experience by providing long-lived sharing shortcuts and surfacing conversations in notifications. More here.

Bubbles - Bubbles are a way to keep conversations in view and accessible while multitasking. Use the Bubbles API on notifications to enable this.

5G - If your app or content can benefit from the faster speeds and lower latency of 5G, explore our developer resources to see what you can build.

Device controls - If your app supports external smart devices, make sure those devices are accessible from the new Android 11 device controls area. More here.

Media controls - For media apps, we recommend supporting the Android 11 media controls so users can manage playback and resumption from the Quick Settings shade. More here.

Read more about all of the Android 11 features at developer.android.com/11. Coming to a device near you! Android 11 will begin rolling out today on select Pixel, OnePlus, Xiaomi, OPPO and realme phones, with more partners launching and upgrading devices over the coming months. If you have a Pixel 2, 3, 3a, 4, or 4a phone, including those enrolled in this year’s Beta program, watch for the over-the-air update arriving soon! Android 11 factory system images for Pixel devices are also available through the Android Flash Tool, or you can download them here. As always, you can get the latest Android Emulator system images via the SDK Manager in Android Studio. For broader testing on other Treble-compliant devices, Generic System Images (GSI) are available here. If you're looking for the Android 11 source code, you'll find it here in the Android Open Source Project repository under the Android 11 branches. What’s next? We’ll soon be closing the preview issue tracker and retiring open bugs logged against Developer Preview or Beta builds, but please keep the feedback coming! If you still see an issue that you filed in the preview tracker, just file a new issue against Android 11 in the AOSP issue tracker. Thanks again to the many developers and early adopters who participated in the preview program this year! You gave us great feedback to help shape the release, and you filed thousands of issues that have made Android 11 a better platform for everyone. We're looking forward to seeing your apps on Android 11!

Prefer Storing Data with Jetpack DataStore

02 September 2020

Posted by Florina Muntenescu, Android Developer Advocate, Rohit Sathyanarayana, Software Engineer Welcome Jetpack DataStore, now in alpha - a new and improved data storage solution aimed at replacing SharedPreferences. Built on Kotlin coroutines and Flow, DataStore provides two different implementations: Proto DataStore, that lets you store typed objects (backed by protocol buffers) and Preferences DataStore, that stores key-value pairs. Data is stored asynchronously, consistently, and transactionally, overcoming most of the drawbacks of SharedPreferences. SharedPreferences vs DataStore

* SharedPreferences has a synchronous API that can appear safe to call on the UI thread, but which actually does disk I/O operations. Furthermore, apply() blocks the UI thread on fsync(). Pending fsync() calls are triggered every time any service starts or stops, and every time an activity starts or stops anywhere in your application. The UI thread is blocked on pending fsync() calls scheduled by apply(), often becoming a source of ANRs. ** SharedPreferences throws parsing errors as runtime exceptions. In both implementations, DataStore saves the preferences in a file and performs all data operations on Dispatchers.IO unless specified otherwise. While both Preferences DataStore and Proto DataStore allow saving data, they do this in different ways:

Preference DataStore, like SharedPreferences, has no way to define a schema or to ensure that keys are accessed with the correct type.

Proto DataStore lets you define a schema using Protocol buffers. Using Protobufs allows persisting strongly typed data. They are faster, smaller, simpler, and less ambiguous than XML and other similar data formats. While Proto DataStore requires you to learn a new serialization mechanism, we believe that the strongly typed schema advantage brought by Proto DataStore is worth it.

Room vs DataStore If you have a need for partial updates, referential integrity, or support for large/complex datasets, you should consider using Room instead of DataStore. DataStore is ideal for small , simple datasets and does not support partial updates or referential integrity. Using DataStore Start by adding the DataStore dependency. If you’re using Proto DataStore, make sure you also add the proto dependency: // Preferences DataStore implementation "androidx.datastore:datastore-preferences:1.0.0-alpha01" // Proto DataStore implementation "androidx.datastore:datastore-core:1.0.0-alpha01" When working with Proto DataStore, you define your schema in a proto file in the app/src/main/proto/ directory. See the protobuf language guide for more information on defining a proto schema. syntax = "proto3"; option java_package = "<your package name here>"; option java_multiple_files = true; message Settings { int my_counter = 1; }Create the DataStore Create the DataStore with the Context.createDataStore() extension functions. // with Preferences DataStore val dataStore: DataStore<Preferences> = context.createDataStore( name = "settings" ) If you’re using Proto DataStore, you’ll also have to implement the Serializer interface to tell DataStore how to read and write your data type. object SettingsSerializer : Serializer<Settings> { override fun readFrom(input: InputStream): Settings { try { return Settings.parseFrom(input) } catch (exception: InvalidProtocolBufferException) { throw CorruptionException("Cannot read proto.", exception) } } override fun writeTo(t: Settings, output: OutputStream) = t.writeTo(output) } // with Proto DataStore val settingsDataStore: DataStore<Settings> = context.createDataStore( fileName = "settings.pb", serializer = SettingsSerializer )Read data from DataStore DataStore exposes the stored data in a Flow, either in a Preferences object or as the object defined in your proto schema. DataStore ensures that data is retrieved on Dispatchers.IO so your UI thread isn’t blocked. With Preferences DataStore: val MY_COUNTER = preferencesKey<Int>("my_counter") val myCounterFlow: Flow<Int> = dataStore.data .map { currentPreferences -> // Unlike Proto DataStore, there's no type safety here. currentPreferences[MY_COUNTER] ?: 0 } With Proto DataStore: val myCounterFlow: Flow<Int> = settingsDataStore.data .map { settings -> // The myCounter property is generated for you from your proto schema! settings.myCounter }Write data to DataStore To write data, DataStore offers a suspending DataStore.updateData() function that gives you the current state of the stored data as a parameter—either as a Preferences object, or an instance of the object defined in the proto schema. The updateData() function updates the data transactionally in an atomic read-write-modify operation. The coroutine completes once the data is persisted on disk. Preferences DataStore also provides a DataStore.edit() function to make it easier to update data. Instead of receiving a Preferences object, you receive a MutablePreferences object which you edit. As with updateData(), the changes are applied to disk after the transform block completes, and the coroutine completes once data is persisted to disk. With Preferences DataStore: suspend fun incrementCounter() { dataStore.edit { settings -> // We can safely increment our counter without losing data due to races! val currentCounterValue = settings[MY_COUNTER] ?: 0 settings[MY_COUNTER] = currentCounterValue + 1 } } With Proto DataStore: suspend fun incrementCounter() { settingsDataStore.updateData { currentSettings -> // We can safely increment our counter without losing data due to races! currentSettings.toBuilder() .setMyCounter(currentSettings.myCounter + 1) .build() } }Migrate from SharedPreferences to DataStore To migrate from SharedPreferences to DataStore, you need to pass in a SharedPreferencesMigration object to the DataStore builder. DataStore can automatically migrate from SharedPreferences to DataStore for you. Migrations are run before any data access can occur in DataStore. This means that your migration must have succeeded before DataStore.data returns any values and before DataStore.updateData() can update the data. If you’re migrating to Preferences DataStore, you can use the default SharedPreferencesMigration implementation and just pass in the name used to construct your SharedPreferences. With Preferences DataStore: val dataStore: DataStore<Preferences> = context.createDataStore( name = "settings", migrations = listOf(SharedPreferencesMigration(context, "settings_preferences")) ) When migrating to Proto DataStore, you’ll have to implement a mapping function that defines how to migrate from the key-value pairs used by SharedPreferences to the DataStore schema you defined. With Proto DataStore: val settingsDataStore: DataStore<Settings> = context.createDataStore( produceFile = { File(context.filesDir, "settings.preferences_pb") }, serializer = SettingsSerializer, migrations = listOf( SharedPreferencesMigration( context, "settings_preferences" ) { sharedPrefs: SharedPreferencesView, currentData: UserPreferences -> // Map your sharedPrefs to your type here } ) )Wrap-up SharedPreferences comes with several drawbacks: a synchronous API that can appear safe to call on the UI thread, no mechanism for signaling errors, lack of transactional API, and more. DataStore is a replacement for SharedPreferences that addresses most of these shortcomings. DataStore includes a fully asynchronous API using Kotlin coroutines and Flow, handles data migration, guarantees data consistency, and handles data corruption. As DataStore is still in alpha, we need your help to make it better! To get started, find out more about DataStore in our documentation and try it out by taking our codelabs: Preferences DataStore codelab and Proto DataStore codelab. Then, let us know how we can improve the library by creating issues on the Issue Tracker.

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

Lockscreen and authentication improvements in Android 11

Introducing Android 11 on Android TV

Improve Your Game with Texture Compression Format Targeting

Android GPU Inspector Open Beta

Turning it up to 11: Android 11 for developers

Prefer Storing Data with Jetpack DataStore

Labels

Archive

Feed

Newsletter