Today we’re kicking off Playtime, our annual event series where we host developers from all over the world to discuss features and best practices to help you grow your apps and games businesses. Last month’s Android Dev Summit focused on modern Android development. Here on the Google Play team, we’re focusing on modern app and game distribution — our set of powerful and customizable distribution features and tools that work together to power your success on Google Play.
The Android App Bundle is foundational to modern app and game distribution, replacing the monolithic APK. Since it launched 18 months ago, over 270K apps and games have made the switch, representing over 25% of active installs. Those that switched have seen an average size savings of 20% compared to a universal APK and more efficient releases as a result.
A recent internal analysis revealed that users with storage-constrained devices are much more likely to uninstall apps, so optimizing how much space your app needs is important. Our new metrics on the app size report in the Play Console can show you how many of your active users have little free storage on their devices and if they’re uninstalling more than other users.
Testing app bundles is now much easier with internal app sharing. Make anyone in your company an uploader without giving them access to the Play Console and they’ll be able to share test builds of your app as easily as they used to share APKs. With internal app sharing, you can be sure that each device is receiving exactly what Play would deliver in the wild. You don’t need to use version codes or the prod signing key, you can upload debuggable artifacts, and you’ll soon be able to get install links for old versions of your app, too.
The app bundle also lets you modularize your app with dynamic feature modules. Modularization speeds up build times and engineering velocity, since different teams can design, build, test, and debug features in parallel rather than working on the same complex code for a monolithic app. Based on your feedback, we’ve made it easier to develop modular apps with tools such as the new Dynamic Feature Navigator library and FakeSplitInstallManager, which lets you test on-demand delivery while offline instead of waiting for the Play Store.
In-app updates let you prompt users to update to the latest version of your app, without them having to leave your app. More than 10% of the top apps and games are already using in-app updates with an average acceptance rate of 24%. Based on your feedback, we’re also giving you more control over how and when you show update prompts:
For some games with rich content, the 150MB app bundle size limit is not enough. Using expansion files or content delivery networks can get around this but could introduce complexity when you’re building and releasing your game, and can result in a poor user experience. That’s why we’re extending the app bundle format to support asset delivery with a new delivery construct called asset packs which can go up to multiple gigabytes.
Asset packs are packaged in the app bundle alongside your binary, so you can publish a single artifact to Play that contains everything your game needs, giving you full control of your asset delivery. Play’s asset delivery will also enable texture compression targeting, so that your users only get the assets suitable for their device with no wasted space or bandwidth. And you can rely on Play to keep your assets up to date, just as it does with your game binary. We’re currently testing this with some early partners and hope to make it more widely available soon.
Look out for the sessions from this year’s Playtime, which will be added to the Android Developers YouTube channel. We look forward to sharing more tools and services for your apps and games, made possible by the app bundle and our new dynamic framework. And as always, please give us your feedback and let us know what you think.
How useful did you find this blog post?
★ ★ ★ ★ ★
Since Google Fit was released in 2015, apps with an abundance of features for health and fitness tracking have integrated with the Google Fit APIs. Over the years, the number of users using Google Fit as a central repository for their fitness and wellness data has grown significantly.
With Android 10, we're making further updates to give users even more control over this personal data. One key change concerns how Android apps can monitor a user’s physical activity and retrieve data from Android sensor APIs and the Google Fit platform.
In Android 10: Activity recognition permission
Android 10 introduces a new runtime permission for activity recognition for apps that make use of the user's step and calorie count or classify the user's physical activity, such as walking, biking, or moving in a vehicle through one of the following APIs:
If your app relies only on raw data from other built-in sensors on the device, such as the accelerometer and gyroscope, you don't need to declare this new permission in your app.
Activity Recognition Permission Enforcement
Google Fit physical activity APIs
This new permission affects a subset of data types available in the Google Fit APIs on Android. If your app accesses these types from Google Fit today, then you need to update your app inline with the new permissions.
The activity recognition runtime permission is required for accessing the following APIs / data types:
With Android 10 now launched and SDK 29 becoming your primary development target, now is the time to make sure your apps are compatible with the new runtime permission.
Kevin Chyn, Android Framework
Curtis Belmonte, Android Framework
With the launch of Android 10 (API level 29), developers can now use the Biometric API, part of the AndroidX Biometric Library, for all their on-device user authentication needs. The Android Framework and Security team has added a number of significant features to the AndroidX Biometric Library, which makes all of the biometric behavior from Android 10 available to all devices that run Android 6.0 (API level 23) or higher. In addition to supporting multiple biometric authentication form factors, the API has made it much easier for developers to check whether a given device has biometric sensors. And if there are no biometric sensors present, the API allows developers to specify whether they want to use device credentials in their apps.
The features do not just benefit developers. Device manufacturers and OEMs have a lot to celebrate as well. The framework is now providing a friendly, standardized API for OEMs to integrate support for all types of biometric sensors on their devices. In addition, the framework has built-in support for facial authentication in Android 10 so that vendors don’t need to create a custom implementation.
The FingerprintManager class was introduced in Android 6.0 (API level 23). At the time -- and up until Android 9 (API level 28) -- the API provided support only for fingerprint sensors, and with no UI. Developers needed to build their own fingerprint UI.
FingerprintManager
Based on developer feedback, Android 9 introduced a standardized fingerprint UI policy. In addition, BiometricPrompt was introduced to encompass more sensors than just fingerprint. In addition to providing a safe, familiar UI for user authentication, it enabled a small, maintainable API surface for developers to access the variety of biometric hardware available on OEM devices. OEMs can now customize the UI with necessary affordances and iconography to expose new biometrics, such as outlines for in-display sensors. With this, app developers don’t need to worry about implementing customized, device-specific implementations for biometric authentication.
BiometricPrompt
Then, in Android 10, the team introduced some pivotal features to turn the biometric API into a one-stop-shop for in-app user authentication. BiometricManager enables developers to check whether a device supports biometric authentication. Furthermore, the setDeviceCredentialAllowed() method was added to allow developers the option to use a device’s PIN/pattern/password instead of biometric credentials, if it makes sense for their app.
BiometricManager
setDeviceCredentialAllowed()
The team has now packaged every biometric feature you get in Android 10 into the androidx.biometric Gradle dependency so that a single, consistent, interface is available all the way back to Android 6.0 (API level 23).
androidx.biometric
The androidx.biometric Gradle dependency is a support library for the Android framework Biometric classes. On API 29 and above, the library uses the classes under android.hardware.biometrics, FingerprintManager back to API 23, and Confirm Credential all the way back to API 21. Because of the variety of APIs, we strongly recommend using the androidx support library regardless of which API level your app targets.
Biometric
android.hardware.biometrics
androidx
To use the Biometric API in your app, do the following.
$biometric_version is the latest release of the library
$biometric_version
def biometric_version= '1.0.0-rc02' implementation "androidx.biometric:biometric:$biometric_version"
The BiometricPrompt needs to be recreated every time the Activity/Fragment is created; this should be done inside onCreate() or onCreateView() so that BiometricPrompt.AuthenticationCallback can start receiving callbacks properly.
Activity
Fragment
onCreate()
onCreateView()
BiometricPrompt.AuthenticationCallback
To check whether the device supports biometric authentication, add the following logic:
val biometricManager = BiometricManager.from(context) if (biometricManager.canAuthenticate() == BiometricManager.BIOMETRIC_SUCCESS){ // TODO: show in-app settings, make authentication calls. }
The BiometricPrompt constructor requires both an Executor and an AuthenticationCallback object. The Executor allows you to specify a thread on which your callbacks should be run.
Executor
AuthenticationCallback
The AuthenticationCallback has three methods:
onAuthenticationSucceeded()
onAuthenticationError()
onAuthenticationFailed()
The following snippet shows one way of implementing the Executor and how to instantiate the BiometricPrompt:
private fun instanceOfBiometricPrompt(): BiometricPrompt { val executor = ContextCompat.getmainExecutor(context) val callback = object: BiometricPrompt.AuthenticationCallback() { override fun onAuthenticationError(errorCode: Int, errString: CharSequence) { super.onAuthenticationError(errorCode, errString) showMessage("$errorCode :: $errString") } override fun onAuthenticationFailed() { super.onAuthenticationFailed() showMessage("Authentication failed for an unknown reason") } override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) { super.onAuthenticationSucceeded(result) showMessage("Authentication was successful") } } val biometricPrompt = BiometricPrompt(context, executor, callback) return biometricPrompt }
Instantiating the BiometricPrompt should be done early in the lifecycle of your fragment or activity (e.g., in onCreate or onCreateView). This ensures that the current instance will always properly receive authentication callbacks.
onCreate
onCreateView
Once you have a BiometricPrompt object, you ask the user to authenticate by calling biometricPrompt.authenticate(promptInfo). If your app requires the user to authenticate using a Strong biometric or needs to perform cryptographic operations in KeyStore, you should use authenticate(PromptInfo, CryptoObject) instead.
biometricPrompt.authenticate(promptInfo)
authenticate(PromptInfo, CryptoObject)
This call will show the user the appropriate UI, based on the type of biometric credential being used for authentication – such as fingerprint, face, or iris. As a developer you don’t need to know which type of credential is being used for authentication; the API handles all of that for you.
This call requires a BiometricPrompt.PromptInfo object. A PromptInfo is where you define the text that appears in the prompt: such as title, subtitle, description. Without a PromptInfo, it is not clear to the end user which app is asking for their biometric credentials. PromptInfo also allows you to specify whether it’s OK for devices that do not support biometric authentication to grant access through the device credentials, such as password, PIN, or pattern that are used to unlock the device.
BiometricPrompt.PromptInfo
PromptInfo
Here is an example of a PromptInfo declaration:
private fun getPromptInfo(): BiometricPrompt.PromptInfo { val promptInfo = BiometricPrompt.PromptInfo.Builder() .setTitle("My App's Authentication") .setSubtitle("Please login to get access") .setDescription("My App is using Android biometric authentication") .setDeviceCredentialAllowed(true) .build() return promptInfo }
For actions that require a confirmation step, such as transactions and payments, we recommend using the default option -- setConfirmationRequired(true) -- which will add a confirmation button to the UI, as shown in Figure 2.
setConfirmationRequired(true)
setConfirmationRequired(false)
Now that you have all the required pieces, you can ask the user to authenticate.
val canAuthenticate = biometricManager.canAuthenticate() if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) { biometricPrompt.authenticate(promptInfo) } else { Log.d(TAG, "could not authenticate because: $canAuthenticate") }
And that’s it! You should now be able to perform authentication, using biometric credentials, on any device that runs Android 6.0 (API level 23) or higher.
Because the ecosystem continues to evolve rapidly, the Android Framework team is constantly thinking about how to provide long-term support for both OEMs and developers. Given the biometric library’s consistent, system-themed UI, developers don’t need to worry about device-specific requirements, and users get a more trustworthy experience.
We welcome any feedback from developers and OEMs on how to make it more robust, easier to use, and supportive of a wider range of use cases.
For in-depth examples that showcase additional use cases and demonstrate how you might integrate this library into your app, check out our repo, which contains functional sample apps that make use of the library. You can also read the associated developer guide and API reference for more information.
Android fuels mobile apps on devices that range far beyond your typical small-screen smartphone, from new Chromebooks like the lightweight, high-performance Google Pixelbook Go to multi-display devices and foldable phones like the Samsung Galaxy Fold. Not to mention the more than 175M Android tablets that have the Google Play store installed.1
These large-screen devices set the stage for more engaging and visually immersive experiences, whether by creating a larger canvas for creativity or by giving users faster, more flexible ways to work. As we’ve continued to prioritize large-screen devices with OEM partners like Samsung, Asus, and Lenovo, we’ve been able to expand our reach to a huge new audience of users.
During the week of Black Friday in 2018, 1 in 3 notebooks sold in the U.S. were Chromebooks.2 Chromebook unit sales also increased 22% YoY, while the rest of the notebook category decreased -6.1%.3 And we’re not just reaching more users — we’re reaching more engaged users. In fact, in just the last year, the total amount of time spent in Android apps on Chrome OS has grown 4X.4
By making adjustments for larger screens, you can provide richer experiences across all these devices and tap into a wider audience of app users. Development teams around the world — including Adobe Lightroom, Evernote, and Gameloft, among many others — have already seen some incredible results:
With the goal of allowing users to play any video file, anywhere, on any device or screen size, the developers at VideoLAN project decided to adapt VLC — an open source, cross-platform multimedia player — for all screens. The team started by adding keyboard and mouse support before designing multiple versions of the layout to allow users to easily scale and resize the app.
Users can now enjoy the same immersive experience across a range of different devices and form factors, and VideoLAN has already received overwhelmingly positive feedback from users around the world.
War Robots — a 12-player real-time battle game developed by Pixonic — was originally designed for early-generation phones. The team enabled windowed gameplay so users could play in one window while watching their favorite streamers or upgrading their robots in another, created new tutorials and controls that appear whenever players switch between desktop and tablet mode, and added support for keyboard and mouse input.
More than 100,000 players have already played War Robots on Chrome OS since Pixonic rolled out the latest optimizations, which made War Robots’ battles even more thrilling and engaging on larger screens, and Pixonic has seen 25% longer user sessions on Chromebooks as a result.
1) Laptop and tablet mode Test your core app functions to make sure everything works smoothly without crashing as users switch between different modes.
2) Window management and layout Support multi-window mode and free-form window resizing, and be sure to design optimized layouts for both landscape and portrait orientations. Set up your app to correctly handle configuration changes to avoid crashes when people rotate their devices.
3) Keyboard and mouse input Make sure your app is fully functional without touch input, and add support for keyboards, mice, and game controllers (if applicable).
4) Hardware support If you’re using NDK, be sure to support x86 (32 and 64bit) ABIs to ensure the highest possible performance.
From the start, our goal has been to make the Chromebook a simple, secure, and speedy environment for everyone. The launch of Linux (Beta) on Chrome OS allowed Android developers to build and test apps with a Chromebook. And earlier this year at I/O, we announced that Android Studio 3.5 now fully supports Chrome OS with a simple one-click installation.
Since then, we’ve been working on a few improvements that make Chromebooks an even better place for safe and seamless Android app development. Let’s start with the biggest one:
Deploying an app directly to Chrome OS to enable full Android development In the past, you could only test your apps by deploying them to Android phones. With Chrome OS’s upcoming M80 release, you’ll be able to deploy Android apps directly to your Chromebook. That way, you can develop and test your app on the same machine, all without a connected device or needing to put your laptop in developer mode. Developers can start testing this feature in developer channel in November.
GPU acceleration for a snappier, jank-free UI (now in beta channel) We’ve enabled GPU support to reduce latency and deliver a snappier UI. That goes for developer apps such as Android Studio, Unity Editor, or Visual Studio Code. And for developers who also work on web apps, GPU acceleration means faster testing with Chrome Canary or Firefox.
Container backup and restore to easily move between devices Previously, Linux files and apps were tied entirely to the device — if you lost your device, you lost all the work inside of it. Now, Chrome OS’s container-based architecture allows you to pack up your entire workspace and export it to external storage or Drive. The backup file can be restored at any point, either on the same machine — which is helpful when jumping back to a previous state — or to move to another Chromebook.
You can now find import and export buttons in your Linux settings.
Picture-in-picture (PiP) support
If you’ve built PIP support into your Android apps, you’ll see that function work seamlessly in Chrome OS in 2020. But you can start testing this feature now by enabling PiP in Android settings → Developer options.
With millions of users on Chromebooks, tablets, foldables, and now multi-display devices, designing app experiences with larger screens in mind is crucial. Seize this opportunity to engage more users by optimizing your existing apps to work great across all screens. And the latest Linux features on Chrome OS give you the power to use a single machine to build and run Android apps. Don’t hesitate to take action to ensure your apps work seamlessly on larger screens with Linux on Chrome OS.
1. The number of tablets only accounts for devices that have the Google Play Store installed (e.g., excluding tablets in China); the actual number of tablets capable of running Android applications is much larger.
2. The NPD Group, Inc., Retail Tracking Service, U.S., Notebook Computers, Chrome OS, based on units, Nov. 18, 2018–Nov. 24, 2018 vs. Nov. 19, 2017–Nov. 25, 2017.
3. The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on units, Sept. 2018–Aug. 2019. Sales are adjusted for 5 weeks in Jan. 2018 vs. 4 weeks in Jan. 2019.
4. Google Internal Data, March 2018–March 2019.
Perhaps as a consequence of Android's flexibility, we often get asked by developers what does the Android team recommend when it comes to building apps? You’ve told us: you love our openness..but you’d also love us to marry it with an opinion about the right way to do things. And, to make sure the right way is also the easiest way. And so today, at the Android Dev Summit, the team wanted to answer that question for you.
We call our recommendation “modern Android development". Opinionated and powerful, for fast, easy development. Taking away everything that slows you down so you can focus on building incredible experiences. You can see it in the investments we’ve made like creating Android Studio and Jetpack. (Over 90% of our pro developers are using Android Studio today.) Kotlin and Compose are especially great recent examples. Kotlin is a modern, concise language -- something you asked us for and is now the recommended language for Android. Compose is a modern declarative UI toolkit built for the next 10 years. And this might sound a little strange, but we chose and designed these tools to be enjoyable to use: we think that’s important too. Both Kotlin and Compose also have a critically important property. They are designed to be compatible with your existing apps. This means you can phase in Kotlin code and Compose views on your timeline.
It all starts with a great modern language: Kotlin
Modern Android starts with fantastic language support.In fact, we recently passed a milestone where almost 60% of our top 1000 apps are using Kotlin. And we’re working with JetBrains to make it even better: faster kotlin compile speeds, incremental annotation processing with KAPT, better IDE typing latency, more lint checks, desugaring in D8 and R8, new optimizations in R8 that are aware of Kotlin-specific bytecode patterns. And we’re releasing full IDE support for Kotlin build scripts today. If you want to grow your skills, we are launching an Advanced Android course with Kotlin on Udacity. And, for those who are already experts, we’re also launching a new Android Developer Certification in Kotlin, available at a discount for the next three months. We’re working to make all of our supported first-class languages — Kotlin, the Java programming language, and C++ — better for you and your team, with Java8 library desugaring, NDK r21 with updated LLVM, GNU Make, Fortify enabled by default, and more.
Jetpack: Build high quality, powerful apps with less code
Jetpack is designed to solve real-world problems you face every day, and is used by over 84% of the top 10,000 Play Store apps. And we continue to make Jetpack even more helpful:
Compose: Android’s new UI toolkit to build beautiful, native apps, now in developer preview
Compose makes it easy to build beautiful, native apps. It provides a declarative way to build UIs which makes your code more intuitive and concise. Inspired by Kotlin, you can adopt Compose at your own pace thanks to seamless compatibility with the existing UI toolkit.
Today we are releasing the Jetpack Compose Developer Preview. All you need to do is download the latest Preview build of Android Studio. Compose is being developed completely in the open, in AOSP. The continuous feedback we receive has led to many API improvements and we want to thank you for providing feedback in our developer studies and the Kotlinlang Slack group. As we enter developer preview, we need even more feedback as we work towards bringing Jetpack Compose to beta next year and ready for use in production apps.
Android Studio 4.0 Canary
Today we also released the first canary of Android Studio 4.0 - built hand in hand with Compose for powerful, integrated tooling support. Android Studio 4.0 includes Compose Live Preview, Code Completion, and a full sample of a Compose app. You’ll also find the new Motion Editor, Java 8 Language library desugaring, full support for KTS files, Kotlin live templates, and more.
Android App Bundles and dynamic delivery testing improvements
In just eighteen months after launch, over 270K Android App Bundles are now in production covering 25% of all active installs. Based on your feedback, we’re making App Bundles and Dynamic Delivery much easier to test. Internal app sharing lets you share test builds of your app bundle as easily as you share APKs. You can now grant anyone in the team ability to upload artifacts. You don’t need to sign test versions with your production app signing key, you don’t need to use version codes, and you can upload debuggable artifacts. We’re also making it possible to get download links for old versions of your app from the Play Console, whether they’re app bundles or APKs. And starting today, we’re launching offline testing of dynamic delivery with the fake split install manager so can replicate splits being installed by the Play Store while testing locally.
A modern distribution platform, centered around user trust
User trust and safety has always been a top priority at Google Play, with human reviewers, constant improvements to play protect, and policy updates to evolve with the threats we see. As a result, apps that are installed from Google Play are an order of magnitude safer than from any other source. This year, we’ve been increasing all our detection capabilities for impersonators, repackaging, bad content and other forms of abuse, but we know there's more we can do, and the threats are constantly changing. With your help, we’ve reduced access to sensitive data and have made Play even safer for children and families. We restricted SMS/Call log permissions to only apps that need them as part of their core functionality, and as a result 98% fewer apps access this sensitive data. Thanks to your hard work, users are safer, and know they are safer when they download apps that request fewer permissions.
The Android Developer Challenge!
Over ten years ago, we announced the first Android Developer Challenge. Today, modern Android is shaping the next generation platform. So it seems kind of fitting to announce: the Android Developer Challenge is back! The first Developer Challenge we’re announcing is Helpful Innovation and Machine Learning. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today. You can read more about the challenge here.
So - that’s a quick tour of Modern Android and the road ahead across our developer experience! Whether you’re joining us for Android Dev Summit in person or on the livestream, we have nearly 60 sessions from over 100 speakers where we’ll go deep on everything you need to know about Android. Thank you!
Posted by The Android team
Developers like you have always played an important role in shaping the direction of Android, fueling the wave of Android innovation. It’s the reason that when we first launched the SDK for Android 10+ years ago, we simultaneously announced the Android Developer Challenge: a way to help reward model apps and show us what user problems you wanted to solve. As Android continues to push the boundaries into emerging areas like ML, 5G, foldables and more, we need your help to bring to life the consumer experiences that will define these new frontiers.
So we’re bringing back the Android Developer Challenge and asking you to help us unlock new experiences on Android, and help inspire other developers around these emerging technologies.
As we kick off this challenge, the first area we’ll be focusing on is On-Device Machine Learning. At Google, we’re big believers in how this new technology can open up a world of helpful innovation so you can get things done in ways you never thought possible. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today!
Bringing your idea to life in front of billions of eyes
Got an idea? Whether it’s still a concept or ready for users, tell us how you could use Google’s help, and how it supports the mission of using machine learning to help people get something done. Join the #AndroidDeveloperChallenge topic on GitHub, and share your idea as a repository under this topic. Don’t forget to come back here and officially submit your concept.
We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. Here’s what those 10 developers will get:
Expertise and development support bootcamp: We’ll work with you to provide expertise and guidance to help in your plans to bring your app from concept to reality, including:
Exposure and street cred! Once your idea is ready for prime-time, we’ll help you get users, and celebrate you to the broader Android community, including:
Helpful innovation is an important investment area for us on the Android team, and On-Device Machine Learning has played a critical role in powering new features in the last several releases of Android. We’re just beginning to scratch the surface, and we can’t wait to see what you come up with!
Platform
Android Studio
Google Play
Android Jetpack
Docs
News
