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.
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.
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.
Bubbles and people-centric conversations.
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 and media controls.
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.
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.
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.
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.
With Android 11 on its way to users, now is the time to finish your compatibility testing and publish your updates.
Here are some of the top behavior changes to watch for (these apply regardless of your app’s targetSdkVersion):
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.
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:
We recommend these if relevant for your app:
Read more about all of the Android 11 features at developer.android.com/11.
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.
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.
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 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.
apply()
fsync()
** 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.
Dispatchers.IO
While both Preferences DataStore and Proto DataStore allow saving data, they do this in different ways:
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.
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.
app/src/main/proto/
syntax = "proto3"; option java_package = "<your package name here>"; option java_multiple_files = true; message Settings { int my_counter = 1; }
Create the DataStore with the Context.createDataStore() extension functions.
DataStore
Context.createDataStore()
// 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.
Serializer
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 )
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.
Flow
Preferences
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 }
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.
DataStore.updateData()
updateData()
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.
DataStore.edit()
MutablePreferences
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 } }
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() } }
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.
SharedPreferencesMigration
DataStore.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.
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.
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 } ) )
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.
This is the final blog post for #11WeeksOfAndroid. Thank you for joining us over the past 11 weeks as we dove into key areas of Android development. In case you missed it, here’s a recap of everything we talked about during each week:
Discover how to implement the conversation shortcut and bubbles with ‘conversation notifications’. Also, learn more about conversation additions and other System UI news, and discover the people and conversations developer documentation here. Finally, you can also listen to the Android Backstage podcast where the System UI team is interviewed on people and bubbles.
To tackle user and developer complexity that makes identity a challenge for developers, we've been working on One Tap and Block Store, part of our new Google Identity Services Library.
If you’re interested in learning more about Identity, we published the video “in Identity on Android: what’s new in sign-in,” where Vishal explains the new libraries in the Google Identity System.
Two teams that worked very early with us are the Facebook Messenger team and the direct messaging team from Twitter. Read the story from Twitter here and find out how we worked with Facebook on the implementation here.
Find out more with the People and Identity learning path, playlist, and the week’s wrap-up blog post.
We kicked off the week by announcing the winners of the #AndroidDevChallenge! Check out all the winning apps and see how they used ML Kit and TensorFlow Lite, all focused on demonstrating how machine learning can come to life in a powerful way to help users get things done, like an app to help visually impaired navigate crowded spaces or another to help students learn sign language.
We recently made ML Kit a standalone SDK and it no longer requires a Firebase account. Just one line in your build.gradle file and you can start bringing ML functionality into your app.
Another much anticipated addition is the support for swapping Google models with your own for both Image Labeling as well as Object Detection and Tracking.
Find out about the importance of finding the unique intersection of user problems and ML strengths and how the People + AI Guidebook can help you make ML product decisions. Check out the interview with the Read Along team for more inspiration.
This week we also highlighted how adding a custom model to your Android app has never been easier.
Finally, try out our codelabs:
Find out more with the Machine Learning pathway, playlist, and the week’s wrap-up blog post.
As shared in the “Privacy and Security” blog post, we’re giving users even more control and transparency over user data access.
In Android 11, we introduced various privacy improvements such as one time permissions that let users give an app access to the device microphone, camera, or location, just that one time. Learn more about building privacy-friendly apps with these new changes. You can also learn about various Android security updates in this video.
Other notable updates include:
Find out more with the ‘privacy, trust and security’ learning pathway, playlist, and documentation on privacy and security best practices.
We shipped the second Beta of Android 11 and added a new release milestone called Platform Stability to clearly signal to developers that all APIs and system behaviors are complete. Find out more about Beta 2 and platform stability, including what this milestone means for developers, and the Android 11 timeline. Note: since week #4, we shipped the third and final beta and are getting close to releasing Android 11 to AOSP and the ecosystem. Be sure to check that your apps are working!
To get your apps ready for Android 11, check out some of these helpful resources:
In our “Accelerating Android updates” blog post, we looked at how we’re continuing to get the latest OS to reach critical mass by expanding Android’s updatability architecture.
We also highlighted Excelliance Tech, who recently moved their LeBian SDK away from non-SDK interfaces, toward stable, official APIs so they can stay more compatible with the Android OS over time. Check out the Excelliance Tech story.
Find out more with the Android 11 Compatibility learning pathway, playlist, and the week’s wrap-up blog post.
With the Android 11 beta, we further improved the developer experience for Kotlin on Android by officially recommending coroutines for asynchronous work. If you’re new to coroutines, check out:
Also, check out our new Kotlin case studies page for the latest case studies and data, including the new Google Home case study, and our state of Kotlin on Android video. For beginners, we announced the launch of our new Android basics in Kotlin course.
If you’re a Java language developer, watch support for newer Java APIs on how we’ve made newer OpenJDK libraries available across versions of Android. With Android 11, we also updated the Android runtime to make app startup even faster with I/O prefetching.
Android 11 included updates across the native toolchain, including better tools for profile-guided optimization (PGO) and improvements to native dependency management in Android Studio 4.0.
Finally, we continue to focus on improvements to the D8 and R8 compilers in Android Studio with better support for Kotlin in the R8 shrinker. Learn more.
Find out more with the languages learning pathway, playlist, and the week’s wrap-up blog post.
Interested in what’s new in Jetpack? Check out the #Android11 Beta launch with a quick fly-by introducing many of the updates to our libraries, with tips on how to get started.
This year, we've made several major improvements with the release of Navigation 2.3, which allows you to navigate between different screens of your app with ease while also allowing you to follow Android UI principles.
In Android 11, we continued our work to give users even more control over sensitive permissions. Now there are type-safe contracts for common intents and more via new ActivityResult APIs. These changes simplify how you request permissions, and we’ll continue to work on making permissions easier in the future.
Also learn about our recent releases of the AppStartup library as well as what’s new in WorkManager.
Find out more with the Jetpack learning pathway, playlist, and the week’s wrap-up blog post.
We have brought together an overview of what is new in Android Developer tools.
Check out the latest updates in design tools, and go even deeper:
Also, find out about debugging your layouts, with updates to the layout inspector. Discover the latest developments for Jetpack Compose Design tools, and also how to use the new database inspector in Android Studio.
Discover the latest development tools we have in place for Jetpack Hilt in Android Studio.
Learn about the build system in Android developer tools:
To learn about the latest updates on virtual testing, read this blog on the Android Emulator. Lastly, to see the latest changes for performance tools, watch performance profilers content about System Trace. Additionally, check out more about C++ memory profiling with Android Studio 4.1.
Find out more with the Android developer tools learning pathway, playlist, and the week’s wrap-up blog post.
Check out our webinars about the new Google Play Console beta if you weren’t able to tune in live.
We shared recent improvements we’ve made to app bundles, as well as our intention to require new apps and games to publish with this format in the second half of 2021. The new in-app review API means developers can now ask for ratings and reviews from within your app!
Don’t forget about our policy around more transparent subscriptions to help increase user trust in Google Play Billing. We also expanded our feature set to help you better reach and retain buyers, and launched Play Billing Library 3, which will be required by mid-2021.
Google Play Pass launched in nine new markets last month. Developers using both Google Play Pass and direct billing on Google Play have earned an average of 2.5 times US revenue with Google Play Pass, without diminishing Google Play store earnings. Learn more and express interest in joining.
Find out more with the app distribution and monetization learning pathway, playlist, and the week’s wrap-up blog post.
Check out some of the highlights from this week, including;
Find out more with the learning pathways for Android TV and Large Screens, Beyond phones playlist, and the week’s wrap-up blog post.
We shared several games updates and presented a special "11 Weeks" episode of The Android Game Developer Show.
You can also take advantage of Android 11's new media controls by making sure your app is using MediaStyle with a valid MediaSession token. Learn how to support media resumption by making your app discoverable with a MediaBrowserServiceCompat, using the EXTRA_RECENT hint to help with resuming content, and handling the onPlay and onGetRoot callbacks. Then check out how to leverage the MediaRouter jetpack library and check out the updated version of the UAMP sample.
Finally, we covered some of the primary ways apps can benefit from 5G. Android 11 adds new APIs and updates existing APIs to help ensure you have all the tools you need to leverage the capabilities of 5G, such as an enhanced bandwidth estimation API, 5G detection capabilities, and a new meteredness flag from cellular carriers. The Android emulator now enables you to develop and test these APIs without needing a 5G device or network connection. All of this and more is available from our dedicated 5G page.
Find out more with the ‘games and media’ learning pathway, playlist, and the wrap-up blog post, and visit d.android.com/games to stay up to date on all of our tools and resources for game developers.
In our final week, we released 4 new codelabs, 9 new samples, new documentation and a podcast from the Compose team. If you prefer videos; we’ve got you covered:
New in Android 11 is the ability for apps to create seamless transitions between the on screen keyboard being opened and closed. To find out how to add this to your app, slide on over to the video, blog posts and sample app
We recommend following the Material Design guidelines to ensure that apps operate consistently, enabling patterns learned in one app to be used in another. Find out more about Material Theming (color, type and shape), dark theme and Material’s motion system using the Material Design Components (MDC) library. If you haven’t already migrated to MDC, then check out our migration guide.
It even becomes possible to ease your migration with libraries like the new MDC-Android Compose Theme Adapter which converts an MDC XML theme into a Compose `MaterialTheme`.
Find out more with the Compose learning pathway, the Modern UI learning pathway, playlist, and the week’s wrap-up blog post.
Resources
You can find the entire playlist of #11WeeksOfAndroid video content here. Follow us on Twitter and YouTube, and subscribe to our email list to receive all the latest news and resources. Thanks so much for letting us be a part of this experience with you!
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
