Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا

New ways to reach more drivers on Android for cars

Android Developers Blog

Posted by Mickey Kataria, Director of Product Management, Android for cars

This blog post is part of a weekly series for #11WeeksOfAndroid. For each week, we’re diving into a key area and this week we’re focusing on Android Beyond Phones. Today, we’ll be talking about cars.

Since 2014, Google has been committed to bringing the familiarity of apps and services from Android phones into the car in a safe and seamless way. We’re continuing to see strong momentum and adoption of both Android Auto and Android Automotive OS, and are excited to share new improvements that provide app developers the opportunity to reach more users in the car.

Android Auto momentum

We launched Android Auto for users to stay connected on-the-go and more easily access their Android phones on their car displays— while staying focused on the road. Android Auto is currently available with nearly every major car manufacturer and is on track to be in more than 100 million cars in the coming months. Many car manufacturers, including General Motors, BMW and Kia, have also added support for wireless connections, making it easier for drivers to use Android Auto as soon as they get into their car. We’re continuing to add new features to make the experience more seamless for users and help developers reach more drivers with in-car apps.

Expanding Android Auto’s app ecosystem

One of our most common requests for Android Auto continues to be support for more apps in the car. We currently have over 3,000 apps in Google Play whose in-car experiences have been purpose-built for driving.

Today, we’re showcasing our work with early access partners to build apps in new categories for Android Auto, including navigation, parking and electric vehicle charging. Using our new Android for Cars App Library, we’re able to ensure that all tasks within an app can be achieved with minimal glances or taps.

Early access partners for new apps on Android Auto

To mitigate driver distraction, we collaborated with government, industry and academic institutions to develop our own best practice guidelines that we apply to every aspect of our product development process. With our standard templates and guidelines, developers have the tools to easily optimize their apps for cars, without needing to become an expert in driver distraction.

Our early access partners will be releasing new apps to their beta testers by the end of this year. Pending additional testing and feedback, we then plan to make these APIs publicly available for all developers to build Android Auto apps in these categories.

We're partnering with some of the leading navigation, parking and electric vehicle charging apps around the world including ChargePoint, SpotHero and Sygic.

Android Automotive OS adoption

More recently, we introduced Android Automotive OS as a full-stack, open source and highly customizable platform powering vehicle infotainment systems. With Android Automotive OS, car manufacturers are able to have apps and services like Google Assistant, Google Maps and Google Play built into vehicles so that a mobile device is not required for common activities like navigation, downloading third-party apps and listening to media. Polestar 2, the first car running Android Automotive OS with Google built in, is now on the road and available for customers globally. In addition, Volvo Cars, Renault, General Motors and more have announced plans for infotainment systems powered by Android Automotive OS with Google apps and services built-in.

Extending the reach of media apps in cars

As more manufacturers begin to ship cars with infotainment systems powered by Android Automotive OS, developers have the opportunity to deliver a seamless media experience using Google Play in the car. If you already have a media app for Android Auto, you can extend the reach by adding support for Android Automotive OS. The process for porting over your apps is simple with most of the work already done, just follow these steps.

Making it easier to develop media apps for Android Automotive OS

For the past year, we have been on a journey to allow app developers to design, develop, test and publish media apps directly on Google Play in the car. We are happy to share that this is now possible.

Polestar 2 and Google Generic Automotive system images for Android emulator

We have made updates to the Android Automotive OS design guidelines and development documentation for you to add support for your media apps. We also launched updates to the emulator to include Google Assistant, Google Maps and Google Play, so you can develop and test your apps in an environment that more closely mirrors the software in the car. The Polestar 2 system image enables you to test your app on similar software that is available on the road today. Lastly, the Play Console now accepts Android Automotive OS APKs, enabling you to simply upload your app for quality review and publishing. These changes allow developers to seamlessly complete the end-to-end development process for Android Automotive OS.

Google Play features many media apps today, including Spotify, iHeartRadio, NPR One and more.

To learn more about how to create an app for Android Automotive OS, look out for updates or post on the automotive-developers Google Group or Stack Overflow using android-automotive tags.

With new app expansion on Android Auto and improved development tools for Android Automotive OS, developers have more opportunity than ever to reach users with app experiences optimized for the car. Head over to to get started!


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

August 11th 2020, 9:15 am

6 New ways to engage with users on Android TV

Android Developers Blog

Posted by Dan Aharon, Product Manager, Android TV

This blog post is part of a weekly series for #11WeeksOfAndroid. This week we’re focusing on Android Beyond Phones. So what’s new on Android TV?.

With users asking for more TV shows, movies, and apps than ever, the big screen has become a big deal. There are now over 80% more Android TV monthly active devices than a year ago! Working with 7 of the top 10 Smart TV OEMs and over 160 TV Operators has helped give users more options to spruce up their living room with Android TV. But connecting with this many people wouldn’t have been possible without the developer ecosystem building ~7,000 apps for Google Play on Android TV. Together, our users can now watch, play, and do more on their TVs.

Over the past year, we’ve introduced new features to Android TV to make discovering and accessing your content even easier for users. We updated Google Play with a refreshed look and new app collections while making it easier for users to subscribe to apps. We made additions to the Android TV home screen to highlight trending and important content. And most recently, we released Cast Connect, so your users can cast their favorite content directly to its native Android TV app.

We’ve heard from you on how else we can help support you, and we are excited to announce new ways to help you continue to improve engagement and commerce on the TV:

Easier acquisition and monetization

Let users try your app instantly on Google Play with Google Play Instant on TV

More engaging user experiences

Use Gboard TV to bring speech-to-text and predictive typing to your app.

This is just the latest for developers. You can find videos, codelabs, and documentation to bring more key features to life on the #11weeksofAndroid site and the Android TV Developers site. Catch the “What’s new on Android TV” video for demos and more info about the features in this post.

If you are just getting started, check out our ADT-3 developer kit and Android 11 Developer Preview to start building your TV experience.

We are excited to see what you come up with next.

August 10th 2020, 9:05 am

11 Weeks of Android: App distribution and monetization on Google Play

Android Developers Blog

Posted by Alex Musil, Director of Product Management, Google Play

This blog post is part of a weekly series for #11WeeksOfAndroid. Each week we’re diving into a key area of Android so you don’t miss anything. This week, we spotlighted app distribution and monetization on Google Play; here’s a look at what you should know.

Thanks for joining us for this week of 11 Weeks of Android, where we focused on app distribution and monetization. The developments we announced will enable you to deliver the exciting improvements to the Android platform you’ve been hearing about since week 1.

Google Play partners with developers to deliver amazing digital experiences to billions of Android users. From the start, we’ve committed to providing the tools and insights you need to reach more users and grow your business. This week, we launched even more features — and improved existing ones — to help you continue to maximize your success.

Key takeaways

  1. We released several webinars about the new Google Play Console beta. Check out the videos if you weren’t able to tune in live.
  2. 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.
  3. Developers can now ask for ratings and reviews from within your app with the new in-app review API.
  4. To increase user trust in our billing platform, we made some product updates and reminded you of our policy around more transparent subscriptions. 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.
  5. Google Play Pass launched in nine new markets last month. With an innovative revenue model, participating titles together have earned 2.5x the revenue of Google Play Store-only sales, without diminishing Play Store earnings. You can learn more and express interest in joining.

Google Play Console beta

Thank you to everyone who has already shared their feedback on the new Google Play Console beta, which launched a few months ago at As we’ve continued to update the beta, we’ve launched a number of key releases including:

Earlier this week, we hosted three webinars to get you up to speed on what’s new and what’s changed from the classic Play Console. If you weren’t able to tune in live, you can watch the videos on demand below.

If you’re just getting started, join Google Play Console’s lead engineer, Dan White, for a look at new features like Inbox, policy status, app content, and enhanced team management capabilities.

To help you release with even more confidence, check out this webinar with Google Play UX designer Matt McGriskin, who will walk you through the new testing and publishing workflow.

Finally, if you want to grow your audience, join Google Play engineer Ryan Fanelli for app store optimization best practices and an overview of the new acquisition reports.

You can also take our Play Console Play Academy course. And if you haven’t already, please opt in to 2-Step Verification to sign into Google Play Console, which will be required later this year.

Android App Bundle

We’re glad so many of you are already using the Android App Bundle to release your apps and games. We’re continuing to make app bundles a better publishing format with several recent improvements:

If you haven’t switched to the app bundle yet, we’ve published some FAQs on Play App Signing—which is required for app bundles—as well as guidance on how to test your app bundle. Check out our recent blog post to find out more about the recent improvements we’ve made to developing, testing, and publishing with app bundles.

As we announced as part of the Android 11 Beta launch, we intend to require new apps to publish with the Android App Bundle on Google Play in the second half of 2021. This means that we will also be deprecating APK expansion files (OBBs) and making Play Asset Delivery the standard for publishing games larger than 150MB.

In-app review API

Because ratings and reviews are such an important touchpoint with your users, many of you asked us to give users the ability to leave a review from within your app. Now, with the new in-app review API, you can do just that. Choose when to prompt users for a review and get feedback when it’s most valuable. The in-app review API is available now in the Play Core Library.

We've also released a unified sample for Play Core APIs, which includes in-app reviews as well as on-demand feature modules and in-app updates. Check it out to learn how to use these APIs using our Play Core Kotlin extensions artifact, which makes working with Play Core easier for Kotlin users.

Google Play Commerce

We’ve made a number of updates to Play Commerce aimed at building user trust through clearer, easier payment experiences. The user trust policies we announced in April offer users greater transparency, safer trial experiences, and easier cancellations.

We also launched Play Billing Library 3, which supports cash payments, a better subscription promo code redemption experience, purchase attribution, and more. Billing Play Library 3 will be mandatory for all new apps starting August 2, 2021.

For more information, check out this session with Mrinalini Loew, Group Project Manager for Google Play Commerce.

We’ve also just kicked off a six-article series on Google Play Billing, which you can follow here on Medium.

Google Play Pass

Google Play Pass enables developers to earn additional revenue and connect with untapped audiences by offering experiences free of ads and in-app purchases. Since launching last September, Play Pass has added over 200 new titles to the catalog, from puzzles and racing games to utility and kid-friendly apps. We’re also excited to celebrate the world premieres of Super Glitch Dash and Element this week as the newest “Premiering on Play Pass” titles.

The expanded catalog has enabled rich user experiences and provided a sustainable stream of revenue for developers using an innovative revenue payout model. In aggregate, titles on Play Pass earn more than 2.5x the revenue compared to their Play Store-only earnings in the US.

Last month, we made Google Play Pass available in nine new markets and gave users the option to get started with either an annual subscription or the existing monthly plan.

Today, we are announcing that developers with in-app subscriptions can now nominate their titles to join Play Pass. If you’re building a great experience that Google Play Pass users would love, you can learn more and express interest in participating.

Learning path

If you’re looking for an easy way to pick up the highlights of this week, check out the app distribution and monetization pathway. Test your knowledge of key takeaways to earn a limited-edition virtual badge.

Thanks for joining us for 11 Weeks of Android! We hope you find these recent announcements and resources helpful in powering your success on Google Play.


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

August 7th 2020, 9:49 am

Android 11 final Beta update, official release coming soon!

Android Developers Blog

Posted by Dave Burke, VP of Engineering

It’s already August and the official Android 11 release is coming very soon! As we put the finishing touches on the new platform, today we’re bringing you Beta 3, our last update in this year’s preview cycle. For developers, now is the time to make sure your apps are ready, before we bring the official release to consumers.

You can get Beta 3 today on Pixel 2, 3, 3a, and 4 devices (and coming soon, Pixel 4a!). Just enroll here for an over-the-air update. If you’re already enrolled, you’ll automatically get the update soon. As always, let us know your feedback, and thank you for all of the input you’ve provided so far.

Watch for more information on the official Android 11 release coming soon!

What’s in Beta 3?

Today’s update includes a release candidate build of Android 11 for Pixel devices and the Android Emulator. We reached platform stability at Beta 2, so all app-facing surfaces and behaviors are final, including SDK and NDK APIs, app-facing system behaviors, and restrictions on non-SDK interfaces. With these and the latest fixes and optimizations, Beta 3 gives you everything you need to complete your testing.

As we bring Android 11 to final form, we’re also taking this opportunity to update Android with the Exposure Notifications System in mind. Starting in Beta 3, users will be able to run Exposure Notification apps on Android 11 without needing to turn on the device location setting. This is an exception we’re making for the Exposure Notification System only, given that it has been designed in such a way that apps using it can’t infer device location through Bluetooth scanning. To protect user privacy, all other apps will still be prohibited from performing Bluetooth scanning unless the device location setting is on and the user has granted them location permission. You can read more in our Update on Exposure Notifications post.

Get your apps ready for Android 11!

With the official Android 11 release on the way, we’re asking all Android app and game developers to finish your compatibility testing and publish your updates soon. For SDK, library, tools, and game engine developers, it’s even more important to release a compatible version right away, since your downstream app and game developers may be blocked until they receive your updates.

As we covered in depth at Beta 2, here’s how to test for compatibility with Android 11.

For testing your current app, read behavior changes for all apps to identify areas where platform changes might affect your apps. Here are some of the top changes to watch for (these apply regardless of your app’s targetSdkVersion):

Remember to test the libraries and SDKs in your app for compatibility. If you find an issue, try updating to the latest version of the SDK, or reach out to the developer for help.

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.

Explore the new features and APIs

Android 11 has a ton of new features to build new experiences for users around people, controls, and privacy. When you’re ready to dive in, check out our #Android11 Beta post for a recap of all of the developer features, and you can also visit the Beta Launch page to see talks from the Android team on what’s new in their areas. For complete details on Android 11 features and APIs, visit the Android 11 developer site.

Also make sure to try the Android 11 features in Android Studio that can improve your productivity and workflow, like ADB incremental for faster installs of large APKs, and additional nullability annotations on platform APIs. You can give these a try by downloading the latest Android Studio Beta or Canary version. Instructions for configuring Android Studio for Android 11 are here.

How do I get Beta 3?

It’s easy! Just enroll here to get the Beta 3 update over-the-air on your Pixel 2, 3, 3a, or 4 device (and coming soon, Pixel 4a). If you're already enrolled, you'll receive the update soon and no action is needed on your part. Alternatively, you can give Android Flash Tool a try for easy on-demand updates, and if you’d rather flash manually, downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator in Android Studio or try a GSI image to run Android 11 on supported Treble-compliant devices.

What’s next?

Stay tuned for the official Android 11 launch coming in the weeks ahead! In the meantime, we recommend finishing your testing and publishing your compatible updates as soon as possible. Feel free to share your feedback using our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've given us great feedback so far -- thank you again!

A huge thank you to our developer community for your participation in our recent Android 11 AMA and Android Studio AMA on r/anddroiddev! It’s great to hear what’s important to you and we hope we were able to help!

August 6th 2020, 1:04 pm

Leverage the In-App Review API for your Google Play reviews

Android Developers Blog

Posted by Scott Lin, Product Manager, Google Play

For many developers, ratings and reviews are an important touchpoint with users. Millions of reviews are left on Google Play every day, offering developers valuable insight on what users love and what they want improved. Users also rely on ratings and reviews to help them decide which apps and games are right for them.

Over the past two years, Google Play has launched various features to make it easier for users to leave reviews, as well as for developers to interact and respond to them. For example, users are now able to leave reviews from the Google Play homepage. We also launched the Reviews page under My Apps & Games, which gives users a centralized place to leave and manage reviews.

But one of the most requested features from developers has been to give users the ability to leave a review from within the app, without heading back to the App Details page. So today, we’re pleased to launch the new in-app review API to address that need.

Ask for a review at just the right time

The API lets developers choose when to prompt users to write reviews within the app experience. We believe the best time to prompt your users is when they have used the app enough to be able to provide thorough and useful feedback. However, be sure not to interrupt them in the middle of a task or when their attention is needed, as the review flow will take over the action on the screen.

Users can now give ratings and reviews within your app.

The in-app review API supports both public and private reviews for when your app is in beta.

The review API is part of the Play Core Library, which is distributed for Java/Kotlin, C++, and Unity. It offers a lightweight API that allows apps to request a review and launch the review flow without users leaving the app.

The integration consists of four main steps:

  1. Define the conditions and best place to ask for a review
  2. Request the review flow to the API
  3. Launch the review at an appropriate moment
  4. Continue the flow after the review is completed

Whether the user leaves a review or not, the app must continue without altering the user flow. The in-app review API is designed to be seamless for users.

You can see the in-app review API in action in our newly published sample, which showcases calling the API through the Play Core Kotlin extensions (KTX) library, alongside other Play Core APIs such as in-app updates and on-demand feature modules installation.

Gathering the best feedback

The API will make it much easier for users to share valuable insights about your app.

Here’s what some of our partners said during the early-access program:

“It was quick and easy to integrate with the new In-App Review API changes, and we saw an almost immediate increase in positive ratings and reviews after releasing those changes.”

- Chris Scoville, Engineering Manager at Calm

“The in-app review API allows our customers to rate without leaving the application. Our 5-star ratings since implementing the API has increased by 4x.”

- Nathaniel Khuana, Technical Architect, Tokopedia

"We saw our all-time highest rating just a week after we implemented in-app reviews."

- Welly Chandra, Associate Product Manager at Traveloka

Because the best feedback is honest and unbiased, we designed the API to be self-contained and not require additional prompting other than to invoke the API. We’ve also placed cap limits to ensure that users won’t be prompted excessively should they choose not to leave a review.

We encourage developers to explore integrating the in-app review API as it will unlock the type of feedback that only your dedicated users can provide. And remember, once you receive those reviews, there are a multitude of ratings and reviews tools available to you on the Google Play Console to help you analyze the reviews and respond to users' concerns directly.

How useful did you find this blog post?

August 5th 2020, 9:14 am

Recent Android App Bundle improvements and timeline for new apps on Google Play

Android Developers Blog

Posted by Posted by Dom Elliott and Yafit Becher, Product Managers at Google Play

In a little over two years, the Android App Bundle has become the gold standard for publishing on Google Play. Over 600,000 apps and games currently use the app bundle in production, representing over 35% of all releases on Google Play. App bundles are used by 50% of the top developers on Google Play — such as Adobe, which used app bundles to reduce the size of Adobe Acrobat Reader by 20%.

We recently launched Play Asset Delivery (PAD), bringing the great benefits of app bundles to games and allowing developers to improve the user experience while cutting delivery costs and reducing the size of their games. Gameloft used PAD to improve user retention, resulting in 10% more new players than with their previous asset delivery system.

For those of you making the switch, we’ve published some FAQs on Play App Signing — required for app bundles — as well as guidance on how to test your app bundle. Read on to find out more about the recent improvements we’ve made to developing, testing, and publishing with app bundles.

Play Feature Delivery

The app bundle enables modular app development using dynamic feature modules with a range of customizable delivery options. It’s now possible to shrink resources in dynamic feature modules as well as your base module when building modular apps. This long-requested feature can result in significantly greater size reduction of your apps. The feature is available from Android Studio 4.2, currently in Canary, under the experimental flag: android.experimental.enableNewResourceShrinker=true.

By default, install time modules are now automatically fused when app bundles are processed into distribution APKs (starting in bundletool 1.0.0). This means you can separate your app into modules during development while reducing the number of APKs distributed to each device, which will speed up your app’s download and installation. You can choose to set a “removable flag” for install-time modules to prevent fusing, which allows you to uninstall a module on the device after it’s been used. It’s a good idea to remove large modules once they’re no longer needed — reducing the size of your app can make it less likely to be uninstalled.

Feature-to-feature dependency is now stable in Android Studio 4.0, so you can specify that a dynamic feature module depends on another feature module. Being able to define this relationship ensures that your app has the required modules to unlock additional functionality, resulting in fewer requests and easier modularization of your app.

We know that it is critical for you to test your app delivery and get the same experience as your users would in the wild. Internal app sharing lets you upload test builds to Play and get a sharable link to download your app. When downloading your app from this link, you get an identical binary as would be served to users once your app is released to Play.

Play Asset Delivery

Play Asset Delivery extends the app bundle format, allowing you to package up to 2GB of game assets alongside the binary in a single artifact published on Google Play. PAD lets games larger than 150MB replace the legacy expansion files (OBBs) and rely on Play to keep assets up to date, just like you do with your game binary. It also takes care of compression and delta patching, minimizing the size of the download and getting your game to update faster.

You can then choose one of three delivery modes, depending on when you want those assets to be served to users: upfront, as part of the initial game installation; on-demand, so assets will be delivered only upon request; or fast-follow, which will trigger an additional download immediately after the game installation completes, independently of the user opening the app. Fast-follow lets you minimize time to first interaction while getting assets to users as quickly as possible.

In the coming months, we’ll release texture compression format targeting, which will allow you to include multiple texture compression format assets and rely on us to deliver them to the most advanced format supported by the requesting device.

Learn more in this session from our Game Developer Summit and check out the documentation to see integration options for Unity, Unreal Engine, Gradle, Native, and Java support.

Google Play’s best-in-class distribution

Google Play delivers billions of apps, games, updates, and dynamic feature modules every month to Android users on thousands of device types around the world. We invest a lot of time and energy into making sure your content is delivered to users as seamlessly and efficiently as possible while hiding the complexity from the user experience.

For example, we recently upgraded the download service Google Play uses. This change alone has sped up the installation of app bundle apps by an average of 6% and increased install success globally by 1%, resulting in millions more new installs for developers every week.

We’re also rolling out multiple improvements to dynamic feature module distribution, such as allowing them to be installed when your app is VISIBLE or higher, lowering the free storage threshold that triggers insufficient storage errors, and removing user confirmation for large dynamic features over Wi-Fi. This alone has resulted in 12% more successful deferred module downloads. Apps using dynamic features will benefit from these changes automatically.

Requirement for new apps in the second half of 2021

We’re continuing to make app bundles a better publishing format than APKs on Google Play. For example, the new app bundle explorer lets you manage all your app bundles in one place. You can download and attest the exact APKs that Play generates for delivery, as well as a signed, universal APK (a single, installable APK that includes all code and resources needed for supported devices) that you can use on other distribution channels.

We’ve been thrilled to see the app bundle embraced by the app and game ecosystem, and we’re excited to continue to improve it. As we announced in the Android 11 event, to help us invest in future improvements, we intend to require new apps and games to publish with the Android App Bundle on Google Play in the second half of 2021. In the same timeframe, we will deprecate legacy APK expansion files (OBBs), making Play Asset Delivery the standard option for publishing games over 150MB. We will also require instant experiences to be published via instant-enabled app bundles, deprecating the legacy instant app ZIP format.

Thank you to everyone who has already made the switch to the Android App Bundle, and a special thanks to those of you who’ve shared your feedback. Your comments help us shape the future of app bundles and improve the technology for everyone, so please continue to let us know what you think.

How useful did you find this blog post?

August 4th 2020, 9:08 am

Protecting your Google Play Console account with 2-Step Verification

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play Console

Google Play Console has something for everyone, from QAs and PMs to engineers and marketing managers. The new Google Play Console beta, available now at, offers customized, secure access to everyone on your team. For a closer look at some of its new features and workflows, tune in to this week’s series of live webinars, which will also be available on demand.

Granting your team members safe access to specific features in your developer account is one of the best ways to increase the value of our tools for your organization. We want to make sure that your developer account is as safe as possible so you feel confident when granting access. A key way to do that is to make sure that every person who has access to your account signs in using secure methods that follow best practices. That’s why, towards the end of this year, we’re going to start requiring users of Google Play Console to sign in using Google's 2-Step Verification.

2-Step Verification uses both your password and a second way to identify you for added security. This could be a text message to a registered phone, an authenticator app, alerts on supported devices, or a hardware security key. Normally, you only have to do this when you sign in for the first time on a new computer. It’s one of the easiest ways to increase the level of security for you and your team members’ accounts.

Learn more about 2-Step Verification here, and how to set it up for your own account.

If you have any comments or concerns about using 2-Step Verification to sign in to Google Play Console, or if you think it will impact you or your teams’ use of Google Play Console, use this form to let us know. All responses will be read by our product team and will help us shape our future plans.

Your team won’t be required to use 2-Step Verification immediately, although we recommend that you set it up now. We will start mandating 2-Step Verification with new users to Google Play Console towards the end of Q3, followed by existing users with high-risk permissions like app publishing or changing the prices in in-app products, later in the year. We’ll also remind every impacted user in Google Play Console at least 30 days before the change takes effect. We may also start to re-verify when you’re undertaking a sensitive action like changing your developer name or transferring ownership of an app.

Hundreds of thousands of Google Play Console users already use 2-Step Verification to keep their accounts safe, and it's been the default for G Suite customers for years. But we understand that requiring this may impact some of your existing workflows, which is why we’re giving advance notice of this change and asking for your feedback.

We can all take steps to keep our accounts and the developer community safe. Thanks for publishing your apps on Google Play.

How useful did you find this blog post?

August 3rd 2020, 11:43 am

11 Weeks of Android: Android Developer Tools

Android Developers Blog

Posted by Jamal Eason, Product Manager, Android

This blog post is part of a weekly series for #11WeeksOfAndroid. For each of the #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we spotlighted Android Developer Tools; here’s a look at what you should know.

The big news

During the 11 weeks of Android, we launched a range of developer tool updates in Android Studio. As of today, you can find version 4.0 of Android Studio on the stable release channel, version 4.1 on the beta channel, and the very latest features of version 4.2 on the canary channel. The focus across each of these versions is a balance of app productivity and delivery of a high quality product that you can rely on for app development. For each day of this past week we highlighted improvements and tips in the key points of your development flow from app design, coding, deployment, build, app testing with the emulator, to app performance profiling. This blog highlights the content that we released during the Android Developer Tools week of 11 Weeks of Android.

What to watch and read

To see an overview of what is new in Android Developer Tools across the recent releases of Android Studio, check out this video from the #Android11 Beta launch which includes an exciting and in-depth demo.

What’s New in Android Development Tools


At the beginning of the week we had a day of content focused on app design tools for developers. To start, watch this overview video of the latest updates in design tools:

What’s new in Design Tools

We also posted two in-depth blog posts for the design tools day:

To debug your layouts, watch our video on the updates to the layout inspector:

Debugging UI issues with Layout Inspector

And lastly for design tools, we released a video about the latest developments for Jetpack Compose Design tools:

What's new in Compose Design Tools

Coding & Deployment

During the week, we posted tips and tricks to improve your coding experience and app deployment flow in Android Studio. Check out the following social media channels to review the latest postings:

We also shared a new video on how to use the new database inspector in Android Studio:

Database Inspector

Additionally, you will find an updated blog on the development tools we have in place for Jetpack Hilt:


In the middle of the week, we released four blogs posts around the build system in Android developer tools, which included:

Android Emulator

On top of sharing a series of best practices and tips on social media about using the Android Emulator during the week, you can also a full summary in the following in-depth article:

Performance Profilers

We know improving app performance is critical for a great user experience. Therefore, we ended the week with a day on performance profilers content. To start, we posted a video about System Trace and how you can use it to troubleshoot app performance issues:

Troubleshooting app performance issues with System Trace in Android Studio

Plus, we published a blog post on C++ memory profiling:

Learning path

If you’re looking for an easy way to pick up the highlights of this week, check out the Developer Tools pathway. A pathway is an ordered tutorial that allows users to complete a pre-defined module that culminates in a quiz. It includes videos and blog posts. A virtual badge is awarded to each user who passes the quiz. Test your knowledge of key takeaways about Developer Tools to earn a limited edition badge.

Key takeaways

Thank you for tuning in and learning about the latest in Android Development tools. Thanks to all of you who chatted with us during the Reddit AMA this week. Throughout this past week, we showcased features that can be found either in the latest stable release or the canary release channel of Android Studio. If you want to try out what you learned this week, download Android Studio today.

Below, you will find a quick listing of where you will find each of the major features. Note, that features in non-stable versions may not land in a particular version until they have reached our quality bar:

Features found in Android Studio 4.0 (Stable Channel)

Features found in Android Studio 4.1 (Beta Channel)

Features found in Android Studio 4.2 + (Canary Channel)


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

July 31st 2020, 7:10 pm

Introducing the Motion Editor

Android Developers Blog

Posted by Scott Swarthout, Product Manager

We spoke with the Android developer community and learned that animations are important for making UIs more intuitive and memorable. However, we also heard that adding complex animation to Android apps has been a difficult task.To address this problem, we created a powerful set of APIs with Motion Layout and a corresponding tool – Motion Editor, that when combined make it easier to build pixel-perfect animations. This blog is a quick tour of the new Motion Editor and how to use the latest features during your animation development. Additionally today, you can now watch a new video series specifically created to teach you about the various APIs included with MotionLayout. Watch here.

Motion Editor is a visual design editor for the MotionLayout layout type, making it easier to create and preview animations. We just released the stable version Motion Editor in Android Studio 4.0 and we already see many developers using it to build animations.

Animation running in the Motion Editor

The Motion Editor is an extension of Android Studio’s layout editor, and automatically opens when you select the Design or Split view on an XML file containing a MotionLayout. From there, you can edit your layout and Motion Scene files using the familiar interactive tools of the Layout Editor as well as preview your animations right from the Android Studio preview pane.

Motion Editor

The Motion Editor is broken up into several panels which we will describe in this article. The main panels are: Overview, Selection, Attribute, and Preview.

The Motion Editor has four main panels

Overview panel

MotionLayout helps you animate layout changes, which you specify as transitions between ConstraintSets. The Motion Editor helps you visualize these states with the Overview panel. To edit constraints in a ConstraintSet, click on the corresponding box in the Overview panel.

MotionLayout Scene with two ConstraintSets, start and end, and a Transition between them

Selection panel

The Selection panel provides detailed controls based on the state of the Overview panel. It has three modes:

  1. Motion Layout selected
  2. ConstraintSet selected
  3. Transition selected

The selection panel has three modes depending on the state of the Overview panel

MotionLayout selected

The Motion Editor supports editing of the base Motion Layout. When Motion Layout is selected in the Overview panel, you can select components to see if they are properly constrained.

Check if components are properly constrained with the Selection panel

ConstraintSet selected

When a ConstraintSet is selected, the Selection panel displays the list of components and a checkmark to indicate if the component is constrained in this ConstraintSet.

Select components to be included in the ConstraintSet

Transition selected

When a transition is selected, you can control the playback of the animation with the animation toolbar. When an animation is selected, click Play ▶️ above the timeline to preview the animation.

Preview animations on the Motion Editor timeline


Sometimes you want to modify the path a view takes during an animation. To do this, MotionLayout uses keyframes. We build keyframe editing into the editor to make it easy to tweak animations. To create a new keyframe, click on the new keyframe icon in the top right of the selection panel. This action opens a dialog where you can set attributes for the keyframe. To edit a keyframe, click on the diamond ◆ icon to open the KeyFrame attribute panel.

Create keyframes with the selection panel

Attribute panel

Creating animations in MotionLayout involves editing lots of view parameters, so we brought the Attribute panel from the Layout Editor into the Motion Editor. The Attribute panel includes handy visualizations for Constraints as well as all the attributes set on each view in the Motion Scene file.

Constraint visualization in the Attribute panel

The Attribute panel is also where you can create custom attributes. You use custom attributes when you want to animate view properties that are not part of the ConstraintLayout or MotionLayout APIs, such as backgroundColor. We made it easy to create custom attributes with autocomplete and input validation for all view properties.

Preview panel

We wanted to make it easy to quickly edit and get immediate feedback when working on animations, so you can view animations right from the Preview panel. Now you don’t have to recompile and redeploy your app every time you want to make a small tweak to your animation.

We also added a number of features to the Preview panel to make it easier to understand how views are animating. You can preview animations with the Design view and Blueprint view to get a clearer idea of how your views are moving with fewer visual distractions.

We also added visualizations for the paths views take across the screen, including markers for keyframes. We hope these features make it easier to parse complex transitions and simplify the creation experience.

The Motion Editor is available in Android Studio 4.0, give it a try and let us know what you think! We are eager to see what the community builds with MotionLayout and the Motion Editor. The Android Studio team is constantly gathering feedback to improve the experience of using our tools, so if you have any ideas for new features or run into any issues using these tools, please file a bug.

The code used in this example, along with several other MotionLayout examples, are available on our GitHub sample page, found here.

For more information on MotionLayout, see the following links:

July 27th 2020, 9:16 pm

The winners of the Google Play Indie Games Festival are...

Android Developers Blog

Posted by Leticia Lago, Head of Developer Marketing, EMEA

We wrapped up the Indie Games Festivals in Europe, Japan, and South Korea. You can now check out the three winners and Top 10 finalists from each of the contests.

The Google Play Indie Games Festival celebrates the creativity and innovation that small games developers bring to the Play Store.

We shortlisted 20 finalists for each contest after receiving hundreds of submissions. The finalists were to showcase their art at events in Warsaw, Tokyo, and Seoul. However, this year’s unprecedented events saw the finalists presenting to jury members online. The juries then deliberated to select the winners.

Winning developers receive prize packages designed to help them grow their business on Android and Google Play. Each package offers promotions on the Google Play Store, consultations with members of the Google Play team, Google hardware, promotion campaigns, and more.

Join us in congratulating the developers and try out their games.


(In alphabetical order)

Cookies Must Die by Rebel Twins (Poland)

inbento by Afterburn (Poland)

The White Door by Rusty Lake (Netherlands)

The other finalist to make the Top 10 as selected by the jury members are, in alphabetical order:

60 Parsecs! by Robot Gentleman (Poland)

Alien Escape by KORION Interactive (Germany)

Alt-Frequencies by Accidental Queens (France)

Doors: Awakening by Big Loop Studios (Bulgaria)

My Diggy Dog 2 by King Bird Games (Russia)

Traffix by WebAvenue Unipessoal Lda (Portugal)

Void Tyrant by Quite Fresh Ltd. (United Kingdom)


(In alphabetical order)

GIGAFALL by Shiki Game Studio


Wasurenaide, otona ni natte mo by GAGEX Co.,Ltd.

The other final list to make the Top 10 as selected by the jury members are, in alphabetical order:

Boku to hakubutsukan by oridio Inc.

GummyShooter by simatten

Home Fighter by hap Inc.

MonsterTrader by Mitsuhiro Okada

Snowman Story by Odencat

World for Two by Seventh rank

Zelle by Odencat

South Korea

(In alphabetical order)

Heroes Restaurant by Team Tapas

Magic Survival by LEME

Project Mars by Moontm

The other finalist to make the Top 10 as selected by the online audience and the jury are, in alphabetical order:


Dust by I-eye studio

Extreme Football by 9M Interactive

Great Sword by olivecrow

QV by izzle

Sand Shark: The Boy and The Sea by GABANGMAN STUDIO

Sword Master Story by CodeCAT

Congratulations to all the winners! And thanks to everyone who entered.

How useful did you find this blog post?

July 27th 2020, 11:41 am

11 Weeks of Android: Jetpack

Android Developers Blog

Posted by Diana Wong, Product Manager, Android Jetpack

This blog post is part of a weekly series for #11WeeksOfAndroid. For each of the #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything.This week, we spotlighted Jetpack; here’s a look at what you should know.

The big news

In 2018, we launched Android Jetpack as a suite of libraries to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices. We are excited about the growth we’ve seen and the incredible feedback that developers like you have shared with us. 47% of the top 1000 apps use 2 or more Jetpack libraries, not including core libraries like AppCompat or Lifecycle. Our work over the past year has been about making the basics easy for Android developers, so that you can focus on the code you care about. We have released many updates to our existing libraries as well as new libraries to help make building high-quality apps easier.

What to watch

We have also been busy pushing out many updates over the past year!

For an overall look at what’s new in Jetpack, be sure to check out our talk from #Android11 Beta launch:

It’s a quick fly-by introducing many of the updates to our libraries, with pointers on how to get started.

This week, we’ve also done deep dives into major releases like Hilt, including cheat sheets to help you get started, and how we migrated our own samples to use Hilt for dependency injection. Less boilerplate = more fun.

Paging 3.0 is one of our first libraries written Kotlin-first and based on coroutines. The Paging library adds the features you asked for like better error handling, easier list transformations like map or filter, and support for common features like list separators, headers, and footers. We added RxJava, LiveData and ListenableFutures support and backwards compatibility with Paging 2, so it’s easier to migrate.

Using the Camera in your app? CameraX is in Beta and helps developers manage edge cases across different devices and OS versions, so that you don’t have to.

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. Let us navigate you through them all here:

Spotlight on Permissions

In Android 11, we continued our work to give users even more control over sensitive permissions. At the same time, it's very important to us that we make it as easy as possible for you as developers to build for Android. With the changes in privacy over the past several releases, Android Jetpack is making it easier for your app to work with 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. Find out more in this post.

Learning path

Take a look at our new Learning pathway for an easy way to go through all the highlights from this week. It’s an ordered tutorial which guides you through our new content, culminating in a quiz. Bonus: You earn a bright and shiny Jetpack badge to be saved to your Google Developer Profile. In addition to the learning pathway, we’ve also got a new library explorer to make it simple to find more about Jetpack libraries you might be looking for and their latest updates.

Key takeaways

Best practices are baked into Jetpack libraries, giving opinionated guidance to make it easier for you to build a higher-quality Android app. We’ve released new features to Navigation and Workmanager, updates to increase the stability of CameraX, added robustness for Biometrics, and more. We’ve also launched new libraries, like our collaboration with Dagger for Hilt and a new library to help improve app startup. Your feedback is important to us; so give these libraries a shot, tell us what you think, and help us improve them!


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

July 24th 2020, 1:13 pm

Improving inter-activity communication with Jetpack ActivityResult

Android Developers Blog

Posted by Yacine Rezgui, Developer Advocate

Whether you're requesting a permission, selecting a file from the system file manager, or expecting data from a 3rd party app, passing data between activities is a core element in inter-process communication on Android. We’ve recently released the new ActivityResult APIs to help handle these activity results.

Previously, to get results from started activities, apps needed to implement an onActivityResult() method in their activities and fragments, check which requestCode a result is referring to, verify that the requestCode is OK, and finally inspect its result data or extended data.

This leads to complicated code, and it doesn’t provide a type-safe interface for expected arguments when sending or receiving data from an activity.

What are the ActivityResult APIs?

The ActivityResult APIs were added to the Jetpack activity and fragment libraries, making it easier to get results from activities by providing type-safe contracts. These contracts define expected input and result types for common actions like taking a picture or requesting a permission, while also providing a way to create your own contracts.

The ActivityResult APIs provide components for registering for an activity result, launching a request, and handling its result once it is returned by the system. You can also receive the activity result in a separate class from where the activity is launched and still rely on the type-safe contracts.

How to use it

To demonstrate how to use the ActivityResult APIs, let’s go over an example where we’re opening a document.

First, you need to add the following dependencies to your gradle file:

repositories {

dependencies {
  implementation "androidx.activity:activity:1.2.0-alpha02"
  implementation "androidx.activity:fragment:1.3.0-alpha02"

You need to register a callback along with the contract that defines its input and output types.

In this context, GetContent() refers to the ACTION_GET_DOCUMENT intent, and is one of the default contracts already defined in the Activity library. You can find the complete list of contracts here.

val getContent = registerForActivityResult(GetContent()) { uri: Uri? ->
    // Handle the returned Uri

Now we need to launch our activity using the returned launcher. As you can set a mime type filter when listing the selectable files, GetContent.launch() will accept a string as a parameter:

val getContent = registerForActivityResult(GetContent()) { uri: Uri? ->
    // Handle the returned Uri

override fun onCreate(savedInstanceState: Bundle?) {
    // ...

    val selectButton = findViewById<Button>(

    selectButton.setOnClickListener {
        // Pass in the mime type you'd like to allow the user to select
        // as the input

Once an image has been selected and you return to your activity, your registered callback will be executed with the expected results. As you saw through the code snippets, ActivityResult brings an easier developer experience when dealing with results from activities.

Start using Activity 1.2.0-alpha02 and Fragment 1.3.0-alpha02 for a type-safe way to handle your intent results with the new ActivityResult APIs.

Let us know what you think and how we can make it better by providing feedback on the issue tracker.

July 23rd 2020, 5:47 pm

Decrease startup time with Jetpack App Startup

Android Developers Blog

Posted by Yacine Rezgui, Developer Advocate and Rahul Ravikumar, Software Engineer

Application startup time is a critical metric for any application. Users expect apps to be responsive and fast to load. When an application does not meet this expectation, it can be disappointing to users. This poor experience may cause a user to rate your app badly on the Play store, or even abandon your app altogether.

Jetpack App Startup is a library that provides a straightforward, performant way to initialize components at application startup. Both library developers and app developers can use App Startup to streamline startup sequences and explicitly set the order of initialization.

Apps and libraries often rely on having components (WorkManager, ProcessLifecycleObserver, FirebaseApp etc.) initialized before Application.onCreate(). This is usually achieved by using content providers to initialize each dependency. Instead of defining separate content providers for each component that needs to be initialized, App Startup lets you define initializers that share a single content provider. This significantly improves app startup time, usually by ~2ms per content provider. App Startup also helps you further improve startup performance by making it really easy to initialize components lazily. When App Startup goes stable, we will be updating our libraries like `WorkManager` and `ProcessLifecycle` to benefit from this as well.

App Startup supports API level 14 and above.

How to use it

Gradle setup

To use App Startup in your library or app, add the following dependency to your gradle file:

repositories {

dependencies {
  implementation "androidx.startup:startup-runtime:1.0.0-alpha02"
Define an Initializer

To be able to use App Startup in your application, you need to define an Initializer. This is where you define how to initialize and specify your dependencies. Here’s the interface you need to implement:

interface Initializer<out T: Any> {
    fun create(context: Context): T
    fun dependencies(): List<Class<out Initializer<*>>>

As a practical example, here’s what an Initializer that initializes WorkManager might look like:

class WorkManagerInitializer : Initializer<WorkManager> {
    override fun create(context: Context): WorkManager {
        val configuration = Configuration.Builder()

        WorkManager.initialize(context, configuration)
        return WorkManager.getInstance(context)
    // This component does not have any dependencies
    override fun dependencies() = emptyList<Class<out Initializer<*>>>()

Note: This example is purely illustrative. This Initializer should actually be defined by the WorkManager library.

Lastly, we need to add an entry for WorkManagerInitializer in the AndroidManifest.xml:

    <!-- This entry makes WorkManagerInitializer discoverable. -->
    <meta-data android:name="com.example.WorkManagerInitializer"
          android:value="androidx.startup" />

How it works

App Startup uses a single content provider called InitializationProvider. This content provider discovers initializers by introspecting the <meta-data> entries in the merged AndroidManifest.xml file. This happens before Application.onCreate().

After the discovery phase, it subsequently initializes a component after having initialized all its dependencies. Therefore, a component is only initialized after all its dependencies have been initialized.

Lazy initialization

We highly recommend using lazy initialization to further improve startup performance. To make initialization of a component lazy, you need to do the following:

Add a tools:node="remove" attribute to the <meta-data> entry for the Initializer. This disables eager initialization.

    <!-- disables eager initialization -->
    <meta-data android:name="com.example.WorkManagerInitializer"
              tools:node="remove" />

To lazily initialize WorkManagerInitializer you can then use:

// This returns an instance of WorkManager

Your app now initializes the component lazily. For more information, please read our detailed documentation here.

Final thoughts

App Startup is currently in alpha-02. Find out more about how to use it from our documentation. Once you try it out, help us make it better by giving us feedback on the issue tracker.

July 23rd 2020, 3:14 pm

What’s New in Navigation 2020

Android Developers Blog

Posted by Jeremy Woods, Software Engineer, Android UI Toolkit

The latest versions of the Jetpack Navigation library (2.2.0 and 2.3.0) added a lot of requested features and functionality, including dynamic navigation, navigation back stack entries, a library for navigation testing, additional features for deep linking, and more. Let’s go over the most important changes, see what problems they solve, and learn how to use them!

Dynamic Navigation

We’ve updated Navigation to simplify adding dynamic feature modules for your application.

Previously, implementing navigation between destinations defined in dynamic feature modules required a lot of work. Before you could navigate to the first dynamic destination, you needed to add the Play Core library and the Split Install API to your app. You also needed to check for and download the dynamic module. Once downloaded, you could then finally navigate to the destination. On top of this, if you wanted to have an on-screen progress bar for the module being downloaded, you needed to implement a SplitInstallManager listener.

To address this complexity, we created the Dynamic Navigator library. This library extends the functionality of the Jetpack Navigation library to provide seamless installation of on-demand dynamic feature modules when navigating. The library handles all Play Store interaction for you, and it even includes a progress screen that provides the download status of your dynamic module.

The default UI for showing a progress bar when a user navigates to a dynamic feature for the first time. The app displays this screen as the corresponding module downloads

To use dynamic navigation, all you need to do is:

  1. Change instances of NavHostFragment to DynamicNavHostFragment
  2. Add an app:moduleName attribute to the destinations associated with a DynamicNavHostFragment

For more information on dynamic navigation, see Navigate with dynamic feature modules and check out the samples.

NavBackStackEntry: Unlocked

When you navigate from one destination to the next, the previous destination and its latest state is placed on the Navigation back stack. If you return to the previous destination by using navController.popBackBack(), the top back stack entry is removed from the back stack with its state still intact and the NavDestination is restored. The Navigation back stack contains all of the previous destinations that were needed to arrive at the current NavDestination.

We manage the destinations on the Navigation back stack by encapsulating them into the NavBackStackEntry class. NavBackStackEntry is now public. This means that users can go a level deeper than just NavDestinations and gain access to navigation-specific ViewModels, Lifecycles, and SavedStateRegistries. You can now properly scope data sharing or ensure it is destroyed at the appropriate time.

See Navigation and the back stack for more information.

NavGraph ViewModels

Since a NavBackStackEntry is a ViewModelProvider, you can create a ViewModel to share data between destinations at the NavGraph level. Each parent navigation graph of all NavDestinations are on the back stack, so your view model can be scoped appropriately:

val viewModel: MyViewModel by navGraphViewModels(

For more information on navGraph scoped view models, see Share UI-related data between destinations with ViewModel

Returning a Result from a destination

By combining ViewModel and Lifecycle, you can share data between two specific destinations. To do this, NavBackStackEntry provides a SavedStateHandle, a key-value map that can be used to store and retrieve data, even across configuration changes. By using the given SavedStateHandle, you can access and pass data between destinations. For example to pass data from destination A to destination B:

In destination A:

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    val navController = findNavController();
    // We use a String here, but any type that can be put in a Bundle is supported
        viewLifecycleOwner) { result ->
        // Do something with the result.

And in destination B:

navController.previousBackStackEntry?.savedStateHandle?.set("key", result)

See Returning a result to the previous Destination for more details.

Testing your Navigation Flow

Previously, the recommended testing solution for Navigation was Mockito. You would create a mock NavController and verify that navigate() was called at the appropriate time with the correct parameters. Unfortunately, this solution was not enough to test certain areas of Navigation flow, such as ViewModel interaction or the Navigation back stack. The Navigation Library now offers a well-integrated solution for these areas with the Navigation Testing library.

The Navigation Testing library adds TestNavHostController, which gives access to the Navigation back stack in a test environment. This means that you can now verify the state of the entire back stack. When using the TestNavHostController, you can set your own LifecycleOwner, ViewModelStoreOwner, and OnBackPressDispatcher by using the APIs given by NavHostController. By setting these components, you can test them in the context of navigation.

For example, here's how to test a destination that uses a nav graph-scoped ViewModel:

val navController = TestNavHostController(ApplicationProvider.getApplicationContext())

// This allows fragments to use by navGraphViewModels()

The TestNavHostController also lets you set the current destination. You can move the test directly to the use case being tested without the need to set it up using navigate() calls. This is extremely convenient for writing tests for different navigation scenarios.

When setting the current destination, you might do something like the following:

val navController = TestNavHostController(ApplicationProvider.getApplicationContext())


Remember that when setting the current destination, that destination must be part of your nav graph.

For more information about TestNavHostController, see the Test Navigation docs.

Nav Deep Linking

Deep linking allows you to navigate directly to any destination no matter where you currently are in the NavGraph. This can be very useful for launching your app to a specific destination or jumping between destinations that would otherwise be inaccessible to one another.

When navigating using a deep link, you can now provide deep link query parameters in any order and even leave them out altogether if they have been given a default value or have been made nullable. This means that if you have provided default values for all of the query parameters on a deep link, the deep link can match a URL pattern without including any query parameters.

For example,{arg1}&arg2={arg2} will now match with as long as arg1 and arg2 have default values and/or are nullable.

Deep links can also be matched using intent actions and MIME types. Instead of requiring destinations to match by URI, you can provide the deep link with an action or MIME type and match with that instead. You can specify multiple match types for a single deep link, but note that URI argument matching is prioritized first, followed by action, and then mimeType.

You create a deep link by adding it to a destination in XML, using the Kotlin DSL, or by using the Navigation Editor in Android Studio.

Here's how to add a deep link to a destination using XML:

<fragment android:id="@+id/a"
        <deeplink app:url=""

Here's how to add the same deep link using the Kotlin DSL:

val baseUri = ""

fragment<MyFragment>(nav_graph.dest.a) {
   deepLink(navDeepLink {
    uriPattern = "${baseUri}"
    action = "android.intent.action.MY_ACTION"
    mimeType = "type/subtype"

You can also add the same deep link using the Navigation Editor in Android Studio versions 4.1 and higher. Note that you must also be using the Navigation 2.3.0-alpha06 dependency or later.

Adding a deep link to a destination in the Navigation Editor

To navigate to a destination using a deep link, you must first build a NavDeepLinkRequest and then pass that deep link request into the Navigation controller's call to navigate():

val deepLinkRequest = NavDeepLinkRequest.Builder

For more information on deep links, visit Create a deep link for a destination, as well as the deep linking sections in Navigate to a destination and Kotlin DSL.

Navigation Editor

Android Studio 4.0 includes new features for the Navigation Editor. You can now edit your destinations using a split pane view. This means you can edit the XML or design and see the changes in real time.

Viewing a navigation.xml file in split view mode

In Android Studio 4.1, the Navigation Editor introduced the component tree. This allows you to traverse the entire nav graph, freely going in and out of nested graphs.

Navigating through a graph in the Navigation Editor

Additional Changes

NavigationUI can now use any layout that uses the Openable interface. This means that it is no longer limited to DrawerLayout and allows for customization of the AppBarConfiguration. You can provide your Openable and use it as the layout instead.

Navigation also provides support for Kotlin DSL. Kotlin DSL can be used to create different destinations, actions, or deep links. For more information see the documentation for Kotlin DSL.

Wrap up

Navigation added lots of useful features over the past year. You can simplify your dynamic feature modules by taking advantage of the Dynamic Navigator library, use a NavBackStackEntry to help correctly scope your data, easily test your navigation flow using the TestNavHostController, or even match your deep link using intent actions and/or MIME types.

For more information about the Jetpack Navigation library, check out the documentation at

Please provide feedback (or file bugs) using the Navigation issuetracker component.

July 23rd 2020, 12:02 pm

Getting on the same page with Paging 3

Android Developers Blog

Posted by Florina Muntenescu, Android Developer Advocate

Getting on the same page with Paging 3

The Paging library enables you to load large sets of data gradually and gracefully, reducing network usage and system resources. You told us that the Paging 2.0 API was not enough - that you wanted easier error handling, more flexibility to implement list transformations like map or filter, and support for list separators, headers, and footers. So we launched Paging 3.0 (now in alpha02), a complete rewrite of the library using Kotlin coroutines (still supporting Java users) and offering the features you asked for.

Paging 3 highlights

The Paging 3 API provides support for common functionality that you would otherwise need to implement yourself when loading data in pages:

We also made several Paging 3 components backwards compatible with Paging 2.0; so if you already use Paging in your app, you can migrate incrementally.

Adopting Paging 3 in your app

Let’s say that we’re implementing an app that displays all the good doggos. We get the doggos from a GoodDoggos API that supports index-based pagination. Let’s go over the Paging components we need to implement and how they fit into your app architecture. The following examples will be in Kotlin, using coroutines. For examples in the Java programming language using LiveData/RxJava, check out the documentation.

The Paging library integrates directly into the recommended Android app architecture in each layer of your app:

Paging components and their integration in the app architecture"

Defining the data source

Depending on where you’re loading data from, implement only a PagingSource or a PagingSource and a RemoteMediator:


A PagingSource defines the source of paging data and how to retrieve data from that single source. The PagingSource should be part of the repository layer. Implement load() to retrieve paged data from your data source and return the loaded data together with information about next and previous keys. This is a suspend function, so you can call other suspend functions here, such as the network call:

class DoggosRemotePagingSource(
    val backend: GoodDoggosService
) : PagingSource<Int, Dog>() {
  override suspend fun load(
    params: LoadParams<Int>
  ): LoadResult<Int, Dog> {
    try {
      // Load page 1 if undefined.
      val nextPageNumber = params.key ?: 1
      val response = backend.getDoggos(nextPageNumber)
      return LoadResult.Page(
        data = response.doggos,
        prevKey = null, // Only paging forward.
        nextKey = response.nextPageNumber + 1
    } catch (e: Exception) {
        // Handle errors in this block
        return LoadResult.Error(exception)

PagingData and Pager

The container for paginated data is called PagingData. A new instance of PagingData is created every time your data is refreshed. To build a stream of PagingData create a Pager instance, using a PagingConfig configuration object and a function that tells the Pager how to get an instance of your PagingSource implementation.

In your ViewModel you construct the Pager object and expose a Flow<PagingData> to the UI. Flow<PagingData> has a handy cachedIn() method that makes the data stream shareable and allows you to cache the content of a Flow<PagingData> in a CoroutineScope. That way if you implement any transformations on the data stream, they will not be triggered again each time you collect the flow after Activity recreation. The caching should be done as close to the UI layer as possible, but not in the UI layer, as we want to make sure it persists beyond configuration change. The best place for this would be in a ViewModel, using the viewModelScope:

val doggosPagingFlow = Pager(PagingConfig(pageSize = 10)) {


To connect a RecyclerView to the PagingData, implement a PagingDataAdapter:

class DogAdapter(diffCallback: DiffUtil.ItemCallback<Dog>) :
  PagingDataAdapter<Dog, DogViewHolder>(diffCallback) {
  override fun onCreateViewHolder(
    parent: ViewGroup,
    viewType: Int
  ): DogViewHolder {
    return DogViewHolder(parent)

  override fun onBindViewHolder(holder: DogViewHolder, position: Int) {
    val item = getItem(position)
    if(item == null) {
    } else {

Then, in your Activity/Fragment you’ll have to collect the Flow<PagingData> and submit it to the PagingDataAdapter. This is what the implementation would look like in an Activity onCreate():

val viewModel by viewModels<DoggosViewModel>()

val pagingAdapter = DogAdapter(DogComparator)
val recyclerView = findViewById<RecyclerView>(
recyclerView.adapter = pagingAdapter

lifecycleScope.launch {
  viewModel.doggosPagingFlow.collectLatest { pagingData ->

Paged data transformations

Displaying a filtered list

Transforming PagingData streams is very similar to the way you would any other data stream. For example, if we only want to display playful doggos from our Flow<PagingData<Dog>> we would need to map the Flow object and then filter the PagingData: { pagingData ->
        pagingData.filter { dog -> dog.isPlayful }

List with separators

Adding list separators is also a paged data transformation where we transform the PagingData to insert separator objects into the list. For example, we can insert letter separators for our doggos’ names. When using separators, you will need to implement your own UI model class that supports the new separator items. To modify your PagingData to add separators, you will use the insertSeparators transformation: { pagingData: PagingData<Dog> -> { doggo ->
    // Convert items in stream to UiModel.DogModel.
  .insertSeparators<UiModel.DogModel, UiModel> { before: Dog, after: Dog ->
      return if(after == null) {
          // we're at the end of the list
      if (before == null || before.breed != after.breed) {
          // breed above and below different, show separator
       } else {
           // no separator

Just as before, we're using cachedIn right before the UI layer. This ensures that loaded data and the results of any transformations can be cached and reused after a configuration change.

Advanced Paging work with RemoteMediator

If you’re paging data from a layered source, you should implement a RemoteMediator. For example, in the implementation of this class you need to request data from the network and save it in the database. The load() method will be triggered whenever there is no more data in the database to be displayed. Based on the PagingState and the LoadType we can construct the next page request.

It’s your responsibility to define how the previous and next remote page keys are constructed and retained as the Paging library doesn’t know what your API looks like. For example, you can associate remote keys to every item you receive from the network and save them in the database.

override suspend fun load(loadType: LoadType, state: PagingState<Int, Dog>): MediatorResult {

   val page = ... // computed based on loadType and state

   try {
       val doggos = backend.getDoggos(page)
       val endOfPaginationReached = emails.isEmpty()
       return MediatorResult.Success(endOfPaginationReached = endOfPaginationReached)
   } catch (exception: Exception) {
       return MediatorResult.Error(exception)

When you’re loading data from the network and saving it to the database, the database is the source of truth for the data displayed on the screen. This means that the UI will be displaying data from your database, so you’ll have to implement a PagingSource for your database. If you’re using Room, you’ll just need to add a new query in your DAO that returns a PagingSource:

@Query("SELECT * FROM doggos")
fun getDoggos(): PagingSource<Int, Dog>

The Pager implementation changes slightly in this case, as you need to pass the RemoteMediator instance as well:

val pagingSourceFactory = { database.doggosDao().getDoggos() }

return Pager(
     config = PagingConfig(pageSize = NETWORK_PAGE_SIZE),
     remoteMediator = DoggosRemoteMediator(service, database),
     pagingSourceFactory = pagingSourceFactory

Check out the docs to find out more about working with RemoteMediator. For a complete implementation of RemoteMediator in an app, check out step 15 of the Paging codelab and the accompanying code.

We’ve designed the Paging 3 library to help you accommodate both simple and complex uses of Paging. It makes it easier to work with large sets of data whether it’s being loaded from the network, a database, in-memory cache, or some combination of these sources. The library is built on coroutines and Flow, making it easy to call suspend functions and work with streams of data.

As Paging 3 is still in alpha, we need your help to make it better! To get started, find out more about Paging in our documentation and try it out by taking our codelab or checking out the sample. Then, let us know how we can improve the library by creating issues on the Issue Tracker.

July 21st 2020, 9:25 am

11 Weeks of Android: Languages

Android Developers Blog

Posted by David Winer, Product Manager

This blog post is part of a weekly series for #11WeeksOfAndroid. Each week we’re diving into a key area of Android so you don’t miss anything. This week, we spotlighted languages; here’s a look at what you should know.

Modern Android development starts with outstanding language support. Together, Kotlin, the Java programming language, and C++ form the foundation for Android’s APIs and the tools you use every day for app development. This week we dove into all of the latest news across Android’s three core languages: from Kotlin coroutines to Android 11’s new Java APIs to better tools for native development, there’s a lot packed into the latest release.

Kotlin and coroutines

Kotlin is at the core of Android’s modern, opinionated APIs. We hear from Android developers around the world that they love Kotlin for how expressive it is, how it helps you write higher quality apps, and how easy it is to start using in your existing Java codebase. More than 70% of the top 1000 apps on the Play Store now use Kotlin, and SlashDataTM announced earlier this year that Kotlin has been the fastest growing language community in percentage terms over the past two years. With the Android 11 beta, we decided to further embrace Kotlin by officially recommending coroutines for asynchronous work on Android.

Coroutines make it easy to write, read, and understand async code. The coroutines library is stable and already has deep integration with many of the Jetpack libraries you may be using, including Room, LiveData, and WorkManager. If you’re new to coroutines, check out Android ❤️ Coroutines: How to Manage Async Tasks in Kotlin, the latest coroutines learning pathway, and our new coroutines developer guide.

Getting started with Kotlin

From Kotlin-first libraries in Android Jetpack to deep integration with the tools in Android Studio, Android is deeply committed to Kotlin — and there’s never been a better time to start using it. We’ve heard from many of you, though, that convincing your team to adopt Kotlin is not always easy. Even though Kotlin is 100% interoperable with the Java programming language, your teammates might have concerns. Is it worth spending the time learning a new language? How should you prioritize Kotlin against our other product and technology priorities?

This week we released a new case study from the Google Home team to help answer some of these questions. Over the course of one year, the Google Home team moved all new feature development to Kotlin and found their null pointer exceptions dropped by 33% during the same period. This is consistent with what we’ve heard from Android teams all over the world — from Duolingo to Zomato to Cash App — Kotlin is delivering value both in the form of productivity and higher app quality for teams large and small. For all our latest case studies and data on Kotlin, check out our new Kotlin case studies page.

For beginners, we announced the launch of our new Android Basics in Kotlin course. If you are just learning how to program, Android Basics teaches essential programming concepts like functions and variables and will take you from “Hello World” all the way up through building a whole collection of Android apps in Kotlin.

The Java programming language and C++

When we announced official support for Kotlin three years ago, we didn’t forget about the large number of Java and C++ Android developers. In the Android 11 release, we sought to keep improving our support for both of these languages. With the Android 11 beta, we upgraded our Java library support with a number of new APIs from OpenJDK 9, 10, and 11. We also unveiled Java library desugaring in Android Studio 4.0, making it easy to use many of these newer Java APIs even on older Android devices — for those of you who have asked for java.time support on older devices, we’ve heard you loud and clear, and it’s arrived. For all the latest information on how to make use of these newer APIs, check out Murat Yener’s talk Support for newer Java APIs. With Android 11, we also updated the Android runtime to make app startup even faster with I/O prefetching.

The C++ developer experience continues to get better, too. 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.

Ever-improving toolchains

Finally, we continue to focus on improvements to the D8 and R8 compilers in Android Studio. Android Studio comes with built-in support for the R8 shrinker, which helps you keep your app’s memory footprint small, leading to higher installs and retention among your users. We also recently added support for shrinking Kotlin libraries and apps that use Kotlin reflection with R8. For more information, check out Mads Ager and Morten Krogh-Jespersen’s latest Medium post.


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

July 17th 2020, 5:03 pm

Google Home reduces #1 cause of crashes by 33%

Android Developers Blog

The Google Home app helps set up, manage, and control your Google Home, Google Nest, and Chromecast devices—plus thousands of connected home products like lights, cameras, thermostats, and more.

The engineering team behind the Google Home app benefits from using Kotlin and Android Jetpack libraries to boost engineering productivity and developer happiness.

What they did:

The Google Home team decided to incorporate Kotlin into their codebase to make programming more productive and to enable the usage of modern language features like var/val, smart casts, coroutines, and more. As of June 2020, about 30% of the code base is written in Kotlin, and Kotlin development is encouraged for all new features.

The team also adopted Jetpack libraries to improve developer velocity, decrease the need for boilerplate code maintenance, and reduce the necessary amount of code. Jetpack libraries also helped make their code more testable, since there are clearer functional boundaries and APIs.


"Efficacy and writing less code that does more is the ‘speed’ increase you can achieve with Kotlin.” - Jared Burrows, Software Engineer on Google Home

Switching to Kotlin resulted in a reduction in the amount of required code, compared to the equivalent of existing Java code. One example is the use of data classes and the Parcelize plugin: a class which was 126 hand-written lines in Java can now be represented in just 23 lines in Kotlin—an 80% reduction. Additionally, equality and parcelizing methods can be automatically generated and kept up to date. Many nested loops and filtering checks were also simplified using the functional methods available in Kotlin.

Because Kotlin can make nullability a part of the language, tricky situations can be avoided, like when inconsistent usage of nullability annotations in Java might lead to a missed bug. Since the team started migrating to developing new features with Kotlin, they saw a 33% decrease in NullPointerExceptions. Since this is the most common crash type on Google Play Console, reducing them led to a dramatically improved user experience.

With a large, mature app like Google Home—which has over a million lines of code—it’s helpful to be able to gradually add Jetpack libraries. Incorporating them allowed the team to consolidate and replace custom tailored solutions, sometimes even with a single library. Since Jetpack libraries can help engineers follow best practices and be less verbose (for example, using Room or ConstraintLayout), readability was increased as well. The team considers many of the newer Jetpack libraries ‘must-haves,’ including ViewModel and LiveData, both of which are used extensively in the Google Home codebase.

The Google Home app team found the Jetpack KTX integrations with Kotlin coroutines to be especially helpful. The team is now able to avoid tricky asynchronous programming bugs by associating coroutines with lifecycle-aware components like ViewModel.

Java is a registered trademark of Oracle and/or its affiliates.

Get Started:

Learn more about writing Android apps in Kotlin and using Android Jetpack libraries.

July 16th 2020, 11:13 am

Learn Android and Kotlin with no programming experience

Android Developers Blog

Posted by Kat Kuan, Developer Advocate, Android

Many people today are considering career paths that enable them to work remotely. App development allows for that style of work. For people who want a new opportunity, it’s possible to start learning Android today, even without prior programming experience.

In 2016, we released our Android Basics curriculum, which assumes no programming experience, and the response has been tremendous. Hundreds of thousands of students have been learning Android development and programming concepts simultaneously as they build apps. Since then, there have been big platform changes with four major releases of Android and support added for the Kotlin programming language. We also introduced Jetpack, a suite of libraries that make it easier to build better apps with less code. With all these new updates, it’s time to release the next generation of training content for beginners.

Today we’re announcing the launch of Android Basics in Kotlin, a new online course for people without programming experience to learn how to build Android apps. The course teaches Kotlin, a modern programming language that developers love because of its conciseness and how it increases productivity. Kotlin is quickly gaining momentum in industry. Over a single year from 2018 - 2019, Indeed Hiring Lab found a 76% increase in Kotlin jobs.*

Google announced that Android development is Kotlin-first, and 60% of professional Android developers have already adopted the language. In the Play Store, 70% of the top 1,000 apps use Kotlin. To keep pace and prepare for the future, there has never been a more opportune time to learn Android with Kotlin.

Learning to code for the first time can feel intimidating, but it is possible to learn without a technical background. From a recent Stack Overflow Developer Survey, nearly 40% of the professional developers who studied at university did not receive a formal computer science or software engineering degree.

To build your confidence, the Android Basics in Kotlin course offers step-by-step instructions on how to use Android Studio to build apps, as well as how to run them on an Android device (or virtual device). The goal is to expose you to the tools and resources that professional Android developers use. With hands-on practice, you learn the fundamentals of programming. By the end of the course, you will have completed a collection of Android apps to start building a portfolio.

App screenshots from the course

This course is split up into units, where each unit is made up of a series of pathways. At the end of each pathway, there is a quiz to assess what you’ve learned so far. If you pass the quiz, you earn a badge that can be saved to your Google Developer Profile.

Badges you can earn

The course is free for anyone to take. Basic computer literacy and basic math skills are recommended prerequisites. Unit 1 of the course is available today, with more units being released as they become available. If you’ve never built an app before but want to learn how, check out the Android Basics in Kotlin course.

If you already have programming experience, check out the other free training courses we offer in Kotlin:

We can’t wait to see what you build!

*from US tech job postings on

July 16th 2020, 9:14 am

Preparing your build for package visibility in Android 11

Android Developers Blog

Posted by David Winer, Product Manager

One of the central themes for Android 11 has been protecting user privacy. On Android 10 and earlier, you could query the full set of installed apps using methods like queryIntentActivities(). Often, however, this approach provides much more access than most apps need to implement their functionality. To better protect user privacy, we updated how apps view and interact with other installed apps on Android 11.
To provide better accountability for access to installed apps, apps targeting Android 11 (API level 30) will see a filtered list of installed apps by default. The new <queries> element in your app or library’s Android manifest allows you to describe which other apps you might need to interact with. For more information about this change, check out our Medium post on package visibility in Android 11.

Android Studio and Gradle support

If you are using Android Gradle plugin 4.1+, your tools should work with the new <queries> declaration. However, older versions of the Android Gradle plugin are not aware of this new element. If you add the <queries> element or if you start relying on a library or SDK that supports targeting Android 11, you may encounter manifest merging errors. For example, when building your app you may see the following error in the Build Output Window:

Android resource linking failed /Users/sample/AndroidStudioProjects/MyApp/app/build/intermediates/merged_manifests/debug/AndroidManifest.xml:18: error: unexpected element <queries> found in <manifest>

Alternatively, you may see an error in the Build Output Window that directs you to the Manifest merger logs:

Manifest merger failed with multiple errors, see logs

Upon expanding the Merged Manifest view you would then see an additional error:

Error: Missing 'package' key attribute on element package

Android Gradle plugin fixes

The best solution to deal with these errors is to upgrade to Android Gradle plugin 4.1 Beta.
We know that not everyone is ready to upgrade to the latest version, though, and you may be relying on old versions of Gradle or libraries that aren’t compatible with 4.1.
So, today we issued a set of dot releases for the Android Gradle plugin that are compatible with <queries>:
For example, if you are currently using Android Gradle plugin version 4.0.0, you can upgrade the version in your project-level build.gradle file:

 buildscript {

    repositories {

    dependencies {
        // classpath ''
        classpath ''

For more information on this new feature in Android 11, check out the package visibility documentation and the Android Gradle plugin release notes.

July 14th 2020, 1:34 pm

11 Weeks of Android: Android 11 Compatibility

Android Developers Blog

Posted by Dirk Dougherty, Android Developer Relations

This blog post is part of a weekly series for #11WeeksOfAndroid. Each week we’re diving into a key area of Android so you don’t miss anything. This week, we spotlighted Android 11 Compatibility; here’s a look at what you should know.

The big news

With Beta 2 now in the hands of users and developers, Android 11 is moving quickly toward the final release later in Q3. For developers, now is the time to make sure your apps are ready! With that in mind, this week we highlighted some resources that can help you get started with app compatibility testing and use some of the new tools in Android 11. Here’s a quick rundown of topics that we covered.
Platform stability
In Android 11 we added a new release milestone called Platform Stability to clearly signal to developers that all APIs and system behaviors are complete. This week, with Beta 2, Android 11 reached Platform Stability, so it’s a great time to do your final compatibility testing and updates. The Beta 2 and Platform Stability blog post goes into more detail on what this milestone means for developers, and you can also read about it in the Android 11 timeline.
App compatibility
As we talked about in our Beta 2 post this week, Android 11 compatibility means that your app is validated to run properly on Android 11 with all of the functionality and features that users expect. To get started, all you need is your app and a device or emulator running Android 11.
When making sure an app is compatible, the goal is to test your app and make the minimum changes to maintain your app’s functionality on Android 11, then publish the compatible version to users by the Android 11 final release. In most cases you should be able to do this without changing your targetSdkVersion or compiling against the new APIs.
It isn’t just for apps and games either - if you develop SDKs, libraries, tools, or even frameworks, now is the time to test those against Android 11 and release a compatible version. App and game developers using your products could be blocked until they can get your Android 11 compatible versions.
For more details on app compatibility, take a look at the migration guide and the list of behavior changes that could affect your apps.
Tools for testing your apps
We highlighted some new tools for you to use as you get started with compatibility testing. Our blog post “Testing app compatibility in Android 11” went into the details.
First is the compatibility framework, a new feature that helps with managing the platform changes that can affect apps. It provides standard metadata for changes, standard gating based on targetSdkVersion, and standard log output to help you identify a change affecting your app. You can toggle behavioral changes in a debuggable app, either through Developer options in Settings or through adb. This helps you isolate changes and test against them individually.
Isolating regressions across devices and API levels can be time-consuming and complex. Now with Android Studio 4.2, you can run instrumentation tests in parallel across multiple physical or virtual devices at once, then compare all of the results in a single Test Matrix. You can run tests on more devices in less time, and catch issues earlier.
Android Generic System Image (GSI) is a great way to expand your Android 11 testing across a broader set of devices and we’ve released an updated Android GSI codelab to help you get started. Through GSI, you can install a generic version of Android 11 on any unlocked, Treble-compliant device that shipped with Android 9 or higher. This includes not only Pixel devices, but many other popular devices in use across the global Android ecosystem.
App compatibility toggles in Developer options.
Ecosystem updates and app compatibility
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. With technology like Project Treble and Google Play system updates, we can deliver updates across more devices faster, and increase consistency across the ecosystem.
The work we’ve been doing with Project Treble is making it dramatically faster and easier to bring up new versions of Android on new and existing devices. It also makes it possible for device-makers to run their own Developer Preview programs, in some cases in parallel with Android’s own ongoing development. These programs help device makers get their OS updates ready sooner and engage earlier with the Android developer community.
With Google Play system updates (Project Mainline) the goal is to directly update core OS components across devices in the Android ecosystem to improve security, privacy, and consistency across the ecosystem. In Android 11, we’ve added more updatable modules to standardize behaviors in key app-facing areas such as permissions, media, NNAPI, and others.
Other improvements include a Generic Kernel Image (GKI) and Virtual A/B, a new over-the-air update mechanism that combines the benefits of seamless updates with smaller storage requirements. We’re working closely with device makers to bring these to Android 11 devices.
Over time, these will help reduce your development and testing costs to make your app compatible across platform versions and devices.

Taking center stage

A common reason for unexpected app compatibility issues is apps and games depending on Android non-SDK interfaces. In Android 11 we're continuing our long-term effort to move apps to using public APIs instead.
This week we highlighted Excelliance Tech, who recently moved their LeBian SDK away from non-SDK interfaces, toward stable, official APIs. Their collaboration with the Android team also led to a new public API for resource loading that all developers can use - the ResourcesLoader API in Android 11.
Check out the Excelliance Tech story in this blog post.
The Excelliance Tech team.

What to watch

During Android 11 Compatibility week we posted three short videos to help you plan for compatibility and test your apps. View the playlist here.
The video below gives you a quick overview of Android’s annual release timeline and what the phases mean for developers.
Next, here’s a video that introduces the compatibility framework, a new testing and debugging feature for developers in Android 11. It shows what it is, why it is useful, and how to use it. You’ll walk through an example that shows how you’d enable a specific change, test your app with the change, and then look for the log output to help you identify the change that affected the app.
Last, this video takes you through a new feature in Android Studio that lets you run instrumentation tests in parallel on multiple devices. It shows you how to set up a device set, run tests on the devices, and then jump into the Text Matrix to compare and analyze results. It’s a great way to do your app compatibility testing in Android Studio.

Learning path

If you’re looking for an easy way to pick up the highlights of this week, check out the Compatibility pathway. A pathway is an ordered tutorial that allows users to complete a pre-defined module that culminates in a quiz. A badge is awarded to each user who passes the quiz and can be saved to your Google Developer Profile. Test your knowledge about Android 11 Compatibility to earn a limited edition Android 11 Compatibility badge.

Key takeaways

With each release, we’re working to reduce the impact of compatibility testing on your apps. In Android 11, we’ve added new processes, developer tools, and release milestones to make it easier. We hope the resources we provided this week are helpful as you get started with your compatibility testing. Here are this week’s key takeaways for developers:
  1. Android 11 has reached Platform Stability and all app-facing APIs and behaviors are now complete.
  2. App and game developers should start compatibility testing now and release updates by the Android 11 final release later this year.
  3. SDK, library, and tool developers should complete testing and release compatible versions as soon as possible to avoid blocking downstream developers.
  4. New tools and resources are available to help. See below for highlights and visit for complete details.


You can find the entire playlist of #11WeeksOfAndroid video content here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Below are the links to resources we talked about during Android 11 Compatibility week.
Blog posts
Testing app compatibility in Android 11
Excelliance Tech: moving to new Android APIs for long-term compatibility
Android 11 Beta 2 and Platform Stability
Accelerating Android updates
Android 11 Compatibility playlist
Android 11 Compatibility week preview
Testing platform changes in Android 11
Testing app compatibility with Android Studio
Platform Stability and the Android release timeline
Installing Android 11 GSI
Learning Paths
Android 11 - Week 4 - Compatibility
Reddit AMA
Android Platform Team AMA
Related documentation
Android 11 timeline
Get Android 11
Android 11 migration guide
Android 11 behavior changes
Testing app compatibility
Non-SDK restrictions in Android 11
Feedback and issues
Android 11 Developer Site

July 10th 2020, 5:37 pm

Accelerating Android Updates

Android Developers Blog

Posted by Eddie Hsu (Technical Program Manager), Brent VerWeyst (Product Manager), Amith Dsouza (Technical Account Manager), Iliyan Malchev (Project Treble Architect)

Over the past few years we’ve introduced new capabilities that enable us to deliver updates more uniformly, quickly, and efficiently to Android devices. These capabilities include:

Android 10 Adoption

Thanks to these efforts, the adoption of Android 10 has been faster than any previous versions of Android. Android 10 was running on 100 million devices 5 months post launch – 28% faster than Android Pie.

Updatability in Android 11

Below are the major themes in updatability this year:

OEM Developer Previews: In Android 11, device makers (OEMs) are continuing their developer previews ahead of the official launch. Seven OEMs have released Developer Preview builds on 13 devices to provide app developers with diverse hardware as they test for compatibility.

Google Play system update: 21 OS components are now updatable, including 9 additions in Android 11 focused on improving privacy, security, and developer consistency across devices. Highlights include an enhanced permissions component that standardizes user and developer access to critical privacy controls on Android devices, a Neural Networks API (NNAPI) component that optimizes performance and guarantees consistent APIs across devices, and a Tethering component for improved interoperability. The new updatable OS components in Android 11 are: Tethering, NNAPI, Cell Broadcast Receiver, adbd, Internet Key Exchange, Media Provider, statsd, WiFi, and SDK extension.

Generic Kernel Image: Our ongoing updatability work extends to the Linux kernel itself, with initiatives such as 6-year LTS support. In Android 11, we are further isolating common code in the Android Linux kernel to create a Generic Kernel Image (GKI) that works across all Android devices, as well as to enable faster security deployments. Stay tuned for a more detailed post on GKI in the coming months.

Virtual A/B: Most OS updates are not delivered via Google Play. Instead, they use separate third-party Over-the-Air (OTA) services that differ among the various OEMs. These services use a mechanism that, while very space efficient, has the disadvantage of being slow to apply, rendering the device inoperable for the duration. To solve this problem, in Android Nougat we launched a mechanism called "A/B OTA" (aka Seamless Updates). A/B OTAs have the advantage of appearing to be near-instant from the user's perspective, since they apply in the background and become active on the next reboot. However, they doubled the amount of storage reserved for the OS itself, limiting adoption among OEMs.

We’ve developed a new OTA mechanism – Virtual A/B – that combines the benefits of the previous two: being seamless from the user's perspective while requiring less storage. We are working closely with our OEM partners to begin implementing Virtual A/B in Android 11 devices, making OTAs as frictionless as possible. Going forward, Virtual A/B will be the only supported OTA mechanism in Android.

Looking to the Future

We’re excited by the increased adoption of Android and are grateful for the close collaborations with our chipset and OEM partners to deploy updates earlier. We continue to work on a number of enhancements in the platform and infrastructure to make it easier for developers and users to benefit from the latest versions of Android.

July 9th 2020, 12:34 pm

Android 11 Beta 2 and Platform Stability

Android Developers Blog

Posted by Dave Burke, VP of Engineering

A few weeks ago we unwrapped the first Beta of Android 11 with a focus on people, controls, and privacy. As we highlighted in the #Android11Beta Launch, we’re making Android more people-centric and expressive, helping users control their smart devices, and giving them even more control over sensitive permissions. Developers can use APIs like Conversations, Bubbles, Device Controls, and Media Controls, to integrate these experiences into their apps.

Today we’re pushing out the second Beta of Android 11 for you to try. This release takes us to the Platform Stability milestone, which means that Android 11’s APIs and behaviors are finalized. For developers, it’s time to get started on your final compatibility updates and publish them in time for the official release later in Q3.

This week’s theme in #11 Weeks of Android is Android 11 Compatibility and we’ll be sharing helpful content and materials all week. You can find them on the #11 Weeks page or follow Android Developers on Twitter and Youtube.

You can get Beta 2 today on your Pixel 2, 3, 3a, and 4 device by enrolling here for over-the-air updates, and downloads are also available. If you previously enrolled for Beta 1, you will automatically get the over-the-air update. Let us know what you think, and thanks for the feedback you’ve provided so far!

Platform Stability

Beta 2 brings Android 11 to Platform Stability, a new release milestone that we added this year just for developers, based on your feedback.

Platform Stability means that all app-facing surfaces and behaviors are now final in Android 11. This includes not only final SDK and NDK APIs, but also final system behaviors and restrictions on non-SDK interfaces that may affect apps. So from Beta 2, you can release compatibility updates with confidence that the platform won’t change. More on the timeline is here.

With the platform now stable, we’re encouraging all app and game developers to start your final compatibility testing and publish your updates ahead of the final release.

For all SDK, library, tools, and game engine developers, it’s even more important to start testing now and release your compatible updates as soon as possible -- your downstream app and game developers may be blocked until they receive your updates. When you’ve released a compatible update, be vocal and let developers know!

Why app compatibility is important

For Android, the term app compatibility means that your app runs properly on a specific version of the platform, typically the latest version. You can check this right now by installing your production app on a device or emulator running Android 11. Just test all of the user flows and features, and if the app looks and runs properly, then you’re done, it’s compatible!

It sounds simple, but sometimes there’s more to it. With each release, we make integral changes that improve privacy and security, as well as implement changes that evolve the overall user experience across the OS. Sometimes these can affect your apps, so it’s important to take a look at the behavior changes and test against them, then publish the compatible update to users. It’s a basic but critical level of quality.

App compatibility comes into play as users update to the latest version of Android, whether they’ve purchased a new device or installed an update on their current device. They’re excited to explore the latest version of Android, and they want to experience it with their favorite apps. If the apps don’t work properly, it’s a major issue - for users and for all of us.

So while there are a ton of new APIs and capabilities to explore, and more changes to consider when you’re ready to change your app’s targeting, start by testing your current app and releasing a compatible update first.

Updates to Pixel and other devices will get started as soon as Android 11 reaches the final release to Android Open Source Project (AOSP), which we expect later in Q3. Multiple partner devices are also in active public previews now to support your compatibility testing.

Making app compatibility easier in Android 11

With each release, we’re working to reduce the work you’ll need to do to get your apps ready. In Android 11, we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates and make it easier for apps to stay compatible.

Get your apps ready for Android 11!

Now that Android 11 is stable, make your apps compatible as soon as possible. Here’s how to do it.

For testing your current app, start with the behavior changes for all apps to see where it could be affected. Here are the top changes (these apply regardless of your app’s targetSdkVersion):

Remember to test the libraries and SDKs in your app for compatibility. If you find an issue, try updating to the latest version of the SDK, or reach out to the developer for help.

Later, after you’ve published the compatible version of your current app, you can start the process of updating your app's targetSdkVersion. Review the behavior changes for Android 11 apps and try the compatibility framework to help find impacts. Here are some of the top changes to test for (these apply only to targetSdkVersion 30+):

During testing, watch for uses of restricted non-SDK interfaces in your app and move those to public SDK equivalents instead. You can read about the restricted APIs here.

Explore the new features and APIs

As soon as you’re ready, dive into Android 11 and learn about the new experiences you can build. Our #Android11 Beta post has a recap of new features for developers, and you can also visit the Beta Launch page to see talks from the Android team on what’s new in their areas.

Android Studio also has new features for Android 11 also, to improve your productivity and workflow, such as ADB incremental for faster installs of large APKs, and additional nullability annotations on platform APIs. You can give these a try by downloading the latest Android Studio Beta or Canary version. Instructions for configuring Android Studio for Android 11 are here.

For complete details on Android 11 features and APIs, visit the Android 11 developer site.

How do I get Beta 2?

It’s easy! You can enroll here to get Android 11 Beta updates over-the-air for Pixel 2, 3, 3a, and 4 devices. Alternatively, give Android Flash Tool a try for easy on-demand updates, and downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator in Android Studio or try a GSI image to run Android 11 on supported Treble-compliant devices.

As always, your feedback is critical, so please let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far -- thank you!

Android 11 compatibility week

This week in #11 Weeks of Android, we’re highlighting Android 11 Compatibility, a theme that’s important for all developers now that the platform has reached stability.

We’re sharing resources to help you with compatibility testing here, and you can follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week!

Also, the Android engineering team will host a Reddit AMA on r/androiddev tomorrow, July 9 at 12:00PM PST, to answer your technical questions about Android 11. See this post for details and to submit your questions.

July 8th 2020, 1:11 pm

Excelliance Tech: moving to new Android dynamic resource loading APIs for long-term compatibility

Android Developers Blog

This blogpost is a collaboration between Google and Excelliance Tech. Authored by Zhuo Chen with support from Zhihai Wang, Gao Huang from Excelliance Tech.

Excelliance Tech improved the stability and compatibility of their LeBian SDK by moving away from non-SDK APIs, toward stable, official APIs. Their collaboration with the Android team during the process also led to a new public API for resource loading that all developers can use - the ResourcesLoader API in Android 11.

Helping game developers keep users engaged

Games are becoming increasingly complex, and a loading progress bar is not only a countdown to a new adventure, but also a bridge which connects players and developers.

Players want the game to load right away, so "loading" has its own priorities: resources that will be used in the first few minutes need to be packed into the APK, while the rest of the content can be downloaded in the background after the game starts.

Developers are always creating new content for their games, so "change" is the only constant: different campaigns bring different launch screens and themes, keeping the game experience fresh for players.

Excelliance Tech’s LeBian (乐变) game assets streaming service helps game developers meet players’ needs by loading fresh resources dynamically while the game is loading or being played.

Meteor, Butterfly And a Sword (流星群侠传) by NetEase Games, Duoduo Auto Chess (多多自走棋) by Dragonest Game, Langrisser (梦幻模拟战) by ZlongGames, Junior Three Kingdom 2 (少年三国志 2) by Yoozoo Games - these games are created by different developers and have different look and feel, but one thing they have in common: they all use LeBian game streaming service to load resources.

The resource loading technology is so useful that Excelliance Tech is even using it in the LeBian SDK itself, bringing a better experience for developers. Dynamic resource loading makes the SDK much easier to use. By dynamically updating its internal resources when needed, the library doesn’t require developers to update the SDK for new resources.

Before Android 11 introduced the ResourcesLoader API, Excelliance Tech had to build their dynamic resource loading capability the hard way, using non-SDK interfaces.

Building the initial product

When Excelliance was first building their product, Android did not offer public APIs for the dynamic resource loading use-case. The team did what they could, but ended up using non-SDK interfaces to add the external resources. While this met the technical need initially, the implementation was fragile - it depended on non-SDK interfaces, which don’t have the same compatibility guarantees as official SDK APIs and can change without notice.

As a result, Excelliance found that compatibility issues would surface unexpectedly as new versions of Android were released. These required additional testing and development to assure the stability of the product. Over many iterations, it took the Excelliance team six engineer-months and a lot of code to stabilize their solution, while knowing that it might break again in the next Android release. With Android tightening restrictions on non-SDK interfaces to achieve better stability and app compatibility, relying on those non-SDK interfaces became no longer an option.

Working toward a sustainable solution

As the Android team increased its focus on moving apps to public APIs, Excelliance saw an opportunity to migrate to a stronger foundation. They reached out to the Android team to give their feedback and highlighted their use case and need for public SDK APIs.

Over time, their collaboration led to the development of the ResourcesLoader public API that’s available for the first time in Android 11. Excelliance Tech has already moved to the new ResourcesLoader API and they’ve seen better productivity and product quality as a result. Excelliance believes the ResourcesLoader API provides advantages including the following:

String sdkroot = getApplicationInfo().dataDir + "/lebian";
ResourcesLoader rl = new ResourcesLoader();
rl.addProvider(ResourcesProvider.loadFromDirectory(sdkroot, null));
Resources res = getResources();
final AssetManager assetManager = res.getAssets();

After moving to the new ResourcesLoader API, the essential code has just a few lines (down from hundreds of lines of code across a number of source files).

Improving performance

Excelliance Tech did a comparison test, loading 16,028 files (uncompressed 1.47GB, compressed 1.36GB) in 4 ways:

  1. Load resources directly from APK
  2. Load resources using non-SDK interfaces
  3. Load APK using ResourcesLoader
  4. Load resources directly from a directory using ResourcesLoader

Resources are compressed in option 1, 2 and 3, and the average loading times are around 19 seconds. Option 4 loads uncompressed resources directly from a directory using ResourcesLoader, the average loading time is about 3 seconds - a 6x performance improvement!

Summarizing the overall impact of ResourcesLoader, Huang Gao, CEO & Product Lead at Excelliance Tech, said “The new ResourcesLoader API dramatically reduces development and maintenance costs and allows us to focus more on product and business innovation."

Co-creating the future

The Excelliance Tech team.

"On the Android platform, we've created some valuable products and services, which makes us want to invest more to create innovative products", Excelliance Tech stated, "We hope to have more opportunities to participate in the building of the Android ecosystem and contribute our efforts to make a better Android both for consumers and developers."

Excelliance Tech made an investment for the long-term compatibility of the LeBian SDK. Moving to the ResourcesLoader API has already yielded stability and performance benefits, reduced the complexity of their code, and reduced risks of future compatibility issues as Android rolls out new versions of the platform. The ResourcesLoader API is part of Android 11’s public APIs, benefitting the entire Android developer community.

July 7th 2020, 1:01 pm

11 Weeks of Android: Testing app compatibility in Android 11

Android Developers Blog

Posted by Diana Wong, Product Manager, Android

This blog post is part of a weekly series for #11WeeksOfAndroid. For each #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we’re spotlighting Android 11 compatibility; here’s a look at what you should know.

Android 11 compatibility week

This week in 11 Weeks of Android, we’re highlighting Android 11 Compatibility, a theme that’s important for all developers. For Android, the term app compatibility means that your app runs properly on a specific version of Android, typically the latest version.

We’re sharing resources to help you with compatibility testing here, and you can follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week!

Making app compatibility easier in Android 11

With each release, we’re working to reduce the work you’ll need to do to get your apps ready. In Android 11, we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates and make it easier for apps to stay compatible.

You’ll hear more about these topics throughout the week. To get things started, read on to learn more about how we're making it easier to test and debug your app in Android 11.

Testing on Android 11

Testing your app for a new Android release can be a challenging task, especially when your app might be affected by multiple platform changes. Many questions can come up:

We've gotten a lot of great feedback from our developer community about these and other questions. In Android 11, we've added new tools to the platform and new features to Android Studio that can make the testing process a little easier for you.

New tools for testing platform changes

Like previous releases, Android 11 includes some changes in the Android platform that may impact your apps. Although these changes are critical to improve the platform, we try to minimize the immediate change to your apps by putting as many changes as possible behind the platform's latest targetSDKVersion. In Android 11, we've also added many of these platform changes to a new compatibility framework.

What is the compatibility framework?

When a change is part of the compatibility framework, you can access new developer tools that help you test and debug your app against that change.

For instance, changes that are part of the compatibility framework are toggleable, so you can force-enable or disable the changes individually, either from a device's developer options or using ADB (Android Debug Bridge). The Android platform automatically adapts its internal API logic, so you don't need to change your targetSDKVersion or recompile your app to perform basic testing. In addition, you can isolate individual changes from each other to lower the amount of time it takes to discover and debug issues in your app.

Choosing a change to test against

Before you start toggling changes on or off, you should read through the lists of behavior changes to determine which changes might affect your app. Changes that are part of the compatibility framework have a corresponding Change ID and Change Name listed before the description of the change.

Generally, we recommend that you start testing with behavior changes that affect all apps because those changes can potentially affect your app regardless of targetSDKVersion. However, let's take a look at a change that is gated by targetSDKVersion so that you can see how to test against these changes without recompiling your app with a different target SDK.

Take a look at the change to background location access. This change affects apps that request all-the-time access to background location. If your app is affected by this change, it might be a great candidate to start testing with. The change's name is BACKGROUND_RATIONALE_CHANGE_ID and the change's ID is 147316723. You'll use this information to enable this change before you test your app against it.

Isolate the change

After deciding which change you want to test against, you can toggle that change on or off using the developer options. To get to the developer options, open your device's Settings app and navigate to System > Advanced > Developer options > App Compatibility Changes.

Toggleable platform changes in the developer options with the background location access change enabled

In this case, the BACKGROUND_RATIONALE_CHANGE_ID is the only change that is enabled to minimize scope of possible causes for any issues that your app might encounter.

You can also use logcat or ADB to identify which changes are enabled and use ADB to toggle changes on or off. Note that you can only toggle changes when using a debuggable app.

Test and debug your app

After enabling a change, you can test and debug your app using your typical testing workflows. If you encounter issues, check your logs to help determine the cause of the problem. If it's not clear whether the problem is caused by the platform change that's enabled, try disabling that change and then retest that area of your app.

Learn more

Check out this week's video on testing platform changes in Android 11 to see another example and read the documentation on

New tools in Android Studio for testing app compatibility

In addition to manual testing on the new platform, we’ve also made it easier to use Android Studio to run automated tests on the latest OS.

Starting in Android Studio 4.2, instrumentation tests can now be run across multiple physical or virtual devices in parallel. When running tests, there’s now the option to select Multiple Devices in the target device dropdown menu.

This feature is designed to help you catch issues as early as possible in your development cycle and allow you to compare differences between different builds of Android. The results of these tests can be investigated using a new Test Matrix under View > Tool Windows > Run.

The new Test Matrix lets you filter your test results by status, device, and API level.

Learn more

Check out this week's video on testing app compatibility with Android Studio and read the documentation on

Next steps

We encourage you to try out these new tools and send us feedback about how they're working for you. We hope these tools help make it easier for you to test your app for Android 11.

Also, the Android engineering team will host a Reddit AMA on r/androiddev thursday, July 9 at 12:00PM PST, to answer your technical questions about Android 11. See this post for details and to submit your questions.

July 6th 2020, 2:01 pm

Bringing modern storage to Viber’s users

Android Developers Blog

This blogpost is a collaboration between Google and Viber. Authored by Kseniia Shumelchyk from Google and Anton Novikov, Sergey Kozlov from Viber.

As a messaging app, Viber needs to store, process and share a significant amount of data. Viber aims to give its users an easy, fast, reliable and secure communication platform by providing an intuitive interface and operating with files in a privacy-preserving way. We believe the modern scoped storage paradigm provides this foundation for app developers and users.

Scoped storage was introduced in Android 10 with further improvements in Android 11 to provide better protection to app and user data on a platform level. Due to Viber's complexity, the team opted to incrementally implement the changes that were required to comply with scoped storage.

In this article, we’ll share how Viber handled the migration to scoped storage, focusing on what they did to optimize working with media files and other data in the app.

Managing storage across Android versions

Android’s storage model has evolved to adapt to changing privacy considerations, leading to the changes in the storage system APIs. Let’s take a look at key platform changes that affected the legacy Viber implementation.

Media directories

Scoped storage changes the way that apps store and access files on a device's external storage. Viber needed to evaluate the differences between the existing app's storage model and updated platform guidelines, followed by gradual application changes to work with files in scoped storage. Therefore Viber invoked the requestLegacyExternalStorage flag to temporarily opt-out of scoped storage on Android 10 until the app was fully compatible.

In order to adjust their app experience to scoped storage, Viber now contributes public media files to well-defined media collections using the MediaStore API. This way, the files are accessible in a device gallery, and can be read by other apps with the storage permission. Private media files are stored in the app-specific directory on external storage and are accessed via the internal ContentProvider.

Storage permissions

The other notable update is related to changes in the storage permissions model: Apps in scoped storage have unrestricted access to their app-specific directories on external storage and can contribute to well-defined media collections without requesting a runtime permission. This change will help Viber provide more granular control to their users:

“This addition supports our efforts to provide our users with the best security and privacy solutions we can provide supported by the Android OS, users will benefit from this added security later without needing to opt-in. We also added a new ‘Save to gallery’ option allowing users to choose to make their photos readable by other apps or not. Because chats may contain private images or videos, it’s important to give users the ability to hide these files from the gallery. This change gives users additional control over the content included in their Viber messages.“ said Anton Novikov and Sergey Kozlov from Viber.

Accessing files outside of app-specific directory

Previously, Viber created and consumed files in a custom top level directory and depended on file path access. With scoped storage, saving app files to a top level directory became an anti-pattern, so Viber has followed best practices to update their implementation to store media files from the chats only in locations that are accessible in scoped storage.

However, to reduce the complexity of migration, Viber decided to keep their own top level directory for Android 10 and below, storing only the media files that are not exposed to the device’s Gallery app, while for Android 11 and above this directory is used in read-only mode to provide backward compatibility.

Another use case that Viber has been refining is sharing files in the chats. The updated storage runtime permission gives read access only to the images, videos and audio files that are available through MediaProvider. Starting from Android 11, the only way for Viber to access non-media files created by other apps is by using the Storage Access Framework document picker, which they had already utilized in a different part of their app.

App-specific files within external storage

In the scoped storage environment, app-specific directories on external storage are becoming private from other apps. This change has helped Viber leverage its use of external storage for storing private user files:

”We find change to app-specific directories to be useful, because it will help to ensure that personal chats are protected and backed with platform security.” said Anton Novikov from Viber. Learn more about how to access app-specific files.

Single interface to access storage

Because Viber targets a large audience running on Android 4.2 and above, they introduced an abstraction layer that aids them in managing storage access efficiently across all supported Android versions and with their use cases in mind.

Previously, Viber heavily used File API to access files, including files in legacy storage locations. Further, they stored absolute file paths for entries in the local database to keep the user's conversation history.

To standardize access to this conversation history and thus ensure that users don’t lose access to their files, Viber replaced absolute file paths with content URIs. In the new implementation, the app is accessing files only via content providers:

By using a consistent ContentProvider layer, the ContentResolver gives the app a unified interface to access the file content.

This approach has also helped Viber optimize the network layer and define a universal Loader abstraction to upload/fetch and to read/store different types of media files like voice messages, chat images and stickers.


Android 11 further enhances scoped storage, which provides better protection of app and user data and makes the transition easier for developers. It’s amazing to see many apps like Viber are migrating to take advantage of scoped storage since Android 10.

We hope Viber’s story is useful and will inspire you to modernize your Android apps as well. Learn more about Android storage use cases and best practices.

July 1st 2020, 1:04 pm

System hardening in Android 11

Android Developers Blog

Posted by Android Platform Hardening Team

In Android 11 we continue to increase the security of the Android platform. We have moved to safer default settings, migrated to a hardened memory allocator, and expanded the use of compiler mitigations that defend against classes of vulnerabilities and frustrate exploitation techniques.

Initializing memory

We’ve enabled forms of automatic memory initialization in both Android 11’s userspace and the Linux kernel. Uninitialized memory bugs occur in C/C++ when memory is used without having first been initialized to a known safe value. These types of bugs can be confusing, and even the term “uninitialized” is misleading. Uninitialized may seem to imply that a variable has a random value. In reality it isn’t random. It has whatever value was previously placed there. This value may be predictable or even attacker controlled. Unfortunately this behavior can result in a serious vulnerability such as information disclosure bugs like ASLR bypasses, or control flow hijacking via a stack or heap spray. Another possible side effect of using uninitialized values is advanced compiler optimizations may transform the code unpredictably, as this is considered undefined behavior by the relevant C standards.

In practice, uses of uninitialized memory are difficult to detect. Such errors may sit in the codebase unnoticed for years if the memory happens to be initialized with some "safe" value most of the time. When uninitialized memory results in a bug, it is often challenging to identify the source of the error, particularly if it is rarely triggered.

Eliminating an entire class of such bugs is a lot more effective than hunting them down individually. Automatic stack variable initialization relies on a feature in the Clang compiler which allows choosing initializing local variables with either zeros or a pattern.

Initializing to zero provides safer defaults for strings, pointers, indexes, and sizes. The downsides of zero init are less-safe defaults for return values, and exposing fewer bugs where the underlying code relies on zero initialization. Pattern initialization tends to expose more bugs and is generally safer for return values and less safe for strings, pointers, indexes, and sizes.

Initializing Userspace:

Automatic stack variable initialization is enabled throughout the entire Android userspace. During the development of Android 11, we initially selected pattern in order to uncover bugs relying on zero init and then moved to zero-init after a few months for increased safety. Platform OS developers can build with `AUTO_PATTERN_INITIALIZE=true m` if they want help uncovering bugs relying on zero init.

Initializing the Kernel:

Automatic stack and heap initialization were recently merged in the upstream Linux kernel. We have made these features available on earlier versions of Android’s kernel including 4.14, 4.19, and 5.4. These features enforce initialization of local variables and heap allocations with known values that cannot be controlled by attackers and are useless when leaked. Both features result in a performance overhead, but also prevent undefined behavior improving both stability and security.

For kernel stack initialization we adopted the CONFIG_INIT_STACK_ALL from upstream Linux. It currently relies on Clang pattern initialization for stack variables, although this is subject to change in the future.

Heap initialization is controlled by two boot-time flags, init_on_alloc and init_on_free, with the former wiping freshly allocated heap objects with zeroes (think s/kmalloc/kzalloc in the whole kernel) and the latter doing the same before the objects are freed (this helps to reduce the lifetime of security-sensitive data). init_on_alloc is a lot more cache-friendly and has smaller performance impact (within 2%), therefore it has been chosen to protect Android kernels.

Scudo is now Android's default native allocator

In Android 11, Scudo replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap, such as:

Scudo does not fully prevent exploitation but it does add a number of sanity checks which are effective at strengthening the heap against some memory corruption bugs.

It also proactively organizes the heap in a way that makes exploitation of memory corruption more difficult, by reducing the predictability of the allocation patterns, and separating allocations by sizes.

In our internal testing, Scudo has already proven its worth by surfacing security and stability bugs that were previously undetected.

Finding Heap Memory Safety Bugs in the Wild (GWP-ASan)

Android 11 introduces GWP-ASan, an in-production heap memory safety bug detection tool that's integrated directly into the native allocator Scudo. GWP-ASan probabilistically detects and provides actionable reports for heap memory safety bugs when they occur, works on 32-bit and 64-bit processes, and is enabled by default for system processes and system apps.

GWP-ASan is also available for developer applications via a one line opt-in in an app's AndroidManifest.xml, with no complicated build support or recompilation of prebuilt libraries necessary.

Software Tag-Based KASAN

Continuing work on adopting the Arm Memory Tagging Extension (MTE) in Android, Android 11 includes support for kernel HWASAN, also known as Software Tag-Based KASAN. Userspace HWASAN is supported since Android 10.

KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs in the Linux kernel. Its Software Tag-Based mode is a software implementation of the memory tagging concept for the kernel. Software Tag-Based KASAN is available in 4.14, 4.19 and 5.4 Android kernels, and can be enabled with the CONFIG_KASAN_SW_TAGS kernel configuration option. Currently Tag-Based KASAN only supports tagging of slab memory; support for other types of memory (such as stack and globals) will be added in the future.

Compared to Generic KASAN, Tag-Based KASAN has significantly lower memory requirements (see this kernel commit for details), which makes it usable on dog food testing devices. Another use case for Software Tag-Based KASAN is checking the existing kernel code for compatibility with memory tagging. As Tag-Based KASAN is based on similar concepts as the future in-kernel MTE support, making sure that kernel code works with Tag-Based KASAN will ease in-kernel MTE integration in the future.

Expanding existing compiler mitigations

We’ve continued to expand the compiler mitigations that have been rolled out in prior releases as well. This includes adding both integer and bounds sanitizers to some core libraries that were lacking them. For example, the libminikin fonts library and the libui rendering library are now bounds sanitized. We’ve hardened the NFC stack by implementing both integer overflow sanitizer and bounds sanitizer in those components.

In addition to the hard mitigations like sanitizers, we also continue to expand our use of CFI as an exploit mitigation. CFI has been enabled in Android’s networking daemon, DNS resolver, and more of our core javascript libraries like libv8 and the PacProcessor.

The effectiveness of our software codec sandbox

Prior to the Release of Android 10 we announced a new constrained sandbox for software codecs. We’re really pleased with the results. Thus far, Android 10 is the first Android release since the infamous stagefright vulnerabilities in Android 5.0 with zero critical-severity vulnerabilities in the media frameworks.

Thank you to Jeff Vander Stoep, Alexander Potapenko, Stephen Hines, Andrey Konovalov, Mitch Phillips, Ivan Lozano, Kostya Kortchinsky, Christopher Ferris, Cindy Zhou, Evgenii Stepanov, Kevin Deus, Peter Collingbourne, Elliott Hughes, Kees Cook and Ken Chen for their contributions to this post.

June 30th 2020, 1:19 pm

11 Weeks of Android: Privacy and Security

Android Developers Blog

Posted by:
Charmaine D’Silva, Product Lead, Android Privacy and Framework
Narayan Kamath, Engineering Lead, Android Privacy and Framework
Stephan Somogyi, Product Lead, Android Security
Sudhi Herle, Engineering Lead, Android Security

This blog post is part of a weekly series for #11WeeksOfAndroid. For each #11WeeksOfAndroid, we’re diving into a key area so you don’t miss anything. This week, we spotlighted Privacy and Security; here’s a look at what you should know.

Privacy and security is core to how we design Android, and with every new release we increase our investment in this space. Android 11 continues to make important strides in these areas, and this week we’ll be sharing a series of updates and resources about Android privacy and security. But first, let’s take a quick look at some of the most important changes we’ve made in Android 11 to protect user privacy and make the platform more secure.

As shared in the “All things privacy in Android 11” video, we’re giving users even more control over sensitive permissions. Throughout the development of this release, we have engaged deeply and frequently with our developer community to design these features in a balanced way - amplifying user privacy while minimizing developer impact. Let’s go over some of these features:

One-time permission: In Android 10, we introduced a granular location permission that allows users to limit access to location only when an app is in use (aka foreground only). When presented with the new runtime permissions options, users choose foreground only location more than 50% of the time. This demonstrated to us that users really wanted finer controls for permissions. So in Android 11, we’ve introduced one time permissions that let users give an app access to the device microphone, camera, or location, just that one time. As an app developer, there are no changes that you need to make to your app for it to work with one time permissions, and the app can request permissions again the next time the app is used. Learn more about building privacy-friendly apps with these new changes in this video.

Background location: In Android 10 we added a background location usage reminder so users can see how apps are using this sensitive data on a regular basis. Users who interacted with the reminder either downgraded or denied the location permission over 75% of the time. In addition, we have done extensive research and believe that there are very few legitimate use cases for apps to require access to location in the background.

In Android 11, background location will no longer be a permission that a user can grant via a run time prompt and it will require a more deliberate action. If your app needs background location, the system will ensure that the app first asks for foreground location. The app can then broaden its access to background location through a separate permission request, which will cause the system to take the user to Settings in order to complete the permission grant.

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. Check out this helpful video to find possible background location usage in your code.

Permissions auto-reset: Most users tend to download and install over 60 apps on their device but interact with only a third of these apps on a regular basis. If users haven’t used an app that targets Android 11 for an extended period of time, the system will “auto-reset” all of the granted runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. If you have an app that has a legitimate need to retain permissions, you can prompt users to turn this feature OFF for your app in Settings.

Data access auditing APIs: Android encourages developers to limit their access to sensitive data, even if they have been granted permission to do so. In Android 11, developers will have access to new APIs that will give them more transparency into their app’s usage of private and protected data. The APIs will enable apps to track when the system records the app’s access to private user data.

Scoped Storage: In Android 10, we introduced scoped storage which provides a filtered view into external storage, giving access to app-specific files and media collections. This change protects user privacy by limiting broad access to shared storage in many ways including changing the storage permission to only give read access to photos, videos and music and improving app storage attribution. Since Android 10, we’ve incorporated developer feedback and made many improvements to help developers adopt scoped storage, including: updated permission UI to enhance user experience, direct file path access to media to improve compatibility with existing libraries, updated APIs for modifying media, Manage External Storage permission to enable select use cases that need broad files access, and protected external app directories. In Android 11, scoped storage will be mandatory for all apps that target API level 30. Learn more in this video and check out the developer documentation for further details.

Google Play system updates: Google Play system updates were introduced with Android 10 as part of Project Mainline. Their main benefit is to increase the modularity and granularity of platform subsystems within Android so we can update core OS components without needing a full OTA update from your phone manufacturer. Earlier this year, thanks to Project Mainline, we were able to quickly fix a critical vulnerability in the media decoding subsystem. Android 11 adds new modules, and maintains the security properties of existing ones. For example, Conscrypt, which provides cryptographic primitives, maintained its FIPS validation in Android 11 as well.

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. We are planning to add this to the Jetpack Biometric library to allow for backward compatibility and will share further updates on this work as it progresses.

Identity Credential API: This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. It’s being built by our security team to ensure this information is stored safely, using security hardware to secure and control access to the data, in a way that enhances user privacy as compared to traditional physical documents. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for such digital-first identity experiences.

Thank you for your flexibility and feedback as we continue to build an increasingly more private and secure platform. You can learn about more features in the Android 11 Beta developer site. You can also learn about general best practices related to privacy and security.

Please follow Android Developers on Twitter and Youtube to catch helpful content and materials in this area all this week.


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

June 29th 2020, 1:10 pm

Full spectrum of on-device machine learning tools on Android

Android Developers Blog

Posted by Hoi Lam, Android Machine Learning

This blog post is part of a weekly series for #11WeeksOfAndroid. Each week we’re diving into a key area of Android so you don’t miss anything. Throughout this week, we covered various aspects of Android on-device machine learning (ML). Whichever stage of development be it starting out or an established app; whatever role you play in design, product and engineering; whatever your skill level from beginner to experts, we have a wide range of ML tools for you.

Design - ML as a differentiator

“Focus on the user and all else will follow” is a Google mantra that becomes even more relevant in our machine learning age. Our Design Advocate, Di Dang, highlighted the importance of finding the unique intersection of user problems and ML strengths. Too often, teams are so keen on the idea of machine learning that they lose sight of their user needs.

Di outlined how the People + AI Guidebook can help you make ML product decisions and used the example of the Read Along app to illustrate topics like precision and recall, which are unique to ML design and development. Check out her interview with the Read Along team together with your team for more inspiration.

New ML Kit fully focused on on-device

When you decide that on-device machine learning is the solution, the easiest way to implement it will be through turnkey SDKs like ML Kit. Sophisticated Google-trained models and processing pipelines are offered through an easy to use interface in Kotlin / Java. ML Kit is designed and built for on-device ML: it works offline, offers enhanced privacy, unlocks high performance for real-time use cases and it is free. 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.

The team has also added new functionalities such as Jetpack lifecycle support and the option to use the face contour models via Google Play Services saving as much as 20MB in app size. 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. This provides one of the easiest ways to add TensorFlow Lite models to your applications without interacting with ByteArray!

Customise with TensorFlow Lite and Android tools

If the base model provided by ML Kit doesn’t quite fit the bill, what should developers do? The first port of call should be TensorFlow Hub where ready-to-use TensorFlow Lite models from both Google and the wider community can be downloaded. From 100,000 US Supermarket products to tomato plant diseases classifiers, the choice is yours.

In addition to Firebase AutoML Vision Edge, you can also build your own model using TensorFlow Model Maker (image classification / text classification) with just a few lines of Python. Once you have a TensorFlow Lite model from either TensorFlow Hub, or the Model Maker, you can easily integrate it with your Android app using ML Kit Image Labelling or Object Detection and Tracking. If you prefer an open source solution, Android Studio 4.1 beta introduces ML model binding that helps wrap around the TensorFlow Lite model with an easy to use Kotlin / Java wrapper. Adding a custom model to your Android app has never been easier. Check out this blog for more details.

Time for on-device ML is now

From the examples of the Android Developer Challenge winners, it is obvious that on-device machine learning has come of age and ML functionalities once reserved for the cloud or supercomputers are now available on your Android phone. Take a step forward with us by trying out our codelabs of the day:

Also checkout the ML Week learning pathway and take the quiz to get your very own ML badge.

Android on-device machine learning is a rapidly evolving platform, if you have any enhancement requests or feedback on how it could be improved, please let us know together with your use-case (TensorFlow Lite / ML Kit). Time for on-device ML is now.


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

June 26th 2020, 2:09 pm

Read Along: Grow child literacy with on-device ML design insights

Android Developers Blog

Posted by Di Dang, Design Advocate

From our Machine Learning-themed week together, we’ve delved into an ML Kit x CameraX Codelab, and we learned how to train your own custom models and integrate them in your Android app. In addition to the technical considerations that go into using ML, it’s important that we design our ML-based apps in a way that enables our users to feel in control of the ML technology, and not the other way around. To help product creators understand some best practices for ML product decisions, the PAIR team published the People + AI Guidebook at Google I/O last year. Let’s take a look at some ML design considerations you can apply in your Android apps by learning from the example of Read Along.

Google recently launched Read Along, an Android app that uses on-device ML and voice UI to help children learn to read anytime, anywhere, using just their voice. According to the UN Division of Sustainable Development Goals, more than 50% of children worldwide are not achieving minimum proficiency in reading. First launched in India as “Bolo”, the “Read Along” app is now available globally. We recently went behind the scenes with the Read Along team in this episode of Centered, to learn how they made an ML- and voice-based app to improve child literacy.

Why Machine Learning and Voice UI?

Since using ML can be time- and cost-intensive, we need to find the intersection of ML strengths and user needs. To learn to read, children need time on task and one-on-one attention, which is challenging for areas where there is a lack of access to teachers or educational materials. “In many parts of the world, there are only so many schools that can be built, only so many teachers can be trained. So first and foremost, it's a scale problem,” said Nitin Kashyap, Read Along’s product manager. This creates a unique opportunity for the use of ML—to provide real-time reading feedback at scale, Read Along utilizes the Google Assistant’s text-to-speech and speech recognition capabilities. The Read Along team also added abilities on edge to preserve children’s privacy. The voice data is analyzed on-device without being sent to any Google servers, enabling children to use Read Along offline as well.

False positives vs. false negatives

Since ML-based systems are inherently probabilistic, they can generate “wrong” predictions in the form of false positives and false negatives. As we create ML-based applications, we need to decide which behavior to optimize for. Within the Read Along experience, a false positive denotes that the child has misread a word, though the system fails to recognize this and does not provide corrective feedback. On the other hand, an example of a false negative is when a child reads a word correctly, but Read Along predicts the word was read incorrectly, and thus prompts the child to try again. “We spent a little time to understand what really happens when the child gets false positive and false negative, and what impact does it have on the psychology, and also on the reading experience,“ said Eshita Priyadarshini, Read Along’s UX Research Lead. “When the child is reading, we don't really tell him, "Oh, you got that word wrong. Why don't you read it again?" By unpacking the impact of false positives and false negatives on the user, the Read Along team decided to optimize for recall, thereby increasing the number of false positives, which results in a user experience that feels more encouraging for children.

To learn more about how the Read Along team made ML product decisions, check out the full Centered episode. For more guidance on how your cross-functional team (spanning UX, PM, and engineering) can come together to design ML-based applications, check out the People + AI Guidebook.

June 25th 2020, 1:13 pm

Android 11 Developer Preview on Android TV

Android Developers Blog

Posted by Xiaodao Wu, Developer Advocate

With the rise in quality content that’s keeping us glued to the big screen, it’s no surprise watch time on the TV continues to grow. As users spend more time in their living rooms, they are also looking to get more from their smart TVs and streaming devices. To help developers meet these needs, we are always working to support the latest Android features on Android TV.

Today, we are releasing an Android 11 Developer Preview for Android TV with many privacy, performance, accessibility and connectivity features. More information can be found on the Android 11 Developer Preview web page.

The Android 11 Developer Preview on TV is for developers (not for consumer use), this image is for ADT-3 developer devices only, it is available by manual download and flash. All user data on the ADT-3 device will be wiped out after flash. Once the device has been flashed to Android 11, you will not be able to go back to the previous Android 10 build.

  1. Download the system image (link) and unzip the file.
  2. Plug in the ADT-3 developer kit for Android TV and enable Developer options.
  3. Run in the unzipped folder to perform manual system image installation to the ADT-3 device.

The flash-all script uses fastboot and adb tools to upgrade the system. The latest version of fastboot is recommended; developers can find it in the Android SDK Platform-Tools package.

We encourage you to test your Android TV app on the Android 11 Developer Preview. If you have any feedback, please reach out to us. We’d love to hear from you.

Tune in to the Android Beyond Phones week of the #11WeeksOfAndroid on August 10th for even more developer resources from Android TV.

June 25th 2020, 11:13 am

New tools for finding, training, and using custom machine learning models on Android

Android Developers Blog

Posted by Hoi Lam, Android Machine Learning

Yesterday, we talked about turnkey machine learning (ML) solutions with ML Kit. But what if that doesn’t completely address your needs and you need to tweak it a little? Today, we will discuss how to find alternative models, and how to train and use custom ML models in your Android app.

Find alternative ML models

Crop disease models from the wider research community available on

If the turnkey ML solutions don't suit your needs, TensorFlow Hub should be your first port of call. It is a repository of ML models from Google and the wider research community. The models on the site are ready for use in the cloud, in a web-browser or in an app on-device. For Android developers, the most exciting models are the TensorFlow Lite (TFLite) models that are optimized for mobile.

In addition to key vision models such as MobileNet and EfficientNet, the repository also boast models powered by the latest research such as:

Many of these solutions were previously only available in the cloud, as the models are too large and too power intensive to run on-device. Today, you can run them on Android on-device, offline and live.

Train your own custom model

Besides the large repository of base models, developers can also train their own models. Developer-friendly tools are available for many common use cases. In addition to Firebase’s AutoML Vision Edge, the TensorFlow team launched TensorFlow Lite Model Maker earlier this year to give developers more choices over the base model that support more use cases. TensorFlow Lite Model Maker currently supports two common ML tasks:

The TensorFlow Lite Model Maker can run on your own developer machine or in Google Colab online machine learning notebooks. Going forward, the team plans to improve the existing offerings and to add new use cases.

Using custom model in your Android app

New TFLite Model import screen in Android Studio 4.1 beta

Once you have selected a model or trained your model there are new easy-to-use tools to help you integrate them into your Android app without having to convert everything into ByteArrays. The first new tool is ML Model binding with Android Studio 4.1. This lets developers import any TFLite model, read the input / output signature of the model, and use it with just a few lines of code that calls the open source TensorFlow Lite Android Support Library.

Another way to implement a TensorFlow Lite model is via ML Kit. Starting in June, ML Kit no longer requires a Firebase project for on-device functionality. In addition, the image classification and object detection and tracking (ODT) APIs support custom models. The latter ODT offering is especially useful in use-cases where you need to separate out objects from a busy scene.

So how should you choose between these three solutions? If you are trying to detect a product on a busy supermarket shelf, ML Kit object detection and tracking can help your user select a specific product for processing. The API then performs image classification on just the part of the image that contains the product, which results in better detection performance. On the other hand, if the scene or the object you are trying to detect takes up most of the input image, for example, a landmark such as Big Ben, using ML Model binding or the ML Kit image classification API might be more appropriate.

TensorFlow Hub bird detection model with ML Kit Object Detection & Tracking AP

Two examples of how these tools can fit together

Here are some resources to help you get started:

Customizing your model is easier than ever

Finding, building and using custom models on Android has never been easier. As both Android and TensorFlow teams increase the coverage of machine learning use cases, please let us know how we can improve these tools for your use cases by filing an enhancement request with TensorFlow Lite or ML Kit.

Tomorrow, we will take a step back and focus on how to appropriately use and design for a machine learning first Android app. The content will be appropriate for the entire development team, so bring your product manager and designers along. See you next time.

June 24th 2020, 1:02 pm

On-device machine learning solutions with ML Kit, now even easier to use

Android Developers Blog

Posted by Christiaan Prins, Product Manager, ML Kit and Shiyu Hu, Tech Lead Manager, ML Kit

Two years ago at I/O 2018 we introduced ML Kit, making it easier for mobile developers to integrate machine learning into your apps. Today, more than 25,000 applications on Android and iOS make use of ML Kit’s features. Now, we are introducing some changes that will make it even easier to use ML Kit. In addition, we have a new feature and a set of improvements we’d like to discuss.

A new ML Kit SDK, fully focused on on-device ML

ML Kit's APIs are built to help you tackle common challenges in the Vision and Natural Language domains. We make it easy to recognize text, scan barcodes, track and classify objects in real-time, do translation of text, and more.

The original version of ML Kit was tightly integrated with Firebase, and we heard from many of you that you wanted more flexibility when implementing it in your apps. As a result, we are now making all the on-device APIs available in a new standalone ML Kit SDK that no longer requires a Firebase project. You can still use both ML Kit and Firebase to get the best of both products if you choose to.

With this change, ML Kit is now fully focused on on-device machine learning, giving you access to the unique benefits that on-device versus cloud ML offers:

Naturally, you still get access to Google’s on-device models and processing pipelines, all accessible through easy-to-use APIs, and offered at no cost.

All ML Kit resources can now be found on our new website where we made it a lot easier to access sample apps, API reference docs and our community channels that are there to help you if you have questions.

What does this mean if I already use ML Kit today?

If you are using ML Kit for Firebase’s on-device APIs in your app today, we recommend you to migrate to the new standalone ML Kit SDK to benefit from new features and updates. For more information and step-by-step instructions to update your app, please follow our Migration guide. The cloud-based APIs, model deployment and AutoML Vision Edge remain available through Firebase Machine Learning.

Shrink your app footprint with Google Play Services

Apart from making ML Kit easier to use, developers also asked if we can ship ML Kit through Google Play Services resulting in a smaller app footprint and the model can be reused between apps. Apart from Barcode scanning and Text recognition, we have now added Face detection / contour (model size: 20MB) to the list of APIs that support this functionality.

// Face detection / Face contour model
// Delivered via Google Play Services outside your app's APK…
implementation ''

// …or bundled with your app's APK
implementation ''

Jetpack Lifecycle / CameraX support

Android Jetpack Lifecycle support has been added to all APIs. Developers can use addObserver to automatically manage teardown of ML Kit APIs as the app goes through screen rotation or closure by the user / system. This makes CameraX integration easier. With this release, we are also recommending that developers adopt CameraX in their apps due to the ease of integration and image quality improvements (compared to Camera1) on a wide range of devices.

// ML Kit now supports Lifecycle
val recognizer = TextRecognizer.newInstance()

// ...

// Just like CameraX
val camera = cameraProvider.bindToLifecycle( /* lifecycleOwner= */this,
    cameraSelector, previewUseCase, analysisUseCase)

For an overview of all recent changes, check out the release notes for the new SDK.

Codelab of the day - ML Kit x CameraX

To help you get started with the new ML Kit and its support for CameraX, we have created this code lab to Recognize, Identify Language and Translate text. If you have any questions regarding this code lab, please raise them at StackOverflow and tag it with [google-mlkit]. Our team will monitor this.

Early access program

Through our early access program, developers have an opportunity to partner with the ML Kit team and get access to upcoming features. Two new APIs are now available as part of this program:

If you are interested, head over to our early access page for details.

Tomorrow - Support for custom models

ML Kit's turn-key solutions are built to help you take common challenges. However, if you needed to have a more tailored solution, one that required custom models, you typically needed to build an implementation from scratch. To help, we are now providing the option to swap out the default Google models with a custom TensorFlow Lite model. We’re starting with the Image Labeling and Object Detection and Tracking APIs, that now support custom image classification models.

Tomorrow, we will dive a bit deeper into how to find or train a TensorFlow Lite model and use it either with ML Kit, or with Android Studio’s new ML binding functionality.

June 23rd 2020, 1:15 pm

New features to acquire and retain subscribers

Android Developers Blog

Posted by Angela Ying, Product Manager, Google Play

Subscription continues to be one of the fastest growing business models for apps in Google Play. As your subscription business evolves and becomes more sophisticated, our platform continues to evolve to better support your needs. Today we’re excited to tell you more about the new subscription capabilities we announced at the Android 11 Beta Launch, including promotional codes to help you access new subscribers, new opportunities to remind users of your value and win back churned users. Many of these capabilities are built on top of the Play Billing Library version 3.

In addition to the new capabilities, we are also making improvements to our existing platform. Over the past few years, we have launched many features, such as account hold, restore, and pause, which have been highly effective in reducing your voluntary and involuntary churn. We want to ensure that everyone can take advantage of them, which is why we are planning on changing the default settings for these features from optional to either mandatory or on by default starting on November 1, 2020. Additional details on these features and implementation requirements can be found at the end of this post.

Here’s everything that is changing about the subscriptions platform:

More targeted promotions

Promotions and deals are an important way to grow your business to acquire new customers. That’s why over the last year, we have invested in new promotional code capabilities for subscriptions that you can use to send promotions to a more targeted set of users.

Last year at I/O 2019, we launched subscription one-time promotion codes, unique alphanumeric codes that can be distributed to individual users for redemption. Now, we have launched a new frictionless redemption flow which allows users to easily redeem the code, purchase the subscription, and install the app in the Play store in a few simple steps. This greatly simplifies the user experience by reducing the friction users go through to use your code. Since this subscription is started outside of your app, it is only available to developers who are using Billing Library 2.0 or higher.

In addition to one-time codes, we are excited to officially announce the launch of custom codes (also known as vanity codes), which can be redeemed by multiple users and can be used for marketing campaigns to drive acquisitions. For example, you can post custom codes in advertisements or in social promotions to creatively engage with potential new users. Users can redeem a custom code in your app by entering it in their payment methods when purchasing a subscription.

Remind users of the value of your subscription

Retaining your subscribers is crucial for the long-term health of your subscriptions business. The reason why users stay subscribed is because they perceive ongoing value from your subscription service. To help you communicate this value, we recently launched a module that will remind users of the benefits gained from a subscription when they go to cancel. To take advantage of this module, add a short list of up to 4 subscriber benefits in the Google Play Console.

Win back churned subscribers

If users do churn from their subscription, we want to make it easy for them to restart it whenever they want. To help you do this, we have launched the ability for users to resubscribe to recently expired subscriptions directly from the Google Play subscriptions center. You can enable your SKUs for resubscribe in the Google Play Console. Since this subscription is started outside of your app, it is only available to developers who are using Billing Library version 2 or higher.

Price decreases without opt-ins

Finally, we’ve heard your feedback that requiring users to opt in to subscription price decreases was too restrictive. We are happy to announce that subscription price decreases will no longer require users to take action to opt in to keep their subscription. Users will be notified of an upcoming price decrease and be able to see the upcoming change in the Google Play subscriptions center.

Updated platform retention settings

Over the past few years, our platform has made strides in helping you keep your subscribers, through features aimed at decreasing both voluntary churn and involuntary churn (churn due to payment failure). For example, account hold has helped developers achieve 8% lower involuntary churn and 35% higher payment decline recovery rate compared to developers without account hold. Although these features are effective, retention may not be something that you are thinking about when starting out for the first time.

That’s why we are announcing updated defaults for several subscriptions features that have been up until now optional, which will take effect on November 1, 2020.

You may have to make modifications to your app or your server to handle these new features. Specifically, your app should:

Although not every feature will require you to make engineering changes, we highly recommend that you test each feature before November 1. To make the transition easier, Google has enabled Account Hold, Pause, Restore, and Resubscribe for all license test accounts. Learn more about testing for subscriptions.

How useful did you find this blog post?

June 23rd 2020, 11:45 am

Announcing the winners of the #AndroidDevChallenge, powered by on-device machine learning

Android Developers Blog

Posted by Jacob Lehrbaum, Director of Developer Relations, Android

Developers like you have always played an important role in Android innovation. Over 10 years ago, when we first launched the Android SDK, we also announced the Android Developer Challenge to reward model apps and highlight new ways of solving user problems. As Android pushes the boundaries of machine learning, 5G, foldables, and more, developers continue to help shape these new frontiers. To celebrate this work, we revived the challenge in 2019, with a focus on “Helpful Innovation,” powered by on-device machine learning.

We received hundreds of creative projects, and at the end of last year, picked 10 winners who each combined a strong idea and a thirst to bring it to life. Since then, we’ve been working with those winners to help turn their ideas into reality. And today, we’re announcing the 10 winners. Some are still at the beginning of their journey but but their apps are now ready for you to download and try out! !

Making on-device machine learning more accessible, with ML Kit and TensorFlow Lite

Increasingly, machine learning is becoming a more accessible tool to developers with limited to no background in the technology. In fact, for most of the winners of the Android Developer Challenge, this was their first foray into machine learning. That’s thanks in part to two key offerings from Google, which bring on-device machine learning into reach for millions of developers around the world.

The first is ML Kit. ML Kit brings Google’s on-device machine learning technologies to mobile app developers, so they can build customized and interactive experiences into their apps. This includes tools such as language translation, text recognition, object detection and more. Eskke, for instance, uses offline text recognition and barcode scanning from ML Kit so users can scan the QR code at a mobile money kiosk and quickly withdraw money. And MixPose uses ML Kit's forthcoming Pose detection API to detect each user’s yoga positions and movements, so teachers can provide feedback.

The other Google resource that many of the Android Dev Challenge winners used was TensorFlow Lite. This powerful machine learning framework can help run machine learning models on Android, iOS and IoT devices that would never normally be able to support them. Its set of tools can be used for all kinds of powerful neural network-related applications, from image detection to speech recognition, bringing the latest cutting-edge technology to the devices we carry around with us wherever we go. Trashly, for instance, uses a custom TensorFlow Lite model to report if an object is recyclable and how to recycle it.

Helpful innovation, such as the 10 winning apps in the Android Developer Challenge, has the potential to change the way we access, use, and interpret information, making it available when we need it, where we need it most. By working with these developers focused on helpful innovation, we hope to inspire the next wave of developers to unlock what’s possible with this new technology.

What’s next in Android Machine Learning week?

As we kick off the second week of #11WeeksOfAndroid, focused on Machine Learning, we will highlight new tools and resources available to Android developers. Here’s a taste of the rest of this week:

On Tuesday and Wednesday, we will also have a “codelab of the day” so get your Android Studio 4.1 beta today, block off an hour in your schedule and take this ML journey with us!

*The apps presented here are the projects of the developers individually, and not Google.

June 22nd 2020, 11:33 am

11 Weeks of Android: People & Identity

Android Developers Blog

Posted by Dr. Stefan Frank, Senior Product Manager, Android System UI

This blog post is part of a weekly series for #11WeeksOfAndroid. Each week we’re diving into a key area of Android so you don’t miss anything. This week, we spotlight people & identity. Here's a look at what you should know.

The big news

One of the goals of Android 11 was making our phones more people-centric. Because nothing matters more to people than connecting to loved ones. It is a core human need especially during our current physical distancing constraints. We have the need to be more social than ever before. Android 11 reimagines how we have conversations on our phones by adding new capabilities to help you maintain your identity across multiple devices.

We are announcing some new features in Android 11 that allows you to easily connect with your loved ones, friends and business colleagues. At the center of this release is the Android Conversation Shortcut API and Identity Services Library. These new tools empower instant connections to your best friend, sharing funny pictures of your dogs, telling your aunt about a tasty seafood recipe that you discovered, or congratulating an office colleague about her promotion. And they also provide a new level of password management that makes it easier for your users to sign up and sign in.

One of our favorite features brings conversations from people that matter most to you right to the lock screen of your phone. You’ll easily recognize them by their avatar and instantly respond to your family, friends, or colleagues. These are people you truly want to connect to. We knew this feature would be useful, but the responses from our beta-testers made us smile. The decision to include the Conversation Shortcut API to improve the lives of our users was one of the easiest decisions for us to make in the release of Android 11.

Creating a bubble from an incoming notification and accessing the conversation from the bubble.

One of the new features building on top of shortcuts is the new conversation space at the top of your notifications. It focuses your attention on what matters most - your conversations. Right from these notifications the user can trigger another new feature in Android 11 - Bubbles. Bubbles are small representations of conversations floating over other content on the side of the screen, which can be expanded to allow quick access to conversations, without changing what you were doing on the device. They are super handy for carrying on conversations while using the device for other tasks.

The new conversations space showing how a conversation is marked as priority and will be displayed on the lock screen.

A long tap on conversation notifications enables the user to mark priority conversations in order to give special prominence to the most important people. Priority conversations will be displayed with their individual avatar right on the lock screen and move to the top of your notifications. They can even be set to break through do-not-disturb. Another use of the conversation shortcuts is that they are used as share targets in the system share sheet, which was already launched in Android 10.

Another focus of this week was identity. 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. One Tap is our new cross-platform sign-in mechanism for Web and Android, supporting and streamlining multiple types of credentials. Block Store is our new token-based sign-in mechanism that’s built on top of Backup and Restore. It allows you to keep your user signed in across Android devices.

We’re super excited about all these features [since] they help all of us connect, communicate and express ourselves to the people that we care about and to the apps we are dealing with -- which is as important now as it’s ever been.”

What to watch

For a high level overview of the people centric functionality, we recommend that you check out the Android 11 launch highlight video on People. Earlier this week, we also launched a new talk on ‘Conversation Notifications’, where Artur describes how to implement the conversation shortcut and bubbles. There is also a great overview talk on the conversation additions and other System UI news from Dan. Finally, you can also listen to Chet’s podcasts where he interviews us on People and Bubbles.

If you’re interested in learning more about Identity, we also published “In Identity on Android: What’s new in sign-in”, this week. In this video, Vishal explains the new libraries in the Google Identity System: One Tap and Block Store."

Two of the teams that worked very early with us on these conversation specific topics are the Messenger team from Facebook and the direct messaging team from Twitter. Read the stories around both of these implementations here and here.

Learning path

If you’re looking for an easy way to pick up the highlights of this week, check out the People and Identity pathway. A pathway is an ordered tutorial that allows users to complete a pre-defined module that culminates in a quiz. It may include codelabs, videos, articles and blog posts. A virtual badge is awarded to each user who passes the quiz. Test your knowledge of key takeaways about People and Identity to earn a limited edition badge.

Key takeaways

Android 11 is the starting point of an ongoing focus on what matters most to users, people and conversations. Many of our partners in our ecosystem introduced amazing apps and services enabling these connections with people and conversations. We in Android want to elevate and surface these partners more prominently in order to support this goal. Thus if you are working on an app that fosters real time communication between people, we strongly encourage you to adopt the conversation shortcut based APIs for notifications, bubbles and sharing when targeting API 30 in order to put users’ conversations front and center and give them quick access to your app. The developer documentation can be found here.

For apps that handle user accounts, we encourage you to help our users avoid messy password hunting and forgotten credential processes by integrating One Tap to streamline credential management and Block Store to handle device updates. These integrations will work on phones back to Android M.

In the spirit of this week, I wish you meaningful and joyful connections with the people that matter to you and seamless experiences with your favorite apps. We hope you will help us in our journey of supporting these goals.


You can find the entire playlist of #11WeeksOfAndroid video content here, and learn more about each week here. We’ll continue to spotlight new areas each week, so keep an eye out and follow us on Twitter and YouTube. Thanks so much for letting us be a part of this experience with you!

June 18th 2020, 6:07 pm

Messenger and Conversations

Android Developers Blog

This blogpost is a collaboration between Google and Messenger from Facebook. Authored by Aaron Labiaga with support from Caleb Gomer and Samuel Guirado from Messenger.

Messenger is ubiquitous in the messaging app world and has pioneered the floating chat bubble. Bubbles help users keep conversations in view and accessible while multitasking, overlaying other UI elements in the foreground, and providing users easy access and visibility to their ongoing chats. Bubbles is one way Android 11 is making the platform more people-centric and expressive, reimagining the way we have conversations on our phones. Messenger’s early pioneering of the floating chat bubble, and the strong reception by users, helped lead to its native implementation in the framework.


The Bubbles API is built on top of the notifications API and is exclusively focused on people in Android 11. First Introduced in Android 10, what was previously an opt-in feature is now on by default. To use bubbles, the developer must create BubbleMetadata, which is set on the notification. This metadata describes the Activity to launch when a bubble is clicked, along with various behaviors relevant to the expanded bubble. The Activity must follow the criteria of being embeddable and resizable in order to use it in a bubble.

Notification bubbles are reserved for conversations with persons in context. These are MessagingStyle notifications with a set long-lived shortcut ID. Please see the following Bubbles code sample how.

A Q&A with the Messenger team

The Messenger team shares their experience with the migration and prospect of the impact of the changes.

How was the migration to bubbles, technical challenges, scope, and impact on codebase?

Prior to Bubbles, Messenger used the SYSTEM_ALERT_WINDOW for its implementation of Bubbles. It achieved our purpose, but hosting complex Android UI outside of Activities is challenging to implement and maintain. Using this natively supported API allowed us to build more traditional, Activity-based Android UI that works well in Bubbles and full screen. This new Bubbles-based chat experience is much simpler and more maintainable than our SAW-based one. We are excited that Android believes that it is a user experience that will help drive improvements in the conversation space.
Ensuring that bubble shortcuts were up-to-date with the latest state of the conversation thread was a technical challenge worth noting. Picture changed, conversation deleted or contact blocked are events that require the bubble shortcut to be updated or even deleted. The Shortcuts API allows for easily registering/unregistering shortcuts and for querying and updating existing ones, which made this whole process very straight forward.

What are your future prospects on the impact of Messenger messages in the conversation space?

The conversation section will give our messages the right visibility. Given that conversation section ranks high in the notification drawer, we definitely want to be present in that space.

A people-centric experience in Android 11

Bubbles are just one way that Android 11 puts people at the heart of the experience for Android; if you’re a messaging or chat app, you should consider using the Bubbles API to help your users as they multi-task. It’s great to see apps like Messenger navigate the openness of Android to create innovative new experiences, and we’re excited to make Bubbles a native experience in Android 11. For more information, please visit the Conversation API guidelines.

June 17th 2020, 5:24 pm

Bringing @Twitter's DMs into Android 11’s Conversation API

Android Developers Blog

This blogpost is a collaboration between Google and Twitter. Authored by Aaron Labiaga with support from Fred Lohner, Suzanne Xie, and Alex Ackerman-Greenberg from Twitter.

Direct Messages for the conversation space

Twitter is a social media app and source for what's happening in the world. And with Android 11’s Conversation APIs, surfacing Twitter’s Direct Messages to the conversation space makes perfect sense as it features real people talking in real time bidirectional conversations.

Conversation Notification API

To surface notifications in the conversation space, developers need to use Messaging style notifications set with a published long-lived shortcut ID. The shortcut ID allows for surfacing the conversation throughout various surfaces in the UI, including as a shortcut in the launcher. For details and sample code on how this is done, please see the conversation API guidelines.

A Q&A with the Twitter team

Frederik Lohner, tech lead of Twitter’s notifications team and Suzanne Xie, Product Management Director for Conversations on Twitter, share their experience with the migration and future prospect of its impact:

How was the migration to messaging style notifications, the technical scope and its impact on codebase?

Due to legacy reasons we first had to migrate to use MessagingStyle notifications for our DM pushes. This offered a great opportunity to clean up a bunch of technical debt, whilst allowing us the opportunity to begin testing things like auto generated replies for notifications with very little additional work on our side.

Were there any challenges in the implementation of shortcuts? As it is a requirement for the conversation space.

We found it challenging to manage the max number of published dynamic shortcuts since there is a limited number, requiring us to manually remove older shortcuts as new ones were created. The first Developer Preview didn't include a great way for managing shortcuts but this changed in Developer Preview 2, with the addition of the pushDynamicShortcut method that handled the limit for you.The addition of this method is a testament to the importance of exploring the APIs in the early stages and the impact one can have on shaping the API through testing and feedback.

What do think is the future prospect on the impact of migration, e.g. more engagement given visibility of DMs in conversation space?

We think these changes will make DM's much easier to use and look forward to getting feedback from our users. The conversation space also fits the purpose of DMs and it is important that these messages are categorized in the right space.

A people-centric experience in Android 11

Android 11 reimagines the way we have conversations on our phones, building an OS that can recognize and prioritize the most important people in your life. If your application has any notion of messaging between people then consider following the guidelines in the Android developer docs to ensure that you're taking advantage of the new conversation space. We’re excited to work with developers like Twitter to help showcase the importance of a people-centric experience on mobile phones with Android 11.

June 16th 2020, 1:10 pm

Meet Google Play Billing Library Version 3

Android Developers Blog

Posted by Steve Hartford, Product Manager, Google Play

Google Play is committed to a healthy ecosystem, where developers succeed by creating high-quality apps that users love. Many developers realize that success using Google Play’s one-time purchase and subscription services. Over the last decade, we’ve improved the purchase experience for Android users with features like paying via carrier billing (with over 180 supported carriers today), and tools to budget expenses and easily manage subscriptions.

We’re furthering these efforts with the launch of Billing Library version 3. Now available, this newest version includes new ways users can pay, subscription promotion capabilities, purchase attribution for games, and improvements to purchase reliability and security. Starting August 2, 2021, all new apps must use Billing Library version 3 or newer. By November 1, 2021, all updates to existing apps must use Billing Library version 3 or newer.

Paying with Cash

We continuously work to ensure users worldwide can pay for your one-time purchases and subscriptions in a way that’s comfortable and convenient.

Cash remains the most widely used payment method globally with 2.7 trillion transactions across all goods and services in 2018 (Source: Euromonitor). Last year we previewed a new payment method in which the transaction is completed off-device, such as paying with cash at a local convenience store. According to World Bank, two billion people worldwide do not have access to a bank account, so these pending transactions can help unlock new buyers, especially in emerging markets where cash is a popular form of payment.

Today we’re announcing users can easily pay for one-time purchases with cash in Indonesia and Malaysia at over 50,000 locations, including at leading retailers such as 7-Eleven and Alfamart. Pending transactions will be available soon for all developers.

Cash Purchases using Billing Library 3

More places for users to discover and purchase

Billing Library version 3 unlocks the ability for users to discover and purchase items outside of your app, such as across the Play store. One example is the new frictionless subscription promo code redemption experience. Now when you offer promo codes for subscription free trials, users can easily redeem them in the Play store - even if your app isn’t installed yet. It’s a simple redeem, subscribe and install experience that reduces the effort required for users to get going.

Purchase Attribution

Many games and apps need to ensure in-app purchases are attributed to a specific in-game character, avatar, or profile. Billing Library now allows you to specify this information when launching the purchase flow. After the purchase completes, you can retrieve the information and correctly attribute the purchase. This removes the need to build a custom solution using the deprecated AIDL developer payload.

Billing Library Version Requirements

Just like Play’s TargetSDK requirements, it’s important that all users are able to benefit from any security, performance, and user experience improvements in new versions of Billing Library. At Google I/O in 2019, we released Billing Library version 2 and announced changes including a two-year support window for each major release.

This means starting August 2, 2021, all new apps must use Billing Library version 3 or newer. By November 1, 2021, all updates to existing apps must use Billing Library version 3 or newer.

After these dates, you won’t be able to publish apps that use older AIDL, Billing Library version 1 or Billing Library version 2 integrations. Apps already in the Play Store can continue to be downloaded and will process in-app purchases. Any subsequent app upgrades, however, will require Billing Library version 3 or newer.

Billing Library version support


Billing Library version 3 is available today for all game and app developers in Java and Kotlin flavors. For game developers using Unity, we also launched a Billing Library 3-based Unity IAP plugin. This plugin allows Unity developers to meet the Billing Library version requirements and access all Play billing features.

Please upgrade any billing-related SDKs and libraries to versions supporting Billing Library version 3. Reach out to the SDK or library owner if one is not available. We’re working with top providers on their Billing Library version 3 compatibility.

Next Steps

While we recommend upgrading annually, we will be supporting each major release for two years. We recommend developers use Billing Library version 3 today for all new apps, and migrate existing billing integrations as soon as feasible - well ahead of the 2021 deadlines.

For developers who haven’t moved to Billing Library, we realize the transition from AIDL can be non-trivial for existing apps, and we want to help make the move as smooth as possible. We’ve created a migration guide for apps currently using AIDL, and there’s also a video walkthrough.

We’ve also updated our documentation - including guides for purchase attribution, using promo codes, and fighting abuse. Please let us know about any implementation issues - here’s how to contact us.

For details on all the Play Commerce platform improvements, watch our “What’s New” video session.

We’re looking forward to working with you to deliver great purchase experiences in your apps and games.

June 11th 2020, 5:13 pm

What’s new in Android gaming

Android Developers Blog

Posted by Greg Hartrell, Head of Product Management, Games on Android & Google Play

In March of this year, at the Google for Games Developer Summit, we shared several new tools and services Google has been working on to help game developers. They make it easier to see how your Android games are performing, expand your reach to more devices and new audiences, and support your go-to-market with Google Play. From the level of interest shown by game developers and the great feedback provided in our developer previews, we’re excited to share the progress we’ve made on these tools, and more.

Discover more about these updates below, and in addition to these, we’ll be back August 17-21, 2020 with even more information during a full week dedicated to Android gaming products, as part of #11WeeksOfAndroid.

Android tools for mobile game development

To support you in building a great Android game, we’re working on tools that help improve productivity and overall game performance. Learn about new updates you can start using today.

Reach more devices & users

To provide greater insights into your game’s performance and help scale your games to reach a growing player-base across the Android ecosystem, we’ve seen growing success with the adoption of Play’s dynamic delivery of game assets as well as our Integrity Protection Suite. Read on for additional launches and updates.

Reach more devices and win go-to-market

We’ve completely redesigned the Google Play Console making it easier for you to improve your app’s quality, engage your audience, earn revenue, and more. We’re also continuing to improve the Google Play Store and other services allowing you to better market your game to expanded audiences.

We hope you start using some of these new tools and features, and continue to share your feedback with our development teams. You can learn about all of the offerings we have to help game developers at

How useful did you find this blog post?

June 11th 2020, 1:07 pm

Performance insights for Games, powered by Android Performance Tuner

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

Android vitals is the destination for managing your app's technical quality. Over 80,000 developers take advantage of its performance and stability metrics every month.

As part of our work to help you deliver better game experiences to more Android users, we're introducing Android Performance Tuner - a new library in the Android Game SDK that unlocks game performance insights in Android Vitals. This gives you a scalable way to measure and optimize your frame rate and graphical fidelity across the whole Android device ecosystem.

Unity Boat Attack Sample with Different Optimizations

Once you have integrated Android Performance Tuner into your game and published it on Play, you'll be able to see how it performs across real users and devices with the following new features in Android vitals.

Frame rate performance

Frame Rate Performance by Quality Level and Device Model

We chart the frame time distribution across your users’ devices, broken down by quality levels that you have implemented in your game, so you can see how specific device models or hardware specifications are performing on each quality level.

Performance issues

We also analyze your performance data to help determine the likely cause of issues, so you can differentiate between problems associated with specific hardware and problems with specific screens or levels in your game. You annotate your code to give contextual information about what your game is doing at that point. This gives you full control over the granularity of the insights.

Top Device Model/Annotation Issues

We call out the top device model issue as well as the top game-specific issue to give you clear guidance on what's most important.

Underperforming Device Models by GPU

You can drill down to see a breakdown of underperforming device models by different specs, such as GPU and SoC. This allows you to decide whether you can work at the GPU or SoC-level to optimize performance. Alternatively, you may decide to change quality levels, rather than work at the device model level.

Device Model Impact, User Impact, GPU Time

You can also see the full list of device models, along with the number of affected user sessions and frame time, to help you prioritize device-specific changes. As well as total frame time, we also show you GPU time to help determine whether the device is GPU bound or has another performance problem, such as being CPU or I/O bound. All data in the device model table can be exported for further analysis and action planning.

Opportunities to make a good experience great

We can also help identify opportunities — places where you could potentially provide users with a better experience by giving them a higher quality level, enabling more advanced graphical features.

Frame Time Performance with Opportunities

The devices on the far left are more than meeting the frame times for smooth performance. You can drill down to see stats by device model and specification to see if there is an opportunity to improve the graphical fidelity across a wide range of devices.

Available (almost) everywhere

The Android Performance Tuner is intended to work across over 99% of the Android device ecosystem. You can get these insights on any Android devices around the world, from Android 4.1 (API 16) onwards.

Integrating Android Performance Tuner

Whether you have your own game engine or are using a third-party game engine, we're doing our best to make integration easy. The Android Performance Tuner relies on tick functions being called each frame. Within the library, this tick information is aggregated into histograms, which are periodically uploaded through an HTTP endpoint, so your game will need to have the internet access permission.

With our plugin for the Unity platform, you can collect frame ticks from Unity 2017.4 onwards. Unity 2019.3.14+ enables the collection of higher-fidelity performance information.

If you're doing a native source code level engine integration, we strongly recommend integrating the Frame Pacing API from the Android Game SDK to get the highest quality information. The Frame Pacing API will give you smoother frame rates and improved support for high-refresh rate displays, so it's worth integrating on its own.

Unreal 4.25+ integrates the Frame Pacing API. You enable it by adding a.UseSwappyForFramePacing=1 to the Android_Default profile to activate it for all Android devices.

Within Unreal or your native engine integration, you pass in the Swappy_injectTracer function from the Frame Pacing API at initialization to enable automatic frame time recording.

void InitTf(JNIEnv* env, jobject activity) {
   SwappyGL_init(env, activity);
   swappy_enabled = SwappyGL_isEnabled();
   TFSettings settings {};
   if (swappy_enabled) {
       settings.swappy_tracer_fn = &SwappyGL_injectTracer;

Enabling Frame Time Recording in the Android Performance Tuner for your Engine

In Unity, we recommend activating Optimized Frame Pacing within the Unity settings (Unity 2019.3+ only), but Frame Pacing isn't required in Unity to use the Android Performance Tuner.

Activating Optimized Frame Pacing in Unity 2019.3

Providing contextual information

Next, you want to define annotations to give contextual information about what your game is doing when a tick is recorded, such as:

Annotation Parameters

If you're using Unity with the Android Performance Tuner plugin, you'll automatically get a scene annotation that maps to the current scene being played. The LoadingState annotation can be easily hooked up to your scripts, and you can define additional annotations within the plugin editor UI.

Annotation Parameters within the Unity Editor from the Android Performance Tuner Plugin

To pass annotation parameters from within your own game engine, you define a protocol buffer message that contains all of these annotations, such as loading state, level or scene, etc.

Fidelity Parameters and Quality Levels

You also define fidelity parameters and associate them with quality levels that your game reports back. These can be used for anything that you use in your game to reduce the complexity of the scene, such as texture quality, draw distance, particle count, post-processing effects, shadow resolution, etc. In the native integration, you define these parameters using a protocol buffer.

import "tuningfork.proto"
message FidelityParams {
  int32 texture_quality_level = 1;
  int32 shadow_resolution = 2;
  float terrain_details_percent = 3;
  int32 post_processing_effects_level = 4;

Example FidelityParams Proto Definition for an In-house Engine

Then, you create up to fifteen sets of quality levels as a set of values defined by the FidelityParams message, which allows the Android Performance Tuner to track its metrics against your quality data. You can create both fidelity parameters and quality levels in the Unity editor interface provided by the Android Performance Tuner for Unity plugin.

Testing your integration

We've created the Tuning Fork Monitor app to act as a local server and display data from an Android Performance Tuner-enabled app. You can call EnableLocalEndpoint() in the Android Performance Tuner Unity plugin on a development build to enable local testing. In your native integration, you set the endpoint_uri_override in the Android Performance Tuner settings.

Once local tests look great, you then enable the Android Performance Parameters API in the Google Cloud Console to test end-to-end.

Available Now

We're committed to helping you bring the best version of your game to the widest number of users and devices in the Android ecosystem. Android Performance Tuner within the Android Game SDK, the Unity plugin, and Performance Insights within Android Vitals are all available now. You can refer to our documentation for a walk through of the process for native and Unity integrations.

June 11th 2020, 12:07 pm

Introducing the new Google Play Console beta

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play Console

Over the years, we’ve seen our community grow to well over a million developers, from one-person shops to companies with hundreds of Google Play Console users. As you’ve grown, Play Console has grown with you. But as we added new features to keep up with your changing needs, Play Console became increasingly busy and a little difficult to navigate. So we’ve redesigned it from the ground up to ensure it continues to help you grow your business on Google Play for years to come.

Today, you can try out the new Google Play Console by joining the beta. Visit Play Console at its new home:

We’ve designed the new Play Console to be more helpful. Now you can:

On behalf of the whole team at Google Play, I’m excited to share the beta with you and to get your feedback. Many thanks to the hundreds of developers who have already provided feedback — your input helps us improve Play Console for the entire developer community.

Clearer and easier to use

The new Google Play Console is built on Google Material, the UI design system for all Google-branded products. This brings a number of advantages as explained by the project’s lead designer, Jesse Orme:

This design system is easier to read and scan, using typography and space to delineate sections and enable clear information hierarchy. A consistent and considered set of styles and components ensure that features are as easy and intuitive to use as possible, even if you’re new to them."

The new Play Console is also responsive, so you can use it across your devices, at home, at work, or when you’re on the move. The responsive design also supports right-to-left languages including Arabic, Farsi, and Hebrew. The team is putting the finishing touches on our mobile layouts now, so these features will roll out to the beta in the coming weeks.

New navigation

Because many Play Console users can be domain specialists like Growth Managers or QAs, we’ve designed the new navigation to reflect how you work, making it easier to find all the tools for your job.

The navigation groups related features based on what you want to achieve. For instance, all of your acquisition setup, reporting, and optimization tools are now collected in a single “Grow” section. We’re also adding a search feature to the beta soon, so you can jump to specific features or pages more quickly.

The new navigation organizes features based on your goals

Similarly, we’ve made the distinction between your production track and your internal, closed, and open testing tracks much clearer. This reflects best practices and will make it easier for your team to understand the status of app’s tracks at a glance so you can release with confidence.

Clearer overviews

The new releases overview gives you a snapshot of all your tracks, so now you can see information about your internal, closed, and open testing tracks, as well as your production track. Quickly see how many users are testing your app or the latest countries you’ve rolled out to.

The new Releases overview lets you see information about all your tracks at a glance

Easier publishing

We've renamed Timed Publishing to Managed Publishing. Use it to see a summary of your changes that are in review and control when to publish on Google Play. Managed Publishing also helps you understand all the changes that have been submitted across your releases, store listings, and more. For those of you with larger teams, you can now review and coordinate all your changes in one place so everything is published at the same time.

Submit your updates for review and launch them when you’re ready with Managed Publishing

The Artifact library has evolved into the new App Bundle Explorer, which you can find in the “Release” section. You can inspect the app bundles you’ve uploaded to Play and understand how Google Play processes them to generate optimized serving artifacts. Download everything Play generates, including APKs for pre-installing on devices and standalone APKs, access an install link for historical versions for testing purposes, and see detailed dynamic delivery information.

And when you’re launching a new app, check out our new guided setup to help you get to production with confidence.

Guided setup includes best practices to help you get to production with confidence

More ways to get the answers you need, fast

Important information is now even easier to find, with more ways to get the answers you need, right when you need them.

Clearer policy and compliance information

The new Policy status and App content sections make it easier for you to provide information Google Play needs to confirm that your apps are compliant with our policies, and to quickly see if there’s an issue that needs addressing. We know this can be a source of worry, so we designed these new sections to help guide you through the process, and they will continue to grow over time.

The App content section makes it easier to provide the information Google Play needs to confirm that your apps comply with our policies


Rolling out soon, the new Play Console Inbox collects everything we think you’ll need to know about your apps and games. Never miss an important message, update, recommendation, or milestone.

Find important messages about your apps and games in the new Play Console Inbox

Easier education

Many of you told us that you don’t feel like you’re using the full capabilities of Google Play Console because you’re not sure what features are available or how best to use them. To help, key features now include educational pages to help your teams understand their value and how to add them to your workflows. These also serve as a hub for related information, like our comprehensive documentation on the Help Center, Play Academy courses, developer case studies, and more.<br>

Educational pages help you understand key features and and how to add them to your workflows

These pages can be accessed without a Play Console account so you can easily share them.

Visit the new educational pages at

Understanding your performance

Many of you told us that you value Google Play Console’s acquisition reports because they help you understand the impact of your store listing optimization and marketing investment. But you also told us that the current report made it challenging to see how your performance was trending over time, and you wanted to analyze performance across multiple dimensions together, such as country and acquisition source.

The new acquisition reports focus on trend analysis, understanding relationships between metrics, and now support expanded dimensions including language, store listing, and reacquisition.

New filters and dimensions let you see trends by acquisition type and region to really understand your performance

Advanced filters and dimensions let you drill down by acquisition type and region to really understand your performance. For instance, did your campaign to increase organic installs in France pay off? Now you can find out.

Rolling out soon, deeply integrated benchmarks — including over 100 app and game categories, plus countries and regions — can help you identify areas for growth and where you’re leading the market.

Better, safer team management

Another area we’ve enhanced is team-member management. The new Google Play Console includes features, insights, and data to help every member of your team, from your engineers, PMs, and QAs to your marketing managers and executives. We know that granting broad access to everyone in your organization could be a challenge, with permissions that were sometimes hard to understand, and a UI that made managing large numbers of team members difficult.

We’ve updated the new team-member management area with better, more granular controls. Written in collaboration with developers, new permission names and descriptions are clearer, so you can understand what you are — and aren’t — allowing people to do. There’s clearer differentiation between global and app-level permissions, and we’ve added full user search and bulk-edit capabilities to make managing your teams easier.

Safely grant your team members access to Play Console’s features with granular permission controls

We want as many people as possible to benefit from Play Console’s tools, and these changes should help you grant access with confidence.

Try the new Play Console beta today

The features above are just the beginning — every page on Google Play Console has been enhanced. Features like Pre-launch reports, Android vitals, Statistics, and Play Game Services have all been made more usable and helpful.

Visit to check out the beta today. Once you do, please share your thoughts using this feedback form or in Play Console using the button on the top right. Your feedback is crucial to helping our teams build better products for you.

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?

June 10th 2020, 1:35 pm

Unwrapping the Android 11 Beta, plus more developer updates

Android Developers Blog

Posted by Stephanie Cuthbertson, Director, Product Management

Editor’s note: The global community of Android developers has always been a powerful force in shaping the direction of the Android platform; each and every voice matters to us. We have cancelled the virtual launch event to allow people to focus on important discussions around racial justice in the United States. Instead, we are releasing the Android 11 Beta today in a much different form, via short-form videos and web pages that you can consume at your own pace when the time is right for you. Millions of developers around the world build their business with Android, and we're releasing the Beta today to continue to support these developers with the latest tools. We humbly thank those who are able to offer their feedback on this release.

Today, we’re unwrapping the Beta release for Android 11 as well as the latest updates for developers from Kotlin coroutines, to progress on the Jetpack Compose toolkit, to faster builds in Android Studio, even a refreshed experience for the Play Console.

Android 11 Beta: now available

You’ve been helping us with feedback on the Android 11 developer previews since February, and today we released the first Beta of Android 11 focused on three key themes: People, Controls, and Privacy.

People: we’re making Android more 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 your life:

Controls: the latest release of Android can now help you can quickly get to all of your smart devices and control them in one space:

Privacy: In Android 11, we’re giving users even more control over sensitive permissions and working to keep devices more secure through faster updates.

Developer friendliness: We want to make it easy for developers to take advantage of the new release, so to make compat testing easier, we’ve:

Android 11 also includes a number of other developer productivity improvements like wireless ADB debugging, ADB incremental for faster installs of large APKs, and more nullability annotations on platform APIs (to catch issues at build time instead of runtime), and more.

The first Beta for Android 11 is available today, with final SDK and NDK APIs and new features to try in your apps. If you have a Pixel 2, 3, 3a, or 4 device, enroll here to get Android 11 Beta updates over-the-air. As always, downloads for Pixel and the Android Emulator are also available. To learn about all of the developer features in Android 11, visit the Android 11 developer site.

Modern Android development

Over the past several years, the Android team has been hard at work improving the mobile developer experience, to make you more productive. This includes the Android Studio IDE, a great language (Kotlin!), Jetpack libraries to make common tasks easy, and Android App Bundles to improve app distribution. Today we call this modern Android development - bringing you the best of Android to make you as efficient and productive as possible.

Android Studio

Today, we released new features in Android Studio 4.1 Beta and 4.2 Canary, focused on a number of crucial asks from developers:

Try out the latest: Android Studio 4.1 Beta and Android Studio 4.2 Canary.

Kotlin and Jetpack

Languages and libraries are a major area of investment in modern Android development, with Kotlin’s modern, concise language and Jetpack’s opinionated powerful libraries all focused around making you more productive.

With the rise in Kotlin adoption (with over 70% of top 1000 apps on Google Play now using Kotlin) and so many developers using Kotlin, we can now use it to simplify your experience in new ways. Kotlin coroutines are a language feature of Kotlin which make concurrent calls much easier to write and understand. We’re making coroutines our official recommendation, and we’ve built coroutines support into 3 of the most-used Jetpack libraries -- Lifecycle, WorkManager, and Room -- so you can write even better code.

Kotlin itself also continues to get better with every release, thanks to the awesome team at Jetbrains. Kotlin 1.4 provides faster code completion, more powerful type inference enabled by default, function interfaces, as well as helpful quality of life improvements like mixing named and positioning arguments.

We also continue to push Jetpack forward - a suite of libraries which spans multiple Android releases and is designed to make common mobile development patterns fast and easy. Many of us have long loved Dagger, so we worked with the Dagger team to bring you Hilt, a developer-friendly wrapper on top of Dagger, as a recommended Dependency Injection solution for Android. You’ll find this in alpha ready to try out. We’ve also added a second new library App Startup, to help both app developers and library developers improve app startup time by optimizing initialization of libraries. We have many more updates to existing libraries as well, including a major update to Paging 3, rewritten Kotlin-first with full support for coroutines!

The latest on our new UI toolkit, Compose

There’s one more thing you need to be super productive — and that’s a powerful UI toolkit to quickly and easily build beautiful UIs on Android, with native access to the platform APIs. That’s why we’re building Jetpack Compose, our new modern UI toolkit that brings your app to life with less code, powerful tools, and intuitive Kotlin APIs.

Today we are launching Jetpack Compose Developer Preview 2, packed with features developers have been asking us for:

We've also added a number of new capabilities to Android Studio 4.2, in close partnership with Jetbrains Kotlin team, to help you build apps with Compose:

Compose isn’t ready for production use yet, in particular as we finish performance optimizations, but we’d love you to give it a try and share feedback. We plan to launch Alpha this summer and 1.0 next year.

An all-new Google Play Console

Google Play is focused on helping developers grow their business. With that mission in mind, we've redesigned the Google Play Console to help you maximize your success on our platform. In addition to being clearer and easier to use, we've added features to help you:

Learn more about the new Google Play Console in this post or join the beta now at Your feedback helps us continue to improve Google Play Console for everyone, so please let us know what you think.

Wrapping it all up

But there’s so much more we’re launching that we didn’t get to talk about!

June 10th 2020, 1:35 pm

Introducing Google Play Asset Delivery

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

Two years ago, we introduced the Android App Bundle, a new publishing format that allows Google Play to help optimize your app delivery. The app bundle is now Play’s recommended publishing format; with almost 50% of all top apps & games already using it.

It replaces the traditional monolithic APK at publishing time, allowing you to package all of your languages, screen densities and device architectures into a single artifact. The bundle itself can't be installed; Play takes care of generating APKs optimized for each requesting device from the single bundle that you publish.

Dynamic Delivery with App Bundle Produces Optimized APKs

Apps have seen great success with app bundles, but games often have different delivery challenges.

Today, large Android games rely on APK Expansion Files and custom Content Delivery Networks (CDNs) to deliver content. APK Expansion Files, also known as OBBs, support large resources but require you to maintain an additional publishing artifact, which causes many developer issues. Using CDNs for resource delivery often results in a suboptimal user-experience; users install and open the game just to face a long progress bar as they wait for additional resources to be downloaded. Users may also have to wait for updated resources, rather than having them delivered as part of the game auto-update. Finally, CDNs usually aren’t free, so this way of delivering game assets also involves extra cost that needs to be accounted for.

To handle the unique needs of games, Play is introducing Play Asset Delivery, giving you dynamic delivery of the right game assets to the right devices at the right time at no additional cost. To achieve this, we extended the Android App Bundle publishing format by adding asset packs.

The contents of an Android App Bundle with one base module, two dynamic feature modules, and two asset packs.

Asset packs contain non-code game content such as textures, materials, and sounds. They are served from Google Play with large size limits that are ideal for games, and you can customize how and when each asset pack is downloaded onto a device.

Keeping assets up-to-date

Play Asset Delivery (PAD) lets you rely on Google Play to take care of updating your assets, just like it does with your game binary. When your app auto updates, the entire game gets updated, including all assets. When your users open the game, they will already have the freshest binary and assets, and they won’t need to wait for resources to get updated. Play also takes care of delta patching for you, minimizing the download size and the update time.

To handle cases when the user opens the game before it has had a chance to update, you can trigger updates within the context of your game with our In-App Updates API.

Play Asset Delivery engine support

Customizing when asset packs are installed

You can customize when asset packs are installed according to three delivery modes: install-time, fast-follow, and on-demand.

Both on-demand and fast-follow assets are delivered as raw files and placed in your game’s internal storage. You can track download progress with the PAD API and access the assets directly using file system calls.

Extending Android App Bundle for Games

When using Play Asset Delivery, you get to take advantage of the App Bundle format, which allows Play to optimize the binary for the device, making it easier to support both 64-bit and 32-bit devices and different CPU architectures such as ARM and X86. We also want to help you serve the optimal set of assets to each device, and the first step in this direction is texture compression format targeting.

In an upcoming release of Play Asset Delivery, you'll be able to package textures in multiple texture compression formats, relying on Play to serve optimal assets per device model. This means you won't need to compromise by using suboptimal texture compression formats, and your users will always get the best assets suitable for their device without wasting network bandwidth or having suboptimal loading performance.

Better retention with an improved install experience

Asphalt 8 by Gameloft

Gameloft integrated Play Asset delivery into Asphalt 8, Asphalt Xtreme, and Minion Rush. Asphalt Xtreme was easy to switch from using APK expansion files to using PAD with install-time delivery. Asphalt 8 and Minion Rush both originally used a custom CDN, which Gameloft replaced with PAD. They were able to leverage fast-follow and on-demand delivery by replacing their custom CDN calls with calls to the PAD API. They saw the expected reduction in CDN costs, but with fast-follow delivery, they have also seen a significant increase in the number of users who completed the secondary download to start playing the game. This resulted in better user retention, with 10% more new players compared to their previous CDN asset delivery system. With the promising early results and seamless implementation process, Gameloft plans to use PAD in more of their upcoming releases. Read more about their experience.

Improved user experience with cost savings

Puzzle Kids - Animals Shapes and Jigsaw Puzzles by RV AppStudios

US-based developer RV AppStudios has over 200 million downloads to date across their portfolio of casual games, educational kids apps, and utility apps. Their Puzzle Kids app delivers over 23 MB of assets as players progress through the levels. When they switched from a third-party CDN to using Play Asset Delivery’s on-demand mode, they saw a 4.7% increase in 15-day retention and 21% reduction in crashes & ANRs. Overall, these changes helped improve the user experience by offering more stable, transparent, and secure downloads, while also saving costs for RV AppStudios. Read more about their experience.

Play Asset Delivery is available now

We're committed to helping you serve your entire game through Play with customized dynamic delivery. Play Asset Delivery, with the new app bundle format for games, along with its three delivery modes and updates + patching are all generally available. You can find documentation at that will walk you through the integration process depending on the game engine you use.

June 9th 2020, 1:03 pm

Android Studio 4.0

Android Developers Blog

Posted by Adarsh Fernando, Product Manager

During these uncertain times, we’re humbled by the many developers around the world who are finding ways to keep doing what they do best—create amazing apps for Android. Whether you’re working from your kitchen table on a laptop or from a home office, you need tools that keep up with you. Android Studio 4.0 is the result of our drive to bring you new and improved tools for coding smarter, building faster, and designing the apps your users depend on, and it’s now available on the stable channel.

Some highlights of Android Studio 4.0 include a new Motion Editor to help bring your apps to life, a Build Analyzer to investigate causes for slower build times, and Java 8 language APIs you can use regardless of your app’s minimum API level. Based on your feedback, we’ve also overhauled the CPU Profiler user interface to provide a more intuitive workflow and easier side-by-side analysis of thread activity. And the improved Layout Inspector now provides live data of your app’s UI, so you can easily debug exactly what’s being shown on the device.

As always, this release wouldn’t be possible without the early feedback from our Preview users. So read on or watch below for further highlights and new features you can find in this stable version. If you’re ready to jump in and see for yourself, head over to the official website to download Android Studio 4.0 now.


Motion Editor

The MotionLayout API extends the rich capabilities of ConstraintLayout to help Android developers manage complex motion and widget animation in their apps. In Android Studio 4.0, using this API is made easier with the new Motion Editor—a powerful interface for creating, editing, and previewing MotionLayout animations. You no longer have to create and modify complex XML files; the Motion Editor generates them for you, with support for editing constraint sets, transitions, keyframes, and view attributes. And if you do want to see the code the editor creates, it is one click away. And just as conveniently, for developers already using ConstraintLayout, the IDE can easily convert those to MotionLayout. Learn more

Create, edit, and preview animations in the Motion Editor

Upgraded Layout Inspector

Have you ever wanted to investigate where a value for a particular attribute came from? Or see a live 3D representation of nested views to more easily inspect your view hierarchy? With the new Layout Inspector, debugging your UI is much more intuitive by giving you access to data that stays updated with your running app and providing insights on how resources are being resolved.

Debug your app’s UI in real-time with Live Layout Inspector

Use the live Layout Inspector by selecting View > Tool Windows > Layout Inspector from the main menu. If you are deploying to a device running API 29 level or higher, you have access to additional features, such as a dynamic layout hierarchy that updates as views change, detailed view attributes that also help you determine how resource values are resolved, and a live 3D model of your running app’s UI. Navigate, animate, and transition between views on your running app while always having the ability to debug your UI to pixel perfection. Learn more

Layout Validation

Compare your UI across multiple screens with Layout Validation

When you’re developing for multiple form-factors, screen sizes, and resolutions, you need to verify that changes you make to your UI look great on every screen you support. With the Layout Validation window, you can preview layouts on different screens and configurations simultaneously, so you can easily ensure your app looks great across a range of devices. To get started, click on the Layout Validation tab in the top-right corner of the IDE.

Develop & Profile

CPU Profiler UI Upgrades

The improved UI of the CPU Profiler

The CPU profiler is designed to provide a rich amount of information about your app’s thread activity and trace recordings. So, when you provided us feedback about how we can make the UI even more intuitive to navigate and the data easier to understand, we listened. In Android Studio 4.0, CPU recordings are now separated from the main profiler timeline and organized in groups to allow for easier analysis. You can move groups up and down, or drag-and-drop individual items within a group for additional customization.

Easier side-by-side analysis of thread activity

For easier side-by-side analysis, you can now view all thread activity in the Thread Activity timeline (including methods, functions, and events) and try new navigation shortcuts to easily move around the data—such as using W, A, S, and D keys for fine-grained zooming and panning. We’ve also redesigned the System Trace UI so Events are uniquely colored for better visual distinction, threads are sorted to surface the busier ones first, and you can now focus on seeing data for only the threads you select. Finally, we invested in the quality of the CPU profiler, and consequently we’ve seen a significant decrease in the user-reported error rates of recordings since Android Studio 3.6. There are even more improvements to try, so learn more.

Smart editor features when writing rules for code shrinking

Smart editor feature when writing rules for R8

R8 was introduced in Android Gradle plugin 3.4.0 to combine desugaring, shrinking, obfuscating, optimizing, and dexing all in one step—resulting in noticeable build performance improvements. When creating rules files for R8, Android Studio now provides smart editor features, such as syntax highlighting, completion, and error checking. The editor also integrates with your Android project to provide full symbol completion for all classes, methods, and fields, and includes quick navigation and refactoring.

IntelliJ IDEA 2019.3 platform update

The core Android Studio IDE has been updated with improvements from IntelliJ IDEA 2019.3 and 2019.3.3 releases. These improvements largely focus on quality and performance improvements across the IDE.

Kotlin Android live templates

Live templates is a convenient IntelliJ feature that allows you to insert common constructs into your code by typing simple keywords. Android Studio now includes Android-specific live templates for your Kotlin code. For example, simply type toast and press the Tab key to quickly insert boilerplate code for a Toast. For a full list of available live templates, navigate to Editor > Live Templates in the Settings (or Preferences) dialog.

Clangd support for C++

For developers writing C++, we have switched to clangd as the primary language analysis engine for code navigation, completion, inspection, and showing code errors and warnings. We also now bundle clang-tidy with Android Studio. To configure Clangd or Clang-Tidy behavior, go to the IDE Settings (or Preferences) dialog, navigate to Languages & Frameworks > C/C++ > Clangd or Clang-Tidy, and configure the options.


Android Gradle plugin 4.0.0 includes support for Android Studio’s Build Analyzer by using Java 8 language APIs (regardless of your app’s minimum API level), and creating feature-on-feature dependencies between Dynamic Feature modules. For a full list of updates, read the Android Gradle plugin 4.0.0 release notes.

Build Analyzer

Address bottlenecks in your build performance with Build Analyzer

Android Developers rely on a variety of Gradle plugins and custom build logic to tailor the build system for their app. However, outdated or misconfigured tasks can cause longer build times that lead to frustration and lost productivity. The Build Analyzer helps you understand and address bottlenecks in your build by highlighting the plugins and tasks that are most responsible for your overall build time and by suggesting steps to mitigate regressions. Learn more

Java 8 Language library desugaring in D8 and R8

Previous versions of the Android Gradle plugin supported a variety of Java 8 language features for all API levels, such as lambda expressions and method references, through a process called desugaring. In Android Studio 4.0, the desugaring engine has been extended to support Java language APIs, regardless of your app’s minSdkVersion. This means that you can now use standard language APIs, which were previously available in only recent Android releases (such as, java.util.function and java.time). Learn more

Feature-on-feature dependencies

Feature-on-feature dependencies

When using Android Gradle plugin 4.0.0 and higher, you can now specify that a Dynamic Feature module depends on another feature module. Being able to define this relationship ensures that your app has the required modules to unlock additional functionality, resulting in fewer requests and easier modularization of your app. For example, a :video feature can depend on the :camera feature. If a user wants to unlock the ability to record videos, your app automatically downloads the required :camera module when it requests :video. Learn more

New options to enable or disable build features

The Android Gradle plugin has built-in support for modern libraries, such as data binding and view binding, and build features, such as auto-generated BuildConfig classes. However, you might not need these libraries and features for every project. In version 4.0.0 of the plugin, you can now disable discrete build features, as shown below, which can help optimize build performance for larger projects. For the DSL and full list of features you can control, see the release notes.

android {
    // The default value for each feature is shown below.
    // You can change the value to override the default behavior.
    buildFeatures {
        // Determines whether to support View Binding.
        // Note that the viewBinding.enabled property is now deprecated.
        viewBinding = false
        // Determines whether to support Data Binding.
        // Note that the dataBinding.enabled property is now deprecated.
        dataBinding = false

Android Gradle plugin DSL for enabling or disabling build features

Essential support for Kotlin DSL script files

Android Studio 4.0 now has built-in support for Kotlin DSL build script files (*.kts), which means that Kotlin build scripts offer a full suite of quick fixes and are supported by the Project Structure dialog. While we are excited about the potential for using Kotlin to configure your build, we will continue to refine the Android Gradle Plugin’s DSL API throughout the next year, which may result in breaking API changes for Kotlin script users. Long term, these fixes will make for a more idiomatic, easy-to-use DSL for Kotlin script users.

Dependencies metadata

When building your app using Android Gradle plugin 4.0.0 and higher, the plugin includes metadata that describes the library dependencies that are compiled into your app. When uploading your app, the Play Console inspects this metadata to provide alerts for known issues with SDKs and dependencies your app uses, and, in some cases, provide actionable feedback to resolve those issues.

The data is compressed, encrypted by a Google Play signing key, and stored in the signing block of your release app. If you’d rather not share this information, you can easily opt-out by including the following in your module’s build.gradle file:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false

Disable dependency metadata for your APKs, app bundle, or both

To recap, Android Studio 4.0 includes these new enhancements & features:


Develop & Profile


For a full list of changes, read the official release notes.

Getting Started


Download Android Studio 4.0 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio.

As always, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, please file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

May 28th 2020, 1:13 pm

#Android11: The Beta Launch Show - Here’s how to join in and watch next week!

Android Developers Blog

Posted by The #Android11 team

In just under a week, we’ll kick off #Android11: The Beta Launch Show, your opportunity to find out what’s new in Android from the people who build Android. Join us on June 3, 11AM ET (8AM PT, 4PM BST, 8:30PM IST) as we unveil new features packed inside the next release, Android 11, as well as updates to help developers get the most out of modern Android development. You’ll be able to watch the show live on YouTube (don’t forget to set a reminder) or Twitter, and can sign-up for updates here.

Get your #AskAndroid questions answered live

Got a burning question? We’ve got experts ready to answer your #AskAndroid questions, and we’ll be wrapping up the show with a live Q&A session. All you have to do is share your question on Twitter using #AskAndroid, and we’ll be selecting questions for Android engineering and product leads Dave Burke and Stephanie Cuthbertson to answer live on-the-air.

Check out the list of talks

Also on June 3, we’ll be sharing 12 talks on a range of topics from Jetpack to Android Studio and Google Play–talks that we had originally planned for Google I/O–to help you take advantage of the latest in Android development. We just posted the full list of talks on the event page.

Sketchnote with us

We want to see your take on the show, so grab your best pens, markers, and paper, download the template, and get ready to show off your sketchnote skills during The Beta Launch Show. Don’t forget to share your work using the hashtag #Android11 for a chance to be featured.

We can’t wait to share with you the latest we’ve been working on with you in just over a week at #Android11: The Beta Launch Show!

May 27th 2020, 1:17 pm

Answers to your questions about app signing by Google Play

Android Developers Blog

Posted by Dom Elliott, Product Manager, Google Play

Google Play's first priority is to build a trusted, safe, and secure platform for billions of users and millions of developers for many years into the future. The sustainability and success of the ecosystem depends on this.

As part of this goal, almost two years ago, we announced app signing by Google Play. With app signing by Google Play, Google manages and protects your app's signing key for you and uses it to sign your APKs for distribution. It’s a secure way to store your app signing key that helps protect you if your key is ever lost or compromised. If you’re not enrolled in app signing and you lose your signing key, you’ll lose the ability to update your app.

App signing by Play also enables you to publish your app or game with the Android App Bundle, the recommended publishing format in use by over 500,000 apps in production on Google Play. The Android App Bundle reduces the size of your app, simplifies your releases, and unlocks next generation distribution features such as dynamic features and dynamic asset delivery.

Developers often have questions when enrolling in app signing for the first time so my colleague has written a Medium post with answers to some frequently asked questions. Read the post to find out more about the benefits of app signing, how we protect developer keys, and to learn about features like key upgrade for new installs and the new source stamp that bundletool will start adding to apps published with app bundles to give you more peace of mind about Play-signed apps.

May 7th 2020, 4:36 pm

Android 11: Beta Plans

Android Developers Blog

Posted by Dave Burke, VP of Engineering

When we started planning Android 11, we didn’t expect the kinds of changes that would find their way to all of us, across nearly every region in the world. These have challenged us to stay flexible and find new ways to work together, especially with our developer community.

To help us meet those challenges we’re announcing an update to our release timeline. We’re bringing you a fourth Developer Preview today and moving Beta 1 to June 3. And to tell you all about the release and give you the technical resources you need, we’re hosting an online developer event that we’re calling #Android11: the Beta Launch Show.

Join us for #Android11: The Beta Launch Show

While the circumstances prevent us from joining together with you in-person at Shoreline Amphitheatre for Google I/O, our annual developer conference, we’re organizing an online event where we can share with you all the best of what’s new in Android. We hope you’ll join us for #Android11: The Beta Launch Show, your opportunity to find out what’s new in Android from the people who build Android. Hosted by me, Dave Burke, we’ll be kicking off at 11AM ET on June 3. And we’ll be wrapping it up with a post-show live Q&A; tweet your #AskAndroid questions to get them answered live!

Later that day, we’ll be sharing a number of talks on a range of topics from Jetpack Compose to Android Studio and Google Play–talks that we had originally planned for Google I/O–to help you take advantage of the latest in Android development. You can sign-up to receive updates on this digital event at

Android 11 schedule update

Our industry moves really fast, and we know that many of our device-maker partners are counting on us to help them bring Android 11 to new consumer devices later this year. We also know that many of you have been working to prioritize early app and game testing on Android 11, based in part on our Platform Stability and other milestones. At the same time, all of us are collaborating remotely and prioritizing the well-being of our families, friends and colleagues.

So to help us meet the needs of the ecosystem while being mindful of the impacts on our developers and partners, we’ve decided to add a bit of extra time in the Android 11 release schedule. We’re moving out Beta 1 and all subsequent milestones by about a month, which gives everyone a bit more room but keeps us on track for final release later in Q3.

Here are some of the key changes in the new schedule:

By bringing you the final APIs on the original timeline while shifting the other dates, we’re giving you an extra month to compile and test with the final APIs, while also ensuring that you have the same amount of time between Platform Stability and the final release, planned for later in Q3. Here’s a look at the timeline.

You can read more about what the new timeline means to app developers in the preview program overview.

App compatibility

The schedule change adds some extra time for you to test your app for compatibility and identify any work you’ll need to do. We recommend releasing a compatible app update by Android 11 Beta on June 3rd to get feedback from the larger group of Android Beta users who will be getting the update.

With Beta 1 the SDK and NDK APIs will be final, and as we reach Platform Stability in July, the system behaviors and non-SDK greylists will also be finalized. At that time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. You can read more in the timeline for developers.

You can start compatibility testing today on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test the user flows. Make sure to review the behavior changes for areas where your app might be affected. There’s no need to change the app’s targetSdkVersion at this time, although we recommend evaluating the work since many changes apply once your app is targeting the new API level.

Get started with Android 11

Today we're pushing a Developer Preview 4 with the latest bug fixes, API tweaks, and features to try in your apps. It’s available by manual download and flash for Pixel 2, 3, 3a, or 4 devices, and if you’re already running a Developer Preview build, you’ll get an over-the-air (OTA) update to today’s release.

For complete information on Android 11, visit the Android 11 developer site, and please continue to let us know what you think!

May 6th 2020, 1:14 pm

High refresh rate rendering on Android

Android Developers Blog

Posted by Ady Abraham, Software Engineer

For a long time, phones have had a display that refreshes at 60Hz. Application and game developers could just assume that the refresh rate is 60Hz, frame deadline is 16.6ms, and things would just work. This is no longer the case. New flagship devices are built with higher refresh rate displays, providing smoother animations, lower latency, and an overall nicer user experience. There are also devices that support multiple refresh rates, such as the Pixel 4, which supports both 60Hz and 90Hz.

A 60Hz display refreshes the display content every 16.6ms. This means that an image will be shown for the duration of a multiple of 16.6ms (16.6ms, 33.3ms, 50ms, etc.). A display that supports multiple refresh rates, provides more options to render at different speeds without jitter. For example, a game that cannot sustain 60fps rendering must drop all the way to 30fps on a 60Hz display to remain smooth and stutter free (since the display is limited to present images at a multiple of 16.6ms, the next framerate available is a frame every 33.3ms or 30fps). On a 90Hz device, the same game can drop to 45fps (22.2ms for each frame), providing a much smoother user experience. A device that supports 90Hz and 120Hz can smoothly present content at 120, 90, 60 (120/2), 45(90/2), 40(120/3), 30(90/3), 24(120/5), etc. frames per second.

Rendering at high rates

The higher the rendering rate, the harder it is to sustain that frame rate, simply because there is less time available for the same amount of work. To render at 90Hz, applications only have 11.1ms to produce a frame as opposed to 16.6ms at 60Hz.

To demonstrate that, let’s take a look at the Android UI rendering pipeline. We can break frame rendering into roughly five pipeline stages:

  1. Application’s UI thread processes input events, calls app’s callbacks, and updates the View hierarchy’s list of recorded drawing commands
  2. Application’s RenderThread issues the recorded commands to the GPU
  3. GPU draws the frame
  4. SurfaceFlinger, which is the system service in charge of displaying the different application windows on the screen, composes the screen and submits the frame to the display HAL
  5. Display presents the frame

The entire pipeline is controlled by the Android Choreographer. The Choreographer is based on the display vertical synchronization (vsync) events, which indicate the time the display starts to scanout the image and update the display pixels. The Choreographer is based on the vsync events but has different wakeup offsets for the application and for SurfaceFlinger. The diagram below illustrates the pipeline on a Pixel 4 device running at 60Hz, where the application is woken up 2ms after the vsync event and SurfaceFlinger is woken up 6ms after the vsync event. This gives 20ms for an app to produce a frame, and 10ms for SurfaceFlinger to compose the screen.

When running at 90Hz, the application is still woken up 2ms after the vsync event. However, SurfaceFlinger is woken up 1ms after the vsync event to have the same 10ms for composing the screen. The app, on the other hand, has just 10ms to render a frame, which is very short.

To mitigate that, the UI subsystem in Android is using “render ahead” (which delays a frame presentation while starting it at the same time) to deepen the pipeline and postpone frame presentation by one vsync. This gives the app 21ms to produce a frame, while keeping the throughput at 90Hz.

Some applications, including most games, have their own custom rendering pipelines. These pipelines might have more or fewer stages, depending on what they are trying to accomplish. In general, as the pipeline becomes deeper, more stages could be performed in parallel, which increases the overall throughput. On the other hand, this can increase the latency of a single frame (the latency will be number_of_pipeline_stages x longest_pipeline_stage). This tradeoff needs to be considered carefully.

Taking advantage of multiple refresh rates

As mentioned above, multiple refresh rates allow a broader range of available rendering rates to be used. This is especially useful for games which can control their rendering speed, and for video players which need to present content at a given rate. For example, to play a 24fps video on a 60Hz display, a 3:2 pulldown algorithm needs to be used, which creates jitter. However, if the device has a display that can present 24fps content natively (24/48/72/120Hz), it will eliminate the need for pulldown and the jitter associated with it.

The refresh rate that the device operates at is controlled by the Android platform. Applications and games can influence the refresh rate via various methods (explained below), but the ultimate decision is made by the platform. This is crucial when more than one app is present on the screen and the platform needs to satisfy all of them. A good example is a 24fps video player. 24Hz might be great for video playback, but it’s awful for responsive UI. A notification animating at only 24Hz feels janky. In situations like this, the platform will set the refresh rate to ensure that the content on the screen looks good.

For this reason, applications may need to know the current device refresh rate. This can be done in the following ways:

Applications can influence the device refresh rate by setting a frame rate on their Window or Surface. This is a new capability introduced in Android 11 and allows the platform to know the rendering intentions of the calling application. Applications can call one of the following methods:

Please refer to the frame rate guide on how to use these APIs.

The system will choose the most appropriate refresh rate based on the frame rate programmed on the Window or Surface.

On Older Android versions (before Android 11) where the setFrameRate API doesn’t exist, applications can still influence the refresh rate by directly setting WindowManager.LayoutParams.preferredDisplayModeId to one of the available modes from Display.getSupportedModes. This approach is discouraged starting with Android 11 since the platform doesn’t know the rendering intention of the app. For example, if a device supports 48Hz, 60Hz and 120Hz and there are two applications present on the screen that call setFrameRate(60, …) and setFrameRate(24, …) respectively, the platform can choose 120Hz and make both applications happy. On the other hand, if those applications used preferredDisplayModeId they would probably set the mode to 60Hz and 48Hz respectively, leaving the platform with no option to set 120Hz. The platform will choose either 60Hz or 48Hz, making one app unhappy.


Refresh rate is not always 60Hz - don’t assume 60Hz and don’t hardcode assumptions based on that historical artifact.

Refresh rate is not always constant - if you care about the refresh rate, you need to register a callback to find out when the refresh rate changes and update your internal data accordingly.

If you are not using the Android UI toolkit and have your own custom renderer, consider changing your rendering pipeline according to the current refresh rate. Deepening the pipeline can be done by setting a presentation timestamp using eglPresentationTimeANDROID on OpenGL or VkPresentTimesInfoGOOGLE on Vulkan. Setting a presentation timestamp indicates to SurfaceFlinger when to present the image. If it is set to a few frames in the future, it will deepen the pipeline by the number of frames it is set to. The Android UI in the example above is setting the present time to frameTimeNanos1 + 2 * vsyncPeriod2

Tell the platform your rendering intentions using the setFrameRate API. The platform will match different requests by selecting the appropriate refresh rate.

Use preferredDisplayModeId only when necessary, either when setFrameRate API is not available or when you need to use a very specific mode.

Lastly, familiarize yourself with the Android Frame Pacing library. This library handles proper frame pacing for your game and uses the methods described above to handle multiple refresh rates.


  1. frameTimeNanos received from Choreographer 

  2. vsyncPeriod received from Display.getRefreshRate()  

April 27th 2020, 2:46 pm

Android 11: Developer Preview 3

Android Developers Blog

Posted by Dave Burke, VP of Engineering

Our teams, like all of you, continue getting used to a new normal. For many of us, that means working from living rooms, kitchens, backyards and bedrooms. So, from our homes to yours, we wanted to take a moment to share our most recent developer preview for Android 11. This update includes bug fixes and a set of productivity improvements for developers.

You can see some of the highlights below, and visit the Android 11 developer site for details on all of the new features in Android 11. Today’s release is for developers and not intended for daily or consumer use, so we’re making it available by manual download and flash for Pixel 2, 3, 3a, or 4 devices. If you’re already running a Developer Preview build, you’ll receive an over-the-air (OTA) update to today’s release soon. As always, let us know what you think, and thank you for the helpful feedback you’ve shared so far.

What’s in Developer Preview 3

In today’s release there are a number of new features and changes for you to try, as well as the latest updates to existing features, APIs, and tools. Here are just a few:

App exit reasons updates - Apps can exit for a variety of reasons, from crash to system kill or user action. Across the many device types, memory configurations, and user scenarios that your app runs in, it’s important to understand why the app exited and what the state was at the time. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits. In DP3 we’ve updated the APIs based on your input, so please take a look. If you haven’t had a chance to check out this new API yet, we recommend giving it a try and please let us know what you think here.

GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible. For details, see the documentation.

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. To use this new developer tool, first sign your APK with the new APK signature scheme v4 format, and then install your APK with the updated ADB command line tool found in the Android 11 Preview SDK. This new feature is part of a broad suite of new tools we're investing in to make you more productive in building games on Android. Note that in DP3, ADB Incremental only works with Pixel 4 / 4XL devices due to a required file system change at the device level. All new devices launching with Android 11 will include this change and will support ADB Incremental. Learn more here.

Wireless Debugging - In Android 11, we’ve completely revamped the debugging experience using ADB over a Wi-Fi connection. With limited USB ports on laptops, and a myriad of USB cables & connections to manage, the Wireless Debugging feature in Android 11 can help you be more productive. Unlike the existing TCP/IP debugging workflow, Wireless Debugging on Android 11 does not need a cable to set up, remembers connections over time, and can utilize the full speed of the latest Wi-Fi standards. In DP3, use the pairing code workflow to get started with this developer feature. We plan to add an integrated experience for Wireless Debugging with QR code scanning in a future Android Studio release, but we want to get your early feedback on the command line tool offered in Android 11 DP3. For details, see the documentation.

Try the new wireless debugging feature in Developer Options.

Data access auditing updates - In DP3 we renamed several of the APIs for this Android 11 developer feature. If you are already using the APIs, make sure to check out the changes. If you aren’t familiar, 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. Give data access auditing a try in your apps - you can read more here or see an example in our sample app. Let us know your feedback here.

For details on everything that’s changed in Developer Preview 3, take a look at the DP3 diff report and read the release notes for details about known issues.

App compatibility

With Developer Preview 3, we’re well on the way to finalizing features and APIs and shifting our focus to polish and performance. If you haven’t already, now is the time to begin testing your app for compatibility and identify any work you’ll need to do. We recommend releasing a compatible app update by Android 11 Beta to get feedback from the larger group of Android Beta users.

When we reach Platform Stability, system behaviors, non-SDK greylists, and APIs are finalized. At that time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. You can read more in the timeline for developers.

You can start compatibility testing today on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test the user flows. Make sure to review the behavior changes for areas where your app might be affected. There’s no need to change the app’s targetSdkVersion at this time, although we recommend evaluating the work since many changes apply once your app is targeting the new API level.

To help you test, we’ve made many of the targetSdk changes toggleable, so you can force-enable or disable them individually from Developer options or ADB. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.

App compatibility toggles in Developer Options.

Get started with Android 11

Developer Preview 3 has everything you need to try the latest Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the latest Android 11 Preview SDK and tools, see the set up guide for details.

As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.

For complete information on Android 11, visit the Android 11 developer site.

April 23rd 2020, 1:19 pm

Developer tools to debug WebView in Beta

Android Developers Blog

Posted by Nate Fischer, Software Engineer, WebView team

Since 2014, Android WebView has paved the way as an updateable system component, delivering stability and performance improvements, modern web platform features, and security patches to Android apps and users. However, updates can be a double edged sword: as much as we strive for stability and backward compatibility, new crashes and breaking changes occasionally slip through. To solve these issues faster, today we're announcing WebView DevTools, a new set of on-device debugging tools to diagnose WebView-caused crashes and misbehaving web platform features.

For your convenience, WebView DevTools comes included as part of WebView itself. The easiest way to launch WebView Devtools is to try out WebView Beta. WebView's beta program is a way for app developers to get WebView several weeks before they reach users, for extra lead time to report compatibility bugs to our team. Starting with today's release (M83), WebView Beta includes a launcher icon for WebView DevTools. Just look for the blue and gray WebView gear icon to get started debugging WebView in your app.

Inspecting a crash in WebView DevTools.

No software is bug-free and loading web content can be challenging, so it's no surprise WebView crashes are a pain point for apps. Worse yet, these crashes are difficult to debug because WebView's Java and C++ stack traces are obfuscated (to minimize APK size for Android users). To help make these crashes more actionable, we're exposing first-class access to WebView's built-in crash reporter. Just open WebView DevTools, tap on "crashes," and you'll see a list of recent WebView-caused crashes from apps on your device. You can use this tool to see if the crash report has been uploaded to our servers, force-upload it if necessary, and subsequently file a bug. This ensures our team has all the information we need to swiftly resolve these crashes and ensure a smoother user experience in your app.

Using flags to highlight WebView usage in Android apps.

However, not all bugs cause crashes. A handful of past WebView releases have broken Android apps due to behavior changes caused by new features. While our team's policy is to roll back features which break compatibility, the chromium team launches several features for WebView in each release, and we often need time to identify the offending feature. WebView DevTools can help here too. Inspired by Google Chrome's chrome://flags tool, which enables compatibility testing with web platform features, we're offering app developers similar controls for experimental features. To get started, open WebView DevTools, tap on "flags," enable or disable any available features, then kill and restart the WebView-based app you're testing. Using WebView DevTools will help us work together to pin down the culprit so we can roll it back. We've also included flags for features slated for upcoming releases, so you can test compatibility even earlier by enabling these features on your test device.

We hope you find WebView DevTools helpful for reporting crashes and testing against new WebView features. Install WebView Beta today to get started with WebView DevTools, and check out the user guide for more tips and tricks.

April 17th 2020, 1:38 pm

Building user trust through more transparent subscriptions

Android Developers Blog

Posted by Angela Ying, Product Manager, Google Play

For many developers, subscriptions are an important part of your business. Google Play has continued to support the growth of subscription offerings through developer tools such as new insights in the Google Play Console, and an improved user experience, including the subscriptions center, where users can easily manage all of their subscriptions. Part of improving the subscription user experience comes from fostering a trustworthy platform for subscribers; making sure they feel fully informed when they purchase in-app subscriptions.

To continue to build this trust, we announced an updated subscriptions policy today, as part of a broader policy update to build user trust and enhance user safety across Google Play. This new policy requires you to be transparent about your subscription offering, to ensure every user evaluating your service has an informed choice.

When users lose trust in your app due to unclear subscription offers, they unsubscribe and often leave negative reviews, ultimately hurting your business. On the other hand, a clear and compelling offer gives users all the information they need to make a decision, increasing their trust in your service and hopefully encouraging them to stick around for a long time.

Complying with our subscriptions policy

The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation. You can read the full policy and see examples of best practices and common violations in the Policy Center, but the most important thing is to make sure you are clear about your subscription offering within your app. Consider the following best practices:

Be explicit about your subscription terms, such as:

If you offer free trials and introductory offers, clearly and accurately tell users:

Ensure your app clearly discloses how a subscriber can cancel and/or manage a subscription.

You have until June 16, 2020 to bring your existing apps into compliance with this policy.

A better user experience without additional development work for you

In conjunction with these policy updates, we’ve made several platform-level product changes to help increase user trust and build user confidence in subscribing.

We believe that although these changes may lead to fewer conversions or more subscription cancelations in the short term, they will also result in higher quality, more committed subscribers with lower refund and chargeback rates. Overall, this should result in a more stable recurring revenue.

Resources to help

We want to help you do the right thing for your subscribers, so we’ve created this checklist, video and training in Google Play’s Academy for App Success to use as a reference when you’re making any necessary app updates.

Thank you for continuing to partner with us to make Google Play a trustworthy platform for you and your users. Not only can we work together to create great experiences for users, but we can continue to grow subscription businesses as well.

How useful did you find this blog post?

April 16th 2020, 1:13 pm

Google Play Trust and Safety Update

Android Developers Blog

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

As part of our continuing efforts to enhance user trust and safety across Google Play, we regularly examine our policies to ensure a positive experience for developers and users. Today we are announcing policy updates that give users more control over their data, tighten subscription policies, and help prevent deceptive apps and media getting onto the Play Store.

We understand that many of you are adjusting to or actively supporting efforts in response to the current unprecedented circumstances. We want to assure you that we are mindful and supportive of those efforts, and have taken steps to minimize the potential short-term impact of these changes. You can read more about that in this blog post which shares resources for developers navigating the current context. We also wanted to briefly highlight two of the more impactful policies announced today.

More transparent subscription offers

Subscriptions continue to grow in popularity on Play; however, we hear user feedback that it isn’t always clear what you are signing up for. The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation.

This blog post goes into more detail about the changes and gives examples of best practices and common violations. Developers have until June 16th to make any changes to their offer page.

Limiting unnecessary location access

Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Android users have always needed to grant explicit permission to any app that wants access to their location data. In Android 11, we’re granting additional user controls with the ability to grant a temporary “one-time” permission.

In February, we announced we would require that developers get approval if they want to access background location in their app. This ensures that only apps that really need access for core functionality can ask users for permission. This policy is now live and we encourage all developers who access location to view it.

We realize complying with certain aspects of this policy may require work for some developers so we are giving you an extended timeline to make changes. We suggest that you review location best practices and evaluate whether you have appropriate disclosures, and really need background location; however, no action will be taken for new apps until August 2020 or existing apps until November 2020. Additional details can be found in this help center article and we’ll keep you updated if processes or timelines change. Thanks for your continued support in making Google Play a trustworthy and valuable experience for everyone.

How useful did you find this blog post?

April 16th 2020, 1:13 pm

Promoting high-quality, teacher-approved kids content on Google Play

Android Developers Blog

Posted by Michael Watson, Product Manager, Google Play

With more kids spending time at home, parents are looking for ways to find apps and games for children that are both enriching and entertaining. Today, we’re announcing an update that will make it easier for parents to find this content on the Google Play Store. We’re launching the Teacher Approved program, an editorial program to highlight high-quality, teacher-approved apps for kids. This is part of our ongoing effort to create a safer Google Play for kids.

What’s changing

We consulted with academic experts to develop a framework for rating apps for kids. Specially trained teachers across the US will rate apps for kids based on this framework, evaluating things like:

  • Design quality
  • Appeal to children
  • Enrichment potential
  • Ads & in-app purchases
  • Age appropriateness

Teacher-approved apps will:

  • Be eligible to appear in the new Kids section on Google Play
  • Be eligible for featuring in banners or collections on Google Play
  • Display the new "Teacher approved" badge
  • Display information about what teachers found valuable on their app details page

The Google Play store featuring teacher-approved apps

As a result of these changes, we are removing the Family star badge and the Family section on Google Play. All apps that were in the Family section will continue to be discoverable on the Play Store and appear in search results. Note that this change will have no effect on Family Library.

Who’s eligible

Apps need to meet the requirements of the Designed for Families program before they’re eligible to be reviewed by teachers. All Designed for Families apps are automatically placed in the teacher review queue.

We made the decision to launch the Teacher Approved program a little early given the vast number of kids at home now. Teachers are working hard to review apps as quickly as possible, but it will take time to review all apps, so we appreciate your patience. Our initial launch will be limited to the US, to be followed by a global rollout in the coming months.

To help developers better understand what the teachers are looking for, we published a new learning path on Google Play’s Academy for App Success, including findings from Google Play’s research into technology usage by parents and kids.

Rewarding for all

We’re committed to improving the ecosystem and partnering with our developers. We look forward to continuing to work with you to create the best possible experience for children and families on Google Play. For more information on the Teacher Approved program, check out our FAQs.

How useful did you find this blog post?

April 15th 2020, 2:12 pm

Google Play updates and information: Resources for developers

Android Developers Blog

Posted by Sam Tolomei, Business Development Manager, Google Play

In these unprecedented times, Google Play's mission to support you, ensure your businesses continue to operate well, and help users get the content they need is more important than ever. With a surge in need for information, communications tools, entertainment, and more, we are striving to ensure our operations run smoothly, and we need your support.

Below, we’ve pulled together some important information to help you maintain business continuity, as well as best practices to help you stay nimble in the changing landscape.

Extended app review times

Like many of you, we've had to manage work disruptions as a result of changing business conditions. This has led to a temporary slowing down of the app review process, which now may take 7 days or longer. As the situation evolves, we will continue to make sure that the most important updates reach users quickly, which may result in fluctuating review times. Certain critical apps may receive prioritized review and may not experience an extended delay in review time. Please check the Google Play Console for the most up-to-date information and guidance.

At the same time, in order to help ensure we are providing users with accurate and timely information relating to COVID-19, we also are prioritizing the review of apps published, commissioned, or authorized by official government entities and public health organizations.

If you want to control when your app goes live, we recommend timed publishing. Just submit your app for review, and once it’s approved, click “Go live” in the Play Console to instantly publish your app. Note: If you already have a release submitted to the production track that is under review, you will not see the “timed publishing” option.

Store listing guidelines

At Google Play we take our responsibility to provide accurate and relevant information for our users very seriously. For that reason, we are currently only approving apps that reference COVID-19 or related terms in their store listing if the app is published, commissioned, or authorized by an official government entity or public health organization, and the app does not contain any monetization mechanisms such as ads, in-app products, or in-app donations. This includes references in places such as the app title, description, release notes, or screenshots.

Removing inappropriate reviews

With the recent increase in traffic, some apps are seeing a spike in inappropriate one-star reviews from users. If you are receiving reviews that are not related to your app experience, you can flag the review in the Play Console. We’ve expanded our ability to assess and remove inappropriate reviews so we can handle your request as quickly as possible.

Subscriptions support

While subscriptions are a large part of many app business models, two groups are currently seeing the largest impact: 1) those whose core businesses have been adversely affected by COVID-19 (such as live event ticketing), and 2) those who provide a public service with their content or services.

For developers whose business value proposition has been affected, features like deferred billing and subscription pauses can help retain users until after the crisis has passed. For developers who want to offer their content or services like medical, online learning, and wellbeing apps at reduced or no cost, features like price changes and refunds through Google Play Billing are available to help.

Learn more best practices in our Medium post.

How we’re helping the community

Google is also committed to helping our community at large. To help small businesses reconnect with their customers, Google is granting $340 million in ad credits to be used across our Google Ads platforms — learn more here.

Here’s what else we’re doing:

As the situation progresses, we will continue to gather more resources to help you. We’re also taking steps to limit changes and barriers because we know you have enough on your plate right now. Please stay tuned for more information, and thank you for being a part of the Google Play community. If you have any other suggestions about how we can support you during this time, please let us know by tweeting at us at @GooglePlayDev with #AskGooglePlay.

How useful did you find this blog post?

April 6th 2020, 4:41 pm

Meet the finalists of the Google Play Indie Games Festival

Android Developers Blog

Posted by Leticia Lago, Head of Developer Marketing, EMEA

At the start of this year we opened submissions for 2020’s Google Play Indie Games Festival - an international competition celebrating incredible indie games from Europe, Japan and South Korea.

We’ve received hundreds of fantastic submissions that showcase the technical abilities and groundbreaking creativity of independent studios. Many thanks to everyone who submitted their game. After some hard choices and late nights, we’re happy to announce our 20 finalists in each region.

Please check out the games below (in alphabetical order); each one is a true work of art. They will be receiving promotions and prizes to help them grow their business. They’ll also be competing in the Finals for the top prizes.

While this is a happy announcement, we must also inform you that we will be unable to hold the Finals as planned on April 25 in Poland, Japan and South Korea due to the COVID-19 situation. We will be postponing the events until further notice, as the health and safety of finalists, jury members, players and others involved is our top priority. Please stay tuned for further announcements.


60 Parsecs! by Robot Gentleman

Aisle Trial by Jake Matthews-Belcher

Alien Escape by Korion Games

Alt-Frequencies by Accidental Queens

Bad North by Rawfury

Bounce that Bird! by Affinity Project

Cessabit: a Stress Relief Game by Tepes Ovidiu

Color Spots by US Apps

Cookies Must Die by Rebel Twins

Demons Never Lie by Maika Hernandez

Doors: Awakening by Big Loop

Faraway: Galactic Escape by Pine Studio

inbento by Afterburn

My Diggy Dog 2 by King Bird Games

The White Door by Rusty Lake

Tiny Tomb: Dungeon Explorer by Tinycorp

Traffix by Infinity Games

Tricky Castle by Team Tricky

Unhatched by Filip Loster

Void Tyrant by Quite Fresh


Amayadori by CHARON・Yanase

CUBE GARDEN by Fukudanuki

GIGAFALL by Shiki Game Studio

GummyShooter by simatten

Home Fighter by hap Inc.

Matsuro Palette by SleepingMuseum


Mocha - Dagsaw Puzzle - by Kotoriyama, Inc.

MonsterTrader by Mitsuhiro Okada

Overturn by Katsu Matsuda

Shiritori - The Word Chain Game by Baton

Snowman Story by Odencat


TAP! DIG! MY MUSEUM! by oridio Inc.

Teiji Taisha Online by toru sugitani

The Final Taxi by Zxima.LLC

Uncrowned by NESTOPI Inc.

Wasurenaide, otona ni natte mo by GAGEX Co.,Ltd.

World for Two by Seventh rank

Zelle by Odencat Fuming

South Korea

Castle Defense Online by BlackHammer


DiceEmpire by Banjiha Games

Domino City by Bad Beans

DUST by I-eye studio

Electroad by Night Owl Studio

Extreme football by 9M Interactive

From Earth by Kentauros Entertainment

Great Sword - Stickman Action RPG by Olivecrow

Heroes Restaurant by Team Tapas

Little Boy by 39Studio

Magic Survival by LEME

Mayday Memory by

Petrider by Ddookdak studio

Project Mars by Moontm

QV by Izzle

Sand Shark : The Boy and The Sea by GABANGMAN STUDIO

Staroid : Brick breaker shooter by Spring Games

Sword Master Story by CodeCAT

Undestroyed by Keymaker games

The competition was open to indie developers from the following European countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).

How useful did you find this blog post?

March 30th 2020, 12:50 pm

Run ARM apps on the Android Emulator

Android Developers Blog

Posted by Michael Hazard

As part of the Android 11 developer preview we’ve released Android 11 system images, which are capable of executing ARM binaries with significantly improved performance. Previously, developers who were dependent on ARM libraries and could not build an x86 variant of their app either had to use system images with full ARM emulation, which are much slower than x86 system images when run on x86-based computers, or resort to physical devices. The new Android 11 system images are capable of translating ARM instructions to x86 without impacting the entire system. This allows the execution of ARM binaries for testing without the performance overhead of full ARM emulation.

The new Android 11 (Google APIs) x86 system image supports ARM ABIs, while the older Android Oreo system image does not


The significance of this may require a bit of context, especially if you build apps exclusively with Kotlin or the Java programming language. Unlike Kotlin or the Java programming language, both of which execute on the Android Runtime (ART), any C++ in your Android app compiles directly into machine instructions. This means that it needs to be compiled differently based on the architecture of the target device. Mobile phones tend to have ARM processors; consequently, many C++ dependencies you might add to your app, like a camera barcode scanner library, are only compatible with ARM processors. This is a problem if you develop on a computer with an x86-based processor, as it would prevent you from running your app.

Previously, if you wanted to get around this limitation and execute an app built for ARM on your x86 machine, you would have had to use an emulator system image with full ARM emulation. Due to the overhead of translating an entire system’s worth of ARM instructions to x86, emulator system images with full ARM emulation tend to run much slower than x86-based system images when run on x86 host machines. Additionally, emulator system images with full ARM emulation cannot take advantage of the hardware acceleration and CPU virtualization technologies provided by x86 processors.

The new ARM-compatible Android 11 system images allow the entire system to run x86 natively and take advantage of virtualization technologies as usual. When an app’s process requires an ARM binary, the binary is translated to x86 within that process exclusively. This allows the rest of the process to continue executing in x86, including the Android Runtime (ART), and other performance-critical libraries like libGLES and libvulkan. In addition to this, the translator avoids expensive memory access instrumentation and the associated performance hit by avoiding the execution of low-level hardware-specific libraries. These new emulator system images can be used both locally and on your own continuous integration infrastructure. This is possible thanks to collaboration with ARM Limited.

Going Forward

If you have previously chosen physical devices over the emulator due to the lack of performant ARM support, try out the Android 11 system images, which are now available alongside the Android 11 Developer Preview. These system images can be downloaded in Android Studio via either the SDK Manager or the Android Virtual Device Manager.

Using the Android Virtual Device Manager to create an AVD that runs Android 11

Once you get your app running on the emulator, consider adapting it for Chrome OS. Chrome OS also supports the execution of Android apps built for ARM on x86 laptops. Building for Chrome OS provides access to a substantial ecosystem of larger screen devices, allowing your application to reach even more users globally.

This technology should enable more developers to test with the Android Emulator. That said, we still recommend that developers publish both x86 and ARM ABI variants of their apps to achieve the best physical device performance and reach as many users as possible. Going forward, we plan to roll this technology out across a wider variety of API levels and ensure that it supports testing all use cases that a physical device would. Given that this is a new technology, please let us know of any problems via our Issue Tracker.

Note that the ARM to x86 translation technology enables the execution of intellectual property owned by Arm Limited. It will only be available on Google APIs and Play Store system images, and can only be used for application development and debug purposes on x86 desktop, laptop, customer on-premises servers, and customer-procured cloud-based environments. The technology should not be used in the provision of commercial hosted services.

Java is a registered trademark of Oracle and/or its affiliates.

March 26th 2020, 1:55 pm

Google for Games Developer Summit March 2020

Android Developers Blog

Posted by Greg Hartrell, Head of Product Management, Games on Android & Google Play

While we're sorry we didn't get to see you all in person at GDC, we hope you are all staying healthy and safe. As many of us look to press on with work as much as possible, we’d like to share with you what our teams have been working on at the digital Google for Games Developer Summit. We couldn’t be happier with the continued growth of the vibrant Android gaming ecosystem. In fact, Android remains the world's most popular mobile platform with more than 2.5 billion monthly active devices and great news for game developers, we’re seeing more than 1.4 trillion minutes played per month in your games on Google Play. It’s important to us that our platforms are highly useful to every kind of game developer, so our payment system helps games monetize in more than 65 countries. Moreover, we offer our users more than 275 local forms of payment, including more than 180 carrier billing options, with gift cards sold in over 900 thousand unique retail locations worldwide.
Across Android and Google Play, our mission is to deliver the best platform to build, discover, and experience games. Specifically, we’re working on ways to help you increase the reach of your games and manage the fragmentation of the Android ecosystem. We’re also focused on helping you access a wider player base, once you’ve made a great game and are ready to get it out there. Last year, we shared that we’re investing heavily in our games efforts to address your challenges in these areas, and now we are excited to share several new tools and services built specifically with game developers in mind.

Catch up on everything shared at

New Android tools for mobile game development

A major area of investment for us has been making it easier for developers to build and optimize games for Android. Here’s a round-up of several new tools we’re releasing:
  • Android Studio Profilers: We’ve overhauled our Android Studio System Trace profiler to allow you to inspect and visualize in fine detail how your code is being executed. We also added native memory profiling capabilities so you can see how your game is allocating memory and find memory leaks. Download Android Studio 4.1 Canary and watch the session.
  • Android Game Development Extension for Visual Studio: We’re introducing a new tool to make it easy to add Android support for your cross-platform games. This integrates easily with existing Visual Studio-based workflows so now you can conveniently generate APKs, deploy to Android devices or an emulator, and debug your Android game from within Visual Studio. Apply for the developer preview and watch the session.
  • Android GPU Inspector: Our new Android GPU Inspector enables you to look deeply into an Android GPU and see detailed information about your game’s render stages and GPU counters. Now graphics engineers are empowered with information and insights to optimize their game for better frame rates and more battery life. Apply for the developer preview and watch the session.
  • Game Package Registry for Unity by Google: Our new package registry consolidates various Google APIs, starting with Google Play Billing, Android App Bundles, Play Asset Delivery, Play Instant, and Firebase for Games, all in one place. Learn more and watch the session.
  • Crytek announces Android support: CRYENGINE is known as a high performance game engine for PCs and game consoles and will be adding a full Android pipeline to their engine this summer. Learn more.

New ways to reach more devices & users

We’ve been working to help developers scale their reach to a growing player-base across the Android ecosystem. Today, we’re introducing a few new tools to help your development process and provide greater insights into your game’s performance.
  • Google Play Asset Delivery: Introducing a new set of delivery features for games services, building on our App Bundle infrastructure to give you free, dynamic delivery of the right game assets to the right devices at the right time. All of this allows players to get into your game faster while assets are being downloaded, while you cut the costs of hosting and delivering d game resources. Learn more and watch the session.
  • Android vitals native crash symbolication: Now you can debug your native crashes more easily with support for native symbols in Play Console. Simply upload your native debug symbols to get the benefits in Android Vitals. Apply for the open beta and watch the session.
  • Android vitals performance insights with Android Performance Tuner: We’re making it possible to optimize your frame rate and fidelity across many devices at scale with new performance insights in Android vitals. For those in our developer preview, you can unlock this by integrating the new Android Performance Tuner into your game: a new library in the Android Game SDK. Apply for the developer preview and watch the session.
  • Play Billing Library 2 for Unity developers: Game developers using Unity can now access all of Play Billing Library 2's features, such as allowing users to pay with cash and surfacing IAPs outside of the game. This is the best way for Unity developers to prepare for Play’s Billing Library version requirements in 2021. Learn more.

New ways to reach more devices and win go-to-market

The Google Play store is shifting to be more gameplay centric by showing more visuals that demonstrate gameplay and a new system of tags to help users learn more about specific game traits and aid in exploration. Learn how you can ensure your game is of high-quality and leverage various features and new services to help you succeed in your go-to-market activities.
  • Emphasis on quality: We continue to emphasize high quality gaming experiences across Google Play, to encourage immersive gameplay with strong technical performance and being free of crashes. Learn more.
  • Pre-registration: Hundreds-of-millions of players use pre-registration campaigns on Google Play each year, making it an effective way to expand the reach on launch. We’ll soon be rolling out day 1 auto-installation for all pre-registration games, to help you build early consumer awareness and capture pre-launch demand.
  • Play Pass: Late last year we launched Play Pass in the US market as a subscription service providing users with access to hundreds of great apps and games on Google Play, completely free of ads and in-app purchases. Learn more and express interest.
Thanks for your support in continuing to build incredible games. Make sure to try some of the new tools and services we just released and catch the full playlist of mobile developer sessions. If you’re interested in sharing feedback to help shape the development of cutting edge features, apply to join our developer preview programs from Android and Google Play. You can also learn about all of the offerings we have to help game developers building on Android at
How useful did you find this blog post?

March 23rd 2020, 11:33 am

Android 11: Developer Preview 2

Android Developers Blog

Posted by Dave Burke, VP of Engineering

It’s been a difficult few months for many around the world. The Android team at Google is a global one, and we, like many of you, are learning how to adapt to these extraordinary times. We want to thank you, our developer community, who have given us valuable feedback on Android 11 amidst these circumstances. We hope you, your families and colleagues are all staying well.

Just as many of you are trying to press on with work where possible, we wanted to share the next milestone release of Android 11 for you to try. It’s still an early build, but you can start to see how the OS is enabling new experiences in this release, from seamless 5G connectivity to wrapping your UI around the latest screens, to a smarter keyboard and faster messaging experience.

There’s a lot to check out in Developer Preview 2 - read on for a few highlights and visit the Android 11 developer site for details. Today’s release is for developers only and not intended for daily or consumer use, so we’re making it available by manual download and flash only for Pixel 2, 3, 3a, or 4 devices. To make flashing a bit easier, you can optionally get today’s release from the Android Flash Tool. For those already running Developer Preview 1 or 1.1, we’re also offering an over-the-air (OTA) update to today’s release.

Let us know what you think, and thank you to everyone who has shared such great feedback so far.

New experiences

5G state API - DP2 adds a 5G state API to let you quickly check whether the user is currently on a 5G New Radio or Non-Standalone network. You can use this to highlight your app’s 5G experience or branding when the user is connected. You can use this API together with the 5G dynamic meteredness API and bandwidth estimator API, as well as existing connectivity APIs, to take advantage of 5G’s improved speeds and latency.

Hinge angle for foldables - A top request for foldable devices has been an API to get the angle of the device screen surfaces. Android 11 now supports a hinge angle sensor that lets apps query directly or through a new AndroidX API for the precise hinge angle, to create adaptive experiences for foldables.

Call screening service improvements - To help users manage robocalls, we’re adding new APIs to let call-screening apps do more to help users. In addition to verifying an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of its call details, call-screening apps 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. We’ll have more to share on this soon.

New ops and controls in Neural Networks API - Activation functions control the output of nodes within a neural network. At Google AI, we discovered a swish activation function allowing for faster training time and higher accuracy across a wide variety of tasks. In Android 11, we’re adding a computationally efficient version of this function, the hard-swish op. This is key to accelerating next-generation on-device vision models such as MobileNetV3 which forms the base model for many transfer learning use cases. Another major addition is the Control ops enabling more advanced machine learning models that support branching and loops. Finally, we’ve also added new execution controls to help you minimize latency for common use cases: Asynchronous Command Queue APIs reduce the overhead when running small chained models. See the NDK sample code for examples using these new APIs.

Privacy and security

We’re adding several more features to help keep users secure and increase transparency and control. Give these a try with your apps right away and let us know what you think.

Foreground service types for camera and microphone - in Android 10 we introduced the manifest attribute foregroundServiceType as a way to help ensure more accountability for specific use-cases. Initially apps could choose from “location” and several others. Now in Android 11 we’re adding two new types - “camera” and “microphone”. If your app wants to access camera or mic data from a foreground service, you need to add the foregroundServiceType value to your manifest.

Scoped storage updates- We’re continuing to iterate on our work to better protect app and user data on external storage. In this release we’ve made further improvements and changes, such as support to migrate files from the legacy model to the new scoped storage model, and better management of cached files. Read more here and watch for more enhancements in subsequent updates.

Read more about these and other Android 11 privacy features here.

Polish and quality

Synchronized IME transitions - A new set of APIs let you synchronize your app’s content with the IME (input method editor, aka soft 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 insets animation listener notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, apps can take control of the IME and system bar transitions through the WindowInsetsAnimationController API. For example, app-driven IME experiences let apps control the IME in response to overscrolling the app UI. Give these new IME transitions a try and let us know what other transitions are important to you.

Synchronized IME transition through insets animation listener.

App-driven IME experience through WindowInsetsAnimationController.

Variable refresh rate - Apps and games can now set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some devices 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.

Resume on reboot - Android 11 improves the experience of scheduled overnight over-the-air software updates. Like in previous versions of Android, the device must still reboot to apply the OTA update, but with resume on reboot, apps are now able to access Credential Encrypted (CE) storage after the OTA reboot, without the user unlocking the device. This means apps can resume normal function and receive messages right away - important since OTA updates can be scheduled overnight while the device might be unattended. Apps can still support Direct Boot to access Device Encrypted (DE) immediately after all types of reboot. Give resume on reboot a try by tapping “Restart after 2AM” with your next Developer Preview OTA update, more details here.

Camera support in Emulator - The Android emulator now supports front and back emulated camera devices. The back camera supports Camera2 API HW Level 3 (includes YUV reprocessing, RAW capture). It’s a fully CTS-compliant LEVEL_3 device that you can use to test advanced features like ZSL and RAW/DNG support. The front camera supports FULL level with logical camera support (one logical device with two underlying physical devices). This camera emphasizes logical camera support, and the physical camera devices include narrow and wide field of view cameras. With this emulated camera support, you can build and test with any of the camera features added in Android 11. More details coming soon.

App compatibility

We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, tools, and release milestones to minimize the impact of platform updates and make them easier for developers.

With Developer Preview 2, we’re well into the release and getting closer to Beta. so now is the time to start your compatibility testing and identify any work you’ll need to do. We recommend doing the work early, so you can release a compatible update by Android 11 Beta 1. This lets you get feedback from the larger group of Android 11 Beta users.

When we reach Platform Stability, system behaviors, non-SDK greylists, and APIs are finalized. At this time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. More on the timeline for developers is here.

You can start compatibility testing on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test all of the user flows. There’s no need to change the app’s targetSdkVersion at this time. Make sure to review the behavior changes that could affect your app and test for impacts.

To help you with testing, we’ve made many of the breaking changes toggleable, so you can force-enable or disable them individually from Developer options or adb. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.

App compatibility toggles in Developer Options.

Get started with Android 11

Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the Android 11 Preview SDK and tools, see the set up guide for details.

As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.

March 18th 2020, 1:07 pm

Handling Nullability in Android 11 and Beyond

Android Developers Blog

Posted by David Winer, Kotlin Product Manager

Last May at Google I/O, we announced that Android was going Kotlin first, and now over 60% of the top 1000 Android apps use Kotlin. One feature we love about Kotlin is that nullability is baked into its type system — when declaring a reference, you say upfront whether it can hold null values. In this post, we’ll look at how the Android 11 SDK does more to expose nullability information in its APIs and show how you can prepare your Kotlin code for it.

How does nullability in Kotlin work?

When writing code in Kotlin, you can use the question mark operator to indicate nullability:


var x: Int = 1
x = null // compilation error

var y: Int? = 1
y = null // okay

This aspect of Kotlin makes your code safer — if you later call a method or try to access a property on a non-null variable like x, you know you’re not risking a null pointer exception. We hear over and over again that this feature of Kotlin gives developers more peace of mind and leads to higher quality apps for end users.

How does nullability work with the Java programming language?

Not all of your (or Android’s) APIs are written in Kotlin. Fortunately, the Kotlin compiler recognizes annotations on Java programming languages methods that indicate whether they produce nullable or non-nullable values. For example:


public @Nullable String getCurrentName() {
   return currentName;

The @Nullable annotation ensures that when using the result of getCurrentName in a Kotlin file, you can’t dereference it without a null check. If you try, Android Studio will notify you of an error, and the Kotlin compiler will throw an error in your build. The opposite is true of @NonNull — it tells the Kotlin compiler to treat the method result as a non-null type, forbidding you from assigning that result to null later in your program.

The Kotlin compiler also recognizes two similar annotations, @RecentlyNullable and @RecentlyNonNull, which are the exact same as @Nullable and @NonNull, only they generate warnings instead of errors1.

Nullability in Android 11

Last month, we released the Android 11 Developer Preview, which allows you to test out the new Android 11 SDK. We upgraded a number of annotations in the SDK from @RecentlyNullable and @RecentlyNonNull to @Nullable and @NonNull (warnings to errors) and continued to annotate the SDK with more @RecentlyNullable and @RecentlyNonNull annotations on methods that didn’t have nullability information before.

What’s next

If you are writing in Kotlin, when upgrading from the Android 10 to the Android 11 SDK, you may notice that there are some new compiler warnings and that previous warnings may have been upgraded to errors. This is intended and a feature of the Kotlin compiler — these warnings tell you that you may be writing code that crashes your app at runtime (a risk you would miss entirely if you weren’t writing in Kotlin). As you encounter these warnings and errors, you can handle them by adding null checks to your code.

As we continue to make headway annotating the Android SDK, we’ll follow this same pattern — @RecentlyNullable and @RecentlyNonNull for one numbered release (e.g., Android 10), and then upgrade to @Nullable and @NonNull in the next release (e.g., Android 11). This practice will give you at least a full release cycle to update your Kotlin code and ensure you’re writing high-quality, robust code.

1. Due to rules regarding handling of annotations in Kotlin, there is currently a small set of cases where the compiler will throw an error for @Nullable references but not for @RecentlyNullable references.

Java is a trademark of Oracle and/or its affiliates.

March 12th 2020, 12:03 pm

Join us for the digital Google for Games Developer Summit

Android Developers Blog

Posted by the Google for Games Team

Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.

Google for Games Developer Summit

The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.

Here are some types of sessions to expect:

Sign up to stay informed at

Support for the game developer community

We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.

We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.

We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.

This article was cross-posted from the Google Developer Blog. Google Play will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Google Play even more powerful for game developers!

March 10th 2020, 2:35 pm

Android Platform Codelab Kickstarts OS Development

Android Developers Blog

Posted by Clay Murphy, Technical Writer

The Android Platform Codelab has been published to take developers from bare metal to a (virtual) device under test in a single page. This document will help new Android operating system engineers quickly learn the tools and processes needed to establish a build environment, sync the repository, build a virtual device image, and load that image onto an Android virtual device (AVD), allowing quick iteration of platform changes.

The codelab walks through:

  1. Environment setup
  2. Downloading of code
  3. Creating a Cuttlefish Android Virtual Device (AVD) image
  4. Building the OS
  5. Using Acloud to set up and render the Cuttlefish AVD
  6. Creating and testing changes
  7. Uploading, reviewing, and reverting those modifications

If you encounter errors during this codelab, please report them using the Site feedback link on the bottom of any page. Send questions to the android-building group.

March 5th 2020, 8:59 pm

Unveiling expert insights in our new podcast series: Apps, Games, & Insights

Android Developers Blog

Posted by Lily Sheringham, Global Marketing, Platforms & Ecosystems

This is a cross-post from The Google Keyword blog.

Today we’re launching the Apps, Games, & Insights podcast series, bringing together insights, stories, and learnings from industry experts, on some of today's hottest topics surrounding mobile, apps and games businesses, and the wider industry.

The series has eight episodes which aim to challenge, provoke thought, and enlighten listeners - from designers and developers, through to product managers and marketers, and those interested in the apps and games industry.

The podcast is hosted by Googlers Tamzin Taylor, who heads up Apps & Games Business Development for Google Play in Western Europe, and Dirk Primbs, who leads the Ecosystem Developer Relations team in EMEA. Together, they have many years of experience working with partners to assist with Android development, mobile, app, game, and business growth. Every week they will be joined by different guests for each of the episodes.

Sneak peek at what’s coming up

Kicking off the series are Judy Chen and Sarah Fuchs from Crowdstar, the developers of Covet Fashion and Design Home. They join us for episode 1 to discuss how to build a long-term games business by taking a holistic approach to the game, its players, and the people who create the game.

Ever wonder if it's worth selling your app or game business, and if so how to approach it? It's not all about pocketing the cash and walking away. For episode 2, game mergers and acquisitions expert Chris Petrovic from Zynga will talk about how acquisition can free developers to focus on what they love: creating great apps and games.

The popularity of subscriptions continues to grow, with developers who used subscriptions earning 4X more in 2018, than in 2016. Holly Ackerman and David Berlin, from the sports streaming platform DAZN, join us for episode 3 to provide some fascinating insights into how they have grown their subscription business in this industry.

Whether you are a startup in search of funding or an established business looking to accelerate your investment, venture capital can often be a good source of funds. In episode 4, venture capital expert Matteo Vallone from Cherry Ventures offers insights into the investment process and how to maximize your appeal to investors.

For episode 5, we have what is possibly one of the biggest topics in mobile and throughout the tech industry: privacy. Bruce Gustafson, CEO of Developers Alliance brings us up to speed on trust and safety, platform value, respecting the user, and ultimately building privacy friendly apps and games.

Successful game developers put players front and center of everything they do. When over 270 million people have played your games, you must be doing something right. Ben Clarke, Senior Global Marketing Director at Jagex, joins us for episode 6 to discuss some of the innovative approaches to player engagement and retention taken in their RuneScape games.

Figuring out how to make your app or game accessible to all can often be a challenge, sometimes both from an organizational and technical perspective. However, many developers have made accessibility a core part of their app development process and company culture. For episode 7, we’re joined by Ceri Lindsay and Rosalind Whittam from the BBC to discover how they address accessibility.

Today, Android is not just about smartphones, Android apps and games can run on a range of devices with larger screens, such as Chromebooks. At the same time, mature mobile game franchises are looking for opportunities beyond mobile. In our final episode 8, we’ll be joined by Maximiliano Rodriguez of Gameloft to talk about the challenge of taking games to big screens and new platforms.

We hope you’ll join us over the next eight weeks to dive deeper and hear what our thought leader guests have to say on each topic.

How to stay tuned in

To listen to our first podcast and find out more about what’s coming, check out our new Apps, Games, & Insights podcast homepage.

Listen to our first episode here, or on Spotify, Apple Podcasts, Google Play Music, Google Podcasts, Deezer, iHeartRadio, and also on LibSyn. Keep an eye out on @GooglePlayDev and @AndroidDev on Twitter where we will be announcing the launch of the new episodes each week.

How useful did you find this blog post?

March 5th 2020, 2:06 pm

Update on Google at GDC 2020

Android Developers Blog

Posted by the Google for Games Team

Last Friday, GDC 2020 organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community.

Every year, we look forward to the Game Developers Conference and surrounding events because it gives our teams a chance to connect with game developers, partners, and friends in the industry.

Although we won’t be connecting in-person this year, we’re still excited to share the latest announcements from Google with everyone through our digital experience. We'll be sharing plans for our digital experience in the coming days.

Thank you to all who keep this community thriving and check back soon at for more details.

March 3rd 2020, 12:13 pm

Data Encryption on Android with Jetpack Security

Android Developers Blog

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples.

The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets.

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection.

Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink.

Key Generation

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object.

Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices.

val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices.

Important options:

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present.

// Custom Advanced Master Key
val advancedSpec = KeyGenParameterSpec.Builder(
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
).apply {
    setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {

val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec)

Unlocking time-bound keys

You must use BiometricPrompt to authorize the device if your key was created with the following options:

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user.

BiometricPrompt code to unlock time-bound keys

// Activity.onCreate

val promptInfo = PromptInfo.Builder()
    .setDescription("Would you like to unlock this key?")

val biometricPrompt = BiometricPrompt(
    this, // Activity

private val authenticationCallback = object : AuthenticationCallback() {
        override fun onAuthenticationSucceeded(
            result: AuthenticationResult
        ) {
            // Unlocked -- do work here.
        override fun onAuthenticationError(
            errorCode: Int, errString: CharSequence
        ) {
            super.onAuthenticationError(errorCode, errString)
            // Handle error.

To use:

Encrypt Files

Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it's not possible to reorder.

val secretFile = File(filesDir, "super_secret")
val encryptedFile = EncryptedFile.Builder(
    .setKeysetAlias("file_key") // optional
    .setKeysetPrefName("secret_shared_prefs") // optional

encryptedFile.openFileOutput().use { outputStream ->
    // Write data to your encrypted file

encryptedFile.openFileInput().use { inputStream ->
    // Read data from your encrypted file

Encrypt SharedPreferences

If your application needs to save Key-value pairs - such as API keys - JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to.

Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups.

).edit {
    // Update secret values

More Resources

FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security.

Happy Encrypting!

February 25th 2020, 6:43 pm

Android Studio 3.6

Android Developers Blog

Posted by Scott Swarthout, Product Manager

We are excited to announce the stable release of Android Studio 3.6 with a targeted set of features addressing quality in primarily code editing and debugging use cases. This is our first release after the end of Project Marble, which was focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. We learned a lot from Project Marble and in Android Studio 3.6 we introduce a small set of features, polished existing features, and spent a notable effort addressing bugs and improving underlying performance to ensure we meet the high quality bar we set in the past year.

Some highlights of Android Studio 3.6 include a new way to quickly design, develop and preview app layouts using XML, with a new Split View in the design editors. Additionally, you no longer have to manually type in GPS coordinates to test location with your app because we now embedded Google Maps right into the Android Emulator extended control panel. Finally, we’ve made it easier to optimize your app and find bugs with automatic memory leak detection for Fragments and Activities. We hope all of these features help you be happier and more productive while developing on Android.

Thank you to those who gave your early feedback in preview releases. Your feedback helped us iterate and improve features in Android Studio 3.6. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.6 is ready to download for you to get started.

Below is a full list of new features in Android Studio 3.6, organized by key developer flows.


Split view in design editors

Design editors, such as the Layout Editor and Navigation Editor, now provide a Split view that enables you to see both the Design and Code views of your UI at the same time. Split view replaces and improves upon the earlier Preview window, and can be configured on a file-by-file basis to preserve context information like zoom factor and design view options, so you can choose the view that works best for each use case. To enable split view, click the Split icon in the top-right corner of the editor window. Learn more.

Split view for design editors

Color picker resource tab

In this release we wanted to make it easier to apply colors you have defined as color resources. In Android Studio 3.6, the color picker populates the color resources in your app for you to quickly choose and replace color resources values. The color picker is accessible in the design tools as well as in the XML editor.

Color picker resource tab


View binding

View binding is a feature that allows you to more easily write code that interacts with views by providing compile-time safety when referencing views in your code. When enabled, view binding generates a binding class for each XML layout file present in that module. In most cases, view binding replaces findViewById. You can reference all views that have an ID with no risk of null pointer or class cast exceptions.These differences mean that incompatibilities between your layout and your code will result in your build failing at compile time rather than at runtime. To enable view binding in your project, include the following in each module’s build.gradle file:

android {
    viewBinding.enabled = true

For more information, check out this blog post by one of our developer experts.

Android NDK updates

The following Android NDK features in Android Studio, previously supported in Java, are now also supported in Kotlin:

Learn more

IntelliJ Platform Update

Android Studio 3.6 includes the IntelliJ 2019.2 platform release. This IntelliJ release includes many improvements from a new services tool window to much improved startup times. Learn more

Add classes with Apply Changes

You can now add a class and then deploy that code change to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.

To learn more about the difference between these two actions, see Apply Changes.


Android Gradle Plugin (AGP) updates

Android Gradle plugin 3.6 and higher includes support for the Maven Publish Gradle plugin, which allows you to publish build artifacts to an Apache Maven repository. The Android Gradle plugin creates a component for each build variant artifact in your app or library module that you can use to customize a publication to a Maven repository. This change will make it easier to manage the release lifecycle for your various targets. Learn more

Additionally, Android Gradle plugin has made significant performance improvement for annotation processing/KAPT for large projects. This is caused by AGP now generating R class bytecode directly, instead of .java files.

New packaging tool

The Android build team is continuously working on changes to improve build performance, and in this release we changed the default packaging tool to zipflinger for debug builds. Users should see an improvement in build speed, but you can also revert to using the old packaging tool by setting android.useNewApkCreator=false in your file.

Edit your file to disable the new packaging tool


Android Emulator - Google Maps UI

Android Emulator 29.2.12 includes a new way for app developers to interface with the emulated device location. We embedded the Google Maps user interface in the extended controls menu to make it easier to specify locations and also to construct routes from pairs of locations. Individual points can be saved and re-sent to the device as the virtual location, while routes can be generated through typing in addresses or clicking two points. These routes can be replayed in real time as locations along the route are sent to the guest OS.

Android Emulator location UI with real-time location streaming

Multi-display support

Emulator 29.1.10 includes preliminary support for multiple virtual displays. As more devices are available that have multiple displays, it is important to test your app on a variety of multi-display configurations. Users can configure multiple displays through the settings menu (Extended Controls > Settings).

Multi-display support in Android Emulator

Configure secondary displays in the Android Emulator Extended Controls Panel

Resumable SDK downloads

When downloading Android SDK components and tools using the Android Studio SDK Manager, Android Studio now allows you to resume downloads that were interrupted (for example, due to a network issue) instead of restarting the download from the beginning. This enhancement is especially helpful for large downloads, such as the Android Emulator or system images, when internet connectivity is unreliable.

Pause and resume SDK downloads

In-place updates for imported APKs

Android Studio allows you to import externally-built APKs to debug and profile them. Previously, when changes to those APKs were made, you would have to manually import them again and reattach symbols and sources. Android Studio 3.6 now automatically detects changes made to the imported APK file and gives you an option to re-import it in-place.

Attach Kotlin sources to imported APKs

We added support for attaching Kotlin source files to imported APKs. To learn more, see Attach Kotlin/Java sources.

Attach Kotlin/Java sources to imported APKs


Leak detection in Memory Profiler

Based on your feedback, we’ve added in the Memory Profiler the ability to detect Activity and Fragment instances which may have leaked. To get started, capture or import a heap dump file in the Memory Profiler, and check the Activity/Fragment Leaks checkbox to generate the results. For more information on how Android Studio detects leaks, please see our documentation.

Detect leaked Activities and Fragments in the Memory Profiler

Deobfuscate class and method bytecode in APK Analyzer

When using the APK Analyzer to inspect DEX files, you can now deobfuscate class and method bytecode. While in the DEX file viewer, load the ProGuard mappings file for the APK you’re analyzing. When loaded, you will be able to right-click on the class or method you want to inspect by selecting Show bytecode. Learn more

Deobfuscate class and method bytecode by selecting Show Bytecode in the APK Analyzer

To recap, Android Studio 3.6 includes these new enhancements & features:






Getting Started


Download Android Studio 3.6 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.2.12 downloaded via the Android Studio SDK Manager.

As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

February 24th 2020, 1:06 pm

Native Dependencies in Android Studio 4.0

Android Developers Blog

By Dan Albert, Software Engineer

One thing that NDK users struggle with is managing native dependencies:

With version 4.0 of the Android Gradle Plugin, we’ve addressed these issues by adding support for distributing and exposing native libraries through the same mechanism that you do for Java libraries: Android Archives (AARs).

Here’s how you’d use curl and jsoncpp for example (and automatically pull in the implicit OpenSSL dependency that curl has):

// build.gradle
dependencies {
    implementation ''
    implementation ''

Note: With AGP 4.0 this is still experimental, so to enable this functionality you must set the following properties in your project's file:

# Enables Prefab
# Work around
# 4.0.0 canary 9 defaults to Prefab 1.0.0-alpha3, which is not the latest.

Importing packages into your build

Declaring the dependencies in your build.gradle will cause Gradle to download those dependencies from Maven, but you must still instruct CMake or ndk-build how those dependencies should be used. Fortunately, the necessary CMake package config or ndk-build module will be automatically generated on your behalf. All you need to do is import and use them.

Here’s an example with CMake:

    cmake_minimum_required(VERSION 3.6)
    project(app VERSION 1.0.0 LANGUAGES CXX)

    find_package(curl REQUIRED CONFIG)
    find_package(jsoncpp REQUIRED CONFIG)

    add_library(app SHARED app.cpp)
    target_link_libraries(app curl::curl jsoncpp::jsoncpp)

And here’s the same example with ndk-build:

    LOCAL_PATH := $(call my-dir)

    include $(CLEAR_VARS)
    LOCAL_MODULE := libapp
    LOCAL_SRC_FILES := app.cpp
    LOCAL_SHARED_LIBRARIES := jsoncpp curl

    $(call import-module,prefab/curl)
    $(call import-module,prefab/jsoncpp)

And that’s it. In app.cpp you can now do the following:

#include "curl/curl.h"
#include "json/json.h"

A very common issue that people have is building OpenSSL to use with curl. While not explicitly mentioned in the build scripts above, the curl package itself depends on OpenSSL so this support is available automatically.

For the complete example, see the curl-ssl sample.


The tool that facilitates all of this is called Prefab. Each AAR that exposes C++ libraries to its consumers packages their libraries, headers, and a small amount of metadata into the prefab directory in the AAR. If the prefab directory is found in an AAR dependency, the Android Gradle Plugin automatically runs Prefab to generate build system scripts from the contained information.

Each AAR might contain a large number of prebuilts for different configurations, so Prefab will perform a number of compatibility checks to find a suitable library for your build configuration. The selected library will match your build’s ABI, minSdkVersion, STL choice, and be the best fit for the version of the NDK that you’re using.

What libraries are available?

We’ve already published the following libraries:

For an up to date list, search for “”.

How can I distribute my own libraries?

For the libraries we currently distribute, we wrote ndkports. This is a good fit if the library you’re building is a typical Linux or cross-platform project that doesn’t fit naturally into a typical Android build. If that’s a fit for the library you want, feel free to use ndkports for it, and consider sending us the patch!

If you’d like to request that Google maintain and publish an open source library in Prefab, use the “Package request” bug template on Please keep in mind that each package does come with an ongoing cost, and we will be adding support on a limited basis so we will not be able to support everything.

Coming next is support for exposing your libraries in AARs using the existing Android Library publishing workflow.


For more information about using native dependencies with the Android Gradle Plugin, see the documentation. For more examples, see the NDK samples.

If you’d like to learn more about Prefab itself, see its documentation on GitHub.

If you encounter any issues, file bugs in our Issue Tracker.

February 21st 2020, 1:25 pm

Turning it up to 11: the first Developer Preview of Android 11

Android Developers Blog

Posted by Dave Burke, VP of Engineering

Android has led the way towards the future of mobile, with new technologies like 5G to foldable displays to machine learning built into the core. A hallmark of our approach is a strong developer community that provides early and thoughtful feedback, helping us deliver a robust platform for apps and games that delight billions of users around the world. So today, we’re releasing the first Developer Preview of Android 11, and building on a strong feedback cycle last year, we’re making this year’s preview available to you earlier than ever.

With Android 11 we’re keeping our focus on helping users take advantage of the latest innovations, while continuing to keep privacy and security a top priority. We’ve added multiple new features to help users manage access to sensitive data and files, and we’ve hardened critical areas of the platform to keep the OS resilient and secure. For developers, Android 11 has a ton of new capabilities for your apps, like enhancements for foldables and 5G, call-screening APIs, new media and camera capabilities, machine learning, and more.

This is just a first look; like prior years, we’ll continue to share new features and updates over the coming months and into Google I/O as we work through your feedback. The most important thing for you to do right now is this: visit the Android 11 developer site, download a system image for your Pixel 2, 3, 3a, or 4 device, and let us know what you think!

Today’s release is an early baseline build for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Remember, getting early input from you is crucial in helping us evolve the platform to meet your needs. Read on for a taste of what’s new in Android 11, and visit the developer site for details on timeline, how to test, and how to give feedback.

Helpful innovation

5G experiences

5G brings consistently faster speeds and lower latency to more users around the world. With 5G you can extend your Wi-Fi app experiences -- such as streaming 4K video or loading higher-res game assets -- to mobile users, or you can build new experiences designed specifically for 5G. In Android 11 we’re enhancing and updating the existing connectivity APIs so you can take advantage of 5G’s improved speeds.

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 form-factors and device screens to market. We’ve extended support for these in the platform, with APIs to let you optimize your apps.

People and conversations

Communicating with your friends and colleagues is the most important thing many people do on their phones. In Android 11, we are introducing changes that help developers create deeper conversational experiences, a few of which you’ll see early versions of in DP1:

Real-time, bilateral communication apps should use the sharing/conversation shortcuts API to provide People targets that Android will surface throughout the phone as well as Bubble APIs to allow users to carry on conversations while using the device in other capacities.

Neural Networks API 1.3

Neural Networks API (NNAPI) is designed for running computationally intensive operations for machine learning on Android devices. In Android 11, we’re expanding the operations and controls available to developers. In this release, we’ve added new operations and execution controls to help optimize common use cases:

See the NDK sample code for examples using these new APIs.

Watch for more coming in later preview updates. We’re working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.3.

Privacy and security


Privacy has always been at the core of Android, and each year we’ve added more ways to keep users secure and increase transparency and control. These changes have been popular with users - for example in Android 10 we added the “While app is in use” permission option to give users more granular control over their location and limit background location access. So far, when given the “While app is in use” option, about half of users select it.

In Android 11 we’re continuing our focus on user privacy with new permission options, updates to scoped storage, and more. Please give these features a try with your apps right away and let us know what you think.

One-time permission dialog in Android 11.

In addition to these platform changes, users tell us that they want more protection on earlier versions of Android and more transparency around how apps will use this data, so we are updating Google Play Policy to ensure that apps only request location permissions when truly necessary. Read more


We focus on raising the bar for security with each version of Android -- from reaching more devices with monthly security updates to building more protections into the latest platform. In Android 11, we’ve extended Android’s defense-in-depth strategies to more areas of the platform and added new features and APIs for apps.

Updates and compatibility

Google Play System Updates

Since Android 10, we’ve been scaling up our investment in Google Play System Updates (Project Mainline) to improve security, privacy, and consistency across the ecosystem. Thanks to strong collaboration with device makers, we’ve made significant progress towards this goal and have expanded our infrastructure to reach a wider range of devices more safely and quickly.

In Android 11, we’ve added 12 new updatable modules, for a total of 22 modules. Highlights include a permissions module that standardizes user and developer access to critical privacy controls on Android devices, a media provider module that’s integral to our privacy efforts around Scoped Storage, and an NNAPI (Neural Networks API) module that optimizes performance and guarantees consistent APIs across devices. To learn more about Google Play System Updates, check out the Project Mainline blog post.

App compatibility

We’re also working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates.

App compatibility toggles in Developer Options.

Polish and quality


Image and camera improvements

Low latency

Get started with Android 11

The Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. To get started, download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device. Additionally, you can set up the Android Emulator through Android Studio. The Android Emulator running Android 11 system images includes experimental support to run ARM 32-bit & 64-bit binary app code directly on 64-bit x86 Android Emulator system images. Lastly, for broader testing, GSI images are also available.

Next, update your Android Studio environment with the Android 11 Preview SDK and tools - you can do this from inside Android Studio. See the set up guide for complete details. To take advantage of the latest Android Studio features, we recommend installing the latest version of Android Studio from the canary channel.

When you’re set up, here are some of the things you can do:

For more information, visit the Android 11 developer site. You’ll find an overview of what’s new in this release, details on behavior changes, setup and migration guides, release notes, feedback channels, and more.

Preview updates

We plan to update the preview system images and SDK regularly throughout the Android 11 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Downloads are here and instructions are here.

As we get closer to a final product, we'll be inviting consumers to try it out as well, and we'll open up enrollments through Android Beta at that time. Stay tuned for details, but for now please note that Android Beta is not currently available for Android 11.

Give us your feedback!

As always, your feedback is crucial, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate, and because of timelines, we’re giving priority to input we receive in the next several weeks. When you find issues, please report them here.

February 19th 2020, 1:13 pm

Safer and More Transparent Access to User Location

Android Developers Blog

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

Last year, we made several changes to our platform and policies to increase user trust and safety. We’re proud of the work we’ve done to improve family safety, limit use of sensitive permissions, and catch bad actors before they ever reach the Play Store.

We realize that changes can lead to work for developers. Last year, you told us that you wanted more detailed communications about impactful updates, why we’re making them, and how to take action. You also asked for as much time as possible to make any changes required.

With that feedback in mind, today, we’re previewing Android and Google Play policy changes that will impact how developers access location in the background.

Giving users more control over their location data

Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Since the beginning of Android, users have needed to grant explicit permission to any app that wants access to their location data.

In Android 10, people were given additional control to only grant access when the app is in use, which makes location access more intentional. Users clearly appreciated this option as over half of users select “While app is in use.”

Now in Android 11, we’re giving users even more control with the ability to grant a temporary “one-time” permission to sensitive data like location. When users select this option, apps can only access the data until the user moves away from the app, and they must then request permission again for the next access. Please visit the Android 11 developer preview to learn more.

Preventing unnecessary access to background location

Users tell us they also want more protection on earlier versions of Android - as well as more transparency around how apps use this data.

As we took a closer look at background location usage, we found that many of the apps that requested background location didn’t actually need it. In fact, many of these apps could provide the same user experience by only accessing location when the app is visible to the user. We want to make it easier for users to choose when to share their location and they shouldn't be asked for a permission that the app doesn't need.

Later this year, we will be updating Google Play policy to require that developers get approval if they want to access location data in the background. Factors that will be looked at include:

All apps will be evaluated against the same factors, including apps made by Google, and all submissions will be reviewed by people on our team. Let’s take a look at three examples:

An app that sends emergency or safety alerts as part of its core functionality - and clearly communicates why access is needed to the user - would have a strong case to request background location.

A social networking app that allows users to elect to continuously share their location with friends would also have a strong case to access location in the background.

An app with a store locator feature would work just fine by only accessing location when the app is visible to the user. In this scenario, the app would not have a strong case to request background location under the new policy.

When we spoke to developers for feedback, the vast majority understood user concerns over their information falling into the wrong hands and were willing to change their location usage to be safer and more transparent.

Getting approval for background access

We know that when we update our policies, you want to get actionable feedback and have ample time to make changes. Before we implement this policy change, you will be able to submit your use case via the Play Console and receive feedback on whether it will be allowed under the new policy.

We anticipate the following timeline for this policy rollout; however, it is subject to change.

Review and evaluate your location access

We encourage all developers to review the following best practices for accessing location data in their apps:

We hope you found this policy preview useful in planning your roadmap for the year and we appreciate your efforts to build privacy-friendly apps. Together, we can keep the Android ecosystem safe and secure for everyone.

February 19th 2020, 1:00 pm

Handling Device Orientation Efficiently in Vulkan With Pre-Rotation

Android Developers Blog

By Omar El Sheikh, Android Engineer

Francesco Carucci, Developer Advocate

Vulkan provides developers with the power to specify much more information to devices about rendering state compared to OpenGL. With that power though comes some new responsibilities; developers are expected to explicitly implement things that in OpenGL were handled by the driver. One of these things is device orientation and its relationship to render surface orientation. Currently, there are 3 ways that Android can handle reconciling the render surface of the device with the orientation of the device :

  1. The device has a Display Processing Unit (DPU) that can efficiently handle surface rotation in hardware to match the device orientation (requires a device that supports this)
  2. The Android OS can handle surface rotation by adding a compositor pass that will have a performance cost depending on how the compositor has to deal with rotating the output image
  3. The application itself can handle the surface rotation by rendering a rotated image onto a render surface that matches the current orientation of the display

What Does This Mean For Your Apps?

There currently isn't a way for an application to know whether surface rotation handled outside of the application will be free. Even if there is a DPU to take care of this for us, there will still likely be a measurable performance penalty to pay. If your application is CPU bound, this becomes a huge power issue due to the increased GPU usage by the Android Compositor which usually is running at a boosted frequency as well; and if your application is GPU bound, then it becomes a potentially large performance issue on top of that as the Android Compositor will preempt your application's GPU work causing your application to drop its frame rate.

On Pixel 4XL, we have seen on shipping titles that SurfaceFlinger (the higher-priority task that drives the Android Compositor) both regularly preempts the application’s work causing 1-3ms hits to frametimes, as well as puts increased pressure on the GPU’s vertex/texture memory as the Compositor has to read the frame to do its composition work.

Handling orientation properly stops GPU preemption by SurfaceFlinger almost entirely, as well as sees the GPU frequency drop 40% as the boosted frequency used by the Android Compositor is no longer needed.

To ensure surface rotations are handled properly with as little overhead as possible (as seen in the case above) we recommend implementing method 3 - this is known as pre-rotation. The primary mechanism with which this works is by telling the Android OS that we are handling the surface rotation by specifying in the orientation during swapchain creation through the passed in surface transform flags, which stops the Android Compositor from doing the rotation itself.

Knowing how to set the surface transform flag is important for every Vulkan application, since applications tend to either support multiple orientations, or support a single orientation where its render surface is in a different orientation to what the device considers its identity orientation; For example a landscape-only application on a portrait-identity phone, or a portrait-only application on a landscape-identity tablet.

In this post we will describe in detail how to implement pre-rotation and handle device rotation in your Vulkan application.

Modify AndroidManifest.xml

To handle device rotation in your app, change the application’s AndroidManifest.xml to tell Android that your app will handle orientation and screen size changes. This prevents Android from destroying and recreating the Android activity and calling the onDestroy() function on the existing window surface when an orientation change occurs. This is done by adding the orientation (to support API level <13) and screenSize attributes to the activity’s configChanges section:

<activity android:name=""

If your application fixes its screen orientation using the screenOrientation attribute you do not need to do this. Also if your application uses a fixed orientation then it will only need to setup the swapchain once on application startup/resume.

Get the Identity Screen Resolution and Camera Parameters

The next thing that needs to be done is to detect the device’s screen resolution that is associated with the VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR as this resolution is the one that the Swapchain will always need to be set to. The most reliable way to get this is to make a call to vkGetPhysicalDeviceSurfaceCapabilitiesKHR() at application startup and storing the returned extent - swapping the width and height based on the currentTransform that is also returned in order to ensure we are storing the identity screen resolution:

    VkSurfaceCapabilitiesKHR capabilities;
    vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);

    uint32_t width = capabilities.currentExtent.width;
    uint32_t height = capabilities.currentExtent.height;
    if (capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR ||
        capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) {
      // Swap to get identity width and height
      capabilities.currentExtent.height = width;
      capabilities.currentExtent.width = height;

    displaySizeIdentity = capabilities.currentExtent;

displaySizeIdentity is a VkExtent2D that we use to store said identity resolution of the app's window surface in the display’s natural orientation.

Detect Device Orientation Changes (Android 10+)

To know when the application has encountered an orientation change, the most reliable means of tracking this change involves checking the return value of vkQueuePresentKHR() and seeing if it returned VK_SUBOPTIMAL_KHR

  auto res = vkQueuePresentKHR(queue_, &present_info);
  if (res == VK_SUBOPTIMAL_KHR){
    orientationChanged = true;

One thing to note about this solution is that it only works on devices running Android Q and above as that is when Android started to return VK_SUBOPTIMAL_KHR from vkQueuePresentKHR()

orientationChanged is a boolean stored somewhere accessible from the applications main rendering loop

Detecting Device Orientation Changes (Pre-Android 10)

For devices running older versions of Android below 10, a different implementation is needed since we do not have access to VK_SUBOPTIMAL_KHR.

Using Polling

On pre-10 devices we can poll the current device transform every pollingInterval frames, where pollingInterval is a granularity decided on by the programmer. The way we do this is by calling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() and then comparing the returned currentTransform field with that of the currently stored surface transformation (in this code example stored in pretransformFlag)

  if (currFrameCount >= pollInterval){
    VkSurfaceCapabilitiesKHR capabilities;
    vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);

    if (pretransformFlag != capabilities.currentTransform) {
      window_resized = true;
    currFrameCount = 0;

On a Pixel 4 running Android Q, polling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() took between .120-.250ms and on a Pixel 1XL running Android O polling took .110-.350ms

Using Callbacks

A second option for devices running below Android 10 is to register an onNativeWindowResized() callback to call a function that sets the orientationChanged flag to signal to the application an orientation change has occurred:

void android_main(struct android_app *app) {
  app->activity->callbacks->onNativeWindowResized = ResizeCallback;

Where ResizeCallback is defined as:

void ResizeCallback(ANativeActivity *activity, ANativeWindow *window){
  orientationChanged = true;

The drawback to this solution is that onNativeWindowResized() only ever gets called on 90 degree orientation changes (going from landscape to portrait or vice versa), so for example an orientation change from landscape to reverse landscape will not trigger the swapchain recreation, requiring the Android compositor to do the flip for your application.

Handling the Orientation Change

To actually handle the orientation change, we first have a check at the top of the main rendering loop for whether the orientationChanged variable has been set to true, and if so we'll go into the orientation change routine:

bool VulkanDrawFrame() {
 if (orientationChanged) {

And within the OnOrientationChange() function we will do all the work necessary to recreate the swapchain. This involves destroying any existing Framebuffers and ImageViews; recreating the swapchain while destroying the old swapchain (which will be discussed next); and then recreating the Framebuffers with the new swapchain’s DisplayImages. Note that attachment images (depth/stencil images for example) usually do not need to be recreated as they are based on the identity resolution of the pre-rotated swapchain images.

void OnOrientationChange() {

 for (int i = 0; i < getSwapchainLength(); ++i) {
   vkDestroyImageView(getDevice(), displayViews_[i], nullptr);
   vkDestroyFramebuffer(getDevice(), framebuffers_[i], nullptr);

 createFrameBuffers(render_pass, depthBuffer.image_view);
 orientationChanged = false;

And at the end of the function we reset the orientationChanged flag to false to show that we have handled the orientation change.

Swapchain Recreation

In the previous section we mention having to recreate the swapchain. The first steps to doing so involves getting the new characteristics of the rendering surface:

void createSwapChain(VkSwapchainKHR oldSwapchain) {
   VkSurfaceCapabilitiesKHR capabilities;
   vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);
   pretransformFlag = capabilities.currentTransform;

With the VkSurfaceCapabilities struct populated with the new information, we can now check to see whether an orientation change has occurred by checking the currentTransform field and store it for later in the pretransformFlag field as we will be needing it for later when we make adjustments to the MVP matrix.

In order to do so we must make sure that we properly specify some attributes within the VkSwapchainCreateInfo struct:

VkSwapchainCreateInfoKHR swapchainCreateInfo{
  .imageExtent = displaySizeIdentity,
  .preTransform = pretransformFlag,
  .oldSwapchain = oldSwapchain,

vkCreateSwapchainKHR(device_, &swapchainCreateInfo, nullptr, &swapchain_));

if (oldSwapchain != VK_NULL_HANDLE) {
  vkDestroySwapchainKHR(device_, oldSwapchain, nullptr);

The imageExtent field will be populated with the displaySizeIdentity extent that we stored at application startup. The preTransform field will be populated with our pretransformFlag variable (which is set to the currentTransform field of the surfaceCapabilities). We also set the oldSwapchain field to the swapchain that we are about to destroy.

It is important that the surfaceCapabilities.currentTransform field and the swapchainCreateInfo.preTransform field match because this lets the Android OS know that we are handling the orientation change ourselves, thus avoiding the Android Compositor.

MVP Matrix Adjustment

The last thing that needs to be done is actually apply the pre-transformation. This is done by applying a rotation matrix to your MVP matrix. What this essentially does is apply the rotation in clip space so that the resulting image is rotated to the device current orientation. You can then simply pass this updated MVP matrix into your vertex shader and use it as normal without the need to modify your shaders.

glm::mat4 pre_rotate_mat = glm::mat4(1.0f);
glm::vec3 rotation_axis = glm::vec3(0.0f, 0.0f, 1.0f);

if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(90.0f), rotation_axis);

else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(270.0f), rotation_axis);

else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(180.0f), rotation_axis);

MVP = pre_rotate_mat * MVP;

Consideration - Non-Full Screen Viewport and Scissor

If your application is using a non-full screen viewport/scissor region, they will need to be updated according to the orientation of the device. This requires that we enable the dynamic Viewport and Scissor options during Vulkan’s pipeline creation:

VkDynamicState dynamicStates[2] = {

VkPipelineDynamicStateCreateInfo dynamicInfo = {
  .pNext = nullptr,
  .flags = 0,
  .dynamicStateCount = 2,
  .pDynamicStates = dynamicStates,

VkGraphicsPipelineCreateInfo pipelineCreateInfo = {
  .pDynamicState = &dynamicInfo,

VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineCreateInfo, nullptr, &mPipeline);

The actual computation of the viewport extent during command buffer recording looks like this:

int x = 0, y = 0, w = 500, h = 400;
glm::vec4 viewportData;

switch (device->GetPretransformFlag()) {
    viewportData = {bufferWidth - h - y, x, h, w};
    viewportData = {bufferWidth - w - x, bufferHeight - h - y, w, h};
    viewportData = {y, bufferHeight - w - x, h, w};
    viewportData = {x, y, w, h};

const VkViewport viewport = {
    .x = viewportData.x,
    .y = viewportData.y,
    .width = viewportData.z,
    .height = viewportData.w,
    .minDepth = 0.0F,
    .maxDepth = 1.0F,

vkCmdSetViewport(renderer->GetCurrentCommandBuffer(), 0, 1, &viewport);

Where x and y define the coordinates of the top left corner of the viewport, and w and h define the width and height of the viewport respectively.

The same computation can be used to also set the scissor test, and is included below for completeness:

int x = 0, y = 0, w = 500, h = 400;
glm::vec4 scissorData;

switch (device->GetPretransformFlag()) {
    scissorData = {bufferWidth - h - y, x, h, w};
    scissorData = {bufferWidth - w - x, bufferHeight - h - y, w, h};
    scissorData = {y, bufferHeight - w - x, h, w};
    scissorData = {x, y, w, h};

const VkRect2D scissor = {
    .offset =
            .x = (int32_t)viewportData.x,
            .y = (int32_t)viewportData.y,
    .extent =
            .width = (uint32_t)viewportData.z,
            .height = (uint32_t)viewportData.w,

vkCmdSetScissor(renderer->GetCurrentCommandBuffer(), 0, 1, &scissor);

Consideration - Fragment Shader Derivatives

If your application is using derivative computations such as dFdx and dFdy, additional transformations may be needed to account for the rotated coordinate system as these computations are executed in pixel space. This requires the app to pass some indication of the preTransform into the fragment shader (such as an integer representing the current device orientation) and use that to map the derivative computations properly:


In order for your application to get the most out of Vulkan on Android, implementing pre-rotation is a must. The most important takeaways from this blogpost are:

  1. Ensure that during swapchain creation or recreation, the pretransform flag is set so that it matches the flag returned by the Android operating system. This will avoid the compositor overhead
  2. Keep the swapchain size fixed to the identity resolution of the app's window surface in the display’s natural orientation
  3. Rotate the MVP matrix in clip space to account for the devices orientation since the swapchain resolution/extent no longer update with the orientation of the display
  4. Update viewport and scissor rectangles as needed by your application

Here is a link to a minimal example of pre-rotation being implemented for an android application:

February 14th 2020, 4:36 pm

Detecting Memory Corruption Bugs With HWASan

Android Developers Blog

Posted by Evgenii Stepanov, Staff Software Engineer, Dynamic Tools

Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android.

In previous years our memory bug detection efforts were focused on Address Sanitizer (ASan). ASan catches these errors but causes your app to use 2x-3x extra memory and to run slower.

To better tackle these problems we’ve developed Hardware-Assisted Address Sanitizer (HWASan). HWASan typically only requires 15% more memory. It’s also a lot faster than ASan. HWASan’s performance makes it usable not only for unit testing, but also for interactive human-driven testing. We use this to find memory issues in the Android OS itself, and now we've made it easy for app developers to use it too. HWASan is fast enough that some Android developers use it on their development devices for everyday tasks.

Under the hood

HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes.

Under the hood, HWASan uses shadow memory - a sparse map that assigns a tag value to each 16 byte block of program memory. Compile time code instrumentation is used to insert checks that compare pointer and memory tags for every memory access, and raise an error if they do not match.

This approach allows us to detect both use-after-free and buffer-overflow types of bugs. The memory tag in the shadow is changed to a random value during allocation and deallocation. As a result, attempting to access deallocated memory with a dangling pointer will almost certainly fail due to a tag mismatch. The same is true for an attempt to access memory outside of the allocated region, which is very likely to have a different tag. Stack and global variables are similarly protected.

Use-after-free bug detection with memory tagging.

This approach is non deterministic: because of the limited number of possible tags, an invalid memory access has 1 chance out of 256 (approximately 0.4%) to pass undetected. We have not observed this as a problem in practice, but, due to the tag randomness, running the program the second time is very likely to find any bugs that the first run has missed.

An advantage of HWASan over ASan is its ability to find bugs that happen far from their origination point - for example, a use-after-free where the memory is accessed long after it has been deallocated, or a buffer overflow with a large offset. This is not the case with ASan, which uses red zones around memory allocations, and a quarantine for the temporary storage of recently deallocated memory blocks. Both redzones and the quarantine are of limited size, and error detection is unlikely beyond that. HWASan uses a different approach that does not have these limitations.


When a bug is discovered the process is terminated and a crash dump is printed to logcat. The “Abort message” field contains a HWASan report, which shows the access type (read or write), access address, thread id and the stack trace of the bad memory access. This is followed by a stack trace for the original allocation, and, for use-after-free bugs, a stack trace showing where the deallocation took place. Advanced users can find extra debugging information below this, including a map of memory tags for nearby locations.

signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '==21586==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0042a0807af0 at pc 0x007b23b8786c
WRITE of size 1 at 0x0042a0807af0 tags: db/19 (ptr/mem) in thread T0
    #0 0x7b23b87868 (/data/app/com.example.myapp/lib/arm64/
    #1 0x7b8f1e4ccc (/apex/

0x0042a0807af0 is located 0 bytes to the right of 16-byte region [0x0042a0807ae0,0x0042a0807af0)
allocated here:
    #0 0x7b92a322bc (/path/to/
    #1 0x7b23b87840 (/data/app/com.example.myapp/lib/arm64/

An example snippet from a HWASan crash report.

Google uses HWASan extensively in Android development, and now you can too. Find out more -- including the details of how to rebuild your app for use with HWASan -- at Prebuilt HWASan system images are available on the AOSP build server (or you can build your own). They can be easily flashed onto a compatible device using the recently announced web flash tool.

February 13th 2020, 4:03 pm

How we fought bad apps and malicious developers in 2019

Android Developers Blog

Posted by Andrew Ahn, Product Manager, Google Play + Android App Safety

Google Play connects users with great digital experiences to help them be more productive and entertained, as well as providing app developers with tools to reach billions of users around the globe. Such a thriving ecosystem can only be achieved and sustained when trust and safety is one of its key foundations. Over the last few years we’ve made the trust and safety of Google Play a top priority, and have continued our investments and improvements in our abuse detection systems, policies, and teams to fight against bad apps and malicious actors.

In 2019, we continued to strengthen our policies (especially to better protect kids and families), continued to improve our developer approval process, initiated a deeper collaboration with security industry partners through the App Defense Alliance, enhanced our machine learning detection systems analyzing an app’s code, metadata, and user engagement signals for any suspicious content or behaviors, as well as scaling the number and the depth of manual reviews. The combination of these efforts have resulted in a much cleaner Play Store:

In addition we’ve launched a refreshed Google Play Protect experience, our built-in malware protection for Android devices. Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure. Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.

While we are proud of what we were able to achieve in partnership with our developer community, we know there is more work to be done. Adversarial bad actors will continue to devise new ways to evade our detection systems and put users in harm's way for their own gains. Our commitment in building the world's safest and most helpful app platform will continue in 2020, and we will continue to invest in the key app safety areas mentioned in last year’s blog post:

Our teams of passionate product managers, engineers, policy experts, and operations leaders will continue to work with the developer community to accelerate the pace of innovation, and deliver a safer app store to billions of Android users worldwide.

February 11th 2020, 1:09 pm

The path to DX deprecation

Android Developers Blog

Posted by Leo Sei, Product Manager on Android

Back in 2017, we released D8, a new faster dexing compiler to replace DX, producing smaller APKs. In April 2018, we announced D8 as the default option in Android Studio 3.1.

In that announcement, we laid out 3 phases to deprecate DX and we are now entering phase 2:

“Once we've seen a six month window without major regressions from DX to D8, we'll enter the second phase. This phase will last for a year, and is intended to ensure that even complex projects have lots of time to migrate. During this phase, we'll keep DX available, but we'll treat it as fully deprecated; we won't be fixing any issues.”

If you haven’t already, it is now the time to migrate to D8 (see details in the previous post). As always, if you encounter issues, please do let us know!

Next steps

On Feb 1st, 2021, we’ll move to step 3, removing DX fully from Android Studio and any other build environments.

Note: This post is about DX only (and does not include shrinking tools)

February 4th 2020, 12:13 pm

Flashing Builds from the Android Open Source Project

Android Developers Blog

Posted by Mitchell Wills, Android Build Software Engineer

AOSP has been around for a while, but flashing builds onto a development device has always required a number of manual steps. A year ago we launched Android's Continuous Integration Dashboard, which gives more visibility into the continuous build status of the AOSP source tree. However, these builds were not available for phones and flashing devices still required a manual command line process.

In order to support developers working in AOSP we are launching Android Flash Tool, which allows developers to flash devices with builds listed on the Continuous Integration Dashboard. This can be used by developers working on the Android OS to test changes or App developers to test compatibility with the latest AOSP build.

A device being flashed.

Android Flash Tool allows anyone to use a browser supporting WebUSB, such as Chrome 79 or Edge 79, to flash an Android device entirely from the browser (Windows requires installing a driver). After connecting a device and authorizing the page to connect to it users will be presented with a list of available builds. After choosing a build click flash and the tool does the rest. You can flash recent Pixel devices and the HiKey reference boards with builds based on aosp-master.

Try Android Flash Tool yourself at

Find out more at

January 28th 2020, 12:23 pm

Get ready for the Game Developers Conference

Android Developers Blog

Posted by Kacey Fahey, Games Developer Marketing, Google

Cross-posting from the Google Developers Blog.

Join us online or live* at the Google Developer Summits during the Game Developers Conference on March 16 and 17 to learn about the latest tools and updates to build great games, reach more players, and improve discovery of your game.

Google has lots to share with the game development community at the Game Developers Conference (GDC) in March. Check out our plans and sign up to keep up to date with the latest GDC news and announcements from Android, Google Play, Firebase, and more.

For one week, tens of thousands of creators from the gaming community come together at GDC to hear the latest industry innovations and network with peers to enable better gaming experiences for players around the world.

Below is a preview of what to expect from Google, and remember, it’s just the beginning. Don’t forget to sign up for our newsletter as we reveal more leading up to the event, or you can check out our website, Google for Games at GDC.

Google for Games Keynote

We will start the week with the Google for Games Keynote on Monday, March 16 at 9:30 am PST. Join the livestream and learn about the latest tools and solutions to help game developers create great games, connect with players, and scale their businesses.

Google Developer Keynote photo at GDC 2019

Google Developer Summit

We have two days of in-depth sessions where you can uplevel your skills across Google products and solutions. Topics range from new tools to optimize game development, how to reach more devices and players, using new Firebase features to alleviate infrastructure management challenges, and much more.

Learn more about the Google Developer Summit we’ll be hosting on March 16 -17 and how you can join in person with an official GDC ticket or via livestream.

We’ll be sharing more details about everything we have planned at GDC in the coming weeks so be sure to sign up to be among the first to hear the latest updates, and save the date to watch the keynote and other Developer Summit sessions at

More to come soon!

The Google for Games team

*On-site events are part of the official Game Developers Conference and require a pass to attend.

January 27th 2020, 1:59 pm

Enter the Indie Games Festival from Google Play

Android Developers Blog

Posted by Patricia Correa, Director, Developer Marketing

The indie developer community released several fantastic titles on Google Play during 2019, showing the technical skill and innovative design that makes them an essential part of the gaming landscape.

To continue helping indie developers thrive, today we’re announcing the 2020 edition of our annual Google Play Indie Games Festival. This year we will host three competitions for developers from several European countries*, Japan, and South Korea.


Prizes are designed to help you grow your business, including:


The contests are open to developers from selected countries, with no more than 50 employees. The submitted game must be new, released at least in open beta between May 7, 2019 and March 2, 2020. See other requirements in the terms and conditions for each of the contests.


Simply fill out the relevant form by clicking here. Submissions are open until March 2, 2020, at 3pm CET.

The Top 20 entries in each region will be announced in March and invited to showcase at the Festival events where the field will be narrowed to 10 by the event audience, industry experts and the Google team. The Top 10 will present their games on stage and the 3 winners will be selected.

Not submitting a game? Come and take part:

Even if you’re not submitting a game to the competitions, we’d love to see you at one of the Festival events on the 25th of April 2020.

Learn more and sign up on

* The European competition is open to developers from the following countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).

How useful did you find this blog post?

January 9th 2020, 3:08 am

Kotlin/Everywhere - it’s a wrap!

Android Developers Blog

Posted by Florina Muntenescu, Developer Advocate (@FMuntenescu)

At Google I/O 2019 we announced that Android development will become increasingly Kotlin-first. Together with JetBrains, we also launched Kotlin/Everywhere - a global series of community led events focusing on the potential of using Kotlin everywhere; on Android, servers, web front-end and other platforms.

Kotlin/Everywhere events took place from May through December and we want to thank everyone for getting involved

👨‍💻👩‍💻30,000+ developers participated in-person at Kotlin/Everywhere events

🎥🍿200,000 views of live-streams and event recordings like Kotlin/Everywhere Bengaluru, Minsk, Chicago, Buenos Aires and more.

📅 500+ events: from short evening meetups, half-day sessions, and full day events, to Kotlin/Everywhere tracks at larger events like DevFests, or even StudyJams that spanned several weeks.

🎤~30 speakers from Google and JetBrains gave ~70 talks at events around the world.

🌎 85+ countries: from United States to Chile, Kenya, Greece, Taiwan, New Zealand and so many more, with some countries hosting 1-2 events to some hosting dozens: Nigeria - 38, China - 27, India - 25 just to name a few.

💻 Many of the resources used or created for Kotlin/Everywhere by Google and JetBrains are available online:

General Kotlin:

Kotlin in Android:

Kotlin in Google Cloud Platform:

Multi-platform Kotlin:

We’re grateful for this engagement with Kotlin from communities around the world, as well as for all the organisers, speakers and attendees who made these events possible! To participate in more Kotlin events, check out JetBrains’ KotlinConf’19 Global initiative, happening through March 2020.

With all of the resources available, there’s never been a better time to adopt Kotlin… Everywhere!

December 18th 2019, 12:18 pm

Our highlights from Android & Google Play in 2019 - building for the next decade

Android Developers Blog

Posted by Patricia Correa, P&E Developer Marketing Director

The last 12 months have seen Google Play continue to grow, with over 116 billion downloads of the apps and games that you created.

We’ve been working hard to build the latest technology and tools for modern Android development and distribution, improving Google Play and the Play Console to offer you new and better ways for your app to be discovered, promoted, and monetized.

A key focus has been addressing the challenge of keeping users safe and maintaining trust in Google Play.

Modern Android development

We are focused on building great tools and services and your feedback is crucial in helping us do so. You have told us that you love Android’s openness, but we have also heard that you would like us to marry it with an opinion about the right way to do things. We call this approach 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 modern Android development come to life in a number of investments we made this year:

Android 10

Android 10, released earlier this year, is built around three important themes. First, Android 10 is shaping the leading edge of mobile innovation with advanced machine-learning and support for emerging devices like foldables and 5G enabled phones. Next, Android 10 has a central focus on privacy and security, with almost 50 features that give users greater protection, transparency, and control. Finally, Android 10 expands users' digital wellbeing controls so individuals and families can find a better balance with technology.

Modern app and game distribution

We introduced Android App Bundles last year as a mechanism to simplify and streamline app distribution, overcome the constraints of APK publishing, and introduce advanced distribution features such as dynamic delivery. There are now over 300K app bundle apps and games in production, covering nearly 30% of all active installs. If this doesn’t include your app or game, check out 16 reasons to publish your apps and games with the Android App Bundle.

This year we’ve made it much easier to test and implement app bundles and dynamic delivery. Internal app sharing makes it easy to share test builds with others. You can easily grant anyone on your team the ability to upload a test build to Play and get a download link to share with your testers. 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, and can even upload debuggable artifacts.You can also get download links for old versions of your app from the Play Console, whether they’re app bundles or APKs.

Protecting the ecosystem

In 2019, you helped us make Google Play even safer, building user trust in your apps and Google Play as a whole. Thanks to your hard work, we have:

To help you protect your apps, we’ve improved our ability to detect impersonators, repackaging, bad content, and other forms of abuse. Additionally, we’re investing in resources like policy-focused Play Academy courses to help you better understand and navigate our policy changes.

Because the threats are always changing, it’ll take all of us working together to keep users safe and our platform secure. Thank you for continuing to work with us on this.

Building better app businesses

During 2019 we continued to look for new ways to help you market and monetize your apps and games:

And that’s a wrap

With such scale comes responsibility. We’re committed to ensuring our users’ safety for the future, to making development easier and distribution faster, and to offering you more effective ways for your app to be discovered and monetized.

On this note, we hope we can all continue working together to make Android and Google Play better for billions of people around the world, in 2020, and the years to come. From everyone on our team, we wish you all a happy holiday season and a prosperous new year.

How useful did you find this blog post?

December 17th 2019, 3:03 pm

Code Search with Cross References for the Android Open Source Project

Android Developers Blog

Posted by Jeff Bailey, AOSP Engineering Manager; Ally Sillins, AOSP Program Manager; Kris Hildrum, Open Source Code Search Tech Lead; Jay Sachs, Kythe Tech Lead/Manager

Searching for "it's all about the code" open source on Google returns more than a million hits. Today we’re introducing a public code search tool for the Android Open Source Project (AOSP).


The Android repository is made up of a collection of git repositories which are managed together using our ‘repo’ tool. Because of this, most tools (such as github, gitweb, etc) can’t see the source code the way that it’s laid out when it’s checked out on the system. In partnership with our colleagues who run Google’s internal Code Search and Kythe, we’re pleased to present a code search tool that presents a view of all of the Android source code as you actually use it.

Here are some features you can take advantage of starting today:

This is the beginning of our journey, and while today not all parts of the Android code base are cross-referenced, you can expect to see this grow over time.

We hope this makes it easier to engage with the Android code base!

December 10th 2019, 5:09 pm

Android 10 on Android TV

Android Developers Blog

Posted by Paul Lammertsma, Developer Advocate

Technology has changed the way media and entertainment is accessed and consumed in the home. While the living room experience is evolving with the addition of smart devices, TVs still remain the largest and most frequently used screen for watching content.

When Android TV was first introduced in 2014, we set out to bring the best of Android into the connected home on the TV. We worked closely with the developer community to grow our content and app ecosystem and bring users the content they want. Since then, we’ve seen tremendous momentum with OEM and operator partners as well as consumer adoption worldwide.

Today, we are bringing Android API level 29 with the recent performance and security updates made with Android 10 to Android TV. We’re excited to provide faster updates through Project Treble and more secure storage with encrypted user data. TLS 1.3 by default also brings better performance benefits and is up to date with the TLS standard. In addition, Android 10 includes hardening for several security-critical areas of the platform.


To make sure developers have the ability to build and test Android TV app implementations on Android 10 prior to rollout, we’re introducing a new, developer-focused streaming media device called ADT-3.

With a quad-core A53, 2GB of DDR3 memory and 4Kp60 HDR HDMI 2.1 output, we’ve designed this pre-certified TV dongle with updates and security patches to help developers design for the next generation of Android TV devices. By providing a way to test on physical and up to date hardware, developers can better validate their Android TV app’s compatibility.

ADT-3 will be made available to developers in the coming months for purchase online through an OEM partner.

December 10th 2019, 12:06 pm

Android’s commitment to Kotlin

Android Developers Blog

Posted by David Winer, Kotlin Product Manager

When we announced Kotlin as a supported language for Android, there was a tremendous amount of excitement among developers. Since then, there has been a steady increase in the number of developers using Kotlin. Today, we’re proud to say nearly 60% of the top 1,000 Android apps contain Kotlin code, with more and more Android developers introducing safer and more concise code using Kotlin.

During this year’s I/O, we announced that Android development will be Kotlin-first, and we’ve stood by that commitment. This is one of the reasons why Android is the gold partner for this year’s KotlinConf.

Seamless Kotlin on Android

In 2019, we focused on making programming in Kotlin on Android a seamless experience, with modern Kotlin-first APIs across the Android platform. Earlier this year, we launched a developer preview of Jetpack Compose, a modern UI toolkit for Android built using a Kotlin domain-specific language (DSL). We also incorporated coroutines into several of the flagship Jetpack libraries, including Room and Lifecycle. Finally, we brought Kotlin extensions (KTX) to even more major Google libraries, including Firebase and Play Core.

On the tooling side, we strengthened our commitment to Kotlin in Android Studio and the Android build pipeline. Significant updates to R8 (the code shrinker for Android) brought the ability to detect and handle Kotlin-specific bytecode patterns. Support was added for .kts Gradle build scripts in Android Studio, along with improved Kotlin support in Dagger. We worked closely with the JetBrains team to optimize support for the Kotlin plugin, and make the Kotlin editing experience in Android Studio fluid and fast.

Better Kotlin learning

This year we’ve also invested in quality Kotlin on Android learning content.

We released two free video learning courses in partnership with Udacity: Developing Android Apps in Kotlin and Advanced Android in Kotlin. This content was also released as the Codelab courses Android Kotlin Fundamentals and Advanced Android in Kotlin, for those who prefer text-based learning. The popular Kotlin Bootcamp for Programmers Udacity course was also published as a Codelabs course, helping provide a Kotlin foundation for non-Kotlin developers. Kotlin-based instructional Codelabs were also created for topics including Material Design, Kotlin coroutines, location, refactoring to Kotlin, billing in Kotlin, and Google Pay in Kotlin. It hasn’t been just about new content: we've updated Kotlin Codelab favorites to take advantage of important features such as coroutines.

Looking ahead

In 2020, Android development will continue to be Kotlin-first. We’ve been listening to your feedback, and will continue partnering with JetBrains to improve your experience with Kotlin.

This includes working with JetBrains to improve the Kotlin compiler over the next year. Our teams are making the compiler more extensible with a new backend, and making your builds faster with a significantly faster frontend. We’re also working with many of the largest annotation processors to make compilation faster for Kotlin code. You can also expect more Kotlin-first updates to Android, including more Jetpack libraries that make use of Kotlin features such as coroutines.

Thank you for letting us be part of your app development journey this year. We look forward to continuing the journey with you in 2020.

December 6th 2019, 2:16 pm

Android Game SDK

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

With over 2.5 billion monthly active devices, the Android Platform gives incredible reach for game developers. Taking advantage of that opportunity can be a challenge, particularly if your game really tries to push the limits of what mobile can do. We've spent years working with game developers to try to both capture and address the biggest issues, and we're just beginning to see the fruits of that effort with the launch of the Android Game SDK. The Android Game SDK is a set of libraries that you can use to enhance your Android game.

The first library we are launching in the Android Game SDK helps developers with frame pacing, the synchronization of a game's rendering loop with the OS display subsystem and underlying display hardware. Android's display subsystem is designed to avoid tearing that occurs when the display hardware switches to a new frame in the middle of an update. To this end, it buffers past frames, detects late frame submissions, and repeats the display of past frames when late frames are detected. When a game render loop renders at a different rate than the native display hardware, such as a game running at 30 frames-per-second attempting to render on a device that natively supports 60 FPS, the optimal display flow involves synchronization between the game render loop, the system compositor, and the display hardware.

Optimal Display Flow

Any mismatch in synchronization can create substantial inconsistencies in frame times. If a frame takes substantially less time to render, it can shorten the presentation of the previous frame, causing something like a 33ms, 16ms, and a 50ms sequence.

Synchronization Mismatch: Rendering too Fast

If a frame takes too long to render, a similar problem occurs. The frame will be presented for an extra frame, causing something like a 50ms, 16ms, and 33ms sequence.

Synchronization Mismatch: Slow Frame

In either of these two scenarios, the game player will experience inconsistent delays between game input and screen updates. Visually, things will look less smooth and polished. Both visuals and game play can be impacted.

The Frame Pacing library uses Android's Choreographer API for synchronization with the display subsystem, using presentation timestamp extensions on both OpenGL and Vulkan APIs to make sure frames are presented at the proper time, and sync fences to avoid buffer stuffing. Multiple refresh rates are handled if supported by the device, giving a game more flexibility in presenting a frame. For a device that supports a 60 Hz refresh rate as well as 90 Hz, a game that cannot produce 60 frames per second can drop to 45 FPS instead of 30 FPS to remain smooth. The library detects the expected game frame rate and auto-adjusts frame presentation times accordingly. The Frame Pacing library allows games to take advantage of higher refresh rate 90 and 120 Hz displays, while also making it easy to lock the refresh rate to a desired value, regardless of the underlying display refresh rate.

The Frame Pacing library is built into Unity versions 2019.2 and beyond. Just select the optimized Frame Pacing checkbox under Android Settings to enable smoother frame rates for your game. If you have source to your game engine, it's straightforward to integrate the library into your OpenGL or Vulkan renderer. We've just added library binaries for download at, or you can download the source code from the Android Open Source Project.

To learn more about Frame Pacing, check out the documentation at, along with the Frame Pacing section of the Optimizing Android Games Performance talk from Google I/O 2019. Be sure to subscribe to our Twitter channel and stay tuned for our announcements at GDC 2020 for more on how we're working to make Android game development better, so you can bring the best game experience to billions of devices.

December 5th 2019, 3:55 pm

An Update on Android TLS Adoption

Android Developers Blog

Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS).

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Percentage of apps that block cleartext by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

The latest releases of Android Studio and Google Play’s pre-launch report warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers as part of the pre-launch report.

What can I do to secure my app?

For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.

If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.

    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true"></domain>
        <domain includeSubdomains="true"></domain>

If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your element inside a element. This ensures the connections in the production version of your app are secure.

            <certificates src="user"/>

What can I do to secure my library?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

Android’s built-in networking libraries and other popular HTTP libraries such as OkHttp or Volley have built-in Network Security Config support.

Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams

December 3rd 2019, 2:41 pm

#AndroidDevChallenge: today is the last day to apply!

Android Developers Blog

Today is the last day to apply for the Android Developer Challenge! And to spark your imagination, we wanted to take a look at one of the original Android Developer Challenge winners, from over 10 years ago. Meet Maurizio Leo:

Maurizio and team have been working on Android for a while now. In fact, he was one of the winners of the original Android Developer Challenge, which launched with the start of Android over ten years ago. Their app, which won 3rd place worldwide at the time, has gone on to be downloaded over 30 million times!

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. 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. You can read more about all of the prizes here.

There’s still time to submit your idea before the deadline today! Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

December 2nd 2019, 5:59 pm

3 things to know about Jetpack from Android Dev Summit 2019

Android Developers Blog

Posted by Jisha Abubaker, Product Manager

Last month’s #AndroidDevSummit was jam-packed with announcements and technical much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. We previously spotlighted Jetpack Compose, Kotlin and Android Studio, and today, we’re highlighting the rest of Android Jetpack, with the top three things you should know:

#1: A number of new & updated Jetpack libraries ready to use:

WorkManager 2.2 (Stable) has landed significant updates in the last releases with features like on-demand initialization improving app startup time when using WorkManager and improved testing support. Hear more of the new features and best practices.

Room 2.2 (Stable) is packed with features you asked for too : pre-packaged databases, improved relationship support and now better support for Kotlin Flow as well. Check out the What’s new in Room session to catch up.

Benchmarking (Stable) helps you measure the performance of tasks in your app with confidence. Here’s a deep dive on how you can exercise the library in fighting performance regressions in CI, like we do ourselves for Jetpack libraries and Compose.

LiveData w/ support for Kotlin coroutines & Flow (RC) : Kotlin coroutines and Flows has been the Android developer community’s interest in simplify async patterns in your apps. Learn how best to take advantage of the liveData builder in your app:

View binding (Beta) is type-safe solution bundled with Android Studio 3.6 Beta with minimal build-time impact, no more findViewById(), no more annotation processors. Check out What’s new in Studio for a demo !

#2: We’re busy baking more libraries

CameraX (Alpha) simplifies the development experience and lets you focus on your app instead by addressing the differences between the many devices in the Android ecosystem, like Samsung, Xiaomi, Oppo, Motorola, LG who are already unifying behind CameraX. Expected in Beta soon, learn what the Camera team has been up to since I/O 2019.

Security (Alpha) helps you simplify data at rest encryption for your app needs. Hear of best practices with encryption on Android from the Security library team.

#3:It’s time to migrate to androidx!

With all the new and updated Jetpack libraries and upcoming release of Jetpack Compose, it is time to get your app updated and ready. Nick and Tiem share a great step by step plan and best practices from the community in migrating to androidx namespace.

...and we also heard from you!

But Android Dev Summit isn’t just about what we’ve got to say; it’s also about you telling us what you’d like to see worked on to make your life easier. And this year, one thing that we heard strongly from our community was the need to provide a simplified Dependency injection developer experience for Jetpack libraries and expand improved Kotlin support to other Jetpack libraries! We’re on it!

You can find the entire playlist of Jetpack sessions at the Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 27th 2019, 1:10 pm

Our panel of experts for the #AndroidDevChallenge (apply by Dec. 2)

Android Developers Blog

Just a little over a week left to finish your submission for the Android Developer Challenge, due December 2! Technology is enabling us to create a whole new era of helpful innovation by helping people get things done more quickly and surfacing patterns that would be difficult to detect using traditional methods. Ultimately, this helpful innovation is enabling us to live better, more productive, and safer lives.

Earlier this week, we highlighted the type of helpful innovation ideas powered by machine learning which are the sort of examples we’re looking for, to help inspire you. Today, we wanted to share the names of the panel of experts we’ve assembled to help bring your projects to life as part of the Android Developer Challenge. These experts will be making the final decision on the 10 finalists of the Android Developer Challenge, and if you’re selected as one of those finalists, we plan to have you meet them when we bring you to Google HQ for a bootcamp next year:

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. 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. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

November 22nd 2019, 10:35 am

Android Developer Challenge: here’s what we’re looking for! (Apply by Dec. 2)

Android Developers Blog

Last month, we kicked off the next Android Developer Challenge, and asked you to submit your ideas focused on helpful innovation, powered by on-device machine learning. But what exactly do we mean when we say helpful innovation? We’re glad you asked! We rounded up a few of Google’s on-device machine learning offerings, together with some great recent examples of this technology in action, to help inspire your submission. Don’t forget, submit your idea by December 2!

Using machine learning to tackle Fall Armyworm

Take Nazirini Siraji. When she and a team of developers noticed a crop-pest threatening the livelihood of Ugandan farmers, they taught themselves TensorFlow to combat this pest. They collected training data from nearby fields in the form of images. With TensorFlow, they re-trained a MobileNet, a technique known as transfer learning and then used the TensorFlow Converter to generate a TensorFlow Lite FlatBuffer file which they deployed in an Android app. With the app, a farmer can snap a picture of their crop and the image frame is analysed to look for Fall armyworm damage. Depending on the results from this phase, a suggestion of a possible solution is given. It’s pretty cool!

Helping doctors detect respiratory diseases using machine learning

Tambua Health is helping doctors determine the likelihood of respiratory diseases by turning any smartphone into a powerful non-invasive screening tool. They developed an app using TensorFlow Lite that can help doctors analyze lung sounds for the presence of abnormal sounds like wheezes, crackles, stridor, and other adventitious sounds.

adidas uses machine learning to make the shopping experience easier

Even brands are tapping the power of machine learning. Take adidas, who recently launched a new “Bring It to Me” experience for their London store. Shoppers can use Visual Lookup to scan products on their phones while they are in the store, and the app lets them check stock and request their size without the need for queues. Under the hood, ML Kit is helping power the experience. It’s another way machine learning is helping users get things done more quickly.

The benefits of on-device machine learning

Running machine learning on a user’s device comes with a number of benefits. First, you reduce the amount of data you send to your server, enhancing user privacy. And because it runs on device, it can also work offline - perfect for inaccessible areas such as the middle of a rainforest, a desert or the London Underground. Last but not least, the most exciting aspect of running your model on device is low latency and this can enable all kinds of new user experiences. Machine learning is not just for automating tasks, it can work alongside your users and give them super powers too!

At Google, we offer a number of different technologies to help you take advantage of this:

If you’ve got a great idea that can help users get things done, we want to hear from you! 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. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. We can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by on-device machine learning to more and more users!

November 20th 2019, 4:46 pm

Unifying Background Task Scheduling on Android

Android Developers Blog

Posted by Caren Chang, Developer Programs Engineer, @calren24

Android users care a lot about the battery life on their phones. In particular, how your app schedules deferrable background tasks play an important role in battery life. To help you build more battery-friendly apps, we introduced WorkManager as the unified solution for all deferrable background processing needs.

Starting November 1, 2020, we are unifying deferrable background tasks on Android around WorkManager, and GCMNetworkManager will be deprecated and no longer supported.

Why WorkManager

The WorkManager API incorporates the features of Firebase Job Dispatcher (FJD) and GcmNetworkManager solutions, providing a consistent job scheduling service back to API level 14 while being conscious of battery life. For example, if your app needs to send log files up to the server, it would be more efficient to wait until the device is both charging and connected to WiFi. In this case, WorkManager will ensure that the sync will execute when the given constraints (charging and connected to WiFi) are met. Additionally, it does not require Google Play Services, unlike FJD and GcmNetworkManager.

Some of the other key features of WorkManager include:

What it means for developers

Now that the WorkManager library has reached maturity, we have decided to deprecate alternative solutions to simplify the developer story and focus on WorkManager stability and features.

Migrating to WorkManager

Now is the time to migrate your apps to WorkManager if you haven't already done so! You can start by reading the official documentation for WorkManager.

If your app is still using FirebaseJobDispatcher, you can migrate your app to WorkManager by following the migration guide. A similar migration guide from GCMNetworkManager to WorkManager is also available.

YouTube recently moved over to WorkManager for their background scheduling needs and has reported improvements in app startup time as well as an 8% drop in crash rates.

Going forward

The team is dedicated to improving and continuing feature development on WorkManager. If you encounter issues using the library, have proposals for features you would like to see, or have any feedback about the library, please file an issue.

November 19th 2019, 1:39 pm

New! Learn advanced skills for developing Android apps in Kotlin

Android Developers Blog

Posted by Aleks Haecky

Advanced Android in Kotlin, developed by Google together with Udacity, is our newly-released, free, self-paced online course. In this course expert instructors from the Android team at Google will introduce you to some of the advanced features you can build into your Android apps.

This course is intended for developers who have mastered the basics of building an Android app in Kotlin, and want to dive deeper into advanced functionality. To benefit most from this course, you need skills equivalent to what's taught in our Android Fundamentals Udacity or codelab courses.

Advanced Android in Kotlin teaches you about notifications, graphics and animations on Android, using third-party authentication for login, and how to add maps to your apps. Learn how to create custom views that can look like anything you want, draw to a canvas, and have eye-catching animations. And, most importantly, you will learn how to properly test your apps!

Here is a sample of apps you will build:

Check out the YouTube course trailer below for additional information about the course and apps:

Different people like to learn in different ways, so we are offering this course as both a Udacity video-based course and as a series of codelabs with topics that you can explore in any order. Whether you prefer to work on your own with just the text and code, or to have an instructor help walk through the code with you on video, we’ve got you covered; just choose your path and get learning!

November 18th 2019, 4:23 pm

3 things to know about Android Studio from Android Dev Summit 2019

Android Developers Blog

Posted by Deepanshu Madan, Product Manager

Last month’s #AndroidDevSummit was jam-packed with announcements and technical much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. Earlier this week, we spotlighted Kotlin and Jetpack Compose, and today, we’re highlighting Android Studio, with the top three things you should know:

#1: Support for Jetpack Compose

For the best experience developing with Jetpack Compose, you can now use the latest version of Android Studio 4.0 in the canary channel, and benefit from smart editor features, such as New Project templates, code completion and the ability to immediately preview your Jetpack Compose UI.

#2: What’s new in Android Studio session

We covered both new features and successes of our quality initiative called Project Marble. On the quality aspect, we discuss improvements around hangs and latency, memory leak detection, automatic IDE heap sizing and build speed. Also during the session you will find demos on new developments & features in Android Studio such as Build Attribution tool which helps you understand and diagnose problems with your build system, Java 8 library desugaring, View binding, Kotlin Android live templates, an updated live Layout inspector which allows you to drill into resources right from the view to find where a property value originates in the source code with a 3D visualization of your view hierarchy.

#3: Android Studio Design tools

We introduced new features of Layout & Navigation editor including a new split view, new tools such as Multi-preview which allows you to visualize your layout in different configurations and MotionEditor, visual design editor for the MotionLayout layout type, making it easier to create and preview animations. The Motion Editor provides a simple interface for manipulating elements from the MotionLayout library that serves as the foundation for animation in Android apps. In previous releases, creating and altering these elements required manually editing constraints in XML resource files. Now, the Motion Editor can generate this XML for you, with support for start and end states, keyframes, transitions, and timelines.

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 15th 2019, 2:47 pm

Still Using InstallBroadcast? Switch to the Play Referrer API by March 1, 2020

Android Developers Blog

Posted by Marcus Leal, Product Manager, Google Play Ads

How do people find your app? It’s the million-dollar question for any developer, and the answer can help you make the right choices about your marketing strategy and budget. Accurate install referral data is crucial for understanding which traffic sources send users to download your app from the Google Play Store, as well as identifying fraudulent attempts to claim install attributions.

That’s why in 2017, we launched the Play Install Referrer API, which provides a reliable and robust mechanism for apps to retrieve referral information directly from the Play Store. It was a big step forward from the old install_referrer intent broadcast, so many developers made the switch right away, including App Attribution Program partners like Adjust, AppsFlyer, and Kochava. Now, because it’s been replaced by the new API, we’ve decided to deprecate the install_referrer intent broadcast mechanism on March 1, 2020. After this date, new versions of the Play Store app will no longer broadcast the install_referrer intent after app installs.

We are asking developers who still rely on the install_referrer to use the Play Install Referrer API instead. Among other advantages, the Install Referrer API offers better performance. uses a secure communication channel between your app and the Play store, and offers a more robust solution against spoof and attribution fraud.

If you still use the Broadcast API and the install_referrer intent to track your referrals, be sure to make the switch by March 1, 2020. Migration is easy, and the cost of adoption is low. Learn how to use the Play Install Referrer API to track your app installs today.

November 15th 2019, 12:47 pm

3 things to know about Kotlin from Android Dev Summit 2019

Android Developers Blog

Last month’s #AndroidDevSummit was jam-packed with announcements and technical much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. First up, we’re spotlighting Kotlin, with the top things you should know:

#1: Kotlin momentum on Android

Kotlin is at the heart of modern Android development — and we’ve been excited to see how quickly it has won over developers around the world. At Android Dev Summit we announced that nearly 60% of the top 1000 Android apps on the Play Store now use Kotlin, and we’re seeing more developers adopt it every day. Kotlin has helpful features like null safety, data classes, coroutines, and complete interoperability with the Java programming language. We’re doubling down on Kotlin with more Kotlin-first APIs even beyond AndroidX — we just released KTX extensions, including coroutines support, for Play Core. There’s never been a better time to give Kotlin a try.

#2: Learn more: Getting started with Kotlin & diving into advanced Kotlin with coroutines

If you’re introducing Kotlin into an existing codebase, chances are that you’ll be calling the Java programming language from Kotlin and vice versa. At Android Dev Summit, developer advocates Murat Yener, Nicole Borrelli, and Wenbo Zhu took a look at how nullability, getters, setters, default parameters, exceptions, and more work across the two languages.

For those looking into more advanced Kotlin topics, we recommend watching Jose Alcérreca's and Yigit Boyar's talk that explains how coroutines and Flow can fit together with LiveData in your app's architecture and one on testing coroutines by Sean McQuillan and Manuel Vivo.

#3: Get certified in Kotlin

We announced the launch of our Associate Android Developer certification in Kotlin. Now you can prove your proficiency with modern Kotlin development on Android to your coworkers, your professional network, or even your future employer. As part of this launch, you can take this exam at a discount when using the code ADSCERT99 through January 25.

It’s especially great to hear from you, the Android community, at events like Android Dev Summit: what do you want to hear more about, and how can we help with something you’re working on. We asked you to submit your burning questions on Twitter and the livestream, and developer advocates Florina Muntenescu and Sean McQuillan answered your Kotlin and coroutines questions live during our #AskAndroid segment:

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow Android Developers on Twitter. Thanks so much for letting us be a part of this experience with you!

Java is a registered trademark of Oracle and/or its affiliates.

November 13th 2019, 4:42 pm

3 things to know about Jetpack Compose from Android Dev Summit 2019

Android Developers Blog

Posted by Anna-Chiara Bellini, @dr0nequeen

Last month’s #AndroidDevSummit was jam-packed with announcements and technical much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. Earlier today, we spotlighted Kotlin and now we’re diving into Jetpack Compose, with the top three things you should know:

#1: Jetpack Compose is available in Developer Preview!

Jetpack Compose is Android’s modern toolkit for building native UI. It allows developers to write beautiful Android apps in an intuitive way, writing less code and accelerating development. It's powerful, because when writing code is a pleasure, you can focus on making your apps look beautiful and giving your users the best experience. At #AndroidDevSummit, we released the Developer Preview, to enable more feedback as we work towards bringing Jetpack Compose to beta next year. All you need to do is download the Android Studio 4.0 Canary build to try it out. To give feedback, feel free to reach out through the Kotlinlang Slack channel or our Bug Tracker to let us know what you think. It's your chance to help us build the right thing!

#2: See what's new in Jetpack Compose

At Android Dev Summit we showed how we've designed Compose to simplify development of Android apps, details on the new Material UI components we are building, and insights on some of the learnings that are informing the way we think about Compose. We also showcased how to write a small app, including layout and state management for a list of elements, in just a few lines of code.

Watch the Android Dev Summit session video to learn more:

Embed: what's new in Jetpack Compose

If you want to take a look behind the scenes, we also had a tech deep dive into the inner workings of Compose:

Embed: Understanding Compose

#3: Try it out, with our tutorial, sample app, and codelab!

Jetpack Compose is still in Developer Preview, which means it's a great time to try it out and let us know what you think about it. To help you with that, you can follow our tutorial, which will take you through the first steps of building a Compose app, and also take a look at our sample app, Jetnews, that shows what is currently possible with Jetpack Compose. We also have a popular codelab available to take you through how to build UIs with Compose, how to manage state in composable functions, and data flow principles in Compose.

Jetnews sample app

...and we also heard from you!

But Android Dev Summit isn’t just about what we’ve got to say; it’s also about you telling us what you’d like to see worked on to make your life easier. And this year, one thing we heard strongly from our community was how important it is to have the right tools to manage your layouts on so many different form factors and devices. Jetpack Compose has full Android Studio support and you can iterate fast with live Previews.

Android Dev Summit is over for this year, but you can keep giving us your feedback through the Kotlinlang Slack channel and Bug Tracker.

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 13th 2019, 12:07 pm

A modern approach to Android development, with Jetpack Compose and more!

Android Developers Blog

Posted by Stephanie Cuthbertson, Director, Product Management

Modern Android Development today

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!

November 12th 2019, 10:50 am

Introducing Google Play Points in the U.S.

Android Developers Blog

Posted by Paul Feng, Product Manager, Google Play

At Google Play, we continue to build new experiences to delight users and help developers succeed. Today, we’re excited to announce that the Google Play Points rewards program is expanding to the United States following successful launches in Japan and Korea, where millions of people have already enrolled. The program is designed to show appreciation to our users and help increase engagement with your games and apps.

Google Play Points rewards users for any purchase they make on Play — including apps, games, in-app items, music, movies, books, and subscriptions - and for downloading select apps and games. For all developers, if you’re on Play billing, users will earn points on your apps and games immediately.

Play Points can then be redeemed for unique rewards like special items and discounts in Candy Crush, Homescapes, Lords Mobile and many others. We’re fortunate to be working with a select group of developers to offer these rewards for the U.S. launch — including Niantic, King, Electronic Arts, Playrix, Jam City, Kabam, Ludia, Kongregate, and others. Users can also redeem their points for Google Play Credit, and spend it on your app or game just as they do today.

Users are finding value in our initial Play Points markets, Japan and Korea, and developers there are incredibly happy with the results. In the future, we look forward to working with additional partners to deliver more unique rewards to users as Google Play Points evolves.

Google Play Points is rolling out in the US over the next few days. If you’d like to enroll as a user in the program, open the Play Store app on your Android device, tap menu, then tap Play Points to get started.

How useful did you find this blog post?

November 12th 2019, 10:50 am

High engagement, larger screens: How Android developers can reach users on any device

Android Developers Blog

Posted by Allan Livingston, Product Management Director, Chrome OS App Ecosystem

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:

App developers driving engagement on larger screens

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.

Is your app optimized for large-screen devices? Here are a few things to consider:

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.

Build, test, and run Android apps on a Chromebook

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.

Build your apps with larger screens in mind

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.

November 12th 2019, 10:50 am

Privacy protections for physical activity in Android 10

Android Developers Blog

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.

November 12th 2019, 10:50 am

Modern app and game distribution on Google Play

Android Developers Blog

Posted by Kobi Glick, Product Lead, Google Play

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 future of Android distribution

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.

New tools to speed up your workflows and engineering velocity

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.

Get more users on your latest release with improved in-app updates

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:

Modern game distribution

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.

Here’s to another successful Playtime

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?

November 12th 2019, 10:50 am

One Biometric API Over all Android

Android Developers Blog

Posted by Isai Damier, Android Developer Platform Engineering (@isaidamier)

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.

A bit of background

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.

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.

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.

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

How it works

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.

To use the Biometric API in your app, do the following.

1. Add the Gradle dependency to your app module

$biometric_version is the latest release of the library

def biometric_version= '1.0.0-rc02'
implementation "androidx.biometric:biometric:$biometric_version"

2. Check whether the device supports biometric authentication

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.

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.

3. Create an instance of BiometricPrompt

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.

The AuthenticationCallback has three methods:

  1. onAuthenticationSucceeded() is called when the user has been authenticated using a credential that the device recognizes.
  2. onAuthenticationError() is called when an unrecoverable error occurs.
  3. onAuthenticationFailed() is called when the user is rejected, for example when a non-enrolled fingerprint is placed on the sensor, but unlike with onAuthenticationError(), the user can continue trying to authenticate.

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() {
           showMessage("Authentication failed for an unknown reason")

       override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
           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.

4. Build a PromptInfo object

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.

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.

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

Figure 1. Example face authentication flow using BiometricPrompt with setConfirmationRequired(false).

Figure 2. Example face authentication flow using BiometricPrompt with setConfirmationRequired(true) (default behavior).

5. Ask the user to authenticate

Now that you have all the required pieces, you can ask the user to authenticate.

val canAuthenticate = biometricManager.canAuthenticate()
if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) {
} 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.

Going forward

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.

November 12th 2019, 10:50 am

Android Developer Challenge: helpful innovation, powered by On-Device Machine Learning + you!

Android Developers Blog

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!

November 12th 2019, 10:50 am

All About Updates: More Treble

Android Developers Blog

Posted by Iliyan Malchev, Project Treble Architect

Android 10, our newest release, brings helpful tools for both developers and consumers like suggested actions in Smart Reply to help you multitask faster, Dark theme for battery saving, Focus mode that keeps you from digital distractions, and more. And with almost 50 changes related to privacy and security, Android 10 gives you greater protection, transparency, and control over your data than ever before. It is important to both users and developers that these new releases find their way to mobile devices as fast as possible. In this post, we’ll share an update on the progress we’ve made with Project Treble, an initiative to help manufacturers update devices to new versions of Android more quickly.

Wait and See

When we launched Project Treble with Android 8.0 Oreo, we asked ourselves if our investment would pay off. There were two factors to consider in measuring the effectiveness of the program:

The Partner Beta Program

One of the earliest indications that Project Treble was having a positive effect was our ability to run the Beta program for Android 9 Pie on many more devices from more manufacturers. In addition to Google Pixels, we had 7 device models from 7 OEMs supporting Android 9 Pie Beta.

With Android 10, this year, we increased the number of devices to 18 (again, in addition to Pixels), representing 12 OEMs. This represents a significant increase over the previous year and shows that Project Treble is having an impact.

Distribution Chart

Beta releases are great, but how did we fare on actual upgrades? To answer this question, we considered two points in time. The first point is right before we released Android 9. The second point is right before we released Android 10. By each of these points in time, the previous release had had a year to reach devices.

In late July, 2018, just before Android 9 Pie was launched in AOSP, Android 8.0 (Oreo) accounted for 8.9% of the ecosystem. By comparison, in late August 2019, just before we launched Android 10, Android 9 (Pie) accounted for 22.6% of the ecosystem. This makes it the largest fraction of the ecosystem, and shows that Project Treble has had a positive effect on updatability.

The adoption of Android Pie has been much higher than that of Android Oreo and Oreo MR1 when measured relative to the launch date.

Continuous Improvements in Updatability

The progress shown above results from work we did in Android 8.0 Oreo. We have made serious improvements with Android 9 Pie as well. The most significant one was our behind-the-scenes collaboration with silicon manufacturers. This work had the effect of reducing the average time to upgrade by more than 3 months, and we expect to see upgrades from Android 9 to Android 10 noticeably sooner this year.

There is also the sheer amount of hardening work on the architecture. We completed the seal between the vendor and system components of Android, which ensures that new versions of the top part of the OS run on older versions provided by our partners. We formalized the interface to the Android Linux kernel, expanded the Treble test suite (VTS), and did so much more. As a result, upgrades from Android 9 to Android 10 are going much more smoothly, as evidenced by direct feedback from our OEM and silicon partners.

We are beginning to see the effects already. This year, we saw two OEMs issue software updates to Android 10 on the day we announced it: Xiaomi and Essential. On the same day, OnePlus started a public beta program, and just a few days later, they started updating devices. HMD Global’s Nokia 8.1 just started receiving the update this week. In addition to these partners, many manufacturers such as ASUS, LG, Motorola, OPPO, Realme, Samsung, Sharp, Sony, Transsion, and Vivo have committed to updating some of their devices to Android 10 by the end of the year. Plus, new devices are already hitting shelves with Android 10, such as the OnePlus 7T. We are very excited that Samsung announced an open beta for Android 10 on their devices and started the rollout on October 12th, compared to November 15th last year.

The ROM developer community benefits from improved updatability as well. Mere days after the Android 10 launch, external developers ported it to 15 devices that launched on Android 8 and 9. This work was made much easier thanks to Project Treble, and we are very excited about the potential for open-source development on the OS. We made this even easier by publishing Google-signed Generic System Images (GSIs) and GMS binaries on, as well as posting detailed instructions for developers to try them on their own.

DSU and Project Mainline

In Android 10, we delivered Dynamic System Updates (DSU). For every device launching on Android 10 that supports DSU, developers are able to install Google-signed Generic System Images and boot into them without having to touch the factory ROMs on their devices. We showcased this work at Google I/O, switching painlessly between GSIs and Factory ROMs on Pixel devices.

We also implemented Project Mainline, which allows Google to update directly, via the Play Store, components of the OS that are critical to security and app compatibility. Project Mainline is to the core of the Android OS what Project Treble is to its foundation. It is a dramatic improvement in the velocity of updates of the OS components that fall under its umbrella.

Project Mainline also builds on the work we've done on a less obvious part of Android, called Google Mobile Services (GMS), which has been receiving updates in this way for years. GMS is the part of your Android device that makes it work seamlessly with all of Google's services. Yet another piece, called Webview, is at the core of your browser and every application that interacts with the web. This security- and correctness-critical component also gets updated via Play Store.

Looking Forward

The Android ecosystem is truly vast. There are hundreds of phone manufacturers, dozens of SoC (mobile CPU) models, and thousands of very different devices. Creating an updatability architecture that covers all of them is a complex task. Android is committed to updatability in all forms, whether it’s real-time updates to first- and third-party apps, developer libraries such as Jetpack, or regular security updates for Android devices.

It has been exciting to see the impact of our efforts on updatability. We have a lot more work to do, and we are tirelessly investing on improving updates. I am proud of the progress we all—Android, Google at large, and our many partners—have made so far. I am very optimistic about the future and look forward to sharing our work for the next release of Android.

November 12th 2019, 10:50 am
Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا