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

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 news...so 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 news...so 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 news...so 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.









Sources

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() {
           super.onAuthenticationFailed()
           showMessage("Authentication failed for an unknown reason")
       }

       override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
           super.onAuthenticationSucceeded(result)
           showMessage("Authentication was successful")
       }
   }

   val biometricPrompt = BiometricPrompt(context, executor, callback)
   return biometricPrompt
}

Instantiating the BiometricPrompt should be done early in the lifecycle of your fragment or activity (e.g., in onCreate or onCreateView). This ensures that the current instance will always properly receive authentication callbacks.

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")
              .setDeviceCredentialAllowed(true)
       .build()
   return promptInfo
}

For actions that require a confirmation step, such as transactions and payments, we recommend using the default option -- setConfirmationRequired(true) -- which will add a confirmation button to the UI, as shown in Figure 2.

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) {
   biometricPrompt.authenticate(promptInfo)
} else {
   Log.d(TAG, "could not authenticate because: $canAuthenticate")
}

And that’s it! You should now be able to perform authentication, using biometric credentials, on any device that runs Android 6.0 (API level 23) or higher.

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 android.com, 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

Celebrating 1 year of Google Play's Academy for App Success

Android Developers Blog

Posted by Dan Lavelle, Head of Learning Operations, Google Play

One year ago, we introduced the Academy for App Success , an e-learning platform to help apps and games businesses who want to grow on Android and Google Play. In that time we've seen tens of thousands of people register for free learning, complete over 50,000 courses, and provide an average course rating of 4.66 out of 5 stars. Thank you to everyone who has spent time learning about best practices, Play Console features, policies and other aspects that are critical to growing your business - we hope to see more of you in the future.

New content and features

Since the debut of Play Academy, we've been working hard to expand our offering to cover the topics you want to learn about. In this time, we have:

We've also been listening to your feedback and have updated Play Academy with content to cover key areas that might interest you:

Google Play policy

Subscription model for games

Track installs, uninstalls, and upgrades


What's next?

Our goal at Play Academy is to provide you with a free learning resource to optimize your use of Play Console features, learn best practices to apply to your app or game business, and stay on the right side of Google Play policy.

Over the coming year, we will continue to create and update content in these key areas, in addition to investing in new learning formats to complement our interactive e-learning content.

Start learning now!

At Google Play, we're looking forward to another great year of learning with you.

It's easy to get started with Play Academy - simply head to g.co/playacademy, sign up for your free account, and choose from over 75 e-learning courses and assessments. While you're there, leave a rating and review on any courses you complete.

How useful did you find this blog post?

October 22nd 2019, 1:34 pm

Here’s how to watch the 2019 Android Dev Summit!

Android Developers Blog

We’re less than 24 hours away from kicking off the 2019 Android Dev Summit, broadcasting live from the Google Events Center (MP7) in Sunnyvale, CA on October 23 & 24. We’ll be broadcasting the entire two days of the event live on YouTube, Twitter and on the Android Dev Summit website. Here’s what you need to know:

The keynote, sessions, sandbox and more, kicking off at 10AM PDT

The summit kicks off on October 23 at 10 a.m. PDT with a keynote, where you'll hear from Dave Burke, VP Engineering for Android, Stephanie Cuthbertson, Director of Product Management and others on the present and future of Android development. From there, we'll dive into two days of deep technical content from the Android engineering team, on topics such as Android platform, Android Studio, Android Jetpack, Kotlin, Google Play, and more. The full agenda is here so you can plan your summit experience.

#AskAndroid your pressing questions!

Tweet us your best questions using the hashtag #AskAndroid in the lead-up to the Android Dev Summit. We’ve gathered experts from Jetpack to Kotlin to Android 10, so we’ve got you covered. We’ll be answering your questions live between sessions on the livestream. Plus, we will share updates directly from the Google Events Center to our social channels, so be sure to follow along!

October 22nd 2019, 11:17 am

Android Automotive OS updates for developers

Android Developers Blog

Posted by Madan Ankapura, Product Manager, Android

Google’s vision is to bring a safe and seamless connected experience to every car. Since 2017, we have announced collaborations with vehicle manufacturers like Volvo Car Group, General Motors and others to power infotainment systems with Android Automotive OS, Google’s open-source Android platform, and to enable integration of Google technology and services. Now with the reveal of Volvo’s XC40 Recharge and the previously announced Polestar 2, we are making progress on our vision with these brand new, customized infotainment systems that feature real-time updates to the Google Assistant, Google Maps and automotive apps created by Google, and the global developer community.

Volvo XC40 Recharge & its infotainment unit

With more manufacturers adding Android Automotive OS based infotainment systems to their vehicles, app developers have an opportunity to reach even more users with innovative, and drive optimized experiences.

Concept image from GM on Maps & Media integration

Developing & testing media apps on emulator

At Google I/O 2019, we published design guidelines for developing media apps for cars, added wizard support to Android Studio, updated emulator to have car specific controls and the Android Automotive OS emulator system image. These latest features helped Android developers start to design, as well as develop and test their existing media apps to run on Android Automotive OS (review developer documentation here).

Today, we’re announcing that developers can download an updated Android Automotive OS emulator system image that includes the Google Play Store. This means developers no longer have to wait to get their hands on a vehicle, but can design, develop, run apps right within the emulator, and can now test distribution via Play Console by requesting access.

In addition to the apps announced at Google I/O, more media app developers, including Amazon Music, Audioburst and YouTube Music, are adapting their apps for Android Automotive OS. The process of porting existing media apps that support Android Auto to this platform is simple and requires minimal development resources.

Audioburst, Amazon Music and YouTube Music running on the Android Automotive OS emulator

And if you want to learn more about creating apps for Android Automotive OS — join us at Android Dev Summit 2019. Come talk to us in our sandbox, tune in via livestream on YouTube, or post on the automotive-developers Google Group or Stack Overflow using android-automotive tags.

We hope to see you there!

October 21st 2019, 1:24 pm

Introducing NDK r21: our first Long Term Support release

Android Developers Blog

Posted by Dan Albert, Android NDK Tech Lead

Android NDK r21 is now in beta! It’s been a longer than usual development cycle (four months since NDK r20), so there’s quite a lot to discuss for this release.

We have the usual toolchain updates, improved defaults for better security and performance, and are making changes to our release process to better accommodate users that need stability without hindering those that want new features.

New Minimum System Requirements

This release comes with new minimum system requirements. Following Android Studio and the SDK, 32-bit Windows is no longer supported. While this change will not affect most developers, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. Linux users must have glibc 2.17 or newer.

Release Cycle Changes and LTS

One release a year will be our Long Term Support (LTS) release for users that want stability more than they need new features. The release will undergo a longer beta cycle before being released, and will receive bug fixes as backports until next year’s LTS release. Generally releasing in Q4, our first LTS release will be NDK r21.

The non-LTS releases each year, which we call the “rolling” release, will be similar to our current process. These will be approximately quarterly releases of our latest set of features, which will only be patched later for critical toolchain fixes. If you want the latest features from Clang and libc++, this is the release for you.

More detail, including the criteria we will use to determine what will be backported, what kinds of bugs will trigger a point release, and the bar we hold each release to can be found documented on our GitHub Wiki.

New Features and Updates

There are quite a lot of new things in this release, resolving bugs and helping you write better, safer code.

We’ve updated GNU Make to version 4.2, which enables --output-sync to avoid interleaving output with error messages. This is enabled by default with ndk-build. This also includes a number of bug fixes, including fixing the pesky CreateProcess errors on Windows.

GDB has been updated to version 8.3, which includes fixes for debugging modern Intel CPUs.

Updated LLVM

As always, we’ve updated LLVM and all of its components (Clang, lld, libc++, etc) which includes many improvements.

The toolchain has been updated to r365631 (the master branch as of 10 July 2019). This includes fixes for quite a few bugs in the previous release, perhaps most importantly LLD no longer hangs when using multithreaded linking on Windows. OpenMP is now available as a dynamic library (and this is the new default behavior, so link with -static-openmp if you want to stick with the static runtime).

A handful of driver improvements have been made to reduce the amount of compiler configuration required by each build system as well. Build system owners should check the updated Build System Maintainers guide.

libc++ has been updated to r369764.

Fortify

Fortify is now enabled by default when using ndk-build or the CMake toolchain file (this includes ExternalNativeBuild users). Fortify enables additional checks in the standard library that can help catch bugs sooner and mitigate security issues. For example, without fortify the following code compiles fine:

    const char src[] = "this string is too long";
    char dst[10];
    strcpy(dst, src);

With fortify, the buffer overflow is diagnosed at compile-time:

    test.cpp:10:18: error: 'strcpy' called with string bigger than buffer
      strcpy(dst, src);
                     ^

It is not always possible for the compiler to detect this issue at compile-time. In those cases, a run-time check will be used instead that will cause the program to abort rather than continue unsafely.

If you’re using a build system other than ndk-build or CMake via the NDK’s toolchain file, this will not be enabled by default. To enable, simply define _FORTIFY_SOURCE=2. The most reliable way to do this is by adding -D_FORTIFY_SOURCE=2 to your compiler flags.

Clang can also statically detect some of these issues by using -Wfortify-source (also new in r21). This is on by default, but it’s recommended to enforce fixing issues with -Werror=fortify-source. Use this in addition to the C library features, not instead of, since the warnings do not cover the same cases as the C library extension, nor can it add run-time checks.

Note that because run-time support is required for fortify and the feature was gradually added to Android over time, the exact set of APIs protected by fortify depends on your minSdkVersion. Fortify is an improvement, but it is not a replacement for good tests, ASan, and writing safe code.

See FORTIFY in Android for an in-depth explanation of fortify.

Other updates

64-bit requirement

Since August 2019, all existing and new apps are now required to support 64-bit before they can be released to Google Play; there’s an extension for a limited set of apps. For more information and help on adding support for 64-bit, see our guide.

Neon by default

Arm code is now built with Neon by default. In a previous release we enabled it conditionally based on minSdkVersion, but given the very small number of devices that don’t support Neon we now enable it unconditionally. This offers improved performance on all 32-bit Arm devices (64-bit Arm always had this, and it does not affect Intel ABIs).

As before, this behavior can be disabled for apps that need to continue supporting devices without Neon. Alternatively, those devices can be blacklisted in the Play Console. See https://developer.android.com/ndk/guides/cpu-arm-neon for more information.

Up Next

Have a look at our roadmap to see what we’re working on next. The next few big things coming up are package management and better CMake integration.

October 17th 2019, 1:46 pm

Previewing #AndroidDevSummit: Sessions, App, & Livestream Details

Android Developers Blog

Posted by The #AndroidDevSummit team

In two weeks, we'll be welcoming Android developers from around the world at Android Dev Summit 2019, broadcasting live from the Google Events Center (MP7) in Sunnyvale, CA on October 23 & 24. Whether you’re joining us in person or via the livestream, we’ve got a great show planned for you; starting today, you can read more details about the keynote, sessions, codelabs, sandbox, the mobile app, and how online viewers can participate.

The keynote, sessions, sandbox and more, kicking off at 10AM PDT

The summit kicks off on October 23 at 10 a.m. PDT with a keynote, where you'll hear from Dave Burke, VP Engineering for Android, and others on the present and future of Android development. From there, we'll dive into two days of deep technical content from the Android engineering team, on topics such as Android platform, Android Studio, Android Jetpack, Kotlin, Google Play, and more.

The full agenda is now available, so you can start to plan your summit experience. We'll also have demos in the sandbox, hands-on learning with codelabs, plus exclusive content for those watching on the livestream.

Get the Android Dev Summit app on Google Play!

The official app for Android Dev Summit 2019 has started rolling out on Google Play. With the app, you can explore the agenda by searching through topics and speakers. Plan your summit experience by saving events to your personalized schedule. You’ll be able to watch the livestream and find recordings after sessions occur, and more. (By the way, the app is also an Instant app, so with one tap you can try it out first before installing!)

2019 #AndroidDevSummit app

A front-row seat from your desk, and #AskAndroid your pressing questions!

We’ll be broadcasting live on YouTube and Twitter starting October 23 at 10 a.m. PDT. In addition to a front row seat to over 25 Android sessions, there will be exclusive online-only content and an opportunity to have your most pressing Android development questions answered live, broadcast right from the event.

Tweet us your best questions using the hashtag #AskAndroid in the lead-up to the Android Dev Summit. We’ve gathered experts from Jetpack to Kotlin to Android 10, so we’ve got you covered. We’ll be answering your questions live between sessions on the livestream. Plus, we will share updates directly from the Google Events Center to our social channels, so be sure to follow along!

October 9th 2019, 6:54 pm

Continuous testing with new Android emulator tools

Android Developers Blog

Posted by Lingfeng Yang, Android Studio team

Developers often use the Android Emulator during their day-to-day development to quickly test the latest changes before they are being committed. In addition, developers are increasingly using the emulator in their continuous integration (CI) systems to run a larger suite of automated tests. To better support this use-case, we are open sourcing the Android Emulator Container Scripts and improving the developer experiences around two pain points:

  1. Deployability - finding and running the desired version of Android Emulator.
  2. Debuggability - tracking down bugs from remote instances of Android Emulator.

Deployability

Android supports a wide variety of hardware and software configurations, and the Android Emulator is no different. However, this wide variety can create confusion over environment configurations. How should developers obtain emulators and system images? What drivers are required? How do you run with or without CPU or GPU acceleration? (etc. etc.)

To address this we have launched:

To increase reproducibility, the underlying Dockerfile template makes the required command line flags and system dependencies more explicit (and reproducible via building Docker images from them). For hardware acceleration, note the --privileged flag that is passed to run.sh; we assume CPU acceleration is available when running the emulator, and --privileged is needed to run the containers with CPU acceleration (KVM) enabled.

For more details on how to create and deploy the Android Emulator image, go to the README.

Debuggability

When the emulator is running and a test or the emulator fails, it can be difficult to dive into the running environment and diagnose the error. Often, diagnosis requires direct interaction with the virtual device. We provide two mechanisms for direct interaction:

  1. ADB
  2. Remote streaming

In the case of ADB, we allow all commands, such as logcat and shell, by forwarding a particular port from the Docker guest to the host. Because the current port is 5555, we'll need to collect more feedback and do more research on how best to separate ports across different containers.

Remote streaming

Security note: With remote streaming, keep in mind that once the service is started, anyone who can connect to your computer on port 80/443 can interact with the emulator. So be careful with running this on a public server!

With remote streaming, you can run the emulator in a container, which is as interactive as running locally. Running the emulator in a container makes it easier to debug issues that can be hard to discover using ADB commands. You can access the emulator using a browser with WebRTC, which is used to stream the video, and gRPC, which is used to send mouse and keyboard events to the emulator. Remote streaming requires three containers:

  1. A container that hosts the latest emulator
  2. A container with an Envoy web proxy needed for gRPC
  3. A container with nginx to serve the React web app

You can compose the Docker containers together using docker-compose, as described in the README. The containers bind to port 80 and 443, so make sure you do not have a web server running. A self-signed certificate will be offered if you point the browser to the host. If you point your browser to the host you should see something like the image below:

Again, keep in mind that anyone who can connect to your host can interact with the emulator. So be careful with running this on a public server!

Let’s scale testing!

Testing can seem to be a tax on development time. However, as many seasoned developers have seen, proper automated testing can increase development velocity as the code base becomes bigger and more complex. Continuous testing should give you confidence that the change you make won’t break your app.

October 2nd 2019, 5:22 pm

Unlock your creativity with Google Play Pass

Android Developers Blog

Posted by Shazia Makhdumi, Global Head of Play Pass Business Development

With over 2.5 billion active Android devices, Google Play helps your apps and games get discovered by billions of users worldwide. And from the latest Google Play Store visual refresh to the Indie Games Showcase, we’re constantly working to help users find apps and games they love while helping you grow successful businesses. Today we’re excited to announce the US launch of Google Play Pass, a new subscription service offering access to hundreds of apps and games, completely free of ads and in-app purchases. Play Pass provides subscribers with a high-quality, curated collection of titles–with new titles added frequently.

Letting diverse, high-quality content shine

Play Pass is designed to enable Google Play users to better experience the variety of content on Play, and all types of apps and games can participate. “For a small studio like ours, being part of Play Pass makes a huge amount of sense,” said Jon Ingold of inkle. “We have the expertise and the creative freedom to create games unlike anything subscribers have ever played before, and we hope they will be thrilled by what they discover as they lose themselves in the worlds we’ve made.”

A new way to make money

Being a part of Google Play Pass’s curated collection of apps and games can help you attract new users who may not have discovered your titles on their own. Subscribers can find your content either through the new “Play Pass” tab or by looking for the Play Pass “ticket” badge that indicates apps and games unlocked with Play Pass. And the more value subscribers find in your title, the more revenue you’ll earn on a recurring basis.

In addition, for a limited time, we’re offering a low introductory price for Play Pass subscribers so that even more users will subscribe and discover Play Pass content. Google is funding this launch offer so that you can benefit from subscriber interest without impacting the revenue you can earn.

Play Pass on Google Play

Little work, lots of opportunity

The same APK that distributes your app or game in the Google Play Store can be used for Play Pass with minimal development work, so you can keep one version of your app or game updated for all of your users. We'll make sure your content is easily identifiable as part of Play Pass and enjoyed without interruptions, so you can stay focused on creating amazing experiences without compromise.

Express interest

If you’re building a great experience that Play Pass users would love, get more information and fill out this form to express interest in participating. Play Pass is currently invitation-only, though we’ll regularly be inviting more developers to participate, so stay tuned!

How useful did you find this blog post?

September 23rd 2019, 12:40 pm

New! Android Kotlin codelab courses are here

Android Developers Blog

Posted by Jocelyn Becker, Senior Program Manager, Google Developer Training

Want to learn to build Android apps in Kotlin? Get started with the Kotlin Bootcamp for Programmers and Developing Android apps in Kotlin codelabs courses.

Google and Udacity currently offer video-based courses for Kotlin Bootcamp and How to build Android apps in Kotlin. To help people that learn in different ways, we have recently reworked these courses to publish them as tutorial-based codelab courses. More than 2.5 million users have worked through Google codelabs like this just this year.

Kotlin Bootcamp

Google provides first class support for building Android apps in Kotlin, including Kotlin-friendly Android APIs and API extensions. Kotlin fully interoperates with the Java programming language and libraries, and is included with IntelliJ and Android Studio.

In the Kotlin Bootcamp course, you will learn everything you need to program in Kotlin, beginning with the basics such as how to write Kotlin statements, and working up to functional manipulation such as extending builtin functions.

If you already know how to program, the Kotlin Bootcamp provides the foundation you'll need to build Android apps in Kotlin.

Start the Kotlin Bootcamp now!

Building Android apps in Kotlin

When you feel comfortable with Kotlin, you can dive right into building Android apps. This course takes you from "Hello World" to connecting with the world. You start building a basic interactive user interface on one screen, and end with a multi-screen Google Developer Group (GDG) Finder app that gets data from a live server on the internet. In between, you learn about Android Jetpack components, such as Room for databases, Work Manager for background processing, the Navigation component, and more. You'll use popular community libraries to simplify common tasks, such as Glide for image loading, Retrofit for networking, and Moshi for JSON parsing. The course teaches key Kotlin features such as coroutines to help you write your app code more quickly and concisely.

In each lesson, you will work with a realistically architected app and implement key features. For example, you start out learning how to deploy a dice roller app. You learn how to implement navigation by building the "Android Trivia" game. You learn how to create a Room database by building a sleep tracker app.

Overall, you will create and work with more than 10 apps, so, by the end of this course, you will have a portfolio of example code that you can use to realize your own amazing app ideas!

Get started now!

September 20th 2019, 4:11 pm

Trust but verify attestation with revocation

Android Developers Blog

Posted by Rob Barnes & Shawn Willden, Android Security & Privacy Team

Billions of people rely on their Android-powered devices to securely store their sensitive information. A vital component of the Android security stack is the key attestation system. Android devices since Android 7.0 are able to generate an attestation certificate that attests to the security properties of the device’s hardware and software. OEMs producing devices with Android 8.0 or higher must install a batch attestation key provided by Google on each device at the time of manufacturing.

These keys might need to be revoked for a number of reasons including accidental disclosure, mishandling, or suspected extraction by an attacker. When this occurs, the affected keys must be immediately revoked to protect users. The security of any Public-Key Infrastructure system depends on the robustness of the key revocation process.

All of the attestation keys issued so far include an extension that embeds a certificate revocation list (CRL) URL in the certificate. We found that the CRL (and online certificate status protocol) system was not flexible enough for our needs. So we set out to replace the revocation system for Android attestation keys with something that is flexible and simple to maintain and use.

Our solution is a single TLS-secured URL (https://android.googleapis.com/attestation/status) that returns a list containing all revoked Android attestation keys. This list is encoded in JSON and follows a strict format defined by JSON schema. Only keys that have non-valid status appear in the list, so it is not an exhaustive list of all issued keys.

This system allows us to express more nuance about the status of a key and the reason for the status. A key can have a status of REVOKED or SUSPENDED, where revoked is permanent and suspended is temporary. The reason for the status is described as either KEY_COMPROMISE, CA_COMPROMISE, SUPERSEDED, or SOFTWARE_FLAW. A complete, up-to-date list of statuses and reasons can be found in the developer documentation.

The CRL URLs embedded in existing batch certificates will continue to operate. Going forward, attestation batch certificates will no longer contain a CRL extension. The status of these legacy certificates will also be included in the attestation status list, so developers can safely switch to using the attestation status list for both current and legacy certificates. An example of how to correctly verify Android attestation keys is included in the Key Attestation sample.

September 6th 2019, 2:51 pm

Expand your app beyond mobile to reach Android users at large

Android Developers Blog

Posted by Sameer Samat, Vice President, Platforms & Ecosystems

From day one, we designed Android to be a flexible, adaptive platform.

Most people picture a smartphone when they think of Android, but Android also powers an amazing number of large-screen devices. In fact, there are more than 175 million Android tablets with the Google Play store,1 making Android tablets a vital form factor for Google and our OEM partners today. Android apps also run on Chrome OS laptops, and the number of monthly active users who enabled Android apps grew 250% in just the last year.2

Here at Google, we’re excited to see how you can take advantage of large-screen formats - including Samsung’s new Galaxy Tab S6, the upcoming Lenovo™ Smart Tab M8 with Google Assistant, the upcoming Samsung Fold, and other devices launching this week at IFA. Our OEM partners are building experiences that help users every day:

From the start, Android was designed as a platform that could handle multiple screen sizes. Over the years, we’ve continued to add functionality for developers to accommodate new devices and form factors.

Android’s layout system helps applications smoothly resize and adjust their layout interactively.

By optimizing your app to take advantage of different form factors, developers have an opportunity to deliver richer, more engaging experiences to millions of users on larger screens. And if you don’t have access to physical devices, the Android Emulator supports all of the form factors mentioned above, from Chrome OS to phones and tablets.


Developers of apps like Mint, Evernote, and Asphalt are just a few who have seen success from taking their existing APK to larger screens.

To learn more about optimizing your Android apps for richer experiences on tablets, Chrome OS laptops, foldables, and more, join us at the Android Developer Summit on October 23-24 — either in person or via the livestream — or check out our recap videos on YouTube.

Sources:

[1] The number of tablets only accounts for devices that have the Google Play Store installed (for example, this excludes tablets in China); the actual number of tablets capable of running Android applications is much larger.

[2] Google Internal Data, March 2018 to March 2019.

September 5th 2019, 3:03 pm

Welcoming Android 10!

Android Developers Blog

Posted by Posted by Stephanie Cuthbertson, Senior Director of Product Management, Android

After more than a year of development and months of testing by early adopters, we’re ready to introduce Android 10 to the world!

Android 10 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.

Today we're releasing the Android 10 source code to Android Open Source Project (AOSP) and making it available to the broader ecosystem. We’re also starting the official Android 10 rollout to all three generations of Pixel devices worldwide. Many partner devices, including those in the Beta program, will receive the update by the end of the year.

Thank you for your support during this year’s Beta -- more than 200,000 of you tested early releases on 26 different Beta devices, reporting 20,000 unique issues. That’s on top of the many articles, discussions, surveys, and in-person meetings where you voiced your thoughts, and the work you did to make your apps compatible by today’s release. Your support and engagement are what make Android such an amazing platform. Together with our OEM partners you’ve created more excitement for this Android release than we’ve ever had. In fact, Android 10 will be available on more devices than any other previous release. Android is fortunate to have such a passionate community!

To get started developing for Android 10, visit developer.android.com/10.

What’s in Android 10?

Here’s a look at what’s in Android 10 and how you can use it today. Make sure to check out our Keyword blog for more too!

Innovation and new experiences

With Android 10 you can take advantage of the latest hardware and software innovations to build amazing app experiences for users.

Foldables - Building on robust multi-window support, Android 10 extends multitasking across app windows and provides screen continuity to maintain your app state as the device folds or unfolds. For details on how to optimize your apps for foldables, see the developer guide.

5G networks promises to deliver consistently faster speeds and lower latency,and Android 10 adds platform support for 5G and extends existing APIs to help you take advantage of these enhancements. You can use connectivity APIs to detect if the device has a high bandwidth connection and check whether the connection is metered. With these, your apps and games can tailor rich, immersive experiences to users over 5G.

Live Caption automatically captions media playing on users’ devices, from videos to podcasts and audio messages, across any app. The ML speech models run right on the phone, and no audio stream ever leaves the device. For developers, Live Caption is optional, but expands the audience for your apps and games by making your content more accessible with a single tap. Live Caption is coming to Pixel devices this fall, and we’re working closely with our partners to launch it broadly on devices running Android 10.

Smart Reply in notifications - Android 10 uses on-device ML to suggest contextual actions in notifications, such as smart replies for messages or opening a map for an address in the notification. We’ve built this feature with user privacy in mind, keeping the ML processing completely on the device. Your apps can take advantage of this feature right away, or you can opt-out if you’d rather generate your own suggestions.

Smart Reply can suggest actions based on notification content.

Dark theme - Android 10 adds a system-wide dark theme that’s ideal for low light and helps save battery. You can build a custom dark theme for your app or let the system create one dynamically from your current theme. See the developer guide for details.

Dark theme in Google Keep

Gesture navigation - Android 10 introduces a fully gesture navigation mode that eliminates the navigation bar area and allows apps to use the full screen to deliver richer, more immersive experiences. Get started optimizing your app today.

Gesture navigation gives apps the full screen for content

Privacy for users

Privacy is a central focus in Android 10, from stronger protections in the platform to new features designed with privacy in mind. Building on previous releases, Android 10 includes extensive changes to protect privacy and give users control, with improved system UI, stricter permissions, and restrictions on what data apps can use. See the Android 10 developer site for details on how to support these in your apps.

Giving users more control over location data - Users have more control over their location data through a new permission option -- they can now allow an app to access location only while the app is actually in use (running in the foreground). For most apps this provides a sufficient level of access, while for users it’s a big improvement in transparency and control. To learn more about location changes, see the developer guide or our blog post.

Protecting location data in network scans - Most of the APIs for scanning networks already required the coarse location permission. Android 10 increases the protection around those APIs by requiring the fine location permission instead.

Preventing device tracking - Apps can no longer access non-resettable device identifiers that could be used for tracking, including device IMEI, serial number, and similar identifiers. The device's MAC address is also randomized when connected to Wi-Fi networks by default. Read the best practices to help you choose the right identifiers for your use case, and see the details here.

Securing user data in external storage - Android 10 introduces a number of changes to give users more control over files in external storage and the app data within them. Apps can store their own files in their private sandboxes, but must use MediaStore to access shared media files and use the system file picker to access shared files in the new Downloads collection. Learn more here.

Blocking unwanted interruptions - Android 10 prevents app launches from the background that unexpectedly jump into the foreground and take over focus from another app. Learn more here.

Security

On Android we’re always working to assess our ongoing security investments; we refer to this as measurable security. One way we measure our ongoing investments is through third party analyst research such as Gartner’s May 2019 Mobile OSs and Device Security: A Comparison of Platforms report (subscription required) which scored Android the highest possible rating in 26 out of 30 categories, ahead on multiple points from authentication to network security and malware protection. Read more about our long-term work on Security in Quantifying Measurable Security. But there is no finish line when it comes to Security. In Android 10, we’ve introduced even more features to keep users secure through advances in encryption, platform hardening, and authentication.

Storage encryption - All compatible devices launching with Android 10 are required to encrypt user data, and to make this more efficient, Android 10 includes Adiantum, our new encryption mode.

TLS 1.3 by default - Android 10 also enables TLS 1.3 by default, a major revision to the TLS standard with performance benefits and enhanced security.

Platform hardening - Android 10 also includes hardening for several security-critical areas of the platform, and updates to the BiometricPrompt framework with robust support for face and fingerprint in both implicit and explicit authentication. Read more about Android 10 security updates here.

Camera and media

Dynamic depth for photos - Apps can now request a Dynamic Depth image, which consists of a JPEG, XMP metadata related to depth related elements, and a depth and confidence map embedded in the same file. These let you offer specialized blurs and bokeh options in your app. Dynamic Depth is an open format for the ecosystem and we're working with our partners to bring it to devices running Android 10 and later.

With Dynamic Depth image you can offer specialized blurs and bokeh options in your app

Audio playback capture - Now any app that plays audio can let other apps capture its audio stream using a new audio playback capture API. In addition to enabling captioning and subtitles, the API lets you support popular use-cases like live-streaming games. We’ve built this new capability with privacy and copyright protection in mind, so the ability for an app to capture another app's audio is constrained. Read more in our blog post.

New audio and video codecs - Android 10 adds support for the open source video codec AV1, which allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android 10 supports audio encoding using Opus - an open, royalty-free codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.

Native MIDI API - For apps that perform their audio processing in C++, Android 10 introduces a native MIDI API to communicate with MIDI devices through the NDK. This API allows MIDI data to be retrieved inside an audio callback using a non-blocking read, enabling low latency processing of MIDI messages. Give it a try with the sample app and source code here.

Vulkan everywhere - Vulkan 1.1 is now a requirement on all 64-bit devices running Android 10 and higher, and a recommendation for all 32-bit devices. We already see significant momentum on Vulkan support in the ecosystem - among devices running Android N or above, over half support Vulkan 1.0.3 or better. With the new requirement in Android 10, we expect to see adoption rise even further in the coming year.

Connectivity

Improved peer-to-peer and internet connectivity - We’ve refactored the Wi-Fi stack to improve privacy and performance, and also to improve common use-cases like managing IoT devices and suggesting internet connections -- without requiring the location permission. The network connection APIs make it easier to manage IoT devices over local Wi-Fi, for peer-to-peer functions like configuring, downloading, or printing. The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity.

Wi-Fi performance modes - Apps can now request adaptive Wi-Fi by enabling high performance and low latency modes. These can be a great benefit where low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use-cases. The platform works with the device firmware to meet the requirement with the lowest power consumption.

Android foundations

ART optimizations - Improvements in the ART runtime help your apps start faster, consume less memory, and run smoother -- without requiring any work from you. ART profiles delivered by Google Play let ART pre-compile parts of your app even before it's run. At runtime, Generational Garbage Collection makes garbage collection more efficient in terms of time and CPU, reduces jank, and helps apps run better on lower-end devices.

This chart shows the percentage improvement in startup time for specific apps when tested using Play profiles.

Neural Networks API 1.2 - We’ve added 60 new operations including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimizations. This lays the foundation for accelerating a much greater range of models -- such as those for object detection and image segmentation. We’re working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.

Faster updates, fresher code

With Android 10 we’re continuing our focus on bringing the new platform to devices more rapidly, working closely with our device-makers and silicon partners like Qualcomm. Project Treble has played a key role, helping us bring 18 partner devices into this year’s Beta program along with 8 Pixel devices -- more than double the number from last year. Even better, we expect those devices to get the official Android 10 update by the end of this year, and we’re working with several partners on other new flagship launches and updates. We’re seeing great momentum with Android 10 already, and more devices than any other previous Android release will be getting this new version in the months ahead.

Android 10 is also the first release to support Project Mainline (officially called Google Play system updates), our new technology for securing Android users and keeping their devices fresh with important code changes - direct from Google Play. With Google Play system updates, we’re able to update specific internal components across all devices running Android 10 and higher, without requiring a full system update from the device manufacturer. We’re expecting to bring the first updates to consumer devices over the next several months.

For developers, we expect these updates in Android 10 to help drive consistency of platform implementation broadly across devices, and over time bring greater uniformity that will reduce your development and testing costs.

Get your apps ready for Android 10!

Now with today’s public release of Android 10 and updates coming soon to devices, we’re asking all Android developers to update your current apps for compatibility as soon as possible to give your users a smooth transition to Android 10.

Here’s how to do it:

Getting apps tested and ready for the new version of Android is crucial to faster platform updates throughout the ecosystem, so please prioritize this work if possible.

Enhance your app with Android 10 features and APIs

Next, when you're ready, dive into Android 10 and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for every app:

We recommend these if relevant for your app:

To read about all of the new features and changes, visit the Android 10 developer site.

To get started developing, download the official API 29 SDK and tools into Android Studio 3.5 or higher. Then follow these instructions to configure your environment.

Coming to a device near you!

Android 10 will begin rolling out today to the three generations of Pixel phones -- Pixel 3 (and 3a), Pixel 2, and even the original Pixel! All Pixel devices will get the update over the next week, including those enrolled in this year’s Beta program. If you own a Pixel device, watch for your official over-the-air update coming soon!

As always, the system images for Pixel devices are available here for manual download and flash, and you can get the latest Android Emulator system images via the SDK Manager in Android Studio. For broader testing on other Treble-compliant devices, Generic System Images (GSI) are available here.

If you're looking for the Android 10 source, you'll find it here in the Android Open Source Project repository under the Android 10 branches.

What’s next?

We'll soon be closing the Android Beta issue tracker and Feedback app, but please keep the feedback coming! You can file a new issue against Android 10 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the Android Beta program this year! You gave us great feedback, and filed thousands of issues that helped us to make the Android 10 platform great for consumers and developers.

We're looking forward to seeing your apps on Android 10!

September 3rd 2019, 1:17 pm

Committed to a safer Google Play for Families

Android Developers Blog

Posted by Kanika Sachdeva, Product Manager, Google Play

In May, we launched new Families policies to provide additional protections for children and families on Google Play. As part of this policy change, we’re requiring all developers to provide information on their app’s target audience and content via the Google Play Console by September 1st. Thanks to everyone who has completed it already. If you haven’t done so, please fill it out as soon as possible and consult our developer guide and training course for additional information.

Apps that include children in their target audience need to adhere to our new policy requirements including appropriate content, showing suitable ads (learn more), and disclosing personally identifiable information correctly. We’ve found that checking for these requirements takes longer than the normal review process, and can result in review times of up to 7 days (or longer in certain exceptional circumstances). Apps who submit inaccurate responses in the target audience and content section will also be subject to these reviews. You can find more details on Google Play’s app submission process in this Help Center article.

We respect that you are running a business and longer review times can impact how you work. Our goal is to prepare you for this change and minimize disruptions for you. These apps will be subject to extended reviews for every update, and you may need to update your processes to accommodate for additional review time. Suggestions for how to best adapt to this change include submitting your app at least a week before any important launch dates and (unless urgent) avoid resubmitting your app while it is under review.

These changes help make the Play Store safer through deeper and longer reviews, which is a tradeoff we think everyone is willing to make. Thanks for your continued support in building a positive and safe experience for all users on Google Play.

How useful did you find this blog post?

August 30th 2019, 2:53 pm

Expanding bug bounties on Google Play

Android Developers Blog

Posted by Adam Bacchus, Sebastian Porst, and Patrick Mutchler — Android Security & Privacy

We’re constantly looking for ways to further improve the security and privacy of our products, and the ecosystems they support. At Google, we understand the strength of open platforms and ecosystems, and that the best ideas don’t always come from within. It is for this reason that we offer a broad range of vulnerability reward programs, encouraging the community to help us improve security for everyone. Today, we’re expanding on those efforts with some big changes to Google Play Security Reward Program (GPSRP), as well as the launch of the new Developer Data Protection Reward Program (DDPRP).

Google Play Security Reward Program Scope Increases

We are increasing the scope of GPSRP to include all apps in Google Play with 100 million or more installs. These apps are now eligible for rewards, even if the app developers don’t have their own vulnerability disclosure or bug bounty program. In these scenarios, Google helps responsibly disclose identified vulnerabilities to the affected app developer. This opens the door for security researchers to help hundreds of organizations identify and fix vulnerabilities in their apps. If the developers already have their own programs, researchers can collect rewards directly from them on top of the rewards from Google. We encourage app developers to start their own vulnerability disclosure or bug bounty program to work directly with the security researcher community.

Vulnerability data from GPSRP helps Google create automated checks that scan all apps available in Google Play for similar vulnerabilities. Affected app developers are notified through the Play Console as part of the App Security Improvement (ASI) program, which provides information on the vulnerability and how to fix it. Over its lifetime, ASI has helped more than 300,000 developers fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users until the issue is fixed.

To date, GPSRP has paid out over $265,000 in bounties. Recent scope and reward increases have resulted in $75,500 in rewards across July & August alone. With these changes, we anticipate even further engagement from the security research community to bolster the success of the program.

Introducing the Developer Data Protection Reward Program

Today, we are also launching the Developer Data Protection Reward Program. DDPRP is a bounty program, in collaboration with HackerOne, meant to identify and mitigate data abuse issues in Android apps, OAuth projects, and Chrome extensions. It recognizes the contributions of individuals who help report apps that are violating Google Play, Google API, or Google Chrome Web Store Extensions program policies.

The program aims to reward anyone who can provide verifiably and unambiguous evidence of data abuse, in a similar model as Google’s other vulnerability reward programs. In particular, the program aims to identify situations where user data is being used or sold unexpectedly, or repurposed in an illegitimate way without user consent. If data abuse is identified related to an app or Chrome extension, that app or extension will accordingly be removed from Google Play or Google Chrome Web Store. In the case of an app developer abusing access to Gmail restricted scopes, their API access will be removed. While no reward table or maximum reward is listed at this time, depending on impact, a single report could net as large as a $50,000 bounty.

As 2019 continues, we look forward to seeing what researchers find next. Thank you to the entire community for contributing to keeping our platforms and ecosystems safe. Happy bug hunting!

August 29th 2019, 12:47 pm

The Google Play store’s visual refresh

Android Developers Blog

Boris Valusek, Design Lead, Google Play

The Google Play Store has over two billion monthly active users coming to find the right app, game, and other digital content. To improve the overall store experience, we’re excited to roll out a complete visual redesign. Aligning with Material design language, we’re introducing several user-facing updates to deliver a cleaner, more premium store that improves app discovery and accessibility for our diverse set of users.

To make browsing faster and easier, we’ve introduced a new navigation bar at the bottom of the Play Store on mobile devices and a new left navigation on tablets and Chrome OS. There are now two distinct destinations for games and apps, which helps us better serve users the right kind of content. Once users find the right app or game, the updated store listing page layout surfaces richer app information at the top of each page as well as a more prominent call-to-action button. This makes it easier for users to see the important details and make a decision to install your app. You’ll also notice our new icon system with a uniform shape, helping content to stand out more over UI. If you haven’t done so already, make sure to update your icon following the new icon specifications as soon as possible.

If you’re looking for best practices to make a compelling store listing page, we have several resources to help. To ensure your page resonates well with Android users, use store listing experiments to test for the best app icon, images, video, and descriptions on Google Play. You can also tailor your marketing messages to specific user groups based on their country, install state or even pre-registration by creating custom store listings. For even more, try our free e-learning resource, Academy for App Success.

How useful did you find this blogpost?

August 21st 2019, 1:01 pm

Android Studio 3.5: Project Marble goes into stable

Android Developers Blog

Posted by Jamal Eason, Product Manager, Android

Have you ever wished that Android Studio was faster, more performant, and more memory efficient? If so, then download Android Studio 3.5 today. This stable version of Android Studio is a different kind of release where the Android Studio team took a step back from large feature work for eight months and instead focused on product quality to further accelerate your day-to-day app development. We called this initiative Project Marble, and it focused on making the fundamental features and flows of Android Studio & Emulator rock-solid by looking at three core areas: system health, feature polish, and bugs. Working on Project Marble was is in direct response to feedback from you and we continue to welcome any further feedback you have.

To improve system health in Android Studio, we first created a new set of infrastructure and internal dashboards to better detect performance problems. We did this to establish a safety net to catch issues that are typically difficult to catch with regular unit testing. Then, the team addressed a range of issues from fixing over 600 bugs, 50 memory leaks, 20 IDE hangs, and improving XML & Kotlin typing latency. Additionally, for the Android Emulator, we decreased the CPU and memory impact on your development machine. Project Mable was a focused period to work on the IDE and Android Emulator system health but it also uncovered a set of quality areas we will continue to work on going forward.

On top of memory and performance, we spent time polishing and fixing core user facing feature areas. For example, we took a look at the app deployment flow to a device, and completely re-architectured and replaced Instant Run with Apply Changes so that it’s more reliable and trusted. With Apply Changes, we no longer modify an APK during your build but instead, we use runtime instrumentation to redefine classes on the fly. If you want to quickly edit code and see code changes, you should try Android Studio 3.5 today.

Lastly, over the course of Project Marble we fixed bugs which landed in Android Studio in 3.5. We are thankful to those who filed bug reports and engaged with us on social media. We are especially thankful for the over 40 external contributors in the Android community that diligently worked with us in filing and resolving critical quality issues in Android Studio 3.5. Project Marble is not the end of quality work for the Android Studio team, but this latest stable release is a major milestone of our on-going quality investment into the IDE. With the quality work and new infrastructure put in place during Project Marble, we hope that you are even more productive in developing Android apps when you download and use Android Studio 3.5.

There are many quality changes we made to Android Studio 3.5. To see the full list of changes, see the Android Studio 3.5 beta release blog and release notes. But you can dive into some of the highlights of the changes below:

System Health

System health improvements during Project Marble was a combination of memory performance, typing & user interfaces freezes, build speed, CPU usage, and I/O performance. For each of these areas we created new ways to detect issues during development and a better process to analyze your feedback both from opt-in analytics and bugs that you file.

Our system health work has many under the hood improvements but a few notable changes include:

Auto-recommend Memory Settings

With Android Studio 3.5, the IDE will recognize when an app project needs more RAM on a machine with higher RAM capacity and will notify you to increase the memory heap size or you can adjust the settings yourself under Appearance & Behavior → Memory Settings.

Memory Settings

User Interface Freezes

During the Project Marble development timeframe, we found in our opt-in product analytics that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.

Code Editing Before - Android Studio 3.4

Code Editing After - Android Studio 3.5

Build Speed

For Android Studio 3.5 we made many speed improvements but a significant change is the addition of incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. Learn more here.

Disk I/O File Access Speed

For users on Microsoft® Windows®, we found that disk I/O access times were notable higher on average than other platforms. Digging into the data, we found the default configuration of anti-virus scanners did not optimally exclude build output folders. In Android Studio 3.5, we detect this situation and help guide you through the optimal setup.

System Health Notification - Anti-virus Check

Feature Polish

In addition to improving system health we relooked at a few critical users flows to address bugs and user friction. The areas we looked at ranged from data binding, layout editor, ChromeOS support to project upgrades. One notable area of improvement to highlight is the app deployment flow:

Apply Changes

The new Apply Changes features is a rewrite of Instant Run which now enables you to quickly see your code edits on an emulator or device without restarting your app is great for app development. Unlike Instant Run, Apply Changes does not modify your APK which means it is realbile and has a predictable behavior. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience

Apply Changes Buttons

App Deployment User Flow

To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:

System Health

Feature Polish

Check our the Android Studio release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts & Google I/O talk:

Opt-In & Feedback

The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.

IDE Data Sharing

Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.

IDE User Feedback

Getting Started

Download

Download Android Studio 3.5 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.1.9 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.

August 20th 2019, 1:15 pm

Improving Accessibility in the Android Ecosystem

Android Developers Blog

Posted by Ian Stoba, Program Manager, Accessibility Engineering

With billions of Android devices in use around the world and millions of apps available on the Play Store, it might seem difficult to drive change across the entire ecosystem, but the Accessibility Developer Infrastructure team is doing just that.

Every time a developer uploads an APK or app bundle to the open or closed tracks, Play tests this upload on various device models running different versions of Android and generates a pre-launch report to inform the developer of issues.

One year ago, the team added accessibility suggestions to the report based on industry best practices and Google’s own experience. These tests check for common issues that can make an app harder to use by people with disabilities. For example, they check that buttons are large enough to be comfortable for people to press, and that text has enough contrast with the background to be easier to read.

Since launching in July 2018, more than 3.8 million apps have been tested and over 171 million suggestions have been made to improve accessibility. Along with each suggestion, the developer gets detailed information about how to implement it. Every developer, from a one-person startup to a large enterprise, can benefit from the accessibility suggestions in the pre-launch report.

We are already seeing the real-world impact of these efforts. This year at Google I/O, the number of developers signing up for in-person accessibility consultations was four times the number from 2018. Googlers staffing these sessions reported that the developers had specific questions that were often based on the suggestions from the pre-launch report. The focused questions allowed the Googlers to give more actionable recommendations. These developers found that improving accessibility isn't just the right thing to do, it also makes good business sense by increasing the potential market for their apps.

Accessibility tests in the pre-launch report are just one way Google is raising awareness about accessibility in the global developer community. We partnered with Udacity to create a free online course about web accessibility, released our Accessibility Scanner for Android on the Play Store, and published iOS Accessibility Scanner on GitHub, allowing iOS developers to easily instrument apps to accessibility tests. Together, these efforts support Google's mission to organize the world's information and make it universally accessible and useful.

Learn more about developing with accessibility in mind by visiting the Android Developer Guidelines and the Google Developer Documentation Style Guide.

August 15th 2019, 4:31 pm

Google releases source code for Google I/O 2019 for Android

Android Developers Blog

Posted by Takeshi Hagikura, Developer Programs Engineer

Today we're releasing the source code for the official Google I/O 2019 Android app.

This year's app substantially modified existing functionality and added several new features. In this post, we’ll highlight several notable changes.

Android Q out of the box

Android Q introduced an option for fully gestural navigation, allowing the user to navigate back and to the home screen using only gestures. To support gesture navigation, app developers need to do two things:

  1. Extend app content to draw edge-to-edge
  2. Handle any conflicting app gestures

The Google I/O 2019 app was one of the first apps to support fully the gestural navigation. For more details, check out this series of blog posts about gesture navigation and the commit in the Google I/O app repository that extended the content to draw edge-to-edge.

Gesture navigation navigating back and to the home screen

Another new feature that was introduced with Android Q was the new system Dark theme that applies to both the Android system UI and apps running on Android devices. Dark theme brings many benefits to developers, including being able to reduce power usage and improving visibility for users with low vision and those who are sensitive to bright light.

To support the dark theme, you must set the app’s theme to inherit from a dark theme.

<style name="AppTheme" parent="Theme.AppCompat.DayNight">
OR
<style name="AppTheme" parent="Theme.MaterialComponents.DayNight">


You also need to avoid hard-coded colors or icons. You should use theme attributes (such as ?android:attr/textColorPrimary) or night-qualified resources (such as colors defined both in the res/values/colors.xml and res/values-night/colors.xml) instead. Check out the Google I/O talk about Dark Theme & Gesture Navigation for more details or the series of commits (1, 2, 3) in the Google I/O 2019 app repository for how we achieved implementing the dark theme in a real app.

Schedule UI in dark theme

Improved schedule screen

In 2018, we adopted a tabbed interface for the schedule UI with horizontal swiping, each tab represented a conference day. In 2019, we changed the UI to address some usability and performance problems. For example, the views in the all tabs were rendered at the same time when the schedule UI became visible. That caused a noticeable UI slowdown especially on a low-end device.

The new schedule UI is a single stream, allowing the app to render only visible content and users to easily jump to another conference day by choosing a day at the top of the UI. Check out the series of commits (1, 2) for how we revamped the schedule UI.

This year’s schedule UI jumping to another conference day

Navigation component

We introduced Navigation component to simplify this year’s app into a Single Activity app and observed the following benefits:

Check out the getting started guide for how you can start introducing the Navigation component in your app and the series of commits (1, 2, 3, 4) in the Google I/O 2019 app repository for the usage in a real app.

All transitions in the navigation editor

Full Text Search with Room

For this year’s app we added a search feature for users to quickly find sessions, speakers, and codelabs. To accomplish this, we used the Full Text Search feature of the Room Jetpack component. Whenever the conference data is fetched from the server, we update the session, speaker, and codelab data in the Room tables, which have corresponding FTS mapping tables. When a user starts typing in the search box, the search term is used to query the session title and description, speaker names, and codelab title. The search results are shown almost instantly, which allows the search results to be updated with each character typed in the search field. The user can then tap on a search result to navigate to see the details on the session, speaker, or codelab. Check out the series of commits (1, 2, 3, 4) for how we achieved the Full Text Search feature.

Searching for a session and a speaker

Lots of improvements

These were the biggest changes we made to the app, but we improved a lot of little things as well. We added the new Home UI, allowing the app to tell the user time relevant information during the conference and the Codelab UI, which gave users more information about codelabs at I/O and how to participate in them.

Home UI and Codelabs UI

We also introduced Firebase Remote Config to toggle the visibility of each feature by updating the boolean values in the Remote Config without updating the app and removed the hard-coded values that were used for representing start and end time of each event in the Agenda UI.

Go explore the code

If you’re interested go checkout the code and let us know what you think. If you have any questions or issues, please let us know via the issue tracker on GitHub.


August 14th 2019, 2:00 pm

Nexon increases day 60 retention and monetization with pre-registration rewards

Android Developers Blog

Posted by Kacey Fahey, Google Play Developer Marketing

Nexon Korea Company has published several games across PC, mobile, and console. With the launch of their mobile game FAITH, a MMORPG released exclusively in Japan, they wanted to promote the game before launch and find a way to capture early consumer demand that would help boost early installs at launch.

What they did

Nexon ran a pre-registration campaign on Google Play with a multi-channel marketing campaign driving players to pre-register and receive an exclusive pre-registration reward. Their campaign used consistent creative assets throughout TV commercials, YouTube influencer campaigns, social media, performance marketing campaigns, and more. Offering a pre-registration reward provided an incentive and benefit for players who pre-registered on Google Play during the month-long campaign leading up to launch.

“It was very easy to run, since the steps to activate the campaign were very clear and simple. All we needed to do was prepare the store assets and APK, then set them up in the Google Play Console,” said Hyomin Kim, Head of Platform Partnerships at Nexon Korea Corporation. Their exclusive pre-registration reward of 300 diamonds (in-game currency) was set up as a unique managed product as part of the campaign. At launch, Google Play provides the reward to all players who pre-registered, allowing Nexon to consume and grant the reward to players in-game using the Google Play Billing API. Not only did this create additional value for users, but it allowed Nexon to identify those who pre-registered in-game so they could measure the cohort’s performance after launch. Once the game became available on launch day, everyone who pre-registered on Google Play received a notification to install.

Results

Nexon reported they had historically seen around 50% of Google Play pre-registrations convert to installs. By offering a pre-registration reward for FAITH, they increased their conversion rate by 20%. And not only that, the campaign drove other strong performance metrics with players who pre-registered for FAITH on Google Play having almost 50% higher day 60 retention than those who did not pre-register. This audience has also shown stronger monetization behavior, with over 70% higher ARPDAU than non-pre-registrants.

“Google Play pre-registration is now a ‘must-do’ strategy when Nexon launches games. From our previous experience, Google Play pre-registration is one of the most effective pre-registration platforms amongst all the channels we utilize, especially for organic impressions and installation conversion,” said Kim.

Get started

All app and game developers can run pre-registration campaigns and offer a pre-registration reward. Get started today!

August 13th 2019, 2:43 pm

Gesture Navigation: A Backstory

Android Developers Blog

Posted by Allen Huang and Rohan Shah, Product Managers on Android UI

One of the biggest changes in Android Q is the introduction of a new gesture navigation. Just to recap - with the new system navigation mode - users can navigate back (left/right edge swipe), to the home screen (swipe up from the bottom), and trigger the device assistant (swipe in from the bottom corners) with gestures rather than buttons.

By moving to a gesture model for system navigation, we can provide more of the screen to apps to enable a more immersive experience.

We wanted to give folks an inside look at how we’ve approached this challenge, the rationale, and some of the trade-offs as well. There is some nerding out on design around gestures ahead, but hopefully it provides some insight into our process and how we balance the developer and OEM ecosystem in service of users. If you’re looking for more detail on how to handle these changes as an app developer, check out Chris’s “Going edge-to-edge” article series.

Why gestures?

One of the amazing things about Android is the opportunity for app developers and Android partners to try new, innovative approaches on the phone.

In the last 3 years, we’ve seen gesture navigation patterns proliferate on handheld devices (though gestures have been around as early as 2009!).

This trend was led by innovative Android partners and Android apps trying some very cool ideas (for example: Fluid NG, XDA).

When we started researching this more, we honed in on the user benefits:

  1. Gestures can be a faster, more natural and ergonomic way to navigate your phone
  2. Gestures are more intentional than software buttons that you might trigger just by grabbing your phone
  3. Gestures enable a more immersive experience for apps by minimizing how much the system draws over app content, i.e. HOME/BACK buttons and the bar they sit on - especially as hardware trends towards bigger screens and smaller bezels

It wasn’t all roses though - we also saw issues with many of the gesture modes:

  1. Gestures don’t work for every user
  2. Gestures are harder to learn and can take some adjustment
  3. Gestures can interfere with an app’s navigation pattern

But most of all, we realized that there was a larger issue of fragmentation when different Android phones had different gestures, especially for Android developers.

Over the last year, we worked with partners like Samsung, Xiaomi, HMD Global, OPPO, OnePlus, LG, Motorola, and many others to standardize gesture navigation going forward. To ensure a consistent user and developer experience, the Android Q gestures will be the default gesture navigation for new Q+ devices.

Understanding that these gestures don’t work for every user, especially those with more limited dexterity and mobility, three-button navigation will continue to be an option on every Android device.

So why these gestures?

We started with research to understand how users held their phones, what typical reach looked like, and what parts of the phone users used the most. From there, we built many prototypes that we tested across axes like desirability, speed-of-use, ergonomics, and more. And we put our ultimate design through a range of studies - how quickly users learned the system, how quickly users got used to the system, how users felt about it.

A unique element of Android navigation since the very beginning is the Back button. It is appreciated by many users that find Android easier to navigate and learn (despite many debates on what the “correct” behavior is) -- and it's used a lot! In fact, 50% more than even Home. So one of our design goals was to make sure the back gesture was ergonomic, dependable, and intuitive -- and we prioritized this goal above other less frequent navigation such as drawers and recents.

Looking at the reachability charts below, we designed our two core gestures (Back and Home) to coincide with the most reachable/comfortable areas and movement for thumbs.

Phone screen heatmaps showing where users can comfortably do gestures, holding the phone in only one hand

As mentioned, we built prototypes of many different gesture models, comparing user ratings and timed user tasks on what ultimately became the Q model to several other navigation paradigms. Here’s a few graphs showing the results of our testing:

Comparison of user ratings for ergonomics and one-handed use across different navigation modes (higher is better)


Comparison of average time required to complete Home/Back tasks across various navigation modes (lower is better)


Comparison of average time required to complete Overview/Recents-based tasks across various navigation modes (lower is better)


Users, on average, performed tasks involving Home and Back more quickly than most other models - even faster than they did with buttons. The model did, however, come at the cost of being able to quickly access Overview/Recent apps, which users go to less than half as often as the Home screen.

From a more qualitative perspective, users viewed the Q model as more one-handed and reachable, although buttons were still viewed as more ergonomic for more users.

App Drawers and other App Swipes

Although we arrived at the side swipe as the gesture for back that best balanced many tradeoffs, it is important to note that there were hard decisions, particularly in how that gesture impacted apps.

For example, we found that ~3-7% of users (depending on the Google app) swipe to open the App Navigation Drawer - the rest of our users push the hamburger menu to invoke the drawer. This drawer swipe gesture is now overloaded with back and some users will need to adapt to using the hamburger menu. This was a tough choice but given the prolific use of back we optimized for what worked best there.

Because it’s never a goal to change out behavior on users, we tried several ways to enable users to distinguish the drawer gesture from the Back gesture. However, all these paths led to users pulling in the drawer when they were trying to go Back and having less confidence that Back would work.

Beyond drawers, gestures are a big change for people and it took on average 1-3 days to adapt - in particular, users struggled with patterns like swiping right or left on a carousel and triggering Back.

In qualitative studies, we found that after an initial break-in period of 1-3 days, users became fluent and could consistently distinguish between these two gestures. The majority of users did not want to switch back to 3 button nav (even though that remains an option).

Additional research showed that there is a clear adjustment phase for users to get used to a new system navigation (across many different navigations). In our Q model, we found that usage of Back goes down for the first 1-3 days. After that period, the average # of Back presses/day ends up being the same as 3-button and our P navigation.

So What Does This Mean for Developers?

With gestural navigation, we are aiming to move forward and standardize the user experience on Android. The model we landed on is the optimal one for most users, but it also means that some of the gestures conflict with existing app gestures, necessitating developer adjustments to how users interact with your apps. We take our responsibility to Android developers seriously and want to help you in this process.

There are three key steps to support gesture navigation:

  1. Go edge-to-edge to enable your app to draw across the entire screen
  2. Handle any visual overlaps with the system user interface (i.e. navigation bar)
  3. Resolve any gesture conflicts with the system gestures

We’ve just published the first article in our “Going edge-to-edge” series on Medium, detailing those steps in turn. The final article in the series will cover some of the common scenarios we’ve seen, and how you can best support them in your apps.

Thank you all for the feedback -- all of your comments and interactions have helped us improve the gesture navigation experience in Android Q and, more broadly, help make Android better each day.

August 8th 2019, 4:27 pm

Final Beta update, official Android Q coming soon!

Android Developers Blog

Posted by Dave Burke, VP of Engineering

We’re just a few weeks away from the official release of Android Q! As we put the final polish on the new platform, today we’re rolling out Beta 6, the last Beta update. Now is the time to make sure your apps are ready, before we bring the official release to consumers. Take this opportunity to finish up your testing and publish your app updates soon to give users a smooth transition to Android Q.

You can get Beta 6 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 5, you'll automatically get Beta 6 soon. Partners participating in the Android Q Beta program will also be updating their devices over the coming weeks -- visit their sites to learn more. To get started with Android Q, visit developer.android.com/preview.

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

What’s in Beta 6?

Today’s Beta 6 update includes the latest Android Q system images for Pixel and Android Emulator, the final API 29 SDK, and updated build tools for Android Studio. Beta 6 includes all of the features, system behaviors, and developer APIs that you’ll find in the final platform, so it gives you everything you need to get your apps ready. For users, Beta 6 includes many new fixes and optimizations -- take a look at the release notes for details.

We've made further refinements to Gesture Navigation in Beta 6 based on user feedback. First, to ensure reliable and consistent operation, there's a 200dp vertical app exclusion limit for the Back gesture. Second, we've added a sensitivity preference setting for the Back gesture. Watch for more details coming soon in our blog post series on optimizing for gesture navigation.

Get your apps ready for Android Q!

With the consumer release coming soon, we’re asking all Android developers to update your current apps for compatibility as soon as possible.

Here’s how to do it:

We realize that supporting these changes is an investment for you too, so thanks to all of you who have prioritized the work to get your apps ready for Android Q!

Enhance your app with Android Q features and APIs

Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for every app:

We recommend these if relevant for your app:

These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

Publish your app updates to Google Play

As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users and then do a staged rollout to production.

How do I get Beta 6?

It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

Please continue to share your feedback and requests in our issue tracker. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.

A big thank you to our developer community for your participation in our recent Reddit AMA on r/androiddev! It’s always great to hear what’s important to you and we hope we were able to help!

August 7th 2019, 1:09 pm

Make stronger decisions with new Google Play Console data

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play

At this year’s Google I/O, we announced a slate of new features to help you take your business further with Google Play. Launching today, these changes include several improvements designed to help you make better decisions about your business by providing clearer, more actionable data.

We know the right data is critical to help you improve your app performance and grow your business. That’s why we’re excited to share a major update that enables you to better measure and analyse your core statistics — the most fundamental install and uninstall metrics by user and device. We’ve also enhanced the Statistics page on the Play Console to show change over time, enable more granular configurations, and, coming soon, exclusive benchmarks for core stats!

More granular configurations are now available on the Statistics page to help you better understand your acquisition and churn.

More accurate and more expansive than before, the new metrics will help you better understand your acquisition and churn. For the first time, we are including data on returning users and devices - something that we understand is critical to many developers' growth strategies.

We’re also including new install methods (such as pre-installs and peer-to-peer sharing) and the ability to aggregate and dedupe over periods that suit your business needs. With these new updates, you can perform analyses that weren’t possible before, such as how many people re-installed your app last month.

Here’s what else is new:

As a result of these updates, you will notice a few changes to your metrics. Old metrics names will be deprecated, but you can configure new metrics that map to the old ones with this cheat sheet. And don’t forget to use the ‘save report’ feature on the stats page so you can easily return to any configurations you find particularly helpful!

Don’t forget to use the ‘save this report’ feature on the stats page to easily return to any configurations you find particularly helpful.

Other metrics like active user and active device will see a step-change as the new definitions are more expansive and include previously under-counted data.

Some new metrics map onto older ones. Where this happens, all historic data will be automatically included. But in other cases new metrics will only be generated from launch day. For unique devices or users, weekly metrics will start to appear two weeks after launch, monthly metrics once there’s a single full month’s data, and quarterly metrics once there’s a full quarter’s data.

We know it’s a lot to take in at once, so make sure to bookmark the cheat sheet for helpful tips as you navigate the transition and explore your new metrics. Additionally, our Decision-Making with the Google Play Console session from Google I/O and our Play Academy training are other great resources to help you get up to speed.

Check out these updates in the Google Play Console today — we hope you find them useful. Your comments help to shape the future of Google Play, so please continue to let us know what you think.

How useful did you find this blog post?

July 31st 2019, 7:02 am

What’s new with Fast Pair

Android Developers Blog

Posted by Catherina Xu (Product Manager)

Last November, we released Fast Pair with the Jaybird Tarah Bluetooth headphones. Since then, we’ve engaged with dozens of OEMs, ODMs, and silicon partners to bring Fast Pair to even more devices. Last month, we held a talk at I/O announcing 10+ certified devices, support for Qualcomm’s Smart Headset Development Kit, and upcoming experiences for Fast Pair devices.

The Fast Pair team presenting at I/O 2019.

Upcoming experiences

Fast Pair makes pairing seamless across Android phones - this year, we are introducing additional features to improve Bluetooth device management.

  • True Wireless Features. As True Wireless Stereo (TWS) headphones continue to gain momentum in the market and with users, it is important to build system-wide support for TWS. Later this year, TWS headsets with Fast Pair will be able to broadcast individual battery information for the case and buds. This enables features such as case open and close battery notifications and per-component battery reporting throughout the UI.

    Detailed battery level notifications surfaced during “case open” for TWS headphones.

    • Find My Device. Fast Pair devices will soon be surfaced in the Find My Device app and website, allowing users to easily track down lost devices. Headset owners can view the location and time of last use, as well as unpair or ring the buds to locate when they are in range.

    Connected Device Details. In Android Q, Fast Pair devices will have an enhanced Bluetooth device details page to centralize management and key settings. This includes links to Find My Device, Assistant settings (if available), and additional OEM-specified settings that will link to the OEM’s companion app.

    The updated Device details screen in Q allows easy access to key settings and the headphone’s companion app.

    Compatible Devices

    Below is a list of devices that were showcased during our I/O talk:

    • Anker Spirit Pro GVA
    • Anker SoundCore Flare+ (Speaker)
    • JBL Live 220BT
    • JBL Live 400BT
    • JBL Live 500BT
    • JBL Live 650BT
    • Jaybird Tarah
    • 1More Dual Driver BT ANC
    • LG HBS-SL5
    • LG HBS-PL6S
    • LG HBS-SL6S
    • LG HBS-PL5
    • Cleer Ally Plus

    Interested in Fast Pair?

    If you are interested in creating Fast Pair compatible Bluetooth devices, please take a look at:

    Once you have selected devices to integrate, head to our Nearby Devices console to register your product. Reach out to us at fast-pair-integrations@google.com if you have any questions.

    July 19th 2019, 4:09 pm
  • Kotlin named Breakout Project of the Year at OSCON

    Android Developers Blog

    Posted by Wojtek Kaliciński, Developer Advocate, Android

    Stephanie Saad Cuthbertson announces support for Kotlin during the Developer Keynote at I/O 2017.

    Today at OSCON (the O'Reilly Open Source Software Conference), Kotlin was awarded the Open Source Award for Breakout Project of the Year.

    There is no doubt to us why Kotlin received this award: it’s a fast moving (but thoughtfully developed) programming language that lets you write better code, faster. It’s great to see Kotlin continue to receive the sort of recognition as Breakout Project of the Year, building on other awards like #1 fastest growing language on Github.

    We’re big fans of Kotlin, and we’ve heard that you are too – feedback from you is in part why we announced support for the language over two years ago. This meant bundling the Kotlin plugin in Android Studio, along with promising to support Kotlin-built apps going forward.

    But there was a long way to go for many teams at Google to provide a first class experience with Kotlin in the Android ecosystem, and to convince developers that Kotlin on Android is not just a fad, but is here to stay.

    If you haven’t tried Kotlin yet, now is a great time to start! In fact, in the past two years, we’ve been adding a number of new features and upgrades to the Kotlin for Android experience, including:

    The road to fully supporting Kotlin on Android was not always easy, but it was truly rewarding seeing Kotlin adoption among professional Android developers rise from a handful of early adopters to around 50% since the original announcement!

    We were confident when we announced earlier this year at Google I/O 2019 that Android is going increasingly Kotlin-first, opening up the possibility for APIs built specifically around Kotlin and for Kotlin users, starting with the new, declarative UI toolkit - Jetpack Compose (still in early development).

    We want to congratulate JetBrains, our partners through the Kotlin Foundation and creators of Kotlin, on receiving the OSCON Open Source Award today. It shows how disruptive and transformative Kotlin has been, and not just for the Android developer community, but beyond.

    We know one thing: on Android, Kotlin is here to stay.

    July 18th 2019, 2:21 pm

    Android Dev Summit 2019 Registration is Open

    Android Developers Blog

    Posted by Sean McQuillan, Developer Advocate, Android

    Registration is now open for Android Dev Summit 2019!

    Learn, share, and connect at #AndroidDevSummit 2019. It's a great place to learn new Android development skills, share feedback and ideas with the Android engineering team, and connect with Android developers from around the globe.

    Join us for the two day conference on October 23-24 hosted at the Google Event Center (MP7) in Sunnyvale, CA. We'll share two days of deep technical talks covering topics such as Jetpack, Android Studio, Android Q, Kotlin, and more. You will learn about the latest innovations straight from the Android engineering team, discover best practices to help you build even better apps, and accelerate your teams’ productivity on Android.

    The Android engineering team will be there in person to answer your questions, hear your ideas and feedback (we love that!), and discuss the direction of Android development. And you will be joined by Android developers from around the globe ⁠— it’s a great place to connect with your community.

    Conference details

    When: October 23-24

    Where: Google Event Center (MP7)

    Unable to attend?

    Wherever you are, you can still watch the talks and engage with the community. You can tune in from anywhere to watch all of the talks online by joining our livestream. Sign up here to stay updated on event announcements. All of the talks will also be posted on YouTube soon after the event, so you can always catch up with the recordings on your own schedule.

    The event schedule has not yet been posted, but we encourage you to check out last year’s sessions to learn more about the great content and opportunities Android Dev Summit has to offer.

    Register now

    Attendance is free and by invitation only ⁠— register now to become eligible for an invitation. Selected attendees will receive their tickets after registration closes on August 15th at 5:00pm PDT. #AndroidDevSummit will fill up fast, so be sure to register today.

    July 16th 2019, 12:10 pm

    What’s new for text in Android Q

    Android Developers Blog

    Posted by Florina Muntenescu, Android Developer Advocate

    Displaying text is an important task in most apps, so in Android Q we're continuing to introduce new features to support your needs and improve performance. We disabled hyphenation by default, enabled creating a typeface using multiple fonts or font families, exposed the list of fonts installed on the device, and improved some of the most-used text styling APIs.

    Hyphenation is off by default in Android Q and AppCompat v1.1.0

    Our performance tests showed that when hyphenation is enabled, up to 70% of the time spent on measuring text is on hyphenation.

    Hyphenation takes up to 70% of the time spent measuring text

    Given that hyphenation often isn’t needed for all TextViews in an app, and because of the impact on performance, we decided to turn hyphenation off by default in Android Q and AppCompat v1.1.0. If you want to use hyphenation, you need to manually turn it on in your app by setting the hyphenation frequency to normal. You can set this in multiple ways:

    As a TextAppearance attribute in styles.xml:

    <style name="MyTextAppearance" parent="TextAppearance.AppCompat">
        <item name="android:hyphenationFrequency">normal</item>
    </style>
    

    As a TextView attribute:

    <TextView android:hyphenationFrequency="normal" />
    

    Directly in code:

    textView.hyphenationFrequency = Layout.HYPHENATION_FREQUENCY_NORMAL
    

    Find out more about how hyphenation works from this talk at Android Dev Summit 2018.

    Use multiple custom fonts in the same TextView

    Consider a button which mixes a custom font (Lato in this example) with an icon font:

    Button with icon and Latin fonts

    The Button class accepts only a single instance of a typeface to be set on the text. Pre-Android Q, you can create a Typeface using a single font family. Android Q enables the creation of a typeface from multiple font families with a new API, Typeface.CustomFallbackBuilder, that allows adding up to 64 font families per typeface.

    Our icon font example can be implemented like this:

    button.typeface = Typeface.CustomFallbackBuilder(
        // add the Latin font
        FontFamily.Builder(
            Font.Builder(assets, "lato.ttf").build()
        ).build()
    ).addCustomFallback(
        // add the icon font
        FontFamily.Builder(
            Font.Builder(assets, "icon_font.ttf").build()
        ).build()
    ).build()
    

    When creating the font family, make sure you don’t put fonts that belong to different families in the same font family object nor the same style fonts into the same font family. For example, putting Lato, Kosugi, and Material into the same font family creates an invalid configuration, as does putting two bold fonts into the same font family.

    To define the general font family (serif, sans-serif, or monospace) to be used when text is rendered using system fonts, use the setSystemFallback() method to set the system fallback font:

    Typeface.CustomFallbackBuilder(
        FontFamily.Builder(
           ...
        ).build()
    ).setSystemFallback("sans-serif")
    .build()
    

    Text styling API updates

    Android Q brings several updates to different text styling APIs:

    Improved support for variable fonts

    TextAppearance now supports the fontVariationSettings attribute:

    <style name="MyTextAppearance" parent="TextAppearance.AppCompat">
        <item name="android:fontVariationSettings">...</item>
    </style>
    

    The fontVariationSettings attribute can be set directly on the TextView in Android Q and in AppCompatTextView:

    <TextView
        ...
        app:fontVariationSettings="..."
    />
    

    Improved spans APIs

    TextAppearanceSpan now supports typeface, shadow settings, fontFeatureSettings and fontVariationSettings.

    LineBackgroundSpan and LineHeightSpan interfaces now have standard implementations: LineBackgroundSpan.Standard and LineHeightSpan.Standard.

    Access system fonts

    With more than 100 languages supported by Android, and with different fonts supporting different character sets, knowing which system font can render a given character is not trivial. Apps doing their own text rendering such as games, document viewers, or browsers need this information. In Android Q, you can retrieve the supported system font for a string with the FontMatcher NDK API.

    System fonts that can render this text

    Let’s consider the above search string. The FontMatcher API returns us the font object and length. A simplified pseudocode example looks like this:

    // font = NotoSansCJK-Regular.ttc
    // length = 2
    auto[font, length] = AFontMatcher_match("たすく a.k.a. のな");
    
    // font = Roboto-Regular.ttf
    // length = 8
    auto[font, length] = AFontMatcher_match(" a.k.a. のな");
    
    // font = NotoSansCJK-Regular.ttc
    // length = 2
    auto[font, length] = AFontMatcher_match("のな");
    

    The FontMatcher API never returns nullptr:

    If you want to get all available system fonts, you can do this with a new font enumeration API. In Java, you can use SystemFonts.getAvailableFonts, or in the NDK, you can use ASystemFontIterator. The results of the font enumeration are changed only by a system update, so you should cache them.

    Font updates

    New Myanmar font

    Android added a new Myanmar font to Android Q that is Unicode-compliant and capable of rendering both Unicode and non-Unicode Burmese (commonly known as Zawgyi), right out of the box. This means starting in Android Q, Android makes it easier for users to switch to Unicode: a user can now use a Unicode font to read Unicode and non-Unicode text for the first time. Android also added new requirements to the Android ecosystem CDD that takes a stronger stance in requiring Unicode, including a new subtag "Qaag" which OEMs should use as a locale designating non-Unicode Burmese. All of these changes should make developers’ life easier in the long term, as reduced ecosystem fragmentation makes it easier to develop for our 50M users in Myanmar.

    New emojis

    New emojis in Android Q

    Say Hello to your new emoji friends! The latest update includes a number of disability-focused emojis, 59 gender-inclusive designs, multi-racial couples, as well as a few cute animals and household objects. See the latest and greatest in Gboard on your Android Q device of choice.

    Text plays an important role in a vast majority of apps, so we’re continuing to invest in improving text API features and performance. Learn more about the new APIs in Android Q along with best practices when working with text in our Google I/O 2019 talk:

    July 11th 2019, 1:22 pm

    Android Q Beta 5 Update

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    Android Q Beta 5 launches today! Today we're rolling out Beta 5, bringing Android Q Beta very close to the system behaviors you'll see in the final release. Developer APIs were already finalized in the previous update. So, now is the time to test your apps for compatibility and make sure they are ready!

    You can get Beta 5 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 4 on your Pixel device, you'll automatically get the update to Beta 5. Partners participating in the Android Q Beta program will also be updating their devices to Beta 5 over the coming weeks.

    To get started with Android Q Beta, visit developer.android.com/preview.

    What’s in Beta 5?

    The Beta 5 update includes the latest Android Q system images for Pixel and Android jEmulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. These give you everything you need to test your apps on Android Q and build with Android Q features.

    Gestural navigation updates

    As we talked about at Google I/O, we’ve been working closely with device-maker partners to ensure a standardized Android gestural navigation for users and developers. Gestural navigation lets apps use the full screen for content while minimizing the visible system chrome and navigation – which is particularly important on today’s edge-to-edge screens. In Beta 5 we’re continuing to improve and polish based on your feedback and we wanted to provide an update on a few key areas.

    We’ve introduced a swipe gesture from either corner to get to the Assistant - you’ll notice indicators in the bottom corners that we’re continuing to tune.

    For apps using a navigation drawer, we’ve added a peek behavior when users have grabbed the drawer to indicate that a swipe will bring in the navigation drawer. This works for all versions of DrawerLayout, with DrawerLayout 1.1.0-alpha02 optimized for the best experience.

    Custom launchers are another area where we’ve heard feedback and we’re continuing to work on issues, particularly with stability and Recents. Starting in Beta 6, we’ll switch users to 3-button navigation when they are using a custom launcher by default. We’ll address the remaining issues in a post-launch update allowing all users to switch to gestural navigation. Meanwhile, please continue to give us your feedback.

    Get your apps ready for Android Q!

    With the consumer release coming soon, it’s highest priority for all Android developers to update your current apps for compatibility as soon as possible.

    Here’s how to do it:

    We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release.

    Enhance your app with Android Q features and APIs

    Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

    We recommend these for every app:

    We recommend these if relevant for your app:

    These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

    Publish your app updates to Google Play

    As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users -- including Beta 5 users — and then do a staged rollout to production.

    How do I get Beta 5?

    It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

    To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

    There will be one more Beta release before the consumer launch later this quarter. Please continue to share your feedback and requests -- you can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.

    Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android Q later this month. Look out for an announcement on r/androiddev with details in the coming weeks. We look forward to addressing your questions!

    July 10th 2019, 1:08 pm

    Capturing Audio in Android Q

    Android Developers Blog

    Posted by Don Turner, Developer Advocate for Android Media

    In Android Q there's a new API which allows applications to capture the audio of other applications. It's called the AudioPlaybackCapture API and it enables some important use cases for easier content sharing and accessibility.

    Some examples include:

    There may be some situations where a developer wishes to disallow the capture of their app's audio. This article explains how audio capture works for users and how developers can disallow their app's audio from being captured if they need to.

    What does the user see?

    In order to capture the audio of other apps the user must grant the record audio permission to the app doing the capturing.

    AUDIO_RECORD permissions dialog

    Additionally, before a capture session can be started the capturing app must call MediaProjectionManager.createScreenCaptureIntent(). This will display the following dialog to the user:

    Screen capture intent dialog

    The user must tap "Start now" in order for a capturing session to be started. This will allow both video and audio to be captured.

    Cast icon showing red in status bar

    During a capture session the cast icon is shown in red in the status bar.

    Can my app's audio be captured?

    Whether your app's audio can be captured by default depends on your target API. Here's a table which summarizes the default behaviour:

    Target API Third party apps can capture your app's audio by default? System apps and components can capture your app's audio by default?
    28 and below No, the app needs to explicitly opt-in Yes for audio with usage type MEDIA, GAME and UNKNOWN
    29 Yes for audio with usage type MEDIA, GAME and UNKNOWN Yes for audio with usage type MEDIA, GAME and UNKNOWN


    Disallowing capture by third party apps

    There may be situations where an app wishes to disallow its audio from being captured by other apps. This could be because the audio contains:

    An app's audio capturing policy can be set either for all audio or for each individual audio player.


    Disallowing capture of all audio by third party apps

    To disallow capture of all audio by third party apps you can do either of the following:

    Add the following to your AndroidManifest.xml

    ...

    android:allowAudioPlaybackCapture="false"/>

    Programmatically disable capture by running the following code prior to playing audio AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)


    Disallowing capture on a per player basis by third party apps

    To disallow capture for an individual player you can set the capture policy for the audio player when it is built by calling:

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)
    

    This approach may be useful if your app plays content with differing licenses. For example, both copyrighted and royalty-free content.


    Disallowing capture by system apps and components

    By default system apps and components are allowed to capture an app's audio if its usage is MEDIA, GAME and UNKNOWN, as this enables important accessibility use cases, such as live captioning.

    In rare cases where a developer wishes to disallow audio capture for system apps as well they can do so in a similar way to the approach for third party apps. Note that this will also disallow capture by third party apps.


    Disallowing capture of all audio

    This can only be done programmatically by running the following code before any audio is played:

    AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    Disallowing capture on a per player basis

    To disallow capture for an individual player you can set the capture policy for the audio player when it is built:

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    What next?

    If your app is targeting API 28 or below and you would like to enable audio capture add android:allowAudioPlaybackCapture="true" to your app's manifest.xml.

    If you would like to disallow some or all of your audio from being captured then update your app according to the instructions above.

    For more information check out the Audio Playback Capture API documentation.

    July 3rd 2019, 10:17 am

    Indie Games Showcase from Google Play - meet the winners!

    Android Developers Blog

    Posted by Patricia Correa, Director, Developer Marketing

    We just wrapped up the Indie Games Showcase in Europe, Japan & South Korea! Back in March we started our search for some of the newest and most creative indie titles from these regions. The search culminated last week with the celebration of indie developers at events in London, Tokyo, and Seoul, and the selection of the winners from our finalists. Developers from 12 countries traveled to the events and showcased their games to the audience of gamers, industry experts, YouTube creators, and journalists.

    The games were on show to the public, who spent several hours trying out their games and voting for their favourites, alongside the Google Play team. The top 10 finalists were then selected, and went on to pitch their games, and compete for big prizes in front of the jury.

    Now, we are happy to announce the winners from each region! They will be returning home with a prize package that includes promotions on the Google Play Store, consultations with Google teams, Google hardware, and more.

    We also want to take this opportunity to congratulate all the other finalists and developers who entered the competition this year. We are impressed by your creativity and passion, and hope you will continue to create amazing experiences for players worldwide.

    Europe

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Ordia by Loju (United Kingdom)

    Photographs by EightyEight Games (United Kingdom)


    The other finalists as selected by audience and Google Play votes were:

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Golf Peaks by Afterburn (Poland)

    Rest in Pieces by Itatake (Sweden)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

    Japan

    Infection - 感染 - by CanvasSoft

    MeltLand by 個人

    Bear's Restaurant by 個人


    The other finalists as selected by audience and Google Play votes were:

    Lunch Time Fish by SoftFunk HULABREAKS

    ReversEstory by 個人

    Kamiori - カミオリ by TeamOrigami

    キグルミキノコ Q-bit -第一章- by 個人

    クマムシさん惑星 ミクロの地球最強伝説 by Ars Edutainment

    Girl x Sun - Terasene - Tower defence & Novel game by SleepingMuseum

    Persephone by Momo-pi

    South Korea

    ROOMS: The Toymaker's Mansion by HandMade Game

    Seoul2033: Backer by Banjiha Games

    Cartoon Craft by Studio NAP


    The other finalists as selected by audience and Google Play votes were:

    Hexonia by Togglegear

    Hexagon Dungeon by Bleor Games

    7Days - Decide your story by Buff Studio

    WhamBam Warriors by DrukHigh

    Onslot Car by Wondersquad

    Maze Cube by IAMABOY

    언노운 나이츠 by teamarex

    How useful did you find this blog post?

    July 2nd 2019, 12:50 pm

    Advanced in-app billing: handling alternative purchase flows

    Android Developers Blog

    Posted by Oscar Rodriguez, Developer Advocate

    When designing and developing an app or game, at some point you may ask yourself if you want to monetize it.

    If you choose to do so by selling products via Google Play, you will most likely have a store screen that shows available items for sale, and use the Google Play Billing Library to display dialogs that allow your users to complete their purchase.

    While there is a more detailed explanation in the documentation and in the Billing Library TrivialDrive samples, the general flow is as follows:

    1. Call the launchBillingFlow() method from the UI thread to launch the Google Play purchase dialog.
    2. If the purchase was successful, Google Play calls the onPurchasesUpdated() method to deliver the result of the purchase operation.
    3. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    4. Acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    5. Finally, grant entitlement to the purchased item inside the app.

    If your app is still using the Google Play Billing AIDL API, it is also possible to perform the same task. Keep in mind that the AIDL API is now deprecated, so we strongly recommend you migrate to the Google Play Billing Library as soon as possible.

    If you are using the AIDL API, the flow is very similar:

    1. Send a getBuyIntent() or getBuyIntentExtraParams() request to specify the item to purchase, and then call startIntentSenderForResult() to launch the Google Play purchase dialog.
    2. When the purchase dialog finishes, Google Play sends a response Intent to your onActivityResult() method, where you can verify if the purchase was successful.
    3. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    4. If the purchase was successful, call the getPurchases() method to retrieve a list of owned items that are still not consumed. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    5. Finally, grant entitlement to the purchased item inside the app.

    Nevertheless, just implementing the above mentioned flow is not enough to correctly handle all types of purchases. There are two main cases in which purchases will not be correctly handled by this flow.

    The first case happens when the purchase flow is interrupted before it finishes. The app may have crashed, the user may have killed the app, or the user’s Internet connection may have been lost. In any case, it is possible for the app not to have delivered the item to the user even though Google Play has already processed the payment. In this case, the item is in limbo, because Google Play will not allow an item to be re-purchased until it is consumed, but the app or game won’t consume the item outside of the flow mentioned above.

    The second case happens during alternative purchase flows, such as in-app promotions, the recently announced out-of-app subscription surfaces, promo codes for subscriptions, or other promotions in collaboration with Google. In these cases, a user gets an item directly on the Play Store app, while the target app or game may be paused, not running, or even not installed.

    For these cases, the Google Play Billing Library and the Google Play Billing AIDL API offer a mechanism to detect purchases that are not acknowledged or consumed.

    When using the Google Play Billing API, do the following:

    1. In your app’s onResume() callback, call the queryPurchases() method to retrieve a list of items, so you can determine which ones are unacknowledged.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. If there are owned but unacknowledged items, acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    4. Grant entitlement to the purchased item inside the app.

    For the Google Play Billing AIDL API, do the following:

    1. In your app’s onResume() callback, call the getPurchases() method to retrieve a list of owned items that are still not consumed.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    4. Finally, grant entitlement to the purchased item inside the app.

    In either case, when you detect and process an unconsumed item in this manner, users will expect the app or game to communicate about it. We suggest that you display a dialog, message box, or notification that tells the user that they have successfully received their item.

    Keep in mind that your app’s onResume() callback will be called when its process is started, as well as when it is brought to the foreground, regardless of which screen the app or game was in before it was paused. For example, a game with a home screen, a store screen, and a game screen might get its onResume() called from any of those screens. For an optimal user experience, we suggest you make it so your app or game handles unacknowledged or unconsumed items regardless of the screen you display when onResume() gets called. Thorough testing of this process in each screen is crucial to deliver a great user experience.

    Finally, there is one more case your app must handle: when a user acquires an item from the Play Store app, and both the Play Store app and your app are visible at the same time with multi-window mode.

    To support this scenario with the Google Play Billing Library, do the following:

    1. Google Play calls the onPurchasesUpdated() method to notify your app that there is a new pending item.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. Acknowledge the purchase either with consumeAsync() for consumable items or with acknowledgePurchase() for non-consumable items.
    4. Finally, grant entitlement to the purchased item inside the app.

    For the Google Play Billing AIDL API, do the following:

    1. In your app’s onResume() callback, register a PurchasesUpdatedListener to receive the com.android.vending.billing.PURCHASES_UPDATED intent. Also, in your app’s onPause() callback, unregister the listener.
    2. If your app has a server, we strongly recommend that you verify the purchase from your server by using the Subscriptions and In-App Purchases API.
    3. Google Play calls your listener to notify your app that there is a new pending item. Inside it, call the getPurchases() method to retrieve a list of owned items that are still not consumed. For consumable items, call the consumePurchase() method to make the item available for purchase again.
    4. Finally, grant entitlement to the purchased item inside the app.

    Just as before, you should display a dialog, message box, or notification that tells the user that they have successfully received their item.

    If you follow these steps, your app or game will be better prepared to robustly handle purchase flow interruptions and alternative purchase flows.

    June 26th 2019, 1:39 pm

    Moving Android Studio and Android Emulator to 64-bit versions

    Android Developers Blog

    Posted by Sam Lin, Product Manager, Android

    With Project Marble, the Android Studio team focused our efforts on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Performance is an underlying tenant to delivering a high quality IDE. To this end, we are sharpening our product focus and we will only support 64-bit operating systems going forward. Using Android Studio with an 64-bit operating systems enables efficient access to memory for both the IDE and the Android Emulator, and overall leads to a better development experience. While this change will not affect most Android Studio users, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. To aid in this transition for those developers using 32-bit versions of Microsoft Windows, we want to give you details on the upcoming depreciation timeline plus steps to take to be ready for this upcoming change.

    Timeline

    To minimize the impact of this change towards exclusively supporting 64-bit operating systems, we will first deprecate the 32-bit version. During the depreciation phase, both Android Studio and the Android Emulator will continue to work but the products will not receive new feature updates. During this transition period you can still download the product from the Android Studio web site. After one year, we will officially end product support and will remove the 32-bit product version download links. Note, if you have the 32-bit version of Android Studio previously installed during this period then the product should continue to work, but we will not provide a link for you to re-download the product. The exact dates for the depreciation and end-of-support period are in the table below:

    Supported 32-bit Product Version Deprecation from End of Support on
    Android Studio IDE 3.6 December 31, 2019 December 31, 2020
    Android Emulator 28.0.25 Jun 30, 2019 December 31, 2020

    Advantages of a 64-bit development environment

    There are a few advantages to using a 64-bit version of Android Studio, which include:

    Next steps

    To recap, before ending support for the 32-bit version of Android Studio, we want to inform you in advance, provide guidance, and allow for a one-year lead time to help you migrate to a 64-bit operating system. You can still use 32-bit versions of Android Studio, but be mindful that these version will not receive future updates. Therefore, if you want to migrate we suggest you start planning early so that you can continue to get the latest product updates and take advantage of the performance improvements of a 64-bit development environment.

    June 11th 2019, 2:25 pm

    Android Q Beta 4 and Final APIs!

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    Last month at Google I/O we talked about what’s new for Android developers, from new features in Android Q to the latest in Kotlin and Jetpack.

    With Android Q, we highlighted three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device machine learning, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.

    We also talked about how we’re going increasingly Kotlin-first, and continuing to expand Jetpack with new libraries like CameraX, Jetpack Security and Jetpack Compose -- a modern reactive-style UI toolkit for Android that takes advantage of Kotlin. If you missed the livestream for the keynotes or tech sessions, make sure to check out the full playlist of Android and Play sessions.

    Today we’re releasing Beta 4 with the final Android Q APIs and official SDK -- the time is now to get your apps ready for the final release later in the summer!

    You can get Beta 4 today on Pixel devices by enrolling here. If you're already enrolled and received the Beta 3 on your Pixel device, you'll automatically get the update to Beta 4. Partners participating in the Android Q Beta program will also be updating their devices to Beta 4 over the coming weeks.

    To get started with Android Q Beta, visit developer.android.com/preview.

    What’s in Beta 4?

    The Beta 4 update includes the latest Android Q system images for Pixel and Android Emulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. Together, these give you everything you need to test your apps for compatibility with Android Q and build with Android Q features and APIs.

    To get started, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

    Make your apps compatible with Android Q!

    With the developer APIs finalized and release candidate builds coming soon, it’s critical for all Android developers to test their current apps for compatibility with Android Q. We recommend getting started as soon as possible.

    Just install your current app from Google Play onto an Android Q Beta device or emulator, then test. As you work through the flows, your app should run and look great and handle all of the Android Q behavior changes properly. Watch for impacts from privacy changes, gestural navigation, changes to dynamic linker paths for Bionic libraries, and others.

    Make sure that you test with the Android Q privacy features, such as the new location permissions, restrictions on background activity starts, changes to data and identifiers, and other key privacy features. See the privacy checklist to get started, and review the behavior changes doc for more areas to test.

    You can use the updated Android Emulator to test your apps for compatibility.

    If you plan to update your platform targeting to API 29, also make sure to test with scoped storage, location permission for wireless scans, and permission for fullscreen intents. You can read about other changes that could affect apps here.

    It's also important to test for uses of restricted non-SDK interfaces and move to public SDK or NDK equivalents instead. Watch for logcat warnings that highlight these accesses and use the StrictMode method detectNonSdkApiUsage() to catch them programmatically.

    Last, make sure to fully test the libraries and SDKs in your app to make sure they work as expected on Android Q and follow best practices for privacy, performance, UX, data handling, and permissions. If you find an issue, try updating to the latest version of the SDK, or reach out to the SDK developer for help. You can also report SDK compatibility issues here.

    When you’ve finished your testing and made any updates, we recommend publishing your compatible app right away. This lets Android Beta users test the app now, and helps you deliver a smooth transition to users as they update to Android Q.

    We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release in the coming months.

    Enhance your app with Android Q features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs that you can use in your apps. Android Q features can help you engage users, give them more control and security, and even improve your app's performance.

    Android Q provides system-suggested replies and actions in notifications.

    For example, you can deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables and supporting gestural navigation in your app. To engage more users, try supporting Dark Theme, suggested replies and actions in notifications, sharing shortcuts, and settings panels.

    Gestural navigation lets you offer an edge-to-edge experience in your apps.

    If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing. If your app manages Wi-Fi internet connections, try the network suggestion APIs as an easier way to surface preferred Wi-Fi networks, without needing to request location permission.

    If you use the camera, learn about dynamic depth format. For media, you can use AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.

    Dynamic Depth lets you offer specialized blurs and bokeh options in your app.

    To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and get your app noticed. If your app uses power intensively, try using the new thermal API to optimize app performance based on device temperature.

    BiometricPrompt is now the preferred way to support fingerprint auth on modern devices, so all developers using fingerprint or other biometric auth should move to using this API as soon as possible. To make the transition easy, use the backwards-compatible BiometricPrompt API that we’re providing in the AndroidX library. Android Q supports both standard and passive (no confirmation, for face and other passive modes) auth flows.

    These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

    Publish your app updates to Google Play

    Today with Android Q Beta 4 we’re also opening up publishing on Google Play to apps that are compiled against, or optionally targeting, API 29. This means you can now push your updates to users now through Google Play to test your app’s compatibility, including on devices running Android Q Beta 4.

    How do I get Beta 4?

    It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners that are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

    For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator.

    As always, your input is critical, so please continue to 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 and we're working to integrate as much of it as possible in the next Beta release.

    We're looking forward to seeing your apps on Android Q!

    June 5th 2019, 1:30 pm

    Indie Games Accelerator - Introducing class of 2019!

    Android Developers Blog

    Posted by Vineet Tanwar, Business Development Manager, Google Play

    In April we opened applications for the 2019 class of Indie Games Accelerator, a program to help top mobile game startups from emerging markets achieve their full potential on Google Play. We’re truly awed by the response we have received with over 1,700 applications from developers across 37 countries*. We continue to be impressed by the innovation and creativity of game developers everywhere.

    Now, it's time to introduce you to the developers selected for the class of 2019. Here they are:

    Congratulations to the selected participants and we look forward to meeting you in Singapore!

    Find out more about the program or express your interest in joining the next class of the Indie Games Accelerator.

    * The competition is open to developers from the following countries: Bangladesh, Brunei, Cambodia, India, Indonesia, Laos, Malaysia, Myanmar, Nepal, Pakistan, Philippines, Singapore, Sri Lanka, Thailand, Vietnam, Egypt, Jordan, Kenya, Lebanon, Nigeria, South Africa, Tunisia, Turkey, Argentina, Bolivia, Brazil, Chile, Colombia, Costa Rica, Ecuador, Guatemala, Mexico, Panama, Paraguay, Peru, Uruguay and Venezuela

    How useful did you find this blog post?

    June 5th 2019, 2:03 am

    Improved app quality and discovery on Google Play

    Android Developers Blog

    Every month, more than 2 billion users from over 190 countries visit the Google Play Store to browse and discover new apps and games. As part of making Google Play a great discovery experience, we continue to increase our focus on quality. Over the coming weeks, we’ll be updating our featuring and ranking logic to further prioritize high quality apps and games with strong technical performance and engaging content.

    If you’re looking for ways to improve your app quality, below are three key areas to focus on. Along with these suggestions, we've highlighted several tools available in the Google Play Console to help you better understand user behavior, monitor technical performance, and deliver the best in-app experience for users. Remember, app quality will impact where and how prominently you're eligible to surface in the store, so always look to create the most compelling and delightful experience possible.

    Good in-app user experience

    Have you thought about your UI and if your app has intuitive navigation, controls, and menu access? Do you have a good first-time-user experience, overall polished design, and enough content to keep users engaged for the long term?

    Quality guidelines: meet user expectations and maximize your exposure opportunities by testing against the quality guidelines for different platforms.

    Testing tracks: release early versions of your app to gather early user feedback and make improvements before full release.

    Engaging content: build loyalty and sustainable app engagement by satisfying your users needs

    Ad placement: for apps with ads integrated, ensure a good user experience by choosing the right ad format and placement throughout your app.

    Strong app stability and technical performance

    Have you considered whether your app has good overall technical performance, and if it is power-thrifty, responsive, efficient, and well-behaved? 42% of users who leave a 1-star review mention stability or bugs.

    Android vitals: review the Android vitals dashboard to see how your app is performing on core vitals metrics including crash rate, ANR rate, excessive wakeups, and stuck partial wake locks in the background. Look at developer selected peer benchmarks to see how you measure up to others in your category. Exhibiting bad behavior in Android vitals will negatively affect the user experience in your app and could limit your exposure opportunities on Google Play.

    Pre-launch reports: identify where your app has problems to ensure you’re presenting the highest possible quality to users upon launch. The pre-launch reports use automated tests on real devices that can identify layout issues, provide crash diagnostics, locate security vulnerabilities, and more.

    Effective store listing page

    Last but not least, a quality app also means having an effective and accurate listing page. Does your store listing page make a great first impression? Does it clearly and accurately communicate the value and intended use cases of your app?

    Best practices: use strong creative assets, including your app title, icon, screenshots and video, along with a clear and informative app description, that provide an accurate representation of your app. To improve discovery opportunities, we suggest all pages have a video (set to public or unlisted and non-monetized) to inform users about your app, and for game developers to provide three or more 16:9 aspect ratio screenshots.

    New icon specification: create a more polished experience on the store by updating your icon before June 24th.

    Ratings and reviews: monitor your user ratings and reviews and respond to negative reviews where possible. When receiving a reply from developers, users increase their rating by +0.7 stars on average. Paying attention to ratings and reviews will be increasingly important as we rollout the new rating score in August 2019. This will place more weight on your most recent ratings in the Google Play Store.

    Store listing experiments: A/B test different versions of your listing page amongst actual Google Play users. Make sure to test each component independently and run tests for at least a week in order to gather significant results.

    Custom store listings: tailor your marketing messages to specific user groups based on their country, install state or even pre-registration. This is a great way to highlight key features and updates best suited for existing or lapsed users.

    Localization: take advantage of Google Play’s worldwide reach to identify key markets, translate your app store listing, and even run store listing experiments to optimize for each country.

    Get the most out of the Google Play Console and learn about improving app quality on the Academy for App Success, a free e-learning resource.

    How useful did you find this blog post?

    June 4th 2019, 12:11 pm

    Google Play services and Firebase migrating to AndroidX

    Android Developers Blog

    Posted by Doug Stevenson, Developer Advocate

    Later this year, the Google Play services and Firebase SDKs will migrate from the Android Support libraries to androidx-packaged library artifacts. We are targeting this change for June/July of 2019. This will not only make our SDKs better, but make it easier for you to use the latest Jetpack features in your app.

    If your app depends on any com.google.android.gms or com.google.firebase libraries, you should prepare for this migration. To quickly test your build with androidx-packaged library artifacts, add the following two lines to your gradle.properies file:

    android.useAndroidX=true
    android.enableJetifier=true

    If your build still works, then you're done! You will be ready to use the new Google Play services and Firebase SDKs when they arrive. If you experience any new build issues or want more information on this migration, visit the official Jetpack migration guide. We will communicate when the androidx migration is complete in the near future, stay tuned!

    June 3rd 2019, 2:42 pm

    Building a safer Google Play for kids

    Android Developers Blog

    Posted by Kanika Sachdeva, Product Manager, Google Play

    At Google Play, we’re committed to providing a positive, safe environment for children and families. Over the last few years, we’ve helped parents find family-friendly content through the Designed for Families program and empowered them to set digital ground rules for their families with Family Link parental controls.

    After taking input from users and developers we are evolving our Google Play policies to provide additional protections for children and families. These policy changes build on our existing efforts to ensure that apps for children have appropriate content, show suitable ads, and handle personally identifiable information correctly; they also reduce the chance that apps not intended for children could unintentionally attract them.

    Over the next few months, we will continue to roll out additional features that will help parents make informed choices before they install apps for their kids.

    What’s changing for developers

    We are asking every developer to thoughtfully consider whether children are part of your target audience.

    Declaring a target audience

    As part of the new policy, all developers must complete the new target audience and content section of the Google Play Console.

    The new target audience and content section of the Google Play Console.

    For most developers, the target audience does not include children and this section should be relatively quick to complete. If children are part of your target audience, we will ask you follow-up questions.

    We will use the information you provide in the Google Play Console, along with our own review of your app marketing assets, to categorize your app and apply policies according to the following target audience groups: children, children and older users, older users.*

    We recommend you review our new policies, developer guide, and this training before starting the target audience and content section so that you clearly understand the implications of your answers.

    Rolling out these changes

    These changes affect every developer on Play, so if your app is already live on the Google Play store, we want to give you time to make any necessary updates. Below are the key dates to keep in mind:

    Our commitment to you

    We’re committed to providing the resources you need to understand and implement these changes. You can view more information on the Android developers website and access training on our new policies on Google Play's Academy for App Success. We have also increased our staffing and improved our communications for app review and appeals processes to help you get timely decisions and understand any changes that are needed.

    Thanks in advance for the work you are putting in. We will continue to listen to your feedback and use it to improve the way we roll out these updates and communicate with the developer community.

    *Note: The word “children” can mean different things in different locales and in different contexts. It is important that you determine what obligations and/or age-based restrictions may apply for the countries where you target your app.

    How useful did you find this blog post?

    May 29th 2019, 10:17 am

    Congratulations to the finalists of the Indie Games Showcase from Google Play

    Android Developers Blog

    Posted by Patricia Correa, Director, Platforms & Ecosystems Developer Marketing

    Back in March we opened submissions for the Indie Games Showcase, an international competition for games studios from Europe*, South Korea, and Japan who are constantly pushing the boundaries of storytelling, visual excellence, and creativity in mobile.

    We were once again impressed by the diversity and creativity that the indie community is bringing to mobile, and we’re happy to announce the 20 finalists.

    Check out the local websites to learn more about the finalists and the events.

    Europe

    AntVentor by LoopyMood (Ukraine)

    CHUCHEL by Amanita Design (Czech Republic)

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Fobia by Tapteek (Russia)

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Gold Peaks by Afterburn (Poland)

    Grayland by 1DER Entertainment (Slovakia)

    Hexologic by MythicOwl (Poland)

    Lucid Dream Adventure by Dali Games (Poland)

    OCO by SPECTRUM48 (United Kingdom)

    Ordia by Loju (United Kingdom)

    Peep by Taw (Russia)

    Photographs by EightyEight Games (United Kingdom)

    Rest in Pieces by Itatake (Sweden)

    Returner Zhero by Fantastic, yes (Denmark)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

    Tiny Room Stories: Town Mystery by Kiary games (Russia)

    Japan

    ALTER EGO by 株式会社カラメルカラム

    Infection - 感染 - by CanvasSoft

    Jumpion - Make a two-step jump ! by Comgate

    Lunch Time Fish by SoftFunk HULABREAKS

    MeltLand by 個人

    ReversEstory by 個人

    キグルミキノコ Q-bit -第一章- by 個人

    SumoRoll - Road to the Yokozuna by Studio Kingmo

    Escape Game: The Little Prince by 株式会社 Jammsworks

    Kamiori - カミオリ by TeamOrigami

    Bear's Restaurant by 個人

    クマムシさん惑星 ミクロの地球最強伝説 by Ars Edutainment

    ゴリラ!ゴリラ!ゴリラ!by Gang Gorilla Games

    Girl x Sun - Terasene - Tower defence & Novel game by SleepingMuseum

    タシテケス by 個人

    Destination: Dragons! by GAME GABURI

    Cute cat's cake shop by 個人

    Persephone by Momo-pi

    Hamcorollin' by illuCalab.

    Food Truck Pup: Cooking Chef by 合同会社ゲームスタート

    South Korea

    다크타운 - 온라인 by 초콜릿소프트

    Bad 2 Bad: Extinction by Dawinstone

    셧더펑 : 슈팅액션 by Take Five Games

    Cartoon Craft by Studio NAP

    Catch Idle by HalftimeStudio

    Hexagon Dungeon by Bleor Games

    Hexonia by Togglegear

    Mahjong - Magic Fantasy by Aquagamez

    Maze Cube by IAMABOY

    Road to Valor: World War II by Dreamotion Inc.

    Onslot Car by Wondersquad

    ROOMS: The Toymaker's Mansion by HandMade Game

    Rhythm Star: Music Adventure by Anbsoft

    7Days - Decide your story by Buff Studio

    Seoul2033: Backer by Banjiha Games

    Super Jelly Pop by STARMONSTER

    UNLINK Daily Puzzle by Supershock

    몬스터파크 온라인 by OVENCODE

    WhamBam Warriors by DrukHigh

    언노운 나이츠 by teamarex

    We will welcome all finalists at events in London, Seoul, and Tokyo, where they will showcase their games to an audience of players, press and industry experts, for a chance to win the top prizes.

    The events are open to the public, so if you would like to meet these games developers, try out their creations, and help choose the winners, sign up on the regional websites.

    Congratulations to all finalists!

    * The competition is open to developers from the following European countries and Israel: Austria, Belgium, Belarus, Czech Republic, Denmark, Finland, France, Germany, Italy, Netherlands, Norway, Poland, Romania, Russia, Slovakia, Spain, Sweden, Ukraine, and the United Kingdom (including Northern Ireland).

    How useful did you find this blog post?

    May 23rd 2019, 2:01 am

    Wide Color Photos Are Coming to Android: Things You Need to Know to be Prepared

    Android Developers Blog

    Posted by Peiyong Lin, Software Engineer

    Android is now at the point where sRGB color gamut with 8 bits per color channel is not enough to take advantage of the display and camera technology. At Android we have been working to make wide color photography happen end-to-end, e.g. more bits and bigger gamuts. This means, eventually users will be able to capture the richness of the scenes, share a wide color pictures with friends and view wide color pictures on their phones. And now with Android Q, it's starting to get really close to reality: wide color photography is coming to Android. So, it's very important to applications to be wide color gamut ready. This article will show how you can test your application to see whether it's wide color gamut ready and wide color gamut capable, and the steps you need to take to be ready for wide color gamut photography.

    But before we dive in, why wide color photography? Display panels and camera sensors on mobile are getting better and better every year. More and more newly released phones will be shipped with calibrated display panels, some are wide color gamut capable. Modern camera sensors are capable of capturing scenes with a wider range of color outside of sRGB and thus produce wide color gamut pictures. And when these two come together, it creates an end-to-end photography experience with more vibrant colors of the real world.

    At a technical level, this means there will be pictures coming to your application with an ICC profile that is not sRGB but some other wider color gamut: Display P3, Adobe RGB, etc. For consumers, this means their photos will look more realistic.

    Display P3

    SRGB

    Display P3

    SRGB

    Above are images of the Display P3 version and the SRGB version respectively of the same scene. If you are reading this article on a calibrated and wide color gamut capable display, you can notice the significant difference between these them.

    Color Tests

    There are two kinds of tests you can perform to know whether your application is prepared or not. One is what we call color correctness tests, the other is wide color tests.

    Color Correctness test: Is your application wide color gamut ready?

    A wide color gamut ready application implies the application manages color proactively. This means when given images, the application always checks the color space and does conversion based on its capability of showing wide color gamut, and thus even if the application can't handle wide color gamut it can still show the sRGB color gamut of the image correctly without color distortion.

    Below is a color correct example of an image with Display P3 ICC profile.

    However, if your application is not color correct, then typically your application will end up manipulating/displaying the image without converting the color space correctly, resulting in color distortion. For example you may get the below image, where the color is washed-out and everything looks distorted.

    Wide Color test: Is your application wide color gamut capable?

    A wide color gamut capable application implies when given wide color gamut images, it can show the colors outside of sRGB color space. Here's an image you can use to test whether your application is wide color gamut capable or not, if it is, then a red Android logo will show up. Note that you must run this test on a wide color gamut capable device, for example a Pixel 3 or Samsung Galaxy S10.

    What you should do to prepare

    To prepare for wide color gamut photography, your application must at least pass the wide color gamut ready test, we call it color correctness test. If your application passes the wide color gamut ready tests, that's awesome! But if it doesn't, here are the steps to make it wide color gamut ready.

    The key thing to be prepared and future proof is that your application should never assume sRGB color space of the external images it gets. This means application must check the color space of the decoded images, and do the conversion when necessary. Failure to do so will result in color distortion and color profile being discarded somewhere in your pipeline.

    Mandatory: Be Color Correct

    You must be at least color correct. If your application doesn't adopt wide color gamut, you are very likely to just want to decode every image to sRGB color space. You can do that by either using BitmapFactory or ImageDecoder.

    Using BitmapFactory

    In API 26, we added inPreferredColorSpace in BitmapFactory.Option, which allows you to specify the target color space you want the decoded bitmap to have. Let's say you want to decode a file, then below is the snippet you are very likely to use in order to manage the color:

    final BitmapFactory.Options options = new BitmapFactory.Options();
    // Decode this file to sRGB color space.
    options.inPreferredColorSpace = ColorSpace.get(Named.SRGB);
    Bitmap bitmap = BitmapFactory.decodeFile(FILE_PATH, options);

    Using ImageDecoder

    In Android P (API level 28), we introduced ImageDecoder, a modernized approach for decoding images. If you upgrade your apk to API level 28 or beyond, we recommend you to use it instead of the BitmapFactory and BitmapFactory.Option APIs.

    Below is a snippet to decode the image to an sRGB bitmap using ImageDecoder#decodeBitmap API.

    ImageDecoder.Source source =
            ImageDecoder.createSource(FILE_PATH);
    try {
        bitmap = ImageDecoder.decodeBitmap(source,
                new ImageDecoder.OnHeaderDecodedListener() {
                    @Override
                    public void onHeaderDecoded(ImageDecoder decoder,
                            ImageDecoder.ImageInfo info,
                            ImageDecoder.Source source) {
                        decoder.setTargetColorSpace(ColorSpace.get(Named.SRGB));
                    }
                });
    } catch (IOException e) {
        // handle exception.
    }

    ImageDecoder also has the advantage to let you know the encoded color space of the bitmap before you get the final bitmap by passing an ImageDecoder.OnHeaderDecodedListener and checking ImageDecoder.ImageInfo#getColorSpace(). And thus, depending on how your applications handle color spaces, you can check the encoded color space of the contents and set the target color space differently.

    ImageDecoder.Source source =
            ImageDecoder.createSource(FILE_PATH);
    try {
        bitmap = ImageDecoder.decodeBitmap(source,
                new ImageDecoder.OnHeaderDecodedListener() {
                    @Override
                    public void onHeaderDecoded(ImageDecoder decoder,
                            ImageDecoder.ImageInfo info,
                            ImageDecoder.Source source) {
                        ColorSpace cs = info.getColorSpace();
                        // Do something...
                    }
                });
    } catch (IOException e) {
        // handle exception.
    }

    For more detailed usage you can check out the ImageDecoder APIs here.

    Known bad practices

    Some typical bad practices include but are not limited to:

    All these cause a severe users perceived results: Color distortion. For example, below is a code snippet that results in the application not color correct:

    // This is bad, don't do it!
    final BitmapFactory.Options options = new BitmapFactory.Options();
    final Bitmap bitmap = BitmapFactory.decodeFile(FILE_PATH, options);
    glTexImage2D(GLES20.GL_TEXTURE_2D, 0, GLES31.GL_RGBA, bitmap.getWidth(),
            bitmap.getHeight(), 0, GLES20.GL_RGBA, GLES20.GL_UNSIGNED_BYTE, null);
    GLUtils.texSubImage2D(GLES20.GL_TEXTURE_2D, 0, 0, 0, bitmap,
            GLES20.GL_RGBA, GLES20.GL_UNSIGNED_BYTE);

    There's no color space checking before uploading the bitmap as the texture, and thus the application will end up with the below distorted image from the color correctness test.

    Optional: Be wide color capable

    Besides the above changes you must make in order to handle images correctly, if your applications are heavily image based, you will want to take additional steps to display these images in the full vibrant range by enabling the wide gamut mode in your manifest or creating a Display P3 surfaces.

    To enable the wide color gamut in your activity, set the colorMode attribute to wideColorGamut in your AndroidManifest.xml file. You need to do this for each activity for which you want to enable wide color mode.

    android:colorMode="wideColorGamut"

    You can also set the color mode programmatically in your activity by calling the setColorMode(int) method and passing in COLOR_MODE_WIDE_COLOR_GAMUT.

    To render wide color gamut contents, besides the wide color contents, you will also need to create a wide color gamut surfaces to render to. In OpenGL for example, your application must first check the following extensions:

    And then, request the Display P3 as the color space when creating your surfaces, as shown in the following code snippet:

    private static final int EGL_GL_COLORSPACE_DISPLAY_P3_PASSTHROUGH_EXT = 0x3490;
    
    public EGLSurface createWindowSurface(EGL10 egl, EGLDisplay display,
                                          EGLConfig config, Object nativeWindow) {
      EGLSurface surface = null;
      try {
        int attribs[] = {
          EGL_GL_COLORSPACE_KHR, EGL_GL_COLORSPACE_DISPLAY_P3_PASSTHROUGH_EXT,
          egl.EGL_NONE
        };
        surface = egl.eglCreateWindowSurface(display, config, nativeWindow, attribs);
      } catch (IllegalArgumentException e) {}
      return surface;
    }

    Also check out our post about more details on how you can adopt wide color gamut in native code.

    APIs design guideline for image library

    Finally, if you own or maintain an image decoding/encoding library, you will need to at least pass the color correctness tests as well. To modernize your library, there are two things we strongly recommend you to do when you extend APIs to manage color:

    1. Strongly recommend to explicitly accept ColorSpace as a parameter when you design new APIs or extend existing APIs. Instead of hardcoding a color space, an explicit ColorSpace parameter is a more future-proof way moving forward.
    2. Strongly recommend all legacy APIs to explicitly decode the bitmap to sRGB color space. Historically there's no color management, and thus Android has been treating everything as sRGB implicitly until Android 8.0 (API level 26). This allows you to help your users maintain backward compatibility.

    After you finish, go back to the above section and perform the two color tests.

    May 20th 2019, 3:22 pm

    Kotlin Is Everywhere! Join the global event series

    Android Developers Blog

    Posted by Posted by Florina Muntenescu & Wojtek Kaliciński, Developer Advocates, Android

    Last week at Google I/O, we announced a big step: Android development will become increasingly Kotlin-first. It’s a language that many of you already love: over 50% of professional Android developers now use Kotlin, and it’s the fastest-growing language on GitHub. As part of this announcement, many new Jetpack APIs and features will be offered first in Kotlin. So if you’re starting a new project, you should try writing it in Kotlin; code written in Kotlin often means much less code for you–less code to type, test, and maintain.

    To help you dive deeper into Kotlin, we’re happy to announce a new program we’re launching together with JetBrains: Kotlin/Everywhere, a series of community-driven events focussing on the potential of Kotlin on all platforms. We are aiming to help learn the essentials and best practices of using Kotlin everywhere, be it for Android, back-end, front-end and other platforms.

    Join the Kotlin/Everywhere global event series between June and December 2019.

    Who can attend the events?

    Whether you are a developer, a speaker, a Kotlin User Group, a Google Developer Group member or any other community leader join us. Anyone interested in learning Kotlin and its ecosystem, sharing knowledge, and hosting a Kotlin-focused event is welcome to attend.

    If you are a developer wanting to learn more about Kotlin, or a speaker excited to share your Kotlin experience with others, you can find events near you to join. Just go to the map on the website. More events will be added over time.

    How to host your Kotlin/Everywhere event?

    If you want to host an event in your city, you can begin by checking out the detailed organizers’ guide. It will help you to decide on the format and what kind of support you might need. All the necessary tips and tricks, materials, and branding assets are inside. Go ahead and submit your event on the official web page.

    Besides the detailed organizers’ guide, we also provide you with resources such as content, codelabs, and guidance to help you maximize your success. You can also apply for support: we have speakers from Google/JetBrains and can help by providing funding for venue, food and drinks, swag, or other. We will also list your event on the official website.

    Still have questions? Ask them at our hangout sessions for organizers on May 16 and 17.

    Let us know if you want to take part! Apply at kotl.in/everywhere

    May 16th 2019, 2:07 pm

    New! Learn How to Build Android Apps with Android Jetpack and Kotlin

    Android Developers Blog

    Posted by Dan Galpin

    Developing Android Apps with Kotlin, developed by Google together with Udacity, is our newly-released, free, self-paced online course. You'll learn how to build Android apps using industry-standard tools and libraries in the Kotlin programming language.

    Android development fundamentals are taught in the context of an architecture that provides the scaffolding for robust, maintainable applications. The course covers why and how to use Android Jetpack components such as Room for databases, Work Manager for background processing, the Navigation component, and more. You'll use popular community libraries to simplify common tasks such as Glide for image loading, Retrofit for networking, and Moshi for JSON parsing. The course teaches key Kotlin features such as coroutines to help you write your app code more quickly and concisely.

    As you work through the course, you'll build fun and interesting apps, such as a Mars photo gallery, a trivia game, a sleep tracker and much more.

    This course is intended for people who have programming experience and are comfortable with Kotlin basics. If you're new to the Kotlin language, we recommend taking the Udacity Kotlin Bootcamp course first.

    The course is available free, online at Udacity; take it in your own time at your own pace.

    Come learn how to build Android apps in Kotlin with us at https://www.udacity.com/course/ud9012.

    May 15th 2019, 5:23 pm

    Supporting Google Play developers regarding local market withholding tax regulations

    Android Developers Blog

    Posted by Gloria On, Program Manager, Google Play

    Many developers are increasingly focused on growing their businesses globally, and there were more than 94 billion apps downloaded from Google Play in the last year, reaching more than 190 countries. The regulatory environment is frequently changing in local markets, and in some countries local governments have implemented withholding tax requirements on transactions with which Google or our payment processor partners must comply. We strive to help both developers and Google meet local tax requirements in markets where we do business, and where Google or our payment processor partners are required to withhold taxes, we may need to deduct those amounts from our payments to developers.

    Due to new requirements in some markets, we'll be rolling out withholding taxes soon to all those doing business in those countries. We wanted to bring this to the attention of Google Play developers to allow you time to prepare for these upcoming changes and take any necessary measures to meet these obligations. We strongly recommend developers consult with a professional tax advisor on your individual tax implications in affected markets and for guidance on the potential impact on your business so that you can make any necessary preparations.

    The first countries where we will roll out these changes will be Saudi Arabia, Kuwait, and Myanmar. You can refer to the Google Play help center page to stay informed on future updates and changes.

    How useful did you find this blog post?

    May 15th 2019, 12:34 pm

    Queue the Hardening Enhancements

    Android Developers Blog

    Posted by Jeff Vander Stoep, Android Security & Privacy Team and Chong Zhang, Android Media Team

    Android Q Beta versions are now publicly available. Among the various new features introduced in Android Q are some important security hardening changes. While exciting new security features are added in each Android release, hardening generally refers to security improvements made to existing components.

    When prioritizing platform hardening, we analyze data from a number of sources including our vulnerability rewards program (VRP). Past security issues provide useful insight into which components can use additional hardening. Android publishes monthly security bulletins which include fixes for all the high/critical severity vulnerabilities in the Android Open Source Project (AOSP) reported through our VRP. While fixing vulnerabilities is necessary, we also get a lot of value from the metadata - analysis on the location and class of vulnerabilities. With this insight we can apply the following strategies to our existing components:

    Here’s a look at high severity vulnerabilities by component and cause from 2018:

    Most of Android’s vulnerabilities occur in the media and bluetooth components. Use-after-free (UAF), integer overflows, and out of bounds (OOB) reads/writes comprise 90% of vulnerabilities with OOB being the most common.

    A Constrained Sandbox for Software Codecs

    In Android Q, we moved software codecs out of the main mediacodec service into a constrained sandbox. This is a big step forward in our effort to improve security by isolating various media components into less privileged sandboxes. As Mark Brand of Project Zero points out in his Return To Libstagefright blog post, constrained sandboxes are not where an attacker wants to end up. In 2018, approximately 80% of the critical/high severity vulnerabilities in media components occurred in software codecs, meaning further isolating them is a big improvement. Due to the increased protection provided by the new mediaswcodec sandbox, these same vulnerabilities will receive a lower severity based on Android’s severity guidelines.

    The following figure shows an overview of the evolution of media services layout in the recent Android releases.

    With this move, we now have the two primary sources for media vulnerabilities tightly sandboxed within constrained processes. Software codecs are similar to extractors in that they both have extensive code parsing bitstreams from untrusted sources. Once a vulnerability is identified in the source code, it can be triggered by sending a crafted media file to media APIs (such as MediaExtractor or MediaCodec). Sandboxing these two services allows us to reduce the severity of potential security vulnerabilities without compromising performance.

    In addition to constraining riskier codecs, a lot of work has also gone into preventing common types of vulnerabilities.

    Bound Sanitizer

    Incorrect or missing memory bounds checking on arrays account for about 34% of Android’s userspace vulnerabilities. In cases where the array size is known at compile time, LLVM’s bound sanitizer (BoundSan) can automatically instrument arrays to prevent overflows and fail safely.

    BoundSan instrumentation

    BoundSan is enabled in 11 media codecs and throughout the Bluetooth stack for Android Q. By optimizing away a number of unnecessary checks the performance overhead was reduced to less than 1%. BoundSan has already found/prevented potential vulnerabilities in codecs and Bluetooth.

    More integer sanitizer in more places

    Android pioneered the production use of sanitizers in Android Nougat when we first started rolling out integer sanization (IntSan) in the media frameworks. This work has continued with each release and has been very successful in preventing otherwise exploitable vulnerabilities. For example, new IntSan coverage in Android Pie mitigated 11 critical vulnerabilities. Enabling IntSan is challenging because overflows are generally benign and unsigned integer overflows are well defined and sometimes intentional. This is quite different from the bound sanitizer where OOB reads/writes are always unintended and often exploitable. Enabling Intsan has been a multi year project, but with Q we have fully enabled it across the media frameworks with the inclusion of 11 more codecs.

    IntSan Instrumentation

    IntSan works by instrumenting arithmetic operations to abort when an overflow occurs. This instrumentation can have an impact on performance, so evaluating the impact on CPU usage is necessary. In cases where performance impact was too high, we identified hot functions and individually disabled IntSan on those functions after manually reviewing them for integer safety.

    BoundSan and IntSan are considered strong mitigations because (where applied) they prevent the root cause of memory safety vulnerabilities. The class of mitigations described next target common exploitation techniques. These mitigations are considered to be probabilistic because they make exploitation more difficult by limiting how a vulnerability may be used.

    Shadow Call Stack

    LLVM’s Control Flow Integrity (CFI) was enabled in the media frameworks, Bluetooth, and NFC in Android Pie. CFI makes code reuse attacks more difficult by protecting the forward-edges of the call graph, such as function pointers and virtual functions. Android Q uses LLVM’s Shadow Call Stack (SCS) to protect return addresses, protecting the backwards-edge of control flow graph. SCS accomplishes this by storing return addresses in a separate shadow stack which is protected from leakage by storing its location in the x18 register, which is now reserved by the compiler.

    SCS Instrumentation

    SCS has negligible performance overhead and a small memory increase due to the separate stack. In Android Q, SCS has been turned on in portions of the Bluetooth stack and is also available for the kernel. We’ll share more on that in an upcoming post.

    eXecute-Only Memory

    Like SCS, eXecute-Only Memory (XOM) aims at making common exploitation techniques more expensive. It does so by strengthening the protections already provided by address space layout randomization (ASLR) which in turn makes code reuse attacks more difficult by requiring attackers to first leak the location of the code they intend to reuse. This often means that an attacker now needs two vulnerabilities, a read primitive and a write primitive, where previously just a write primitive was necessary in order to achieve their goals. XOM protects against leaks (memory disclosures of code segments) by making code unreadable. Attempts to read execute-only code results in the process aborting safely.

    Tombstone from a XOM abort

    Starting in Android Q, platform-provided AArch64 code segments in binaries and libraries are loaded as execute-only. Not all devices will immediately receive the benefit as this enforcement has hardware dependencies (ARMv8.2+) and kernel dependencies (Linux 4.9+, CONFIG_ARM64_UAO). For apps with a targetSdkVersion lower than Q, Android’s zygote process will relax the protection in order to avoid potential app breakage, but 64 bit system processes (for example, mediaextractor, init, vold, etc.) are protected. XOM protections are applied at compile-time and have no memory or CPU overhead.

    Scudo Hardened Allocator

    Scudo is a dynamic heap allocator designed to be resilient against heap related vulnerabilities such as:

    Scudo does not prevent exploitation but rather proactively manages memory in a way to make exploitation more difficult. It is configurable on a per-process basis depending on performance requirements. Scudo is enabled in extractors and codecs in the media frameworks.

    Tombstone from Scudo aborts

    Contributing security improvements to Open Source

    AOSP makes use of a number of Open Source Projects to build and secure Android. Google is actively contributing back to these projects in a number of security critical areas:

    Thank you to Ivan Lozano, Kevin Deus, Kostya Kortchinsky, Kostya Serebryany, and Mike Logan for their contributions to this post.

    May 9th 2019, 11:32 am

    What’s New in Android Q Security

    Android Developers Blog

    Posted by Rene Mayrhofer and Xiaowen Xin, Android Security & Privacy Team

    With every new version of Android, one of our top priorities is raising the bar for security. Over the last few years, these improvements have led to measurable progress across the ecosystem, and 2018 was no different.

    In the 4th quarter of 2018, we had 84% more devices receiving a security update than in the same quarter the prior year. At the same time, no critical security vulnerabilities affecting the Android platform were publicly disclosed without a security update or mitigation available in 2018, and we saw a 20% year-over-year decline in the proportion of devices that installed a Potentially Harmful App. In the spirit of transparency, we released this data and more in our Android Security & Privacy 2018 Year In Review.

    But now you may be asking, what’s next?

    Today at Google I/O we lifted the curtain on all the new security features being integrated into Android Q. We plan to go deeper on each feature in the coming weeks and months, but first wanted to share a quick summary of all the security goodness we’re adding to the platform.

    Encryption

    Storage encryption is one of the most fundamental (and effective) security technologies, but current encryption standards require devices have cryptographic acceleration hardware. Because of this requirement many devices are not capable of using storage encryption. The launch of Adiantum changes that in the Android Q release. We announced Adiantum in February. Adiantum is designed to run efficiently without specialized hardware, and can work across everything from smart watches to internet-connected medical devices.

    Our commitment to the importance of encryption continues with the Android Q release. All compatible Android devices newly launching with Android Q are required to encrypt user data, with no exceptions. This includes phones, tablets, televisions, and automotive devices. This will ensure the next generation of devices are more secure than their predecessors, and allow the next billion people coming online for the first time to do so safely.

    However, storage encryption is just one half of the picture, which is why we are also enabling TLS 1.3 support by default in Android Q. TLS 1.3 is a major revision to the TLS standard finalized by the IETF in August 2018. It is faster, more secure, and more private. TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions. From a security perspective, TLS 1.3 removes support for weaker cryptographic algorithms, as well as some insecure or obsolete features. It uses a newly-designed handshake which fixes several weaknesses in TLS 1.2. The new protocol is cleaner, less error prone, and more resilient to key compromise. Finally, from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.

    Platform Hardening

    Android utilizes a strategy of defense-in-depth to ensure that individual implementation bugs are insufficient for bypassing our security systems. We apply process isolation, attack surface reduction, architectural decomposition, and exploit mitigations to render vulnerabilities more difficult or impossible to exploit, and to increase the number of vulnerabilities needed by an attacker to achieve their goals.

    In Android Q, we have applied these strategies to security critical areas such as media, Bluetooth, and the kernel. We describe these improvements more extensively in a separate blog post, but some highlights include:

    Authentication

    Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and iris. Since the launch, we’ve seen a lot of apps embrace the new API, and now with Android Q, we’ve updated the underlying framework with robust support for face and fingerprint. Additionally, we expanded the API to support additional use-cases, including both implicit and explicit authentication.

    In the explicit flow, the user must perform an action to proceed, such as tap their finger to the fingerprint sensor. If they’re using face or iris to authenticate, then the user must click an additional button to proceed. The explicit flow is the default flow and should be used for all high-value transactions such as payments.

    Implicit flow does not require an additional user action. It is used to provide a lighter-weight, more seamless experience for transactions that are readily and easily reversible, such as sign-in and autofill.

    Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu. To support this, we’ve added a new BiometricManager class. You can now call the canAuthenticate() method in it to determine whether the device supports biometric authentication and whether the user is enrolled.

    What’s Next?

    Beyond Android Q, we are looking to add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license. Apps such as these have a lot of security requirements and involves integration between the client application on the holder’s mobile phone, a reader/verifier device, and issuing authority backend systems used for license issuance, updates, and revocation.

    This initiative requires expertise around cryptography and standardization from the ISO and is being led by the Android Security and Privacy team. We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications. You can expect to hear more updates from us on Electronic ID support in the near future.

    May 9th 2019, 11:32 am

    What’s New with Android Jetpack

    Android Developers Blog

    Posted by Karen Ng, Group Product Manager and Jisha Abubaker, Product Manager, Android

    Last year, we launched Android Jetpack, a collection of software components designed to accelerate Android development and make writing high-quality apps easier. Jetpack was built with you in mind -- to take the hardest, most common developer problems on Android and make your lives easier.

    Jetpack has seen incredible adoption and momentum. Today, 80% of the top 1,000 apps in the Play store are using Jetpack. We’ve also heard feedback from so many of you across our early access developer programs and user studies, as well as Reddit, Stack Overflow, and Slack, that has helped shape these APIs. Very humbly, thank you.

    What’s New in Jetpack

    Today, we are excited to share with you 11 Jetpack libraries that can be used in development now and an early-development, open-source project called Jetpack Compose to simplify UI development.

    Now in Alpha

    CameraX

    We've heard from many of you that developing camera apps or integrating camera functionality within your existing apps is hard. With the new CameraX library, we want to enable you to create great camera-driven experiences in your application without worrying about the underlying device behavior. This API is backwards compatible to Android 5.0 (API 21) or higher, ensuring that the same code works on most devices in the market. While it leverages the capabilities of camera2, it uses a simpler, use case-based approach that is lifecycle-aware eliminating significant amount of boilerplate code vs camera2. Finally, it enables you to access the same functionality as the native camera app on supported devices. These optional Extensions enable features like Portrait, Night, HDR, and Beauty.

    LiveData and Lifecycles w/ coroutines

    We heard you loud and clear and agree that LiveData must support your common one-shot asynchronous operations. With Lifecycle & LiveData KTX, you can do so with Kotlin coroutines that are lifecycle-aware. Kotlin coroutines have been well received by the developer community for how they simplify the way concurrency is handled within Android apps. We want to simplify it even further and enabling you to use them safely by offering coroutine scopes tied to lifecycles, coroutine dispatchers that are lifecycle-aware, and support for simple asynchronous chains with the new liveData builder.

    Benchmark

    The Benchmark library provides you a quick way to benchmark your app code, whether it is written in Kotlin, the Java programming language or native code. We use this library to continuously benchmark Jetpack libraries we release to ensure we do not introduce any latency into your code. You can now do the same right within your development environment in Android Studio, easily measuring database queries, view inflation, or a RecyclerView scroll. The library takes care of what is needed to provide reliable and consistent results like handling warm-up periods, removing outliers, and locking CPU clocks.

    Security

    To maximize security of an application’s data at-rest, the new Security library implements security best practices for you. It provides strong security that balances encryption with performance for consumer apps like banking and chat. It also provides a maximum level of security for apps that require a hardware-backed keystore with user presence and simplifies many operations including key generation and validation.

    ViewModel with SavedState

    ViewModel provided you an easy way to save your UI data in the event of a configuration change. It did not save your app state in the event of process death, and many of you have been relying on SavedInstanceState alongside ViewModel. With the ViewModel with SavedState module, you can eliminate boilerplate code and gain the benefits of using both ViewModel and SavedState with simple APIs to save and retrieve data right from your ViewModel.

    ViewPager2

    ViewPager2, the next generation of ViewPager, is now based on RecyclerView and supports vertical scrolling and RTL (Right-to-Left) layouts. It also provides a much easier way to listen for page data changes with registerOnPageChangeCallback.

    Now in Beta

    ConstraintLayout 2.0

    ConstraintLayout 2.0 brings up new optimizations, and new way of customizing layouts, with the addition of helper classes. As part of ConstraintLayout 2.0, MotionLayout provides an easy way to manage motion and widget animation in your applications. You can easily describe transitions between layouts and animation of properties. MotionLayout is fully declarative in XML, allowing you to describe even complex transitions without requiring any code.

    Biometrics Prompt

    Users are accustomed to biometric credentials on their phones, but if your app requires a biometric login, it is important to make sure that users are provided a consistent and safe way to enter their credentials. The Biometrics library provides a simple system prompt giving the user a trustworthy experience.

    Enterprise

    With the Jetpack Enterprise library, your managed enterprise apps can send feedback back to Enterprise Mobility Management providers in the form of keyed app states, while taking advantage of backwards compatibility with managed configurations.

    Android for Cars

    With the Android for Cars libraries, you can provide your users a driver-optimized version of your app that will be automatically installed onto the vehicle’s infotainment system in vehicles equipped with the Android Automotive OS. It also allows your apps to work with the Android Auto app, providing the driver-optimized version anytime on their device.

    Now in Stable

    And in case you missed it, we announced stable releases of Jetpack WorkManager (background processing) and Jetpack Navigation (in-app navigation) just a few months ago.

    Jetpack Compose

    Today, we open-sourced an early preview of Jetpack Compose, a new unbundled toolkit designed to simplify UI development by combining a reactive programming model with the conciseness and ease-of-use of Kotlin. We have always done our best work when we did it with you - our developer community. That’s why we decided to develop Jetpack Compose in the open, starting today.

    In that vein, we took a step back and chatted with many of you. We heard strong feedback from developers that they like the modern, reactive APIs that Flutter, React Native, Litho, and Vue.js represent. We also heard that developers love Kotlin, with over 53% of professional Android developers using it and with 20% higher language satisfaction ratings than the Java programming language. Kotlin has become the fastest-growing language in terms of number of contributors on GitHub.

    So, we decided to invest in the reactive approach to declarative programming and create an easier way to build UIs with Kotlin.

    We are building Compose with a few core principles:

    A Compose application is made up of composable functions that transform application data into a UI hierarchy. A function is all you need to create a new UI component. To create a composable function just add the @Composable annotation to the function name. Under the hood, Compose uses a custom Kotlin compiler plug-in so when the underlying data changes, the composable functions can be re-invoked to generate an updated UI hierarchy. The simple example below prints a string to the screen.

    We know that adopting any new framework is a big change for existing projects and codebases, which is why we’ve designed Compose like all of Jetpack -- with individual components that you can adopt at your own pace and are compatible with existing views.

    If you want to learn more about Jetpack Compose or download its source to try it for yourself, check out http://d.android.com/jetpackcompose

    We'd love to hear from you as we iterate on this exciting future together. Send us feedback by posting comments below, and please file any bugs you run into on AOSP or directly through the feedback buttons in the Android Studio Jetpack Compose build in AOSP. Since this is an early preview, we do not recommend trying this on any production projects.

    Happy Jetpacking!

    May 8th 2019, 3:44 pm

    I/O 2019: New features to help you develop, release, and grow your business on Google Play

    Android Developers Blog

    Posted by Kobi Glick, Product Lead, Google Play

    Over the last 10 years, we’ve worked together to build an incredible ecosystem with more than 2.5 billion active users in over 190 countries. This would not be possible without you and all the fantastic apps and games you’ve built that entertain, help, and educate people around the world.

    Every month, you upload more than 750,000 APKs and app bundles to the Play Console. We’ve been amazed by your enthusiasm, and it’s been our privilege to help you grow your business. This year, we want to help you go even further. So today at Google I/O, we're announcing new tools and features to help you develop, release, and grow your apps and games — many of them based on your feedback and suggestions.

    Efficient, modular apps and customizable feature delivery

    Last year we introduced Android's new publishing format, the Android App Bundle, and an entirely new dynamic delivery framework on Google Play. There are now over 80,000 apps and games using app bundles in production, with an average size savings of 20%. As a result of those savings, apps have seen up to 11% install uplift. As the future of app delivery, we’re excited to share these latest enhancements to the Android App Bundle.

    Dynamic features are out of beta and available to all developers, including these new delivery options:

    During our beta program, many developers implemented interesting use cases with dynamic features. Netflix, for example, now delivers their customer support functionality as a dynamic feature to users who visit the support center. By making functionality available only to users who need it, Netflix reported a 33% reduction in app size. You can learn more in the video below.

    Seamless internal testing and increased security

    We heard you loud and clear: testing bundles is hard. But with the new internal app sharing, you can now share test builds in a matter of seconds. Just upload your app bundle to Google Play and get a download URL to share with your testers. You don’t need to worry about version codes, signing keys, or most other validations that your production releases need to conform to.

    In addition to efficiency and modularity, the Android App Bundle also now offers increased security with the launch of app signing key upgrade for new installs. With this feature, you can upgrade the cryptographic strength of your signing key for new installs and their updates on Google Play. Many developers sign their apps with keys generated a long time ago, and this new feature is the only backwards-compatible way to increase their strength.

    Easier for users to update

    Although auto-updates reach many users, you told us it was still challenging to get some users to update your apps. Now that our new in-app updates API is in general availability, users will be able to update without ever leaving your app. During our early access program, many developers used our API to create a polished upgrade flow, resulting in a median acceptance rate of about 50%.

    The API currently supports two flows:

    Stronger decision-making with new Google Play Console data

    The right data can help you improve your app performance and grow your business. That’s why we’re excited to tell you about new metrics and insights that will help you better measure your app health and analyze your performance.

    Making it easier to respond to and improve user reviews

    We’re also making big changes to another key source of performance data: your user reviews. Many of you told us that you want a rating that reflects a more current version of your app, not what it was years ago — and we agree. So instead of a lifetime cumulative value, your Google Play Store rating will be recalculated to give more weight to your most recent ratings. Users won’t see the updated rating in the Google Play Store until August, but you can preview your new rating in the Google Play Console today.

    Every day, developers respond to more than 100,000 reviews in the Play Console, and when they do, we’ve seen that users update their rating by +0.7 stars on average. So in addition to the ratings change, we're making it easier to respond to reviews with suggested replies. When you go to respond to a user, you’ll see three suggested replies which have been created automatically based on the content of the review. You can choose to send one as-suggested, customize a suggestion for more personalization, or create your own message from scratch. Suggested replies are available in English now with additional languages coming later.

    Better Google Play Store listing targeting and customization

    Your store listing is where users come to learn more about your app or game and decide whether to install. It’s important real estate, so we’re releasing new features that let you optimize your Google Play Store to address different moments in the user lifecycle.

    Learn more about these and other Google Play features at Google I/O. Join us live or watch later on the Android Developers YouTube channel.

    You can also take your skills and knowledge to the next level with our e-learning courses on Google Play’s Academy for App Success, and sign up for our newsletter to stay up to date with our latest features and updates.

    How useful did you find this blog post?

    May 8th 2019, 2:44 pm

    Android Studio 3.5 Beta

    Android Developers Blog

    Posted by Jamal Eason, Product Manager, Android

    Android Studio 3.5 Beta is ready to download today. Last year, at Google I/O, we heard from many of you that you wanted us to focus even more on quality and stability over features. Consequently, we kicked off Project Marble, focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Android Studio 3.5 is the culmination of this effort. The results of Project Marble are focused on three core areas: system health, feature polish, and bugs. We are seeking your final round of feedback to make sure we didn't miss a key area that matters to you, so download Android Studio 3.5 on the beta channel today to let us know what you think.

    Many times it can be difficult to see the range of changes that go into a quality release. Therefore, this post and our Google I/O talk on What’s New in Android Development Tools walk through a variety of changes in each of the major focus areas of Project Marble within Android Studio 3.5. We are certainly not done improving quality with Android Studio, but with the work and new infrastructure put into Project Marble for long term quality tracking we hope that you are even more productive in developing Android apps.

    System Health - Memory

    One of the major points of feedback on Android Studio is how slow the IDE runs over time. Many times the reason behind this experience is due to unexpectedly reaching memory pressure or IDE memory leaks. We dug into this area, and as part of Project Marble, we have addressed over 33 impactful memory leaks. To identify leaks, we now measure out-of-memory exceptions on an internal dashboard on an on-going basis for those who opt-in to share data with us which enables us to focus and fix the most impactful issues. Starting with Android Studio 3.5, when the IDE runs out of memory, we capture some high level statistics about the size of the memory heap and dominant objects in the heap. With this data the IDE can do two things: suggest better memory settings and offer to do a deeper memory analysis.

    Memory Settings

    Memory Usage Report

    System Health - Exceptions

    We have revamped our exception process backend pipeline. Now with the opt-in data we have earlier signals of common exceptions in aggregate which lets us prioritize and fix issues earlier in the canary release process than before. Moreover, we reduced the amount of times we prompt you for exceptions, since the analytics and opt-in crash reports are now more actionable for our team. The net result is that you should see the blinky red exception report icon in the lower status bar of the IDE less frequently.

    Android Studio Exception Bubble

    System Health - User Interface Freezes

    User Interface (UI) freezes are another common issue we heard from you. In Android Studio 3.5, we extended the infrastructure of the underlying Intellij platform, and now measure UI thread stops that last longer than a few moments. Over time, we will have a bigger picture of the top hit spots to focus our efforts on. For example, during the Project Marble development, we found in our data that XML code editing was notably slower in the IDE. With this data point, we optimized XML typing, and have measurably better performance in Android Studio 3.5. You can see below that editing data binding expressions in XML is faster due to typing latency improvements.

    Code Editing Before - Android Studio 3.4 (left) and Code Editing After - Android Studio 3.5 (right)

    System Health - Build Speed

    We continued our investment in build speed. For those developers with larger projects, it is the number one concern. As we uncovered in our recent Medium blog post on build speed, many elements can affect build performance, sometimes slowing it down more than we can improve. However, during Project Marble, we made speed improvements by adding incremental build support to the top annotation processors including Glide, AndroidX data binding, Dagger, Realm, and Kotlin (KAPT). Incremental support can make a notable impact on build speed. For example, in our preliminary analysis, adding incremental support just for Kotlin has improved submodule non-ABI code changes for the Google I/O schedule app from 9.1 seconds to 3.6 seconds – a 60% improvement. Read more about the performance changes to the build system here.

    System Health - IDE Speed

    In the past, a pro-tip some developers used to do is to turn off Android Studio plugins such as Android NDK support to improve performance. While there is nothing wrong with disabling plugins to remove extra menus or options that you don't need, we removed some unnecessary performance hotspots for the Android NDK support that impacted overall IDE speed.

    System Health - Lint Code Analysis

    Android Lint is a code analysis framework in Android Studio that helps identify common programming mistakes. However, we learned from several user reports that Lint could be too slow—especially when running in batch analysis mode on large projects. After some digging, we found and fixed several large memory leaks, leading to a roughly 2x speedup in Lint performance. We also published a profiling tool that can help identify bottlenecks in individual Lint checks. Read more about the analysis and tool here.

    System Health - I/O File Access for Windows

    Many users of Android Studio use Microsoft Windows. Over time, we received a range of reports from users on this platform that build times and installation speeds were increasingly getting slower. After investigating the problem during Project Marble, we realized that recent anti-virus programs included Android Studio build and installation directories as active scan targets. Since these folders have many small files created and removed over time, the I/O and CPU are partially taxed and consequently impacts the overall build/sync performance of Android Studio.

    Google Internal Data, 2.2GHz quad-core Intel Core i7, April 2019

    System Health Notification - Anti-virus Check

    System Health - Emulator CPU Usage

    Many app developers enjoy the fast and responsive emulator which has had dramatic performance improvements in the last few years. However, we heard from you that the Android Emulator seems to take an inordinate amount of CPU cycles and triggers the cooling fans on laptops even when the emulator is idle in the background. After investigation and measurement, we found that Google Play Services and related services were aggressively running in the background because by default the emulator was set to AC charging instead of battery discharging. We switched the default to battery discharging, and background CPU usage declined by more than 3x. This change is just of the many optimizations we made to the Android Emulator during Project Marble. Learn more about the Android Emulator and Project Marble here.

    Google Internal Data on Apple MacBook Pro (15” 2016), Emulator: Pixel 3 API 28

    Feature Polish - Apply Changes

    Being able to quickly edit and see code changes you have made without restarting your app is great for app development. Two years ago, the Instant Run feature was our attempt to enable this flow, but it ultimately fell short of expectations. During the Project Marble time period, we re-architectured and implemented from the ground-up a more practical approach in Android Studio 3.5 called Apply Changes. Apply Changes uses platform-specific APIs from Android Oreo and higher to ensure reliable and consistent behavior; unlike Instant Run, Apply Changes does not modify your APK. To support the changes, we re-architected the entire deployment pipeline to improve deployment speed, and also tweaked the run and deployment toolbar buttons for a more streamlined experience. Learn more about the architecture behind Apply Changes here.

    Apply Changes Buttons

    Feature Polish - Gradle Sync

    A recent and annoying pain point in Android Studio is to have your project unexpectedly trigger red symbols across your app code, especially when re-opening your project. The Gradle build system retains a cache of all the dependencies in your home directory that allows the IDE to quickly sync without re-downloading new artifacts. The root cause for many of the recent incidents of red symbols appearing is that in a recent Gradle change, these caches were periodically deleted to save hard drive space. The IDE was unaware of the discrepancy and consequently generated red symbols for missing dependencies. Starting with Android Studio 3.5, we now have the conditional logic to check for this state. We certainly have more we can do in this area, but this is just one example of the types of issues we addressed for project sync during Project Marble.

    Feature Polish - Project Upgrades

    Ideally, the Android Studio team would like you to be on the latest version of the IDE since this is where the team does active feature development, bug fixing and performance improvements. We know that upgrading your Android Studio is not a seamless process as it should be with many issues revolving around fixing gradle plugin errors. With Android Studio 3.5, we have updated the user experience on output windows, pop-ups and dialog boxes to help clarify when you actually need to upgrade, plus we made more sync & build upgrade errors more actionable.

    From a recent developer survey, we heard that many developers upgrade the Android Studio IDE and the Gradle plugin at the same time. As of the last several releases, the IDE and your gradle plugin can actually be updated independently. This means if you want the latest build system speed and correctness improvements, you can upgrade your Gradle plugin, but you can also wait until you're ready. Whether or not you upgrade you Gradle plugin at the same time as the IDE, we encourage you to be on the latest release of Android Studio 3.5 to start using all the enhancements from Project Marble.

    Feature Polish - Layout Editor

    Based on user research on the layout editor and input from you, we know that there are several performance and error-prone usability issues that make editing XML the only path forward, especially when working with ConstraintLayout. To address the general usability of the layout editor, we refined a wide range of interactions from constraint selection and deletion, to better device preview resizing. While XML code editing is still a click away, we hope you can see that these interaction refinements can be a big productivity boost when creating and editing layouts in Android Studio. Learn more about the full range of layout editor changes here.

    Layout Editor Before - Android Studio 3.4 (left) and Layout Editor After - Android Studio 3.5 (right)

    Feature Polish - Data Binding

    During Project Marble, we also took a look at long standing issues with data binding. From a performance perspective, we found that creating data binding expressions in XML files would lead to severe hangs in the code editor. After fixing this issue we also improved code completion, navigation, and refactoring.

    Feature Polish - App Deployment Flow

    We streamlined the deployment flow during Project Marble, by adding a new dropdown to easily see and change the device you intend to deploy to and a new menu item to deploy to multiple devices.

    App Deployment User Flow

    Feature Polish - C++ Improvements

    C++ project support was also a focus area during Project Marble. CMake builds are now up to 25% faster for large projects because the IDE now invokes parallel Ninja targets. Additionally, you will find an improved single build variant user interface panel that allows you to specify ABI targets separately.. And lastly, Android Studio 3.5 allows you to use multiple versions of the Android NDK side-by-side in your build.gradle file. This should allow you to have more reproducible builds and mitigate incompatibilities between NDK versions and the Android gradle plugin.

    Single Variant Selection by ABI

    Feature Polish - Intellij Platform Update

    This release of the Android Studio includes the features and quality enhancements of the 2019.1 Intellij platform release. The 2019.1 Intellij updates has a range of improvements from custom themes to better version control system integration.

    Feature Polish - Conditional Delivery for Dynamic Feature Support

    Android Studio 3.5 enhances app bundle feature support with the addition of conditional delivery features for your app bundle. Conditional delivery allows you to set certain device configuration requirements for dynamic feature modules to be downloaded automatically during app install. You can set conditional delivery based on hardware features such as OpenGL versions, support for Augmented Reality, or you set conditions based on API level and user country.

    Module Selection for Conditional Delivery

    Feature Polish - Emulator Foldables & Pixel Device Support

    This release of the IDE includes the Android Emulator skins for Pixel 3a and Pixel 3a XL. Additionally, the Android Studio supports the creation of foldable Android Virtual Devices.

    Android Emulator - Foldable Support

    Feature Polish - Chrome OS Support

    Android Studio 3.5 is now officially supported on Chrome OS 75 and higher on high-end x86 based Chromebooks. During Project Marble we refined a few usability issues, and now have an installer for Android Studio and support app deployment to external USB connected Android devices. Learn more how to setup the IDE on Chrome OS here.

    Android Studio on Chrome OS

    To recap, Android Studio 3.5 has hundreds of bug fixes and notable changes in these core areas:

    System Health

    Feature Polish

    Check our the Android Studio preview release notes page for more details and read about deep dives into several areas of Project Marble in the following Medium blog posts:

    Opt-In & Feedback

    The specific areas and the approach we took to optimize Android Studio for Project Marble were all based on your feedback and metrics data. The aggregate metrics you can opt-in to inside of Android Studio allow us to figure out if there are broader problems in the product for all users, and the data also allows the team to prioritize feature work appropriately. There are are a couple pathways to help us build better insights. At a baseline, you can opt-in to metrics, by going to Preferences /Settings → Appearance & Behavior → Data Sharing.

    IDE Data Sharing

    Additionally, throughout the year, you might see user sentiment emojis in the bottom corner of the IDE. Those icons are a lightweight way to inform the Android Studio team on how things are going and to give us in-context feedback, and the fastest way to log a bug and send to the team.

    IDE User Feedback

    Getting Started

    Download

    Download the beta version of Android Studio 3.5 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. If you want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.

    To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.0.6 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.

    May 8th 2019, 1:44 pm

    Fresher OS with Projects Treble and Mainline

    Android Developers Blog

    Posted by Anwar Ghuloum, Engineering Director and Maya Ben Ari, Product Manager, Android

    With each new OS release, we are making efforts to deliver the latest OS improvements to more Android devices.

    Thanks to Project Treble and our continuous collaboration with silicon manufacturers and OEM partners, we have improved the overall quality of the ecosystem and accelerated Android 9 Pie OS adoption by 2.5x compared to Android Oreo. Moreover, Android security updates continue to reach more users, with an 84% increase in devices receiving security updates in Q4, when compared to a year before.

    This year, we have increased our overall beta program reach to 15 devices, in addition to Pixel, Pixel 2 and Pixel 3/3a running Android Q beta: Huawei Mate 20 Pro, LGE G8, Sony Xperia XZ3, OPPO Reno, Vivo X27, Vivo NEX S, Vivo NEX A, OnePlus 6T, Xiaomi Mi Mix 3 5G, Xiaomi Mi 9, Realme 3 Pro, Asus Zenfone 5z, Nokia 8.1, Tecno Spark 3 Pro, and Essential PH-1.

    But our work hasn’t stopped there. We are continuing to invest in efforts to make Android updates available across the ecosystem.

    Safer and more secure devices with Project Mainline

    Project Mainline builds on our investment in Treble to simplify and expedite how we deliver updates to the Android ecosystem. Project Mainline enables us to update core OS components in a way that's similar to the way we update apps: through Google Play. With this approach we can deliver selected AOSP components faster, and for a longer period of time – without needing a full OTA update from your phone manufacturer. Mainline components are still open sourced. We are closely collaborating with our partners for code contribution and for testing, e.g., for the initial set of Mainline components our partners contributed many changes and collaborated with us to ensure they ran well on their devices.

    As a result, we can accelerate the delivery of security fixes, privacy enhancements, and consistency improvements across the ecosystem.

    Security: With Project Mainline, we can deliver faster security fixes for critical security bugs. For example, by modularizing media components, which accounted for nearly 40% of recently patched vulnerabilities, and by allowing us to update Conscrypt, the Java Security Provider, Project Mainline will make your device safer.

    Privacy: Privacy has been a major focus for us, and we are putting a lot of effort into better protecting users’ data and increasing privacy standards. With Project Mainline, we have the ability to make improvements to our permissions systems to safeguard user data.

    Consistency: Project Mainline helps us quickly address issues affecting device stability, compatibility, and developer consistency. We are standardizing time-zone data across devices. Also, we are delivering a new OpenGL driver implementation, ANGLE, designed to help decrease device-specific issues encountered by game developers.

    Our initial set of components supported on devices launching on Android Q:

    How does this work?

    Mainline components are delivered as either APK or APEX files. APEX is a new file format we developed, similar to APK but with the fundamental difference that APEX is loaded much earlier in the booting process. As a result, important security and performance improvements that previously needed to be part of full OS updates can be downloaded and installed as easily as an app update. To ensure updates are delivered safely, we also built new failsafe mechanisms and enhanced test processes. We are also closely collaborating with our partners to ensure devices are thoroughly tested.

    Project Mainline enables us to keep the OS on devices fresher, improve consistency, and bring the latest AOSP code to users faster. Users will get these critical fixes and enhancements without having to take a full operating system update. We look forward to extending the program with our OEM partners through our joint work on mainline AOSP.

    May 8th 2019, 1:14 pm

    Google I/O 2019: Empowering developers to build the best experiences on Android + Play

    Android Developers Blog

    Posted by Chet Haase

    It's great to be in our backyard again for Google I/O to connect with Android’s developers around the world. The 7,200 attendees at Shoreline Amphitheatre, millions of viewers on the livestream, and thousand of developers at local I/O Extended events across 80+ countries heard about our efforts to make the lives of developers easier. Today at Google I/O, we talked about two big themes; helping our developers become more productive and strengthening user privacy and security in the platform. Let's take a closer look at the major developer news at I/O so far:

    Developer Productivity

    This year, we focused on a simple idea - we want to save you time every today. By making everything you use even better.

    Kotlin

    Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.

    Today we’re announcing another big step: Android development will become increasingly Kotlin-first. Many new Jetpack APIs and features will be offered first in Kotlin. If you’re starting a new project, you should write it in Kotlin; code written in Kotlin often mean much less code for you–less code to type, test, and maintain. And, in partnership with Jetbrains and the Kotlin Foundation, we’re continuing to invest in tooling, docs, trainings and events to make Kotlin even easier to learn and use. This includes Kotlin/Everywhere, a new, global series of events where you can learn more about the language, new Udacity courses, and more.

    Android Jetpack

    Last year, we announced Android Jetpack, Android’s API to accelerate Android development and make writing high-quality apps easy, with less code. Over 80% of our top 1000 apps are already using Jetpack, as we continue to simplify more every-day developer challenges. Today, we are releasing 6 new Jetpack libraries (in alpha), and bringing 5 libraries to beta quality. Here are 3 highlights:

    Android Studio

    Today we’re releasing Android Studio 3.5 to Beta. For months, the team has been exclusively focused on refining and polishing day-to-day development workflows, with Project Marble. Android Studio 3.5 includes better IDE memory management for large projects, lower typing latency, lint improvements, CPU usage optimizations, layout editor improvements, emulator improvements, build changes, as well as a complete rewrite of Instant Run, now called Apply Changes, that now reliably accelerates the ability to see your code changes on a device - plus over 400 high- priority bug fixes.

    Machine Learning at Android scale

    In Android Q, we’ve made significant improvements to Android’s Neural Networks API (NNAPI). First, we have increased the number of Operators supported from 38 to over 90. The vast majority of models can now be accelerated by NNAPI with no alterations. We’ve also introduced an introspection API for advanced users, allowing full control over which hardware components handle acceleration (e.g. DSP vs. NPU). And, we’ve worked closely with hardware vendors to deliver significant improvements in performance, both in latency and power consumption. Working with MediaTek, we were able to accelerate ML Kit’s face detection API by 9X on the Helio P90. Working with Qualcomm, we were able to accelerate Google’s Lens OCR on the Snapdragon 855’s AI Engine, increasing speed by 3X while also reducing power consumption by 3.7X.

    Dynamic Updates and Inline Updates

    Last year we introduced the Android App Bundle to help you reduce app size and increase installs. Since then, we’ve seen over 80,000 app bundles in production, with average size savings of 20%. And today we have a number of announcements to help you reduce size and deliver updates to your users even faster. Today we’re glad to share that dynamic feature modules are moving from beta to stable. With dynamic feature modules, you can reduce your app size even more by choosing which parts of your app to deliver - based on conditions like device features, country. You can even deliver modules on-demand, instead of at install time. And today we’re also moving in-app updates from beta to stable. The ability to dynamically update apps is something you’ve been requesting for a long time. Let’s say you have a crucial bug in your app, and you need to push it out right away; you don’t want to wait until users discover an update in the Play Store. Now you can.

    User privacy and security in Android Q

    As a developer community, we all care about getting this right. It’s about building a platform that offers powerful capabilities for developers, while making sure that user safety and privacy is protected. We introduced Android Q Beta a few months ago with over 50 features and improvements around user privacy and security. These Q changes provide users more transparency and control.

    As always, we are working hard to do everything we can for developers adopting the new release. We know you have your own features to build. That’s why, with these Q changes, we’ve worked very hard to minimize the impact for you, as well as to incorporate your feedback. We’ve given as long a notice period as possible, as well as complete and detailed technical information up front, to make it as easy as possible to adopt. We also want to thank the community for your ongoing feedback. It’s been a huge help to the team who are working hard to get this right. A great example are the Beta 3 storage changes, where your feedback helped us evolve the feature over the course of the Betas. Android has a longstanding commitment to minimizing all breaking changes. Our commitment is unchanged, and we’ll work hard to keep Android the open, flexible, and developer friendly platform we all love.

    Be a part of Google I/O!

    We’ve got a lot of great content in store for you over the next three days, including over 45 sessions across Android. We’re excited for you to join us in-person here at Shoreline, at an I/O Extended event, or online through the livestream. We’re constantly investing in our platform that connects developers to billions of users around the world. To the entire Android community, thank you for your continued support and feedback, and for being a part of Android.

    May 7th 2019, 4:15 pm

    What’s New in Android: Q Beta 3 & More

    Android Developers Blog

    Posted by Dave Burke, VP, Engineering

    Today Android is celebrating two amazing milestones. It’s Android’s version 10! And today, Android is running on more than 2.5B active Android devices.

    With Android Q, we’ve focused on three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device AI, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.

    Earlier at Google I/O we highlighted what’s new in Android Q and unveiled the latest update, Android Q Beta 3. Your feedback continues to be extremely valuable in shaping today’s update as well as our final release to the ecosystem in the fall.

    This year, Android Q Beta 3 is available on 15 partner devices from 12 OEMs -- that’s twice as many devices as last year! It’s all thanks to Project Treble and especially to our partners who are committed to accelerating updates to Android users globally -- Huawei, Xiaomi, Nokia, Sony, Vivo, OPPO, OnePlus, ASUS, LGE, TECNO, Essential, and realme.

    Visit android.com/beta to see the full list of Beta devices and learn how to get today’s update on your device. If you have a Pixel device, you can enroll here to get Beta 3 -- if you’re already enrolled, watch for the update coming soon. To get started developing with Android Q Beta, visit developer.android.com/preview.

    Privacy and security

    As we talked about at Google I/O, privacy and security are important to our whole company and in Android Q we’ve added many more protections for users.

    Privacy

    In Android Q, privacy has been a central focus, from strengthening protections in the platform to designing new features with privacy in mind. It’s more important than ever to give users control -- and transparency -- over how information is collected and used by apps, and by our phones.

    Building on our work in previous releases, Android Q includes extensive changes across the platform to improve privacy and give users control -- from improved system UI to stricter permissions to restrictions on what data apps can use.

    For example, Android Q gives users more control over when apps can get location. Apps still ask the user for permission, but now in Android Q the user has greater choice over when to allow access to location -- such as only while the app is in use, all the time, or never. Read the developer guide for details on how to adapt your app for the new location controls.

    Outside of location, we also introduced the Scoped Storage feature to give users control over files and prevent apps from accessing sensitive user or app data. Your feedback has helped us refine this feature, and we recently announced several changes to make it easier to support. These are now available in Beta 3.

    Another important change is restricting app launches from the background, which prevents apps from unexpectedly jumping into the foreground and taking over focus. In Beta 3 we’re transitioning from toast warnings to actually blocking these launches.

    To prevent tracking we're limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to choose the right identifiers for your use case. We're also randomizing MAC address when your device is connected to different Wi-Fi networks and gating connectivity APIs behind the location permission. We’re bringing these changes to you early, so you can have as much time as possible to prepare your apps.

    Security

    To keep users secure, we’ve extended our BiometricPrompt authentication framework to support biometrics at a system level. We're extending support for passive authentication methods such as face, and we’ve added implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm the transaction. The new implicit flow is designed for a lighter-weight alternative for transactions with passive authentication, and there’s no need for users to explicitly confirm.

    Android Q also adds support for TLS 1.3, a major revision to the TLS standard that includes performance benefits and enhanced security. Our benchmarks indicate that secure connections can be established as much as 40% faster with TLS 1.3 compared to TLS 1.2. TLS 1.3 is enabled by default for all TLS connections made through Android’s TLS stack, called Conscrypt, regardless of target API level. See the docs for details.

    Project Mainline

    Today we also announced Project Mainline, a new approach to keeping Android users secure and their devices up-to-date with important code changes, direct from Google Play. With Project Mainline, we’re now able to update specific internal components within the OS itself, without requiring a full system update from your device manufacturer. This means we can help keep the OS code on devices fresher, drive a new level of consistency, and bring the latest AOSP code to users faster -- and for a longer period of time.

    We plan to update Project Mainline modules in much the same way as app updates are delivered today -- downloading the latest versions from Google Play in the background and loading them the next time the phone starts up. The source code for the modules will continue to live in the Android Open Source Project, and updates will be fully open-sourced as they are released. Also, because they’re open source, they’ll include improvements and bug fixes contributed by our many partners and developer community worldwide.

    For users, the benefits are huge, since their devices will always be running the latest versions of the modules, including the latest updates for security, privacy, and consistency. For device makers, carriers, and enterprises, the benefits are also huge, since they can optimize and secure key parts of the OS without the cost of a full system update.

    For app and game developers, we expect Project Mainline to help drive consistency of platform implementation in key areas across devices, over time bringing greater uniformity that will reduce development and testing costs and help to make sure your apps work as expected. All devices running Android Q or later will be able to get Project Mainline, and we’re working closely with our partners to make sure their devices are ready.

    Innovation and new experiences

    Android is shaping the leading edge of innovation. With our ecosystem partners, we’re enabling new experiences through a combination of hardware and software advances.

    Foldables

    This year, display technology will take a big leap with foldable devices coming to the Android ecosystem from several top device makers. When folded these devices work like a phone, then you unfold a beautiful tablet-sized screen.

    We’ve optimized Android Q to ensure that screen continuity is seamless in these transitions, and apps and games can pick up right where they left off. For multitasking, we’ve made some changes to onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on large screens.

    Our partners have already started showing their innovative foldable devices, with more to come. You can get started building and testing today with our foldables emulator in canary release of Android Studio 3.5.

    5G networks

    5G networks are the next evolution of wireless technology -- providing consistently faster speeds and lower latency. For developers, 5G can unlock new kinds of experiences in your apps and supercharge existing ones.

    Android Q adds platform support for 5G and extends existing APIs to help you transform your apps for 5G. You can use connectivity APIs to detect if the device has a high bandwidth connection and check whether the connection is metered. With these your apps and games can tailor rich, immersive experiences to users over 5G.

    With Android’s open ecosystem and range of partners, we expect the Android ecosystem to scale to support 5G quickly. This year, over a dozen Android device makers are launching 5G-ready devices, and more than 20 carriers will launch 5G networks around the world, with some already broad-scale.

    Live Caption

    On top of hardware innovation, we’re continuing to see Android’s AI transforming the OS itself to make it smarter and easier to use, for a wider range of people. A great example is Live Caption, a new feature in Android Q that automatically captions media playing on your phone.

    Many people watch videos with captions on -- the captions help them keep up, even when on the go or in a crowded place. But for 466 million Deaf and Hard of Hearing people around the world, captions are more than a convenience -- they make content accessible. We worked with the Deaf community to develop Live Caption.

    Live Caption brings real-time captions to media on your phone - videos, podcasts, and audio messages, across any app—even stuff you record yourself. Best of all, it doesn’t even require a network connection -- everything happens on the device, thanks to a breakthrough in speech recognition that we made earlier this year. The live speech models run right on the phone, and no audio stream ever leaves your device.

    For developers, Live Caption expands the audience for your apps and games by making digital media more accessible with a single tap. Live Caption will be available later this year.

    Suggested actions in notifications

    In Android Pie we introduced smart replies for notifications that let users engage with your apps direct from notifications. We provided the APIs to attach replies and actions, but you needed to build those on your own.

    Now in Android Q we want to make smart replies available to all apps right now, without you needing to do anything. Starting in Beta 3, we’re enabling system-provided smart replies and actions that are inserted directly into notifications by default.

    You can still supply your own replies and actions if you want -- such as if you are using ML Kit or other ML frameworks. Just opt out of the system-provided replies or actions on a per-notification basis using setAllowGeneratedReplies() and setAllowSystemGeneratedContextualActions().

    Android Q suggestions are powered by an on-device ML service built into the platform -- the same service that backs our text classifier entity recognition service. We’ve built it with user privacy in mind, and the ML processing happens completely on the device, not on a backend server.

    Because suggested actions are based on the TextClassifier service, they can take advantage of new capabilities we’ve added in Android Q, such as language detection. You can also use TextClassifier APIs directly to generate system-provided notifications and actions, and you can mix those with your own replies and actions as needed.

    Dark theme

    Many users prefer apps that offer a UI with a dark theme they can switch to when light is low, to reduce eye strain and save battery. Users have also asked for a simple way to enable dark theme everywhere across their devices. Dark theme has been a popular request for a while, and in Android Q, it’s finally here.

    Starting in Android Q Beta 3, users can activate a new system-wide dark theme by going to Settings > Display, using the new Quick Settings tile, or turning on Battery Saver. This changes the system UI to dark, and enables the dark theme of apps that support it. Apps can build their own dark themes, or they can opt-in to a new Force Dark feature that lets the OS create a dark version of their existing theme. All you have to do is opt-in by setting android:forceDarkAllowed="true" in your app’s current theme.

    You may also want to take complete control over your app’s dark styling, which is why we’ve also been hard at work improving AppCompat’s DayNight feature. By using DayNight, apps can offer a dark theme to all of their users, regardless of what version of Android they’re using on their devices. For more information, see here.

    Gestural navigation

    Many of the latest Android devices feature beautiful edge-to-edge screens, and users want to take advantage of every bit of them. In Android Q we’re introducing a new fully gestural navigation mode that eliminates the navigation bar area and allows apps and games to use the full screen to deliver their content. It retains the familiar Back, Home, and recents navigation through edge swipes rather than visible buttons.

    Users can switch to gestures in Settings > System > Gestures. There are currently two gestures: Swiping up from the bottom of the screen takes the user to the Home screen, holding brings up Recents. Swiping from the screen’s left or right edge triggers the Back action.

    To blend seamlessly with gestural navigation, apps should go edge-to-edge, drawing behind the navigation bar to create an immersive experience. To implement this, apps should use the setSystemUiVisibility() API to be laid out fullscreen, and then handle WindowInsets as appropriate to ensure that important pieces of UI are not obscured. More information is here.

    Digital wellbeing

    Digital wellbeing is another theme of our work on Android -- we want to give users the visibility and tools to find balance with the way they use their phones. Last year we launched Digital Wellbeing with Dashboards, App Timers, Flip to Shush, and Wind Down mode. These tools are really helping. App timers helped users stick to their goals over 90% of the time, and users of Wind Down had a 27% drop in nightly usage.

    This year we’re continuing to expand our features to help people find balance with digital devices, adding Focus Mode and Family Link.

    Focus Mode

    Focus Mode is designed for all those times you’re working or studying, and you want to to focus to get something done. With focus mode, you can pick the apps that you think might distract you and silence them - for example, pausing email and the News while leaving maps and text message apps active. You can then use Quick Tiles to turn on Focus Mode any time you want to focus. Under the covers, these apps will be paused - until you come out of Focus Mode! Focus Mode is coming to Android 9 Pie and Android Q devices this Fall.

    Family Link

    Family Link is a new set of controls to help parents. Starting in Android Q, Family Link will be built right into the Settings on the device. When you set up a new device for your child, Family Link will help you connect it to you. You’ll be able to set daily screen time limits, see the apps where your child is spending time, review any new apps your child wants to install, and even set a device bedtime so your child can disconnect and get to sleep. And now in Android Q you can also set time limits on specific apps… as well as give your kids Bonus Time if you want them to have just 5 more minutes at bedtime. Family Link is coming to Android P and Q devices this Fall. Make sure to check out the other great wellbeing apps in the recent Google Play awards.

    Family link lets parents set device bedtime and even give bonus minutes.

    Android Foundations

    We’re continuing to extend the foundations of Android with more capabilities to help you build new experiences for your users -- here are just a few.

    Improved peer-to-peer and internet connectivity

    In Android Q we’ve refactored the Wi-Fi stack to improve privacy and performance, and also to improve common use-cases like managing IoT devices and suggesting internet connections -- without requiring the location permission. The network connection APIs make it easier to manage IoT devices over local Wi-Fi, for peer-to-peer functions like configuring, downloading, or printing. The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity.

    Wi-Fi performance modes

    In Android Q apps can now request adaptive Wi-Fi by enabling high performance and low latency modes. These will be of great benefit where low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use-cases. The platform works with the device firmware to meet the requirement with the lowest power consumption. To use the new performance modes, call WifiManager.WifiLock.createWifiLock().

    Full support for Wi-Fi RTT accurate indoor positioning

    In Android 9 Pie we introduced RTT APIs for indoor positioning to accurately measure distance to nearby Wi-Fi Access Points (APs) that support the IEEE 802.11mc protocol, based on measuring the round-trip time of Wi-Fi packets. Now in Android Q, we’ve completed our implementation of the 802.11mc standard, adding an API to obtain location information of each AP being ranged, configured by their owner during installation.

    Audio playback capture

    You saw how Live Caption can take audio from any app and instantly turn it into on-screen captions. It’s a seamless experience that shows how powerful it can be for one app to share its audio stream with another. In Android Q, any app that plays audio can let other apps capture its audio stream using a new API. In addition to enabling captioning and subtitles, the API lets you support popular use-cases like live-streaming games, all without latency impact on the source app or game.

    We’ve designed this new capability with privacy and copyright protection in mind, so the ability for an app to capture another app's audio is constrained, giving apps full control over whether their audio streams can be captured. Read more here.

    Dynamic depth for photos

    Apps can now request a Dynamic Depth image which consists of a JPEG, XMP metadata related to depth related elements, and a depth and confidence map embedded in the same file on devices that advertise support. Requesting a JPEG + Dynamic Depth image makes it possible for you to offer specialized blurs and bokeh options in your app. You can even use the data to create 3D images or support AR photography use-cases. Dynamic Depth is an open format for the ecosystem -- the latest version of the spec is here. We're working with our device-maker partners to make it available across devices running Android Q and later.

    With Dynamic Depth image you can offer specialized blurs and bokeh options in your app

    New audio and video codecs

    Android Q adds support for the open source video codec AV1, which allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android Q supports audio encoding using Opus - a codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it. The MediaCodecInfo API introduces an easier way to determine the video rendering capabilities of an Android device. For any given codec, you can obtain a list of supported sizes and frame rates.

    Vulkan 1.1 and ANGLE

    We're continuing to expand the impact of Vulkan on Android, our implementation of the low-overhead, cross-platform API for high-performance 3D graphics. We’re working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices. For game and graphics developers using OpenGL, we’re also working towards a standard, updateable OpenGL driver for all devices built on Vulkan. In Android Q we're adding experimental support for ANGLE on top of Vulkan on Android devices. See the docs for details.

    Neural Networks API 1.2

    In NNAPI 1.2 we've added 60 new ops including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimisations. This lays the foundation for accelerating a much greater range of models -- such as those for object detection and image segmentation. We are working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.

    Thermal API

    When devices get too warm, they may throttle the CPU and/or GPU, and this can affect apps and games in unexpected ways. Now in Android Q, apps and games can use a thermal API to monitor changes on the device and take action to help restore normal temperature. For example, streaming apps can reduce resolution/bit rate or network traffic, a camera app could disable flash or intensive image enhancement, or a game could reduce frame rate or polygon tesselation. Read more here.

    ART optimizations

    Android Q introduces several improvements to the ART runtime to help your apps start faster, consume less memory, and run smoother -- without requiring any work from you. To help with initial app startup, Google Play is now delivering cloud-based profiles along with APKs. These are anonymized, aggregate ART profiles that let ART pre-compile parts of your app even before it's run. Cloud-based profiles benefit all apps and they're already available to devices running Android P and higher.

    We’re also adding Generational Garbage Collection to ART's Concurrent Copying (CC) Garbage Collector. Generational CC collects young-generation objects separately, incurring much lower cost as compared to full-heap GC. It makes garbage collection more efficient in terms of time and CPU, reduces jank, and helps apps run better on lower-end devices.

    More Android Q Beta devices, more Treble momentum than ever

    In 2017 we launched Project Treble as part of Android Oreo, with a goal of accelerating OS updates. Treble provides a consistent, testable interface between Android and the underlying device code from device makers and silicon manufacturers, which makes porting a new OS version much simpler and more modular.

    In 2018 we worked closely with our partners to bring the first OS updates to their Treble devices. The result: last year at Google I/O we had 8 devices from 7 partners joining our Android P Beta program, together with our Pixel and Pixel 2 devices. Fast forward to today -- we’re seeing updates to Android Pie accelerating strongly, with 2.5 times the footprint compared to Android Oreo's at the same time last year.

    This year with Android Q we’re seeing even more momentum, and we have 21 devices from 12 top global partners joining us to release Android Q Beta 3 -- in addition all Pixel devices. We’re also providing Q Beta 3 Generic System Images (GSI), a testing environment for other supported Treble devices. All of these offer the same behaviors, APIs, and features -- giving you an incredible variety of devices for testing your apps, and more ways for you to get an early look at Android Q.

    You can see the full list of supported partner and Pixel devices at android.com/beta. Try Android Q Beta on your favorite device today and let us know your feedback!

    Explore the new features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Take a look at the API diff report for an overview of what's changed in Beta 3, and see the Android Q Beta API reference for details. Visit the Android Q Beta developer site for more resources, including release notes and how to report issues.

    To build with Android Q, download the Android Q Beta SDK and tools into Android Studio 3.3 or higher, and follow these instructions to configure your environment. If you want the latest fixes for Android Q related changes, we recommend you use Android Studio 3.5 or higher.

    How do I get Beta 3?

    It's easy! Just enroll any Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon, and, no action is needed on your part. Downloadable system images are also available.

    You can also get Beta 3 on any of the other devices participating in the Android Q Beta program, from some of our top device maker partners. You can see the full list of supported partner and Pixel devices at android.com/beta. For each device you'll find specs and links to the manufacturer's dedicated site for downloads, support, and to report issues.

    For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

    As always, your input 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 and we're working to integrate as much of it as possible in the next Beta release.

    We're looking forward to seeing your apps on Android Q!

    May 7th 2019, 3:28 pm

    Developing Apps for Android Automotive OS

    Android Developers Blog

    Posted by Madan Ankapura, Product Manager, Android and Oscar Wahltinez, Developer Programs Engineer

    Google's vision is to bring a safe and seamless connected experience in every car. You can see that vision at work today with Android Auto, which enables millions of users to bring apps they use on their smartphones into cars. As display technologies evolve and cars become more connected, there are even more opportunities for developers to build for innovative car experiences and reach a new audience.

    This is why a few years ago we introduced Android Automotive OS, an Android operating system that is familiar to millions of developers, tailored to run in the car. In just a short time, we have seen increasing demand for Android Automotive OS from vehicle manufacturers. Most recently, Polestar announced that they are shipping their first electric vehicle (Polestar 2) running Android Automotive OS, and this is the first of many to come.

    Polestar 2 with Android Automotive OS

    Starting with media apps

    As the first cars hit the road, we have heard loud and clear from developers, users and OEMs that consuming media like music or podcasts is one of the key use cases while driving. This is why today, we are announcing that media app developers will be able to start creating new entertainment experiences for Android Automotive OS and the Polestar 2, starting at Google I/O.

    With a variety of screen sizes, input methods, OEM customizations and regional driver safety guidelines, building embedded apps for cars at scale is a complicated process for developers to do on their own. In order to help manage these complexities, we are building on the same Android Auto framework.

    Media app user experience in Android Automotive OS

    Beyond media, users require the ability to navigate and communicate with others (via calls, messages). With Android Automotive OS and the Google Play Store, we have plans to enable developers to build apps in these areas and beyond.

    If you are interested in learning more, watch our Google I/O 2019 Automotive developer session - How to Build Android Apps for Cars - where we walk through details on how to build your media app using the latest Android Studio, which features an Android Automotive OS emulator and templates.

    And if you are one of the developers with a Google I/O ticket this year, please come by our Office hours and app reviews hosted by the Android Automotive team, and run through our Automotive OS codelab.

    Test your apps with Android Automotive OS reference unit in Codelabs area

    Lastly, we have also established the automotive-developers Google Groups community for developers to discuss Android Automotive OS. For questions better suited for StackOverflow Q&A style, you can post there using the tag android-automotive.

    See you at Google I/O 2019!

    May 1st 2019, 12:03 pm

    Android Q Scoped Storage: Best Practices and Updates

    Android Developers Blog

    Posted by Jeff Sharkey, Software Engineer, and Seb Grubb, Product Manager

    Application Sandboxing is a core part of Android’s design, isolating apps from each other. In Android Q, taking the same fundamental principle from Application Sandboxing, we introduced Scoped Storage.

    Since the Beta 1 release, you’ve given us a lot of valuable feedback on these changes -- thank you for helping shape Android! Because of your feedback, we've evolved the feature during the course of Android Q Beta. In this post, we'll share options for declaring your app’s support for Scoped Storage on Android Q devices, and best practices for questions we've heard from the community.

    Updates to help you adopt Scoped Storage

    We expect that Scoped Storage should have minimal impact to apps following current storage best practices. However, we also heard from you that Scoped Storage can be an elaborate change for some apps and you could use more time to assess the impact. Being developers ourselves, we understand you may need some additional time to ensure your app’s compatibility with this change. We want to help.

    In the upcoming Beta 3 release, apps that target Android 9 Pie (API level 28) or lower will see no change, by default, to how storage works from previous Android versions. As you update your existing app to work with Scoped Storage, you’ll be able to use a new manifest attribute to enable the new behavior for your app on Android Q devices, even if your app is targeting API level 28 or lower.

    The implementation details of these changes will be available with the Beta 3 release, but we wanted to share this update with you early, so you can better prepare your app for Android Q devices. Scoped Storage will be required in next year’s major platform release for all apps, independent of target SDK level, so we recommend you add support to your app well in advance. Please continue letting us know your feedback and how we can better align Scoped Storage with your app’s use cases. You can give us input through this survey, or file bugs and feature requests here.

    Best practices for common feedback areas

    Your feedback is incredibly valuable and has helped us shape these design decisions. We also want to take a moment to share some best practices for common questions we’ve heard:

    We’ve also provided a detailed Scoped Storage developer guide with additional information.

    What’s ahead

    It’s been amazing to see the community engagement on Android Q Beta so far. As we finalize the release in the next several months, please continue testing and keep the feedback coming. Join us at Google I/O 2019 for more details on Scoped Storage and other Android Q features. We’re giving a ”What’s new on Shared Storage” talk on May 8, and you’ll be able to find the livestream and recorded video on the Google I/O site.

    April 25th 2019, 4:30 pm

    And the 2019 Google Play Award nominees are...

    Android Developers Blog

    Posted by Purnima Kochikar, Director, Apps and Games Business Development, Google Play

    Drum roll please! To kick off Google I/O this year, the 2019 Google Play Awards will take place on Monday, May 6th. We’re excited to highlight nine categories this year, some familiar and some new, to recognize developers that continue to set the bar for quality apps and games on Google Play.

    Building on previous years, we celebrate our fourth year by recognizing some of the best experiences available on Android, with an emphasis on overall quality, strong design, technical performance, and innovation. The nominees were selected by various teams across Google, and meet criteria thresholds covering high star rating, Android vitals, and have had a launch or major update since April 2018.

    Congratulations to this year’s nominees below and remember to check them out on Google Play at play.google.com/gpa2019. Stay tuned as we announce the winners of each category at Google I/O.

    Standout Well-Being App

    Apps empowering people to live the best version of their lives, while demonstrating responsible design and engagement strategies.

    Best Accessibility Experience

    Apps and games enabling device interaction in an innovative way that serve people with disabilities or special needs.

    Best Social Impact

    Apps and games that create a positive impact in communities around the world (focusing on health, education, crisis response, refugees, and literacy).

    Most Beautiful Game

    Games that exemplify artistry or unique visual effects either through creative imagery, and/or utilizing advanced graphics API features.

    Best Living Room Experience

    Apps that create, enhance, or enable a great living room experience that brings people together.

    Most Inventive

    Apps and games that display a groundbreaking new use case, like utilize new technologies, cater to a unique audience, or demonstrate an innovative application of mobile technology for users.

    Standout Build for Billions Experience

    Apps and games with optimized performance, localization and culturalization for emerging markets.

    Best Breakthrough App

    New apps with excellent overall design, user experience, engagement and retention, and strong growth.

    Best Breakthrough Game

    New games with excellent overall design, user experience, engagement and retention, and strong growth.

    Come back on Monday, May 6th when we announce the winners, and until then, make sure to try out some of these great apps and games on Google Play at play.google.com/gpa2019.

    How useful did you find this blog post?

    April 25th 2019, 1:01 pm

    Android Studio 3.4

    Android Developers Blog

    Posted by Jamal Eason, Product Manager, Android

    After nearly six months of development, Android Studio 3.4 is ready to download today on the stable release channel. This is a milestone release of the Project Marble effort from the Android Studio team. Project Marble is our focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. On top of many performance improvements and bug fixes we made in Android Studio 3.4, we are excited to release a small but focused set of new features that address core developer workflows for app building & resource management.

    Part of the effort of Project Marble is to address user facing issues in core features in the IDE. At the top of the list of issues for Android Studio 3.4 is an updated Project Structure Dialog (PSD) which is a revamped user interface to manage dependencies in your app project Gradle build files. In another build-related change, R8 replaces Proguard as the default code shrinker and obfuscator. To aid app design, we incorporated your feedback to create a new app resource management tool to bulk import, preview, and manage resources for your project. Lastly, we are shipping an updated Android Emulator that takes less system resources, and also supports the Android Q Beta. Overall, these features are designed to make you more productive in your day-to-day app development workflow.

    Alongside the stable release of Android Studio 3.4, we recently published in-depth blogs on how we are investigating & fixing a range of issues under the auspices of Project Marble. You should check them out as you download the latest update to Android Studio:

    The development work for Project Marble is still on-going, but Android Studio 3.4 incorporates productivity features and over 300 bug & stability enhancements that you do not want to miss. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.4.

    Develop

    Resource Manager

    Jetpack Import Intentions

    Layout Editor Properties Panel

    Build

    Project Structure Dialogue

    Test

    Android Emulator - Pixel 3 XL Emulator Skin

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

    Develop

    Build

    Test

    Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.

    Getting Started

    Download

    Download the latest version of Android Studio 3.4 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. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.

    To use the mentioned Android Emulator features make sure you are running at least Android Emulator v28.0.22 downloaded via the Android Studio SDK Manager.

    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.

    April 17th 2019, 2:30 pm

    Indie Games Accelerator - Applications open for class of 2019

    Android Developers Blog

    Posted by Anuj Gulati, Developer Marketing Manager and Sami Kizilbash, Developer Relations Program Manager

    Last year we announced the Indie Games Accelerator, a special edition of Launchpad Accelerator, to help top indie game developers from emerging markets achieve their full potential on Google Play. Our team of program mentors had an amazing time coaching some of the best gaming talent from India, Pakistan, and Southeast Asia. We’re very encouraged by the positive feedback we received for the program and are excited to bring it back in 2019.

    Applications for the class of 2019 are now open, and we’re happy to announce that we are expanding the program to developers from select countries* in Asia, Middle East, Africa, and Latin America.

    Successful participants will be invited to attend two gaming bootcamps, all-expenses-paid at the Google Asia-Pacific office in Singapore, where they will receive personalized mentorship from Google teams and industry experts. Additional benefits include Google hardware, invites to exclusive Google and industry events and more.

    Find out more about the program and apply to be a part of it.

    * The competition is open to developers from the following countries: Bangladesh, Brunei, Cambodia, India, Indonesia, Laos, Malaysia, Myanmar, Nepal, Pakistan, Philippines, Singapore, Sri Lanka, Thailand, Vietnam, Egypt, Jordan, Kenya, Lebanon, Nigeria, South Africa, Tunisia, Turkey, Argentina, Bolivia, Brazil, Chile, Colombia, Costa Rica, Ecuador, Guatemala, Mexico, Panama, Paraguay, Peru, Uruguay and Venezuela.

    How useful did you find this blog post?

    April 17th 2019, 2:03 am

    Improving the update process with your feedback

    Android Developers Blog

    Posted by Sameer Samat, VP of Product Management, Android & Google Play

    Thank you for all the feedback about updates we’ve been making to Android APIs and Play policies. We’ve heard your requests for improvement as well as some frustration. We want to explain how and why we’re making these changes, and how we are using your feedback to improve the way we roll out these updates and communicate with the developer community.

    From the outset, we’ve sought to craft Android as a completely open source operating system. We’ve also worked hard to ensure backwards compatibility and API consistency, out of respect and a desire to make the platform as easy to use as possible. This developer-centric approach and openness have been cornerstones of Android’s philosophy from the beginning. These are not changing.

    But as the platform grows and evolves, each decision we make comes with trade-offs. Everyday, billions of people around the world use the apps you’ve built to do incredible things like connect with loved ones, manage finances or communicate with doctors. Users want more control and transparency over how their personal information is being used by applications, and expect Android, as the platform, to do more to provide that control and transparency. This responsibility to users is something we have always taken seriously, and that’s why we are taking a comprehensive look at how our platform and policies reflect that commitment.

    Taking a closer look at permissions

    Earlier this year, we introduced Android Q Beta with dozens of features and improvements that provide users with more transparency and control, further securing their personal data. Along with the system-level changes introduced in Q, we’re also reviewing and refining our Play Developer policies to further enhance user privacy. For years, we’ve required developers to disclose the collection and use of personal data so users can understand how their information is being used, and to only use the permissions that are really needed to deliver the features and services of the app. As part of Project Strobe, which we announced last October, we are rolling out specific guidance for each of the Android runtime permissions, and we are holding apps developed by Google to the same standard.

    We started with changes to SMS and Call Log permissions late last year. To better protect sensitive user data available through these permissions, we restricted access to select use cases, such as when an app has been chosen by the user to be their default text message app. We understood that some app features using this data would no longer be allowed -- including features that many users found valuable -- and worked with you on alternatives where possible. As a result, today, the number of apps with access to this sensitive information has decreased by more than 98%. The vast majority of these were able to switch to an alternative or eliminate minor functionality.

    Learning from developer feedback

    While these changes are critical to help strengthen privacy protections for our users, we’re sensitive that evolving the platform can lead to substantial work for developers. We have a responsibility to make sure you have the details and resources you need to understand and implement changes, and we know there is room for improvement there. For example, when we began enforcing these new SMS and Call Log policies, many of you expressed frustration about the decision making process. There were a number of common themes that we wanted to share:

    In response, we are improving and clarifying the process, including:

    Evaluating developer accounts

    We have also heard concerns from some developers whose accounts have been blocked from distributing apps through Google Play. While the vast majority of developers on Android are well-meaning, some accounts are suspended for serious, repeated violation of policies that protect our shared users. Bad-faith developers often try to get around this by opening new accounts or using other developers’ existing accounts to publish unsafe apps. While we strive for openness wherever possible, in order to prevent bad-faith developers from gaming our systems and putting our users at risk in the process, we can’t always share the reasons we’ve concluded that one account is related to another.

    While 99%+ of these suspension decisions are correct, we are also very sensitive to how impactful it can be if your account has been disabled in error. You can immediately appeal any enforcement, and each appeal is carefully reviewed by a person on our team. During the appeals process, we will reinstate your account if we discover that an error has been made.

    Separately, we will soon be taking more time (days, not weeks) to review apps by developers that don’t yet have a track record with us. This will allow us to do more thorough checks before approving apps to go live in the store and will help us make even fewer inaccurate decisions on developer accounts.

    Thank you for your ongoing partnership and for continuing to make Android an incredibly helpful platform for billions of people around the world.

    How useful did you find this blog post?

    April 16th 2019, 10:47 pm

    Optimize your subscriptions with new insights in the Play Console

    Android Developers Blog

    Posted by Daniel Schramm, Product Manager, Google Play

    Since launching on Google Play nearly 7 years ago, subscriptions have proven to be an essential element in creating sustainable mobile app businesses; 89 of the top 100 highest grossing apps on Google Play in the US now provide subscription products. As the market matures, it is becoming increasingly important for subscription developers to optimize both subscriber conversion and retention in order to maintain growth. To help you do that, we're rolling out new insights available directly in the Play Console.

    Subscription retention report

    Example subscription retention report data in the Play Console. Source: Google Internal Data.

    The recently updated subscription retention report shows how well you are retaining subscribers, along with how well subscribers convert from free trial, introductory price, and first to second payment.

    You can configure two cohorts based on SKU, country, and subscription start date. This is particularly useful for evaluating the success of A/B tests; for example, to determine if changing the duration of a free trial has an impact on free trial conversion.

    Example free trial conversion data in the Play Console. Source: Google Internal Data.

    Cancellation survey results

    Retaining your existing subscribers is just as important as acquiring new subscribers, so we have updated the subscription cancellations report to give more insight into voluntary and involuntary cancellations.

    The launch of the subscriptions center last year introduced a cancellation survey allowing users to give developers feedback as to why they were cancelling, with results available through the Google Play Developer API. To make these results easier to access and monitor, we now surface daily aggregates directly within the Play Console, along with the ability to download written responses in a CSV.

    Example cancellation survey responses in the Play Console. Source: Google Internal Data.

    Recover more users

    Involuntary cancellations, which occur when a user's form of payment fails, account for over a third of all cancellations. The new recovery performance cards in the cancellation report helps you understand how effectively you are recovering users with grace period and account hold, and the day the subscriptions were recovered to help you evaluate the effectiveness of recovery messaging.

    Example account hold performance recovery card in the Play Console. Source: Google Internal Data.

    Make sure you've set up grace periods and account hold for your apps! We've seen that developers who use both grace period and account hold see more than a 3x increase in decline recovery rate from 10% to 33%. Discover more information on grace period and account hold.

    You can find the subscription retention and cancellation reports linked from the bottom of the Subscriptions page, in the Financial reports section of the Play Console. If you don't have access to financial reporting, ask your developer account owner for permission to view financial data.

    Example account hold performance recovery card in the Play Console. Source: Google Internal Data.

    We hope this new reporting gives you new insights to optimize your subscription business, and we look forward to sharing more with you at Google I/O in May.

    How useful did you find this blog post?

    April 11th 2019, 1:00 pm

    Google Play Instant feature plugin deprecation

    Android Developers Blog

    Posted by Miguel Montemayor and Diana García Ríos

    As of Android Gradle plugin 3.4.0 (included in Android Studio 3.4), we are starting the deprecation process of the feature plugin (com.android.feature) and instant app plugin (com.android.instantapp) as a way to build your instant app. When building your app, you will receive a warning flagging com.android.feature as deprecated. If you have an existing instant app built with the feature plugin, migrate your existing app to an instant-enabled app bundle as soon as possible.

    What is changing?

    Last year, we introduced Android App Bundles—a new way to build and publish your Android apps. App bundles simplify delivering optimized APKs, including instant delivery, by unifying uploads into a single artifact. Google Play handles distribution by serving the correct APKs to your instant and installed app users—this is called Dynamic Delivery. To learn more about app bundles, visit the documentation site.

    Dynamic Delivery is based on the idea of shipping dynamic features (com.android.dynamic-feature) to app users when they need them and only if they need them. There are currently three delivery types, based on the different values you will give the dist:module tag attributes on the dynamic feature module’s manifest file:

        <dist:module
           dist:instant="..."
           dist:onDemand="..."
           ...
        </dist:module>
    
    dist:instant="false" dist:instant="true"
    dist:onDemand="false" Dynamic feature delivered at install time Dynamic feature delivered instantly and at install time
    dist:onDemand="true" Dynamic feature delivered on demand (beta) N/A

    By migrating your instant app to an instant-enabled app bundle with dynamic features, you will be ready to leverage the full power of this new paradigm and you will be able to simplify your app’s modular design.

    The migration

    Previously, instant apps required creating a feature module that acted as the base module for your app. This base feature module contained the shared code and resources for both your instant and installed application. The rest of your codebase was comprised of:

    With the new app bundle implementation, your base feature module takes the role as your app module (com.android.application), hosting the code and resources common to all features (instant and installed). You organize additional, modular features as one of three types of dynamic feature modules, based on when you want to deliver them to the user. The instant app module disappears, since the dist:instant attributes in the manifest are enough to identify which features will be included as part of the instant experience.

    If you don’t have an instant experience added to your app and you’d like to create one, use Android Studio 3.3+ to create an instant-enabled app bundle.

    April 9th 2019, 2:49 pm

    ML Kit expands into NLP with Language Identification and Smart Reply

    Android Developers Blog

    Posted by Christiaan Prins and Max Gubin

    Today we are announcing the release of two new features to ML Kit: Language Identification and Smart Reply.

    You might notice that both of these features are different from our existing APIs that were all focused on image/video processing. Our goal with ML Kit is to offer powerful but simple-to-use APIs to leverage the power of ML, independent of the domain. As such, we are excited to expand ML Kit with solutions for Natural Language Processing (NLP)!

    NLP is a category of ML that deals with analyzing and generating text, speech, and other kinds of natural language data. We're excited to start out with two APIs: one that helps you identify the language of text, and one that generates reply suggestions in chat applications. Both of these features work fully on-device and are available on the latest version of the ML Kit SDK, on iOS (9.0 and higher) and Android (4.1 and higher).

    Generate reply suggestions based on previous messages

    A new feature popping up in messaging apps is to provide the user with a selection of suggested responses, either as actions on a notification or inside the app itself. This can really help a user to quickly respond when they are busy or a handy way to initiate a longer message.

    With the new Smart Reply API you can now quickly achieve the same in your own apps. The API provides suggestions based on the last 10 messages in a conversation, although it still works if only one previous message is available. It is a stateless API that fully runs on-device, so we don't keep message history in memory nor send it to a server.

    textPlus app providing response suggestions using Smart Reply

    We have worked closely with partners like textPlus to ensure Smart Reply is ready for prime time and they have now implemented in-app response suggestions with the latest version of their app (screenshot above).

    Adding Smart Reply to your own app is done with a simple function call (using Swift in this example):

    let smartReply = NaturalLanguage.naturalLanguage().smartReply()
    smartReply.suggestReplies(for: conversation) { result, error in
        guard error == nil, let result = result else {
            return
        }
        if (result.status == .success) {
            for suggestion in result.suggestions {
                print("Suggested reply: \(suggestion.text)")
            }
        }
    }

    After you initialize a Smart Reply instance, call suggestReplies with a list of recent messages. The callback provides the result which contains a list of suggestions.

    For details on how to use the Smart Reply API, check out the documentation.

    Tell me more ...

    Although as a developer, you can just pick up this new API and easily get it integrated in your app, it may be interesting to reveal a bit on how it works under the hood. At the core of Smart Reply is a machine-learned model that is executed using TensorFlow Lite and has a state-of-the-art modern architecture based on SentencePiece text encoding[1] and Transformer[2].

    However, as we realized when we started development of the API, the core suggestion model is not all that's needed to provide a solution that developers can use in their apps. For example, we added a model to detect sensitive topics, so that we avoid making suggestions in response to profanity or in cases of personal tragedy/hardship. Also, we included language identification, to ensure we do not provide suggestions for languages the core model is not trained on. The Smart Reply feature is launching with English support first.

    Identify the language of a piece of text

    The language of a given text string is a subtle but helpful piece of information. A lot of apps have functionality with a dependency on the language: you can think of features like spell checking, text translation or Smart Reply. Rather than asking a user to specify the language they use, you can use our new Language Identification API.

    ML Kit recognizes text in 103 different languages and typically only requires a few words to make an accurate determination. It is fast as well, typically providing a response within 1 to 2 ms across iOS and Android phones.

    Similar to the Smart Reply API, you can identify the language with a function call (using Swift in this example):

    let languageId = NaturalLanguage.naturalLanguage().languageIdentification()
    languageId.identifyLanguage(for: "¿Cómo estás?") { languageCode, error in
      guard error == nil, let languageCode = languageCode else {
        print("Failed to identify language with error: \(error!)")
        return
      }
    
      print("Identified Language: \(languageCode)")
    }

    The identifyLanguage functions takes a piece of a text and its callback provides a BCP-47 language code. If no language can be confidently recognized, ML Kit returns a code of und for undetermined. The Language Identification API can also provide a list of possible languages and their confidence values.

    For details on how to use the Language Identification API, check out the documentation.

    Get started today

    We're really excited to expand ML Kit to include Natural Language APIs. Give the two new NLP APIs a spin today and let us know what you think! You can always reach us in our Firebase Talk Google Group.

    As ML Kit grows we look forward to adding more APIs and categories that enables you to provide smarter experiences for your users. With that, please keep an eye out for some exciting ML Kit announcements at Google I/O.

    April 5th 2019, 1:06 pm

    Android Q Beta 2 update

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    A few weeks ago we Introduced Android Q Beta, a first look at the next version of Android. Along with new privacy features for users, Android Q adds new capabilities for developers - like enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 graphics, and more.

    Android's program of early, open previews is driven by our core philosophy of openness, and collaboration with our community. Your feedback since Beta 1 proves yet again the value of that openness - it's been loud, clear, and incredibly valuable. You've sent us thousands of bug reports, giving us insights and directional feedback, changing our plans in ways that make the platform better for users and developers. We're taking your feedback to heart, so please stay tuned. We're fortunate to have such a passionate community helping to guide Android Q toward the final product later this year.

    Today we're releasing Android Q Beta 2 and an updated SDK for developers. It includes the latest bug fixes, optimizations, and API updates for Android Q, along with the April 2019 security patches. You'll also notice isolated storage becoming more prominent as we look for your wider testing and feedback to help us refine that feature.

    We're still in early Beta with Android Q so expect rough edges! Before you install, check out the Known Issues. In particular, expect the usual transitional issues with apps that we typically see during early Betas as developers get their app updates ready.

    You can get Beta 2 today by enrolling any Pixel device here. If you're already enrolled, watch for the Beta 2 update coming soon. Stay tuned for more at Google I/O in May.

    What's new in Beta 2?

    Privacy features for testing and feedback

    As we shared at Beta 1, we're making significant privacy investments in Android Q in addition to the work we've done in previous releases. Our goals are improving transparency, giving users more control, and further securing personal data across platform and apps. We know that to reach those goals, we need to partner with you, our app developers. We realize that supporting these features is an investment for you too, so we'll do everything we can to minimize the impact on your apps.

    For features like Scoped Storage, we're sharing our plans as early as possible to give you more time to test and give us your input. To generate broader feedback, we've also enabled Scoped Storage for new app installs in Beta 2, so you can more easily see what is affected.

    With Scoped Storage, apps can use their private sandbox without permission, but they need new permissions to access shared collections for photos, videos and audio. Apps using files in shared collections -- for example, photo and video galleries and pickers, media browsing, and document storage -- may behave differently under Scoped Storage.

    We recommend getting started with Scoped Storage soon -- the developer guide has details on how to handle key use-cases. For testing, make sure to enable Scoped Storage for your app using the adb command. If you discover that your app has a use-case that's not supported by Scoped Storage, please let us know by taking this short survey. We appreciate the great feedback you've given us already, it's a big help as we move forward with the development of this feature.

    Bubbles: a new way to multitask

    In Android Q we're adding platform support for bubbles, a new way for users to multitask and re-engage with your apps. Various apps have already built similar interactions from the ground up, and we're excited to bring the best from those into the platform, while helping to make interactions consistent, safeguard user privacy, reduce development time, and drive innovation.

    Bubbles will let users multitask as they move between activities.

    Bubbles help users prioritize information and take action deep within another app, while maintaining their current context. They also let users carry an app's functionality around with them as they move between activities on their device.

    Bubbles are great for messaging because they let users keep important conversations within easy reach. They also provide a convenient view over ongoing tasks and updates, like phone calls or arrival times. They can provide quick access to portable UI like notes or translations, and can be visual reminders of tasks too.

    We've built bubbles on top of Android's notification system to provide a familiar and easy to use API for developers. To send a bubble through a notification you need to add a BubbleMetadata by calling setBubbleMetadata. Within the metadata you can provide the Activity to display as content within the bubble, along with an icon (disabled in beta 2) and associated person.

    We're just getting started with bubbles, but please give them a try and let us know what you think. You can find a sample implementation here.

    Foldables emulator

    As the ecosystem moves quickly toward foldable devices, new use-cases are opening up for your apps to take advantage of these new screens. With Beta 2, you can build for foldable devices through Android Q enhanced platform support, combined with a new foldable device emulator, available as an Android Virtual device in Android Studio 3.5 available in the canary release channel.

    7.3" Foldable AVD switches between the folded and unfolded states

    On the platform side, we've made a number of improvements in onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. You can read more in the foldables developer guide.

    To set up a runtime environment for your app, you can now configure a foldable emulator as a virtual device (AVD) in Android Studio. The foldable AVD is a reference device that lets you test with standard hardware configurations, behaviors, and states, as will be used by our device manufacturer partners. To ensure compatibility, the AVD meets CTS/GTS requirements and models CDD compliance. It supports runtime configuration change, multi-resume and the new resizeableActivity behaviors.

    Use the canary release of Android Studio 3.5 to create a foldable virtual device to support either of two hardware configurations 7.3" (4.6" folded) and 8" (6.6" folded) with Beta 2. In each configuration, the emulator gives you on-screen controls to trigger fold/unfold, change orientation, and quick actions.

    Android Studio - AVD Manager: Foldable Device Setup

    Try your app on the foldable emulator today by downloading the canary release of Android Studio 3.5 and setting up a foldable AVD that uses the Android Q Beta 2 system image.

    Improved sharesheet

    Following on the initial Sharing Shortcuts APIs in Beta 1, you can now offer a preview of the content being shared by providing an EXTRA_TITLE extra in the Intent for the title, or by setting the Intent's ClipData for a thumbnail image. See the updated sample application for the implementation details.

    Directional, zoomable microphones

    Android Q Beta 2 gives apps more control over audio capture through a new MicrophoneDirection API. You can use the API to specify a preferred direction of the microphone when taking an audio recording. For example, when the user is taking a "selfie" video, you can request the front-facing microphone for audio recording (if it exists) by calling setMicrophoneDirection(MIC_DIRECTION_FRONT).

    Additionally, this API introduces a standardized way of controlling zoomable microphones, allowing your app to have control over the recording field dimension using setMicrophoneFieldDimension(float).

    Compatibility through public APIs

    In Android Q we're continuing our long-term effort to move apps toward only using public APIs. We introduced most of the new restrictions in Beta 1, and we're making a few minor updates to those lists in Beta 2 to minimize impact on apps. Our goal is to provide public alternative APIs for valid use-cases before restricting access, so if an interface that you currently use in Android 9 Pie is now restricted, you should request a new public API for that interface.

    Get started with Android Q Beta

    Today's update includes Beta 2 system images for all Pixel devices and the Android Emulator, as well updated SDK and tools for developers. These give you everything you need to get started testing your apps on the new platform and build with the latest APIs.

    First, make your app compatible and give your users a seamless transition to Android Q, including your users currently participating in the Android Beta program. To get started, just install your current app from Google Play onto a device or emulator running Beta 2 and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. See the migration guide for steps and a recommended timeline.

    With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you'll want to test against scoped storage, new location permissions, restrictions on background Activity starts, and restrictions on device identifiers. See the privacy checklist as a starting point.

    Next, update your app's targetSdkVersion to 'Q' as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.

    Explore the new features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Take a look at the API diff report for an overview of what's changed in Beta 2, and see the Android Q Beta API reference for details. Visit the Android Q Beta developer site for more resources, including release notes and how to report issues.

    To build with Android Q, download the Android Q Beta SDK and tools into Android Studio 3.3 or higher, and follow these instructions to configure your environment. If you want the latest fixes for Android Q related changes, we recommend you use Android Studio 3.5 or higher.

    How do I get Beta 2?

    It's easy - you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we're supporting all three generations of Pixel -- Pixel 3, Pixel 2, and even the original Pixel!). If you're already enrolled, you'll receive the update to Beta 2 soon, no action is needed on your part. Downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

    As always, your input 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 and we're working to integrate as much of it as possible in the next Beta release.

    April 3rd 2019, 1:16 pm

    Improving app performance with ART optimizing profiles in the cloud

    Android Developers Blog

    Posted by Calin Juravle, Software Engineer

    In Android Pie we launched ART optimizing profiles in Play Cloud, a new optimization feature that greatly improves the application startup time after a new install or update. On average, we have observed that apps start 15% faster (cold startup) across a variety of devices. Some hero cases even show 30%+ faster startup times. One of the most important aspects is that users get this for free, without any effort from their side or from developers!

    Source: Google internal data

    ART optimizing profiles in Play Cloud

    The feature builds on previous Profile Guided Optimization (PGO) work, which was introduced in Android 7.0 Nougat. PGO allows the Android Runtime to help improve an app's performance by building a profile of the app's most important hot code and focusing its optimization effort on it. This leads to big improvements while reducing the traditional memory and storage impact of a fully compiled app. However, it relies on the device to optimize apps based on these code profiles in idle maintenance mode, which means it could be a few days before a user sees the benefits - something we aimed to improve.

    Source: Google internal data

    ART optimizing profiles in Play Cloud leverages the power of Android Play to bring all PGO benefits at install/update time: most users can get great performance without waiting!

    The idea relies on two key observations:

    1. Apps usually have many commonly used code paths (hot code) between a multitude of users and devices, e.g. classes used during startup or critical user paths. This can often be discovered by aggregating a few hundred data points.
    2. App developers often roll-out their apps incrementally, starting with alpha/beta channels before expanding to a wider audience. Even if there isn't an alpha/beta set, there is often a ramp-up of users to a new version of an app.

    This means we can use the initial rollout of an app to bootstrap the performance for the rest of users. ART analyzes what part of the application code is worth optimizing on the initial devices, and then uploads the data to Play Cloud, which will build a core-aggregated code profile (containing information relevant to all devices). Once there is enough information, the code profile gets published and installed alongside the app's APKs.

    On a device, the code profile acts as a seed, enabling efficient profile-guided optimization at install time. These optimizations help improve cold startup time and steady state performance, all without an app developer needing to write a single line of code.

    Step 1: Building the code profile

    One of the main goals is to build a quality, stable code profile out of aggregated & anonymized data as fast as possible (to maximize the number of users that can benefit), while also making sure we have enough data to accurately optimize an app's performance. Sampling too much data takes up more bandwidth and time at installation. In addition, the longer we take to build the code profile, the fewer users get the benefits. Sampling too little data, and the code profile won't have enough information on what to properly optimize in order to make a difference.

    The outcome of the aggregation is what we call a core code profile, which only contains anonymous data about the code that is frequently seen across a random sample of sessions per device. We remove outliers to ensure we focus on the code that matters for most users.

    Experiments show that the most commonly used code paths can be calculated very quickly, over a small amount of time. That means we are able to build a code profile fast enough that the majority of users will benefit from.

    *Data averaged from Google apps, Source: Google internal data

    Step 2: Installing the code profile

    In Android 9.0 Pie, we introduced a new type of installation artifact: dex metadata files. Similar to the APKs, the dex metadata files are regular archives that contain data about how the APK should be optimized - like the core code profiles that have been built in the cloud. A key difference is that the dex metadata are managed solely by the platform and the app stores, and are not directly visible to developers.

    There is also built-in support for App Bundles / Google Play Dynamic Delivery: without any developer intervention, all the app's feature splits are optimized.

    Step 3: Using the code profiles to optimize performance

    To understand how these code profiles achieve better performance, we need to look at their structure. Code profiles contain information about:

    Using this information, we use a variety of optimization techniques, out of which the following three provide most of the benefits:

    Improvements & Observations

    We rolled out profiles in the cloud to all apps on the playstore at the end of last year.

    A very interesting observation is that, on average, ART profiles about 20% of the application methods (even less if we count the actual size of the code). For some apps, the profile covers only 2% of the code while for some the number goes up to 60%.

    Source: Google internal data

    Why is this an important observation? It means that the runtime has not seen a lot of the application code, and is thus not investing in the code's optimization. While there are a lot of valid use-cases where the code will not be executed (e.g. error handling or backwards compatibility code), this may also be due to unused features or unnecessary code. The skew distribution is a strong signal that the latter could play an important role in further optimizations (e.g. lowering APK size by removing unneeded dex bytecode).

    Future Development

    We're excited about the improvements that ART optimizing profiles has shown, and we'll be growing this concept more in the future. Building a profile of code per app opens opportunities for even more application improvements. Data can be used by developers to improve the app based on what's relevant and important for their end users. Using the information collected in Profiles, code can be re-organized or trimmed for better efficiency. Developers can potentially use App Bundles to split their features based on their use and avoid shipping unnecessary code to their users. We've already seen great improvements in app startup time, and hope to see additional benefits coming from profiles to make developer's lives easier while providing better experiences for our users.

    April 1st 2019, 1:27 pm

    AOSP Application Updates

    Android Developers Blog

    Posted by Raman Tenneti, AOSP Software Engineer and Ally Sillins, AOSP Program Manager

    When we started the Android Open Source Project (AOSP) 10 years ago, we included some basic applications in the AOSP build for three main purposes:

    1. to provide a usable set of applications for someone building an Android device from our AOSP
    2. to serve as a demonstration for the nascent Android app developer community, showcasing how they should build some of these applications
    3. to, as part of the platform, provide functionality to other Android applications that would interact with them through the standard Android APIs like the common intents

    However, as the Android ecosystem has matured over time, we've noticed a healthy growth of alternative applications - both as open source and proprietary implementations - developed by the developer community. These alternative applications are not only capable to serve the first two purposes, but often times showcase richer set of features demonstrating the power of Android. Late last year, we began to clean up these applications in AOSP to focus more effectively on the last purpose — their role to provide functionality to other Android applications as part of the platform.

    To date, the following 3 apps have been cleaned up: Music, Calendar, and Calculator. See below for details on these updates. Going forward, you can expect to see similar efforts with the other applications in the AOSP repository.

    As always, we're excited to hear your feedback on the developer website or through our AOSP forum.

    Music Application

    AOSP's Music app can now playback music, one file at a time, and exposes itself as an intent handler for the android.media.browse.MediaBrowserService. The app has controls to play and pause, and a slider moving forward and backward. Features removed include: Music Icon, Artists, Albums, Songs, Playlists, Search, and Settings.

    Calendar Application

    AOSP's Calendar app now exposes itself as an intent handler for the calendar events. New events cannot be created and existing events cannot be edited or deleted. The following features have been deleted: support for multiple accounts, reminders and settings. In addition, some features remain that are not needed for providing a part of the platform functionality: views for day, week, and month. This app may be further simplified in the future.

    Calculator App

    The calculator application is a standalone app, and does not function as part of the platform and hence has been removed from the AOSP build. However, the application will continue to exist as an open source project separately.

    March 28th 2019, 2:06 pm

    Changes to the Google Play Developer API

    Android Developers Blog

    Posted by Vlad Radu, Product Manager and Nicholas Lativy, Software Engineer

    The Google Play Developer API allows you to automate your in-app billing and app distribution workflows. At Google I/O '18, we introduced version 3 of the API, which allows you to transactionally start, manage, and halt staged releases on all tracks, through production, open testing, closed testing (including the new additional testing tracks), and internal testing.

    Updating from versions 1 and 2 to the latest version 3

    In addition to these new features, version 3 also supports all the functionality of previous versions, improving and simplifying how you manage workflows. Starting December 1, 2019, versions 1 and 2 of the Google Play Developer API will no longer be available so you need to update to version 3 ahead of this date.

    Migrating to version 3

    If you use the Google Play API client libraries (available for Java, Python, and other popular languages), we recommend upgrading to their latest versions, which already support version 3 of the API. In many cases, changing the version of the client library should be all that is necessary. However, you may also need to update specific code references to the version of the API in use - see examples in our samples repository.

    Many third-party plugins are already using version 3 of the API. If you use a plugin that does not support version 3 you will need to contact the maintainer. You will start seeing warnings in the Google Play Console in mid-May if we detect that your app is still using version 1 and version 2 endpoints.

    For version 1 users

    If you currently use version 1 of the API, you may also need to link your API project to the Google Console before converting to version 3. Learn more about this process.

    Going forward

    We hope you benefit from the new features of the Google Play Developer Publishing API and are looking forward to your continued feedback to help us improve the publishing experience on Google Play.

    How useful did you find this blog post?

    March 26th 2019, 7:36 pm

    The latest Android App Bundle updates including the additional languages API

    Android Developers Blog

    Posted by Wojtek Kaliciński, Developer Advocate, Android

    Last year, we launched Android App Bundles and Google Play's Dynamic Delivery to introduce modular development, reduce app size and streamline the release process. Since then, we've seen developers quickly adopt this new app model in over 60,000 production apps. We've been excited to see developers experience significant app size savings and reductions in the time needed to manage each release, and have documented these benefits in case studies with Duolingo and redBus.

    Thank you to everyone who took the time to give us feedback on our initial launch. We're always open to new ideas, and today, we're happy to announce some new improvements based on your suggestions:

    Additional languages API

    When you adopt the Android App Bundle as the publishing format for your app, Google Play is able to optimize the installation by delivering only the language resources that match the device's system locales. If a user changes the system locale after the app is installed, Play automatically downloads the required resources.

    Some developers choose to decouple the app's display language from the system locale by adding an in-app language switcher. With the latest release of the Play Core library (version 1.4.0), we're introducing a new additional languages API that makes it possible to build in-app language pickers while retaining the full benefits of smaller installs provided by using app bundles.

    With the additional languages API, apps can now request the Play Store to install resources for a new language configuration on demand and immediately start using it.

    Get a list of installed languages

    The app can get a list of languages that are already installed using the SplitInstallManager#getInstalledLanguages() method.

    val splitInstallManager = SplitInstallManagerFactory.create(context)
    val langs: Set<String> = splitInstallManager.installedLanguages

    Requesting additional languages

    Requesting an additional language is similar to requesting an on demand module. You can do this by specifying a language in the request through SplitInstallRequest.Builder#addLanguage(java.util.Locale).

    val installRequestBuilder = SplitInstallRequest.newBuilder()
    installRequestBuilder.addLanguage(Locale.forLanguageTag("pl"))
    splitInstallManager.startInstall(installRequestBuilder.build())

    The app can also monitor install success with callbacks and monitor the download state with a listener, just like when requesting an on demand module.

    Remember to handle the SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION state. Please note that there was an API change in a recent Play Core release, which means you should use the new SplitInstallManager#startConfirmationDialogForResult() together with Activity#onActivityResult(). The previous method of using SplitInstallSessionState#resolutionIntent() with startIntentSender() has been deprecated.

    Check out the updated Play Core Library documentation for more information on how to access the newly installed language resources in your activity.

    We've also updated our dynamic features sample on GitHub with the additional languages API, including how to store the user's language preference and apply it to your activities at startup.

    Please note that while the additional languages API is now available to all developers, on demand modules are in a closed beta for the time being. You can experiment with on demand modules in your internal, open, and closed test tracks, while we work with our partners to make sure this feature is ready for production apps.

    Instant-enabled App Bundle

    In Android Studio 3.3, we introduced a way to build app bundles that contain both the regular, installed version of your app as well as a Google Play Instant experience for modules marked with the dist:instant="true" attribute in their AndroidManifest.xml:

    <manifest ... xmlns:dist="http://schemas.android.com/apk/distribution">
        <dist:module dist:instant="true" />
        ...
    </manifest>

    Even though you could use a single project to generate the installed and instant versions of your app, up until now, developers were still required to use product flavors in order to build two separate app bundles and upload both to Play.

    We're happy to announce that we have now removed this restriction. It's now possible to upload a single, unified app bundle artifact, containing modules enabled for the instant experience. This functionality is now available for everyone.

    After you build an instant-enabled app bundle, upload it to any track on the Play Console, and you'll be able to select it when creating a new instant app release. This also means that the installed and instant versions of your app no longer need different version codes, which will simplify the release workflow.

    Opt in to app signing by Google Play

    You need to enable app signing by Google Play to publish your app using an Android App Bundle and automatically benefit from Dynamic Delivery optimizations. It is also a more secure way to manage your signing key, which we recommend to everyone, even if you want to keep publishing regular APKs for now.

    Based on your feedback, we've revamped the sign-up flow for new apps to make it easier to initialize the key you want to use for signing your app.

    Now developers can explicitly choose to upload their existing key without needing to upload a self-signed artifact first. You can also choose to start with a key generated by Google Play, so that the key used to locally sign your app bundle can become your upload key.

    Read more about the new flow.

    Permanent uninstallation of install time modules

    We have now added the ability to permanently uninstall dynamic feature modules that are included in your app's initial install.


    This is a behavior change, which means you can now call the existing SplitInstallManager#deferredUninstall() API on modules that set onDemand="false". The module will be permanently uninstalled, even when the app is updated.

    This opens up new possibilities for developers to further reduce the installed app size. For example, you can now uninstall a heavy sign-up module or any other onboarding content once the user completes it. If the user navigates to a section of your app that has been uninstalled, you can reinstall it using the standard on demand modules install API.

    We hope you enjoy these improvements and test them out in your apps. Continue to share your feedback as we work to make these features even more useful for you!

    How useful did you find this blog post?

    March 21st 2019, 6:13 pm

    Google Mobile Developer Day at Game Developers Conference 2019

    Android Developers Blog

    Posted by Kacey Fahey, Developer Marketing, Google Play & Android

    We're excited to host the Google Mobile Developer Day at Game Developers Conference 2019. We are taking this opportunity to share best practices and our plans to help your games businesses, which are fuelling incredible growth in the global mobile games market. According to Newzoo, mobile games revenue is projected to account for nearly 60% of global games revenue by 2021. The drivers of this growth come in many forms, including more developers building great games, new game styles blurring the lines of traditional genres, and the explosion of gaming in emerging markets - most notably in India.

    Image Source: GamesIndustry.biz

    To support your growth, Google is focused on improving the game development experience on Android. We are investing in tools to give you better insights into what is happening on devices, as well as in people and teams to address your feedback about the development process, graphics, multiplayer experiences, and more.

    We have some great updates and new tools to improve game discovery and monetization on Google Play, which we also shared today during our Mobile Developer Day:

    Pre-registration now in general availability

    Starting today, we are launching pre-registration for general availability. Set up a pre-registration campaign in the Google Play Console and start marketing your games to build awareness before launch. Users who pre-register receive a notification at launch, which helps increase day one installs.

    Google Play Instant gaining adoption

    We have seen strong adoption of Google Play Instant with 3x growth in the number of instant games and 5x growth in the number of instant sessions over the last six months. Instant experiences allow players to tap the 'Try Now' button on your store listing page and go straight to a demo experience in a matter of seconds, without installing. Now, they're even easier to build with Cocos and Unity plug-ins and an expanded implementation partner program. Discover the latest updates on Google Play Instant.

    Android App Bundles momentum and new large download size threshold

    Over 60K apps and games on Google Play are now using the Android App Bundle publishing format, which is supported in Android Studio, Unity, and Cocos Creator. The app bundle uses Google Play's Dynamic Delivery to deliver a smaller, optimized APK containing only the resources needed for a specific device.

    To better support high quality game experiences and reflect improved devices, we've also increased the size limit for APKs generated from app bundles to 150MB and raised the threshold for large download user warnings on the Google Play Store to 150MB, from 100MB.

    Improved tools in the Google Play Console

    Store listing experiments let you A/B test changes to your store listing on actual Play Store visitors. We recently rolled out improvements, introducing two new metrics - first time installers and D1 retained users - to more accurately reflect the performance of your store listings. These two new metrics are now reported with hourly intervals and are available via email notifications, letting you see results faster and track performance better.

    Country targeted store listings allow you to tailor your app's store listing to appeal to users in different countries. You can customize the app title, icon, descriptions and graphic assets, allowing you to better appeal to users in specific target markets. For example, you can now tailor your store listing with different versions of the English language for users in India versus the United States.

    Rewarded ads give players the choice to watch an advertisement in exchange for in-app items. With rewarded ads in Google Play, you can now create and manage rewarded ads through the Google Play Console. No additional SDK integrations are required.

    We hope you try some of these new tools and keep sharing ideas so we can make Android and Google Play a better place to grow your business. We are committed to continue improving the platform and building tools that better serve the gaming community.

    Get started today by visiting two new resources, a hub for developers interested in creating games on Android and games.withgoogle.com, for developers looking to connect and scale their business across Google. Many of these updates and resources come from community suggestions, so sign up for our monthly newsletter to stay informed.

    How useful did you find this blog post?

    March 18th 2019, 1:36 pm

    Introducing a new Google Play app and game icon specification

    Android Developers Blog


    Posted by Steve Suppe, Product Manager, Google Play
    As part of our focus and dedication to improving the Google Play Store experience for our users, we are introducing new design specifications for your app icons.

    Left to right: original icon, new icon (example), original icon in legacy mode


    As of early April, you will be able to upload new icons to the Google Play Console and confirm you are compliant with the new specification. Original icons are still accepted in the Google Play Store during this time. As of May 1st, developers will no longer be able to upload icons in the Play Console which do not meet the new specifications, although existing original icons in the Google Play Store during this period can remain unchanged.
    By June 24, we require you to:
    1. Update your icon to the new specification.
    2. Upload your icon to Play Console.
    3. Confirm in Play Console that your icon meets the new specification.
    We highly recommend that you update your icons and confirm they meet the new specification as soon as possible to ensure that you provide the highest quality experience for users.

    What exactly is changing?

    Timelines Changes
    Early April You can start uploading your new icons in Play Console and confirm they meet the new specification.
    • Original icons will continue to display correctly in Google Play.
    • New icons will display correctly in Google Play.
    May 1st Any new icons uploaded in Play Console must be confirmed as meeting the new specification.
    • Original icons will continue to display correctly in Google Play.
    • New icons will display correctly in Google Play.
    June 24th Original icons are converted to "legacy mode." You must confirm that any new icons uploaded in Play Console meet the new specification.
    • Original icons will be automatically converted to "legacy mode" icons.
    • New icons render correctly in the Google Play Store.

    These updates will help us all provide a more unified and consistent look and feel for Google Play, allowing us to better showcase your apps and games and provide a higher quality user experience.
    We will be keeping you up-to-date with these changes in the coming months - so look out for more updates. In the meantime, check out our new icon design specifications.
    How useful did you find this blog post?


    March 15th 2019, 1:15 pm

    Giving users more control over their location data

    Android Developers Blog

    Posted by Jen Chai, Product Manager

    Location data can deliver amazing, rich mobile experiences for users on Android such as finding a restaurant nearby, tracking the distance of a run, and getting turn-by-turn directions as you drive. Location is also one of the most sensitive types of personal information for a user. We want to give users simple, easy-to-understand controls for what data they are providing to apps, and yesterday, we announced in Android Q that we are giving users more control over location permissions. We are delighted by the innovative location experiences you provide to users through your apps, and we want to make this transition as straightforward for you as possible. This post dives deeper into the location permission changes in Q, what it may mean for your app, and how to get started with any updates needed.

    Previously, a user had a single control to allow or deny an app access to device location, which covered location usage by the app both while it was in use and while it wasn't. Starting in Android Q, users have a new option to give an app access to location only when the app is being used; in other words, when the app is in the foreground. This means users will have a choice of three options for providing location to an app:

    Some apps or features within an app may only need location while the app is being used. For example, if a feature allows a user to search for a restaurant nearby, the app only needs to understand the user's location when the user opens the app to search for a restaurant.

    However, some apps may need location even when the app is not in use. For example, an app that automatically tracks the mileage you drive for tax filing, without requiring you to interact with the app.

    The new location control allows users to decide when device location data is provided to an app and prevents an app from getting location data that it may not need. Users will see this new option in the same permissions dialog that is presented today when an app requests access to location. This permission can also be changed at any time for any app from Settings-> Location-> App permission.

    Here's how to get started

    We know these updates may impact your apps. We respect our developer community, and our goal is to approach any change like this very carefully. We want to support you as much as we can by (1) releasing developer-impacting features in the first Q Beta to give you as much time as possible to make any updates needed in your apps and (2) providing detailed information in follow-up posts like this one as well as in the developer guides and privacy checklist. Please let us know if there are ways we can make the guides more helpful!

    If your app has a feature requiring "all the time" permission, you'll need to add the new ACCESS_BACKGROUND_LOCATION permission to your manifest file when you target Android Q. If your app targets Android 9 (API level 28) or lower, the ACCESS_BACKGROUND_LOCATION permission will be automatically added for you by the system if you request either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. A user can decide to provide or remove these location permissions at any time through Settings. To maintain a good user experience, design your app to gracefully handle when your app doesn't have background location permission or when it doesn't have any access to location.

    Users will also be more likely to grant the location permission if they clearly understand why your app needs it. Consider asking for the location permission from users in context, when the user is turning on or interacting with a feature that requires it, such as when they are searching for something nearby. In addition, only ask for the level of access required for that feature. In other words, don't ask for "all the time" permission if the feature only requires "while in use" permission.

    To learn more, read the developer guide on how to handle the new location controls.

    March 14th 2019, 3:13 pm

    Android Jetpack Navigation Stable Release

    Android Developers Blog

    Posted by Ian Lake, Software Engineering Lead & Jisha Abubaker, Product Manager

    Cohesive tooling and guidance for implementing predictable in-app navigation

    Today we're happy to announce the stable release of the Android Jetpack Navigation component.

    The Jetpack Navigation component's suite of libraries, tooling and guidance provides a robust, complete navigation framework, freeing you from the challenges of implementing navigation yourself and giving you certainty that all edge cases are handled correctly.

    With the Jetpack Navigation component you can:

    The Jetpack Navigation component adheres to the Principles of Navigation, providing consistent and predictable navigation no matter how simple or complex your app may be.

    Simplify navigation code with Jetpack Navigation Libraries

    The Jetpack Navigation component provides a framework for in-app navigation that makes it possible to abstract away the implementation details, keeping your app code free of navigation boilerplate.

    To get started with the Jetpack Navigation component in your project, add the Navigation artifacts available on Google's Maven repository in Java or Kotlin to your app's build.gradle file:

     dependencies {
        def nav_version = 2.0.0
    
        // Java
        implementation "androidx.navigation:navigation-fragment:$nav_version"
        implementation "androidx.navigation:navigation-ui:$nav_version"
    
        // Kotlin KTX 
        implementation "androidx.navigation:navigation-fragment-ktx:$nav_version"
        implementation "androidx.navigation:navigation-ui-ktx:$nav_version"
      }

    Note: If you have not yet migrated to androidx.*, the Jetpack Navigation stable component libraries are also available as android.arch.* artifacts in version 1.0.0.

    navigation-runtime : This core library powers the navigation graph, which provides the structure of your in-app navigation: the screens or destinations that make up your app and the actions that link them. You can control how you navigate to destinations with a simple navigate() call. These destinations may be fragments, activities or custom destinations.

    navigation-fragment: This library builds upon navigation-runtime and provides out-of-the-box support for fragments as destinations. With this library, fragment transactions are now handled for you automatically.

    navigation-ui: This library allows you to easily add navigation drawers, menus and bottom navigation to your app consistent with the Material Design guidelines.

    Each of these libraries provide an Android KTX artifact with the -ktx suffix that builds upon the Java API, taking advantage of Kotlin-specific language features.

    Tools to help you build predictable navigation workflows

    Available in Android Studio 3.3 and above, the Navigation Editor lets you visually create your navigation graph , allowing you to manage user journeys within your app.

    With integration into the manifest merger tool, Android Studio can automatically generate the intent filters necessary to enable deep linking to a specific screen in your app. With this feature, you can associate URLs with any screen of your app by simply setting an attribute on the navigation destination.

    Navigation often requires passing data from one screen to another. For example, your list screen may pass an item ID to a details screen. Many of the runtime exceptions during navigation have been attributed to a lack of type safety guarantees as you pass arguments. These exceptions are hard to replicate and debug. Learn how you can provide compile time type safety with the Safe Args Gradle Plugin.

    Guidance to get it right on the first try

    Check out our brand new set of developer guides that encompass best practices to help you implement navigation correctly:

    What developers say

    Here's what Emery Coxe, Android Lead @ HomeAway, has to say about the Jetpack Navigation component :

    "The Navigation library is well-designed and fully configurable, allowing us to integrate the library according to our specific needs.

    With the Navigation Library, we refactored our legacy navigation drawer to support a dynamic, runtime-based configuration using custom views. It allowed us to add / remove new screens to the top-level experience of our app without creating any interdependencies between discreetly packaged modules.

    We were also able to get rid of all anti-patterns in our app around top-level navigation, removing explicit casts and hardcoded assumptions to instead rely directly on Navigation. This library is a fundamental component of modern Android development, and we intend to adopt it more broadly across our app moving forward.

    Get started

    Check out the migration guide and the developer guide to learn how you can get started using the Jetpack Navigation component in your app. We also offer a hands-on codelab and a sample app.

    Also check out Google's Digital Wellbeing to see another real-world example of in-app navigation using the Android Jetpack Navigation component.

    Feedback

    Please continue to tell us about your experience with the Navigation component. If you have specific feedback on features or if you run into any issues, please file a bug via one of the following links:

    March 14th 2019, 1:13 pm

    Introducing Android Q Beta

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    In 2019, mobile innovation is stronger than ever, with new technologies from 5G to edge to edge displays and even foldable screens. Android is right at the center of this innovation cycle, and thanks to the broad ecosystem of partners across billions of devices, Android's helping push the boundaries of hardware and software bringing new experiences and capabilities to users.

    As the mobile ecosystem evolves, Android is focused on helping users take advantage of the latest innovations, while making sure users' security and privacy are always a top priority. Building on top of efforts like Google Play Protect and runtime permissions, Android Q brings a number of additional privacy and security features for users, as well as enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 support, faster app startup, and more.

    Today we're releasing Beta 1 of Android Q for early adopters and a preview SDK for developers. You can get started with Beta 1 today by enrolling any Pixel device (including the original Pixel and Pixel XL, which we've extended support for by popular demand!) Please let us know what you think! Read on for a taste of what's in Android Q, and we'll see you at Google I/O in May when we'll have even more to share.

    Building on top of privacy protections in Android

    Android was designed with security and privacy at the center. As Android has matured, we've added a wide range of features to protect users, like file-based encryption, OS controls requiring apps to request permission before accessing sensitive resources, locking down camera/mic background access, lockdown mode, encrypted backups, Google Play Protect (which scans over 50 billion apps a day to identify potentially harmful apps and remove them), and much more. In Android Q, we've made even more enhancements to protect our users. Many of these enhancements are part of our work in Project Strobe.

    Giving users more control over location

    With Android Q, the OS helps users have more control over when apps can get location. As in prior versions of the OS, apps can only get location once the app has asked you for permission, and you have granted it.

    One thing that's particularly sensitive is apps' access to location while the app is not in use (in the background). Android Q enables users to give apps permission to see their location never, only when the app is in use (running), or all the time (when in the background).

    For example, an app asking for a user's location for food delivery makes sense and the user may want to grant it the ability to do that. But since the app may not need location outside of when it's currently in use, the user may not want to grant that access. Android Q now offers this greater level of control. Read the developer guide for details on how to adapt your app for this new control. Look for more user-centric improvements to come in upcoming Betas. At the same time, our goal is to be very sensitive to always give developers as much notice and support as possible with these changes.

    More privacy protections in Android Q

    Beyond changes to location, we're making further updates to ensure transparency, give users control, and secure personal data.

    In Android Q, the OS gives users even more control over apps, controlling access to shared files. Users will be able to control apps' access to the Photos and Videos or the Audio collections via new runtime permissions. For Downloads, apps must use the system file picker, which allows the user to decide which Download files the app can access. For developers, there are changes to how your apps can use shared areas on external storage. Make sure to read the Scoped Storage changes for details.

    We've also seen that users (and developers!) get upset when an app unexpectedly jumps into the foreground and takes over focus. To reduce these interruptions, Android Q will prevent apps from launching an Activity while in the background. If your app is in the background and needs to get the user's attention quickly -- such as for incoming calls or alarms -- you can use a high-priority notification and provide a full-screen intent. See the documentation for more information.

    We're limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to help you choose the right identifiers for your use case, and see the details here. We're also randomizing the device's MAC address when connected to different Wi-Fi networks by default -- a setting that was optional in Android 9 Pie.

    We are bringing these changes to you early, so you can have as much time as possible to prepare. We've also worked hard to provide developers detailed information up front, we recommend reviewing the detailed docs on the privacy changes and getting started with testing right away.

    New ways to engage users

    In Android Q, we're enabling new ways to bring users into your apps and streamlining the experience as they transition from other apps.

    Foldables and innovative new screens

    Foldable devices have opened up some innovative experiences and use-cases. To help your apps to take advantage of these and other large-screen devices, we've made a number of improvements in Android Q, including changes to onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. To you get started building and testing on these new devices, we've been hard at work updating the Android Emulator to support multiple-display type switching -- more details coming soon!

    Sharing shortcuts

    When a user wants to share content like a photo with someone in another app, the process should be fast. In Android Q we're making this quicker and easier with Sharing Shortcuts, which let users jump directly into another app to share content. Developers can publish share targets that launch a specific activity in their apps with content attached, and these are shown to users in the share UI. Because they're published in advance, the share UI can load instantly when launched.

    The Sharing Shortcuts mechanism is similar to how App Shortcuts works, so we've expanded the ShortcutInfo API to make the integration of both features easier. This new API is also supported in the new ShareTarget AndroidX library. This allows apps to use the new functionality, while allowing pre-Q devices to work using Direct Share. You can find an early sample app with source code here.

    Settings Panels

    You can now also show key system settings directly in the context of your app, through a new Settings Panel API, which takes advantage of the Slices feature that we introduced in Android 9 Pie.

    A settings panel is a floating UI that you invoke from your app to show system settings that users might need, such as internet connectivity, NFC, and audio volume. For example, a browser could display a panel with connectivity settings like Airplane Mode, Wi-Fi (including nearby networks), and Mobile Data. There's no need to leave the app; users can manage settings as needed from the panel. To display a settings panel, just fire an intent with one of the new Settings.Panel actions.

    Connectivity

    In Android Q, we've extended what your apps can do with Android's connectivity stack and added new connectivity APIs.

    Connectivity permissions, privacy, and security

    Most of our APIs for scanning networks already require COARSE location permission, but in Android Q, for Bluetooth, Cellular and Wi-Fi, we're increasing the protection around those APIs by requiring the FINE location permission instead. If your app only needs to make peer-to-peer connections or suggest networks, check out the improved Wi-Fi APIs below -- they simplify connections and do not require location permission.

    In addition to the randomized MAC addresses that Android Q provides when connected to different Wi-Fi networks, we're adding new Wi-Fi standard support, WP3 and OWE, to improve security for home and work networks as well as open/public networks.

    Improved peer-to-peer and internet connectivity

    In Android Q we refactored the Wi-Fi stack to improve privacy and performance, but also to improve common use-cases like managing IoT devices and suggesting internet connections -- without requiring the location permission.

    The network connection APIs make it easier to manage IoT devices over local Wi-Fi, for peer-to-peer functions like configuring, downloading, or printing. Apps initiate connection requests indirectly by specifying preferred SSIDs & BSSIDs as WiFiNetworkSpecifiers. The platform handles the Wi-Fi scanning itself and displays matching networks in a Wi-Fi Picker. When the user chooses, the platform sets up the connection automatically.

    The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity. Apps initiate connections indirectly by providing a ranked list of networks and credentials as WifiNetworkSuggestions. The platform will seamlessly connect based on past performance when in range of those networks.

    Wi-Fi performance mode

    You can now request adaptive Wi-Fi in Android Q by enabling high performance and low latency modes. These will be of great benefit where low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use-cases.

    To use the new performance modes, call WifiManager.WifiLock.createWifiLock() with WIFI_MODE_FULL_LOW_LATENCY or WIFI_MODE_FULL_HIGH_PERF. In these modes, the platform works with the device firmware to meet the requirement with lowest power consumption.

    Camera, media, graphics

    Dynamic depth format for photos

    Many cameras on mobile devices can simulate narrow depth of field by blurring the foreground or background relative to the subject. They capture depth metadata for various points in the image and apply a static blur to the image, after which they discard the depth metadata.

    Starting in Android Q, apps can request a Dynamic Depth image which consists of a JPEG, XMP metadata related to depth related elements, and a depth and confidence map embedded in the same file on devices that advertise support.

    Requesting a JPEG + Dynamic Depth image makes it possible for you to offer specialized blurs and bokeh options in your app. You can even use the data to create 3D images or support AR photography use-cases in the future. We're making Dynamic Depth an open format for the ecosystem, and we're working with our device-maker partners to make it available across devices running Android Q and later.

    With Dynamic Depth image you can offer specialized blurs and bokeh options in your app.

    New audio and video codecs

    Android Q introduces support for the open source video codec AV1. This allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android Q supports audio encoding using Opus - a codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.

    The MediaCodecInfo API introduces an easier way to determine the video rendering capabilities of an Android device. For any given codec, you can obtain a list of supported sizes and frame rates using VideoCodecCapabilities.getSupportedPerformancePoints(). This allows you to pick the best quality video content to render on any given device.

    Native MIDI API

    For apps that perform their audio processing in C++, Android Q introduces a native MIDI API to communicate with MIDI devices through the NDK. This API allows MIDI data to be retrieved inside an audio callback using a non-blocking read, enabling low latency processing of MIDI messages. Give it a try with the sample app and source code here.

    ANGLE on Vulkan

    To enable more consistency for game and graphics developers, we are working towards a standard, updateable OpenGL driver for all devices built on Vulkan. In Android Q we're adding experimental support for ANGLE on top of Vulkan on Android devices. ANGLE is a graphics abstraction layer designed for high-performance OpenGL compatibility across implementations. Through ANGLE, the many apps and games using OpenGL ES can take advantage of the performance and stability of Vulkan and benefit from a consistent, vendor-independent implementation of ES on Android devices. In Android Q, we're planning to support OpenGL ES 2.0, with ES 3.0 next on our roadmap.

    We'll expand the implementation with more OpenGL functionality, bug fixes, and performance optimizations. See the docs for details on the current ANGLE support in Android, how to use it, and our plans moving forward. You can start testing with our initial support by opting-in through developer options in Settings. Give it a try today!

    Vulkan everywhere

    We're continuing to expand the impact of Vulkan on Android, our implementation of the low-overhead, cross-platform API for high-performance 3D graphics. Our goal is to make Vulkan on Android a broadly supported and consistent developer API for graphics. We're working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices. Going forward, this will help provide a uniform high-performance graphics API for apps and games to use.

    Neural Networks API 1.2

    Since introducing the Neural Networks API (NNAPI) in 2017, we've continued to expand the number of operations supported and improve existing functionality. In Android Q, we've added 60 new ops including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimisations. This lays the foundation for accelerating a much greater range of models -- such as those for object detection and image segmentation. We are working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.

    Strengthening Android's Foundations

    ART performance

    Android Q introduces several new improvements to the ART runtime which help apps start faster and consume less memory, without requiring any work from developers.

    Since Android Nougat, ART has offered Profile Guided Optimization (PGO), which speeds app startup over time by identifying and precompiling frequently executed parts of your code. To help with initial app startup, Google Play is now delivering cloud-based profiles along with APKs. These are anonymized, aggregate ART profiles that let ART pre-compile parts of your app even before it's run, giving a significant jump-start to the overall optimization process. Cloud-based profiles benefit all apps and they're already available to devices running Android P and higher.

    We're also continuing to make improvements in ART itself. For example, in Android Q we've optimized the Zygote process by starting your app's process earlier and moving it to a security container, so it's ready to launch immediately. We're storing more information in the app's heap image, such as classes, and using threading to load the image faster. We're also adding Generational Garbage Collection to ART's Concurrent Copying (CC) Garbage Collector. Generational CC is more efficient as it collects young-generation objects separately, incurring much lower cost as compared to full-heap GC, while still reclaiming a good amount of space. This makes garbage collection overall more efficient in terms of time and CPU, reducing jank and helping apps run better on lower-end devices.

    Security for apps

    BiometricPrompt is our unified authentication framework to support biometrics at a system level. In Android Q we're extending support for passive authentication methods such as face, and adding implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm the transaction in the TEE during the authentication. The implicit flow is designed for a lighter-weight alternative for transactions with passive authentication. We've also improved the fallback for device credentials when needed.

    Android Q adds support for TLS 1.3, a major revision to the TLS standard that includes performance benefits and enhanced security. Our benchmarks indicate that secure connections can be established as much as 40% faster with TLS 1.3 compared to TLS 1.2. TLS 1.3 is enabled by default for all TLS connections. See the docs for details.

    Compatibility through public APIs

    Another thing we all care about is ensuring that apps run smoothly as the OS changes and evolves. Apps using non-SDK APIs risk crashes for users and emergency rollouts for developers. In Android Q we're continuing our long-term effort begun in Android P to move apps toward only using public APIs. We know that moving your app away from non-SDK APIs will take time, so we're giving you advance notice.

    In Android Q we're restricting access to more non-SDK interfaces and asking you to use the public equivalents instead. To help you make the transition and prevent your apps from breaking, we're enabling the restrictions only when your app is targeting Android Q. We'll continue adding public alternative APIs based on your requests; in cases where there is no public API that meets your use case, please let us know.

    It's important to test your apps for uses of non-SDK interfaces. We recommend using the StrictMode method detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI. Even if the APIs are exempted (grey-listed) at this time, it's best to plan for the future and eliminate their use to reduce compatibility issues. For more details on the restrictions in Android Q, see the developer guide.

    Modern Android

    We're expanding our efforts to have all apps take full advantage of the security and performance features in the latest version of Android. Later this year, Google Play will require you to set your app's targetSdkVersion to 28 (Android 9 Pie) in new apps and updates. In line with these changes, Android Q will warn users with a dialog when they first run an app that targets a platform earlier than API level 23 (Android Marshmallow). Here's a checklist of resources to help you migrate your app.

    We're also moving the ecosystem toward readiness for 64-bit devices. Later this year, Google Play will require 64-bit support in all apps. If your app uses native SDKs or libraries, keep in mind that you'll need to provide 64-bit compliant versions of those SDKs or libraries. See the developer guide for details on how to get ready.

    Get started with Android Q Beta

    With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you'll want to enable and test with Android Q storage changes, new location permission states, restrictions on background app launch, and restrictions on device identifiers. See the privacy documentation for details.

    To get started, just install your current app from Google Play onto a device or Android Virtual Device running Android Q Beta and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. Take a look at the migration guide for steps and a recommended timeline.

    Next, update your app's targetSdkVersion to 'Q' as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.

    Explore the new features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Take a look at the API diff report, the Android Q Beta API reference, and developer guides as a starting point. Also, on the Android Q Beta developer site, you'll find release notes and support resources for reporting issues.

    To build with Android Q, download the Android Q Beta SDK and tools into Android Studio 3.3 or higher, and follow these instructions to configure your environment. If you want the latest fixes for Android Q related changes, we recommend you use Android Studio 3.5 or higher.

    How do I get Android Q Beta?

    It's easy - you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we're supporting all three generations of Pixel -- Pixel 3, Pixel 2, and even the original Pixel!). Downloadable system images for those devices are also available. If you don't have a Pixel device, you can use the Android Emulator, and download the latest emulator system images via the SDK Manager in Android Studio.

    We plan to update the preview system images and SDK regularly throughout the preview. We'll have more features to share as the Beta program moves forward.

    As always, your feedback is critical, so please 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. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.

    March 13th 2019, 3:48 pm

    Grow your indie game with Google Play

    Android Developers Blog

    Posted by Patricia Correa, Director, Platforms & Ecosystems Developer Marketing

    Google Play empowers game developers of all sizes to engage and delight people everywhere, and build successful businesses too. We are inspired by the passion and creativity we see from the indie games community, and, over the past few years, we've invested in and nurtured indie games developers around the world, helping them express their unique voice and bring ideas to life.

    This year, we've put together several initiatives to help the indie community.

    Indie Games Showcase

    For indie developers who are constantly pushing the boundaries of storytelling, visual excellence, and creativity in mobile we are announcing today the Indie Games Showcase, an international competition for games studios from Europe*, South Korea and Japan. Those of you who meet the eligibility criteria (as outlined below) can enter your game for a chance to win several prizes, including:

    How to enter the competition

    If you're over 18 years old, based in one of the eligible countries, have 30 or less full time employees, and have published a new game on Google Play after 1 January 2018, you can enter your game. If you're planning on publishing a new game soon, you can also enter by submitting a private beta. Submissions close on May 6 2019. Check out all the details in the terms and conditions for each region. Enter now!

    Indie Games Accelerator

    Last year we launched our first games accelerator for developers in Southeast Asia, India and Pakistan and saw great results. We are happy to announce that we are expanding the format to accept developers from select countries in the Middle East, Africa, and Latin America, with applications for the 2019 cohort opening soon. The Indie Games Accelerator is a 6 month intensive program for top games startups, powered by mentors from the gaming industry as well as Google experts, offering a comprehensive curriculum that covers all aspects of building a great game and company.

    Mobile Developer Day at GDC

    We will be hosting our annual Developer Day at the Game Developers Conference in San Francisco on Monday, March 18th. Join us for a full day of sessions covering tools and best practices to help build a successful mobile games business. We'll focus on game quality, effective monetization and growth strategies, and how to create, connect, and scale with Google. Sign up to stay up to date or join us via livestream.

    Developer Days

    We also want to engage with you in person with a series of events. We will be announcing them shortly, so please make sure to sign up to our newsletter to get notified about events and programs for indie developers.

    Academy for App Success

    Looking for tips on how to use various developer tools in the Play Console? Get free training through our e-learning program, the Academy for App Success. We even have a custom Play Console for game developers course to get a jump start on Google Play.

    We look forward to seeing your amazing work and sharing your creativity with other developers, gamers and industry experts around the world. And don't forget to submit your game for a chance to get featured on Indie Corner on Google Play.

    * The competition is open to developers from the following European countries: Austria, Belgium, Belarus, Czech Republic, Denmark, Finland, France, Germany, Israel, Italy, Netherlands, Norway, Poland, Romania, Russia, Slovakia, Spain, Sweden, Ukraine, and the United Kingdom (including Northern Ireland).


    How useful did you find this blog post?

    March 13th 2019, 2:07 am

    Supplement your earnings with Rewarded Products

    Android Developers Blog

    Posted by Patrick Davis, Product Manager, Google Play

    Developers are increasingly using multiple methods to monetize their apps and games. One trend has been to reward users for a monetizable action, like watching a video, with in-game currency or other benefits. This gives users more choice in how they experience the app or game, and has been an effective way to monetize non-paying users.

    To support this monetization method, Google Play is excited to announce rewarded products, a new product type now available in open beta in the Play Console.

    Rewarded products make it easy for Google Play developers to increase their monetized user base. Our first rewarded product offering will be in a video format. Users can elect to watch a video advertisement and upon completion be rewarded with virtual goods or in-game currency. In the example below, the user selects "watch ad", views the video, and then is granted 100 coins.

    Rewarded products can be added to any app using the Google Play Billing Library or AIDL interface with only a few additional API calls. No extra SDK integration is required. This significantly reduces the work required to implement compared to other offerings. Rewarded products are powered by AdMob technology to give access to the broad range of content from advertisers currently working with Google.

    Get started with rewarded products.

    For developers interested in best practices on how to diversify revenue and how rewarded products fit in, please visit us at Google's Mobile Developer day at GDC or watch via the livestream.

    How useful did you find this blog post?

    March 6th 2019, 1:14 pm

    Android Jetpack WorkManager Stable Release

    Android Developers Blog

    Posted by Sumir Kataria, Software Engineering Lead & Jisha Abubaker, Product Manager

    Simplify how you manage background work with WorkManager

    Today, we're happy to announce the release of Android Jetpack WorkManager 1.0 Stable. We want to thank so many of you in our dev community who have given us feedback and logged bugs along the way - we've gotten here thanks to your help!

    When we looked at the top problems faced by developers, we saw that doing background processing reliably and in a battery-friendly manner was a huge challenge. This meant that periodically fetching fresh content or uploading your logs was complex. Different versions of Android provided different tools for the job, each with their own API quirks. For example, listening for network or storage availability and automatically retrying your tasks involved a lot of work.

    Our answer to these challenges was WorkManager. We introduced a preview of the Android Jetpack WorkManager library at Google I/O 2018 and have since iterated on it with additional features and bug fixes thanks to your valuable input.

    The goal of WorkManager is to make background operations easy for you. WorkManager takes into account constraints like battery-optimization, storage, or network availability, and it only runs its tasks when the appropriate conditions are met. It also knows when to retry or reschedule your work--even if your device or app restarts.

    We believe WorkManager is a friendly, approachable API that can take care of one of the most complex parts of Android for you so you can focus on the code that makes your app unique.

    WorkManager Highlights

    Here are some key features of WorkManager:

    Watch and read below to learn when and how to use WorkManager to simplify managing background work in your apps:

    When to use WorkManager

    WorkManager is best suited for tasks that can be deferred, but are still expected to run even if the application or device restarts (for example, syncing data periodically with a backend service and uploading logs or analytics data).

    For tasks like sending an instant message that are required to run immediately or for tasks that are not required to run after the app exits, take a look at our background processing guide to learn which solution meets your needs.

    How to use WorkManager

    To get started with the WorkManager API, add the WorkManager dependency available on Google's Maven repository in Java or Kotlin to your application's build.gradle file:

    dependencies {
        def work_version = 1.0.0
    
        // Java
        implementation "android.arch.work:work-runtime:$work_version"
    
        // Kotlin KTX + coroutines
        implementation "android.arch.work:work-runtime-ktx:$work_version"
      }

    Now, simply subclass a Worker and implement your background work with doWork() and enqueue it with WorkManager.

    class MyWorker(ctx: Context, params: WorkerParameters)
      : Worker(ctx, params) {
      override fun WorkerResult doWork() {
        //do the work you want done in the background here
        return Result.success()
      }
    }
    
    // optionally, add constraints like power, network availability
    val constraints: Constraints = Constraints.Builder()
         .setRequiresCharging(true)
                    .setRequiredNetworkType(NetworkType.CONNECTED)
                    .build()
    
    val myWork = OneTimeWorkRequestBuilder<MyWorker>()
                    .setConstraints(constraints).build()
    
    // Now, enqueue your work
    WorkManager.getInstance().enqueue(myWork)

    WorkManager will now take care of running your task when it detects that your device is charging and the network is available.

    Why use WorkManager

    Backward compatibility

    WorkManager will leverage the right scheduling API under the hood: it uses JobScheduler API on Android 6.0+ (API 23+) and a combination of AlarmManager and BroadcastReceiver on previous versions.

    It also seeks to ensure the best possible behavior so that it complies with system optimizations introduced in newer Android API versions to maximize battery and enforce good app behavior.

    For example, WorkManager will schedule background work during the maintenance window for Android 6.0+ (API 23+) devices when the system is in Doze mode.

    Reliable scheduling

    With WorkManager, you can easily add constraints like network availability or charging status. Your work will run when the constraints are met and automatically retried if they fail while running. For example, if your task requires network to be available, the task will be stopped when network is no longer available and retried later.

    You can also monitor work status and retrieve work result using LiveData. This allows your UI to be notified when your task is completed.

    In the event that your work fails, you can control how your work is retried by configuring how backoff is handled.

    WorkManager is also able to reschedule your work, using a record of your work in its local database, if an application or device restart occurs.

    Control over how your work is run

    We understand that each app has unique needs, and so do your tasks--even within the same app. WorkManager provides a simple yet highly flexible API surface to help configure your work and how it is run.

    Take advantage of one-off scheduling with OneTimeWorkRequest or recurrent scheduling with PeriodicWorkRequest.

    You can also chain your one time work requests to run in order or in parallel. If any work in the chain fails, WorkManager seeks to ensure that the remaining chain of work will not run. Read more about chaining work requests here.

    If you require more flexibility over how WorkManager parallelizes and manages work, check out our advanced threading guide.

    What developers have to say

    redBus, the largest online bus ticketing platform, shares their experience using WorkManager to simplify how they collect user feedback in their Android app:

    "Feedback is critical to redBus as we expand into other countries. It often happens that a user gives critical feedback about a functionality within the redBus app but when the app tries to upload the feedback to backend servers, there might not be enough network coverage or battery.
    WorkManager has simplified the way redBus app delivers information to it's backend servers. WorkManager library's capability to handle parameters like network connectivity, battery and use appropriate handlers like AlarmManager or JobScheduler has enabled us to concentrate on building business logics and offloading execution complexity to WorkManager."

    - Dinesh Shanmugam

    Android Lead, redBus.in

    Get started with WorkManager

    Check out our getting started guide and hands-on codelab to start using the WorkManager library for your background task needs.

    We appreciate your feedback, including features you like and features you would like to see.

    If you find a bug or issue, feel free to file an issue.

    March 5th 2019, 1:09 pm

    Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerabilit

    Android Developers Blog

    Posted by Patrick Mutchler and Meghan Kelly, Android Security & Privacy Team

    Helping Android app developers build secure apps, free of known vulnerabilities, means helping the overall ecosystem thrive. This is why we launched the Application Security Improvement Program five years ago, and why we're still so invested in its success today.

    What the Android Security Improvement Program does

    When an app is submitted to the Google Play store, we scan it to determine if a variety of vulnerabilities are present. If we find something concerning, we flag it to the developer and then help them to remedy the situation.

    Think of it like a routine physical. If there are no problems, the app runs through our normal tests and continues on the process to being published in the Play Store. If there is a problem, however, we provide a diagnosis and next steps to get back to healthy form.

    Over its lifetime, the program has helped more than 300,000 developers to fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users with the same security issues present, which we consider a win.

    What vulnerabilities are covered

    The App Security Improvement program covers a broad range of security issues in Android apps. These can be as specific as security issues in certain versions of popular libraries (ex: CVE-2015-5256) and as broad as unsafe TLS/SSL certificate validation.

    We are continuously improving this program's capabilities by improving the existing checks and launching checks for more classes of security vulnerability. In 2018, we deployed warnings for six additional security vulnerability classes including:

    1. SQL Injection
    2. File-based Cross-Site Scripting
    3. Cross-App Scripting
    4. Leaked Third-Party Credentials
    5. Scheme Hijacking
    6. JavaScript Interface Injection

    Ensuring that we're continuing to evolve the program as new exploits emerge is a top priority for us. We are continuing to work on this throughout 2019.

    Keeping Android users safe is important to Google. We know that app security is often tricky and that developers can make mistakes. We hope to see this program grow in the years to come, helping developers worldwide build apps users can truly trust.

    February 28th 2019, 1:19 pm

    Google Play Protect in 2018: New updates to keep Android users secure

    Android Developers Blog

    Posted by Rahul Mishra and Tom Watkins, Android Security & Privacy Team

    In 2018, Google Play Protect made Android devices running Google Play some of the most secure smartphones available, scanning over 50 billion apps everyday for harmful behaviour.

    Android devices can genuinely improve people's lives through our accessibility features, Google Assistant, digital wellbeing, Family Link, and more — but we can only do this if they are safe and secure enough to earn users' long term trust. This is Google Play Protect's charter and we're encouraged by this past year's advancements.

    Google Play Protect, a refresher

    Google Play Protect is the technology we use to ensure that any device shipping with the Google Play Store is secured against potentially harmful applications (PHA). It is made up of a giant backend scanning engine to aid our analysts in sourcing and vetting applications made available on the Play Store, and built-in protection that scans apps on users' devices, immobilizing PHA and warning users.

    This technology protects over 2 billion devices in the Android ecosystem every day.

    What's new

    On by default

    We strongly believe that security should be a built-in feature of every device, not something a user needs to find and enable. When security features function at their best, most users do not need to be aware of them. To this end, we are pleased to announce that Google Play Protect is now enabled by default to secure all new devices, right out of the box. The user is notified that Google Play Protect is running, and has the option to turn it off whenever desired.

    New and rare apps

    Android is deployed in many diverse ways across many different users. We know that the ecosystem would not be as powerful and vibrant as it is today without an equally diverse array of apps to choose from. But installing new apps, especially from unknown sources, can carry risk.

    Last year we launched a new feature that notifies users when they are installing new or rare apps that are rarely installed in the ecosystem. In these scenarios, the feature shows a warning, giving users pause to consider whether they want to trust this app, and advising them to take additional care and check the source of installation. Once Google has fully analyzed the app and determined that it is not harmful, the notification will no longer display. In 2018, this warning showed around 100,000 times per day

    Context is everything: warning users on launch

    It's easy to misunderstand alerts when presented out of context. We're trained to click through notifications without reading them and get back to what we were doing as quickly as possible. We know that providing timely and context-sensitive alerts to users is critical for them to be of value. We recently enabled a security feature first introduced in Android Oreo which warns users when they are about to launch a potentially harmful app on their device.

    This new warning dialog provides in-context information about which app the user is about to launch, why we think it may be harmful and what might happen if they open the app. We also provide clear guidance on what to do next. These in-context dialogs ensure users are protected even if they accidentally missed an alert.

    Auto-disabling apps

    Google Play Protect has long been able to disable the most harmful categories of apps on users devices automatically, providing robust protection where we believe harm will be done.

    In 2018, we extended this coverage to apps installed from Play that were later found to have violated Google Play's policies, e.g. on privacy, deceptive behavior or content. These apps have been suspended and removed from the Google Play Store.

    This does not remove the app from user device, but it does notify the user and prevents them from opening the app accidentally. The notification gives the option to remove the app entirely.

    Keeping the Android ecosystem secure is no easy task, but we firmly believe that Google Play Protect is an important security layer that's used to protect users devices and their data while maintaining the freedom, diversity and openness that makes Android, well, Android.

    Acknowledgements: This post leveraged contributions from Meghan Kelly and William Luh.

    February 26th 2019, 1:26 pm

    Expanding target API level requirements in 2019

    Android Developers Blog

    Posted by Edward Cunningham, Android Security & Privacy Team

    In a previous blog we described how API behavior changes advance the security and privacy protections of Android, and include user experience improvements that prevent apps from accidentally overusing resources like battery and memory.

    Since November 2018, all app updates on Google Play have been required to target API level 26 (Android 8.0) or higher. Thanks to the efforts of thousands of app developers, Android users now enjoy more apps using modern APIs than ever before, bringing significant security and privacy benefits. For example, during 2018 over 150,000 apps added support for runtime permissions, giving users granular control over the data they share.

    Today we're providing more information about the Google Play requirements for 2019, and announcing some changes that affect apps distributed via other stores.

    Google Play requirements for 2019

    In order to provide users with the best Android experience possible, the Google Play Console will continue to require that apps target a recent API level:

    Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Apps can still use any minSdkVersion, so there is no change to your ability to build apps for older Android versions.

    For a list of changes introduced in Android 9 Pie, check out our page on behavior changes for apps targeting API level 28+.

    Apps distributed via other stores

    Targeting a recent API level is valuable regardless of how an app is distributed. In China, major app stores from Huawei, OPPO, Vivo, Xiaomi, Baidu, Alibaba, and Tencent will be requiring that apps target API level 26 (Android 8.0) or higher in 2019. We expect many others to introduce similar requirements – an important step to improve the security of the app ecosystem.

    Over 95% of spyware we detect outside of the Play Store intentionally targets API level 22 or lower, avoiding runtime permissions even when installed on recent Android versions. To protect users from malware, and support this ecosystem initiative, Google Play Protect will warn users when they attempt to install APKs from any source that do not target a recent API level:

    These Play Protect warnings will show only if the app's targetSdkVersion is lower than the device API level. For example, a user with a device running Android 6.0 (Marshmallow) will be warned when installing any new APK that targets API level 22 or lower. Users with devices running Android 8.0 (Oreo) or higher will be warned when installing any new APK that targets API level 25 or lower.

    Prior to August, Play Protect will start showing these warnings on devices with Developer options enabled to give advance notice to developers of apps outside of the Play Store. To ensure compatibility across all Android versions, developers should make sure that new versions of any apps target API level 26+.

    Existing apps that have been released (via any distribution channel) and are not receiving updates will be unaffected – users will not be warned when installing them.

    Getting started

    For advice on how to change your app’s target API level, take a look at the migration guide and this talk from I/O 2018: Migrate your existing app to target Android Oreo and above.

    We're extremely grateful to the Android developers worldwide who have already updated their apps to deliver security improvements for their users. We look forward to making great progress together in 2019.

    February 21st 2019, 2:36 pm

    How we fought bad apps and malicious developers in 2018

    Android Developers Blog

    Posted by Andrew Ahn, Product Manager, Google Play

    Google Play is committed to providing a secure and safe platform for billions of Android users on their journey discovering and experiencing the apps they love and enjoy. To deliver against this commitment, we worked last year to improve our abuse detection technologies and systems, and significantly increased our team of product managers, engineers, policy experts, and operations leaders to fight against bad actors.

    In 2018, we introduced a series of new policies to protect users from new abuse trends, detected and removed malicious developers faster, and stopped more malicious apps from entering the Google Play Store than ever before. The number of rejected app submissions increased by more than 55 percent, and we increased app suspensions by more than 66 percent. These increases can be attributed to our continued efforts to tighten policies to reduce the number of harmful apps on the Play Store, as well as our investments in automated protections and human review processes that play critical roles in identifying and enforcing on bad apps.

    In addition to identifying and stopping bad apps from entering the Play Store, our Google Play Protect system now scans over 50 billion apps on users' devices each day to make sure apps installed on the device aren't behaving in harmful ways. With such protection, apps from Google Play are eight times less likely to harm a user's device than Android apps from other sources.

    Here are some areas we've been focusing on in the last year and that will continue to be a priority for us in 2019:

    Protecting User Privacy

    Protecting users' data and privacy is a critical factor in building user trust. We've long required developers to limit their device permission requests to what's necessary to provide the features of an app. Also, to help users understand how their data is being used, we've required developers to provide prominent disclosures about the collection and use of sensitive user data. Last year, we rejected or removed tens of thousands of apps that weren't in compliance with Play's policies related to user data and privacy.

    In October 2018, we announced a new policy restricting the use of the SMS and Call Log permissions to a limited number of cases, such as where an app has been selected as the user's default app for making calls or sending text messages. We've recently started to remove apps from Google Play that violate this policy. We plan to introduce additional policies for device permissions and user data throughout 2019.

    Developer integrity

    We find that over 80% of severe policy violations are conducted by repeat offenders and abusive developer networks. When malicious developers are banned, they often create new accounts or buy developer accounts on the black market in order to come back to Google Play. We've further enhanced our clustering and account matching technologies, and by combining these technologies with the expertise of our human reviewers, we've made it more difficult for spammy developer networks to gain installs by blocking their apps from being published in the first place.

    Harmful app contents and behaviors

    As mentioned in last year's blog post, we fought against hundreds of thousands of impersonators, apps with inappropriate content, and Potentially Harmful Applications (PHAs). In a continued fight against these types of apps, not only do we apply advanced machine learning models to spot suspicious apps, we also conduct static and dynamic analyses, intelligently use user engagement and feedback data, and leverage skilled human reviews, which have helped in finding more bad apps with higher accuracy and efficiency.

    Despite our enhanced and added layers of defense against bad apps, we know bad actors will continue to try to evade our systems by changing their tactics and cloaking bad behaviors. We will continue to enhance our capabilities to counter such adversarial behavior, and work relentlessly to provide our users with a secure and safe app store.

    How useful did you find this blog post?

    February 13th 2019, 1:18 pm

    An Update on Android Things

    Android Developers Blog

    Posted by Dave Smith, Developer Advocate for IoT

    Over the past year, Google has worked closely with partners to create consumer products powered by Android Things with the Google Assistant built-in. Given the successes we have seen with our partners in smart speakers and smart displays, we are refocusing Android Things as a platform for OEM partners to build devices in those categories moving forward. Therefore, support for production System on Modules (SoMs) based on NXP, Qualcomm, and MediaTek hardware will not be made available through the public developer platform at this time.

    Android Things continues to be a platform for experimenting with and building smart, connected devices using the Android Things SDK on top of popular hardware like the NXP i.MX7D and Raspberry Pi 3B. System images for these boards will remain available through the Android Things console where developers can create new builds and push app updates for up to 100 devices for non-commercial use.

    We remain dedicated to providing a managed platform for IoT devices, including turnkey hardware solutions. For developers looking to commercialize IoT products in 2019, check out Cloud IoT Core for secure device connectivity at scale and the upcoming Cloud IoT Edge runtime for a suite of managed edge computing services. For on-device machine learning applications, stay tuned for more details about our Edge TPU development boards.

    February 12th 2019, 2:00 pm

    Google releases source code of Santa Tracker for Android 2018

    Android Developers Blog

    Posted by Chris Banes, Chief Elf of Android Engineering

    Today, we pushed the source code for Google's Santa Tracker 2018 Android app at google/santa-tracker-android, including its 17 mini-games, Santa tracking feature, Wear app and more!

    Visually the app looks much the same this year, but underneath the hood the app has gone on a massive size reduction exercise to make the download from Google Play as small as possible. When a user downloads the app the initial download is now just 9.2MB, compared to last year's app which was 60MB. That's a 85% reduction! 🗜️

    Android App Bundle

    We achieved that reduction by migrating the app over to using an Android App Bundle. The main benefit is that Google Play can now serve dynamically optimized APKs to users' devices. Moreover, we were also able to separate out all of the games into their own dynamic feature modules, downloaded on demand. This is why you might have seen a progress bar when you first opened a game, we are actually downloading the game from Google Play before starting the game:

    The progress bar shown while a game is fetched from Google Play

    You can read more about our journey migrating over to App Bundle in a small blog series, starting with our 'Moving to Android App Bundle' post.

    Gboard stickers

    One of the new features we added this year was a Gboard sticker pack, allowing users to share stickers to their friends. You might even notice some of the characters from the games in the stickers!

    'Santa Dunk' is one of the 20 available stickers

    We use Firebase App Indexing to publish our stickers to the local index on the device, where the Gboard keyboard app picks them up, allowing the user to share them in apps. You can see the source code here.

    The sticker pack being used in a very important conversation

    Lots of code improvements

    Aside from the things mentioned above, we've also completed a number of code health improvements. We have increased the minimum SDK version to Lollipop (21), migrated from the Support Library to AndroidX, reduced the file size of our game assets by switching to modern formats, and lots of other small improvements! Phew 😅.

    Go explore the code

    If you're interested go checkout the code and let us know what you think. If you have any questions or issues, please let us know via the issue tracker.

    January 29th 2019, 1:04 pm

    Google Mobile Developer Day is coming to GDC 2019

    Android Developers Blog

    Posted by Kacey Fahey, Developer Marketing, Google Play

    We're excited to be part of the Game Developers Conference (GDC) 2019 in San Francisco. Join us on Monday, March 18th at the Google Mobile Developer Day, either in person or over live stream, for a full day of sessions covering tools and best practices to help build a successful mobile games business on Google Play. We'll focus on game quality, effective monetization and growth strategies, and how to create, connect, and scale with Google.

    This year's sessions are focused on tips and tools to help your mobile game business succeed. Come hear our latest announcements and industry trends, as well as learnings from industry peers. We will hold a more technical session in the second half of the day, where we'll share ways to optimize your mobile game's performance for the best possible player experience.

    Also, make sure to visit the Google booth from Wednesday March 20th until Friday March 22nd. Here, you will be able to interact with hands-on demos, attend talks in the theater, and get your questions answered by Google experts. We're bringing a big team and hope to see you there.

    Learn more about Google's activities throughout the week of GDC and sign up to stay informed. For those who can't make it in person, join the live stream starting at 10am PST on Monday, March 18th. These events are part of the official Game Developers Conference and require a pass to attend.

    How useful did you find this blog post?

    January 23rd 2019, 12:49 pm

    Grow your app business internationally through localization on Google Play

    Android Developers Blog

    Posted by Chris Yang, Program Manager, Translation Service

    It is not uncommon for developers to have the following concerns and thoughts when considering whether to localize their apps: "I just don't have the time!" "Translation is too expensive." "High-quality translation is just hard to find.'' Does this sound familiar?

    At Google, we consider translation a key component of making the world's information universally accessible and useful. This commitment extends not only to localizing our own products, but also to providing tools to help developers and translators more easily localize their apps.

    Introducing the Google Play App Translation Service

    Available in the Google Play Console, the Google Play App Translation Service simplifies localization of your app user interface strings, store listing, in-app product names, and universal apps campaign ads. Thousands of developers have already used this service to reach hundreds of millions of users worldwide.

    Here is an overview of some of the ways it can help:

    1. Quick and easy - Order in minutes and receive your translation in as little as two days.

    2. Professional and human - Get high-quality translations by real human translators.

    3. Value for money - Translate your app for as little as $0.07 per word.

    Ordering a Translation

    Find the Translation Service in the Google Play Console:

    When you're ready to translate, just select the languages to use for translation, choose a vendor, and place your order.

    Select languages to translate into.

    Choose what type of content you want to translate.

    Easily complete purchase of the service.

    Language recommendations

    You can also expand your global footprint with translation recommendations that can help increase installs. The recommendations can be found in the Google Play Console.

    The language recommendation feature is developed using machine learning and is based on your app's install history and market data.

    Did you know that you can reach almost 80% of internet users worldwide with only 10 languages. In particular, the Google Play opportunity in Russia and the Middle East continues to grow. Let us know once you have localized for these markets so we can consider featuring your app or game in the Now in Russian and Now in Arabic collections on the Play Store.

    Launching the translation

    Once you download the translation, you'll be ready to publish your newly translated app update on Google Play.

    Get started with the App Translation Service today and let us know what you think!

    How useful did you find this blog post?

    January 16th 2019, 4:27 pm

    Get your apps ready for the 64-bit requirement

    Android Developers Blog

    Posted by Vlad Radu, Product Manager, Play and Diana Wong, Product Manager, Android

    64-bit CPUs deliver faster, richer experiences for your users. Adding a 64-bit version of your app provides performance improvements, makes way for future innovation, and sets you up for devices with 64-bit only hardware.

    We want to help you get ready and know you need time to plan. We’ve supported 64-bit CPUs since Android 5.0 Lollipop and in 2017 we first announced that apps using native code must provide a 64-bit version (in addition to the 32-bit version). Today we’re providing more detailed information and timelines to make it as easy as possible to transition in 2019.

    The 64-bit requirement: what it means for developers

    Starting August 1, 2019:

    Starting August 1, 2021:

    The requirement does not apply to:

    We are not making changes to our policy on 32-bit support. Play will continue to deliver apps to 32-bit devices. This requirement means that apps with 32-bit native code will need to have an additional 64-bit version as well.

    Preparing for the 64-bit requirement

    We anticipate that for most developers, the move to 64-bit should be straightforward. Many apps are written entirely in non-native code (e.g. the Java programming language or Kotlin) and do not need code changes.

    All developers: Here is an overview of the steps you will need to take in order to become 64-bit compliant. For a more detailed outline of this process refer to our in-depth documentation.

    Inspect your APK or app bundle for native code. You can check for .so files using APK Analyzer. Identify whether they are built from your own code or are imported by an SDK or library that you are using. If you do not have any .so files in your APK, you are already 64-bit compliant.

    Enable 64-bit architectures and rebuild native code (.so files) imported by your own code. See the documentation for more details.

    Game developers: The three most used engines all currently support 64-bit (Unreal & Cocos2d since 2015, Unity since 2018). We understand that migrating a 3rd party game engine is an intensive process with long lead times.

    Since Unity only recently began providing 64-bit support in versions 2017.4 and 2018.2, we are granting an automatic extension to existing games using versions 5.6 or older until August 2021. Unity provides guides that can help you through the process of upgrading to a 64-bit compliant version.

    SDK and library owners: Update for 64-bit compliance as soon as possible to give app developers time to adapt, and let your developers know. Sign up and register your SDK to receive updates about the latest tools and information that can help you serve your customers.

    Going forward

    For those that already support 64-bit - thank you and great work! If you haven’t yet, we encourage you to begin any work for the 64-bit requirement as soon as possible. As we move closer to the deadline, we’ll be updating our developer documentation with more information on how to check if your app is compliant.

    We’re excited about the future that 64-bit CPUs bring in areas such as artificial intelligence, machine learning, and immersive mobile. Supporting 64-bit prepares the ecosystem for the innovation enabled by the advanced compute capabilities of 64-bit devices, and for future Android devices that only support 64-bit code.

    How useful did you find this blog post?

    January 15th 2019, 5:21 pm

    Reminder SMS/Call Log Policy Changes

    Android Developers Blog

    Posted by Paul Bankhead, Director, Product Management, Google Play

    TLDR; As previously announced and directly communicated to developers via email, we'll be removing apps from the Google Play Store that ask for SMS or Call Log permission. If you have not submitted a permissions declaration form and you're app is removed, see below for next steps.

    We take access to sensitive data and permissions very seriously. This is especially true with SMS and Call Log permissions, which were designed to allow users to pick their favorite dialer or messaging app, but have also been used to enable many other experiences that might not require that same level of access. In an effort to improve users' control over their data, last October we announced we would be restricting developer access to SMS and Call Log permissions.

    Our new policy is designed to ensure that apps asking for these permissions need full and ongoing access to the sensitive data in order to accomplish the app's primary use case, and that users will understand why this data would be required for the app to function.

    Developers whose apps used these permissions prior to our announcement were notified by email and given 90 days to either remove the permissions, or submit a permissions declaration form to enable further review.

    More about app reviews

    We take this review process seriously and understand it's a change for many developers. We apply the same criteria to all developers, including dozens of Google apps. We added to the list of approved use cases over the last few months as we evaluated feedback from developers.

    Our global teams carefully review each submission. During the review process, we consider the following:

    With this change, some uses cases will no longer be allowed. However, many of the apps we reviewed with one of these permissions can rely on narrower APIs, reducing the scope of access while accomplishing similar functionality. For example, developers using SMS for account verification can alternatively use the SMS Retriever API, and apps that want to share content using SMS can prepopulate a message and trigger the default SMS app to show via intents.

    Tens of thousands of developers have already resubmitted their apps to support the new policy or have submitted a form. Thank you! Developers who submitted a form received a compliance extension until March 9th.

    Next steps

    Over the next few weeks, we will be removing apps from the Play Store that ask for SMS or Call Log permission and have not submitted a permission declaration form. If your app is removed and you would like to have it republished, you can do one of the following in the Play Console:

    Keeping our overall Android ecosystem healthy is very important, and protection of user data is vital to the long term health of all developers. We know these changes have required significant work from you and we appreciate your efforts to create innovative experiences while protecting user's privacy.

    January 14th 2019, 7:23 pm

    Android Studio 3.3

    Android Developers Blog

    Posted by Jamal Eason, Product Manager

    We are excited to kick off the new year with a stable release of Android Studio 3.3 focused on refinement and quality. You can download it today from developer.android.com/studio. Based on the feedback from many of you, we have taken a step back from large features to focus on our quality fundamentals. The goal is to ensure Android Studio continues to help you stay productive in making great apps for Android. Since the last stable release, Android Studio 3.3 addresses over 200 user- reported bugs. This release also includes official support for Navigation Editor, improved incremental Java compilation when using annotation processors, C++ code lint inspections, an updated new project wizard, and usability fixes for each of the performance profilers. In addition, saving snapshots on exit for the Android emulator is 8x faster.

    Android Studio 3.3 kicks off the broader quality focus area for the year, which we call Project Marble. Announced at the Android Developer Summit in November 2018, Project Marble is the Android Studio team's focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid, along with refining and polishing the user-facing features that matter to you in your day-to-day app development workflows. In Project Marble, we are specifically looking at reducing the number of crashes, hangs, memory leaks, and user-impacting bugs. We are also investing in our measurement infrastructure to prevent these issues from occurring. Stay tuned for more updates and details as we progress on this initiative.

    This release of Android Studio is a solid milestone for the product. If you want the latest in feature refinement and quality, then download Android Studio 3.3 today on the stable release channel. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.3.

    Develop

    Navigation Editor

    Clang-Tidy Code Inspection Settings

    New Project Wizard

    Delete Unused Directories Dialogue

    IDE User Feedback

    Build

    Single-Variant Project Sync

    Test

    Android Pie à la mode: Security & Privacy

    Android Developers Blog

    Posted by Vikrant Nanda and René Mayrhofer, Android Security & Privacy Team

    There is no better time to talk about Android dessert releases than the holidays because who doesn't love dessert? And what is one of our favorite desserts during the holiday season? Well, pie of course.

    In all seriousness, pie is a great analogy because of how the various ingredients turn into multiple layers of goodness: right from the software crust on top to the hardware layer at the bottom. Read on for a summary of security and privacy features introduced in Android Pie this year.

    Strengthening Android

    Making Android more secure requires a combination of hardening the platform and advancing anti-exploitation techniques.

    Platform hardening

    With Android Pie, we updated File-Based Encryption to support external storage media (such as, expandable storage cards). We also introduced support for metadata encryption where hardware support is present. With filesystem metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based encryption (such as, directory layouts, file sizes, permissions, and creation/modification times).

    Android Pie also introduced a BiometricPrompt API that apps can use to provide biometric authentication dialogs (such as, fingerprint prompt) on a device in a modality-agnostic fashion. This functionality creates a standardized look, feel, and placement for the dialog. This kind of standardization gives users more confidence that they're authenticating against a trusted biometric credential checker.

    New protections and test cases for the Application Sandbox help ensure all non-privileged apps targeting Android Pie (and all future releases of Android) run in stronger SELinux sandboxes. By providing per-app cryptographic authentication to the sandbox, this protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data widely accessible.

    Anti-exploitation improvements

    With Android Pie, we expanded our compiler-based security mitigations, which instrument runtime operations to fail safely when undefined behavior occurs.

    Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of compiled code. In Android Pie, it has been enabled by default within the media frameworks and other security-critical components, such as for Near Field Communication (NFC) and Bluetooth protocols. We also implemented support for CFI in the Android common kernel, continuing our efforts to harden the kernel in previous Android releases.

    Integer Overflow Sanitization is a security technique used to mitigate memory corruption and information disclosure vulnerabilities caused by integer operations. We've expanded our use of Integer Overflow sanitizers by enabling their use in libraries where complex untrusted input is processed or where security vulnerabilities have been reported.

    Continued investment in hardware-backed security

    One of the highlights of Android Pie is Android Protected Confirmation, the first major mobile OS API that leverages a hardware-protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. Developers can use this API to display a trusted UI prompt to the user, requesting approval via a physical protected input (such as, a button on the device). The resulting cryptographically signed statement allows the relying party to reaffirm that the user would like to complete a sensitive transaction through their app.

    We also introduced support for a new Keystore type that provides stronger protection for private keys by leveraging tamper-resistant hardware with dedicated CPU, RAM, and flash memory. StrongBox Keymaster is an implementation of the Keymaster hardware abstraction layer (HAL) that resides in a hardware security module. This module is designed and required to have its own processor, secure storage, True Random Number Generator (TRNG), side-channel resistance, and tamper-resistant packaging.

    Other Keystore features (as part of Keymaster 4) include Keyguard-bound keys, Secure Key Import, 3DES support, and version binding. Keyguard-bound keys enable use restriction so as to protect sensitive information. Secure Key Import facilitates secure key use while protecting key material from the application or operating system. You can read more about these features in our recent blog post as well as the accompanying release notes.

    Enhancing user privacy

    User privacy has been boosted with several behavior changes, such as limiting the access background apps have to the camera, microphone, and device sensors. New permission rules and permission groups have been created for phone calls, phone state, and Wi-Fi scans, as well as restrictions around information retrieved from Wi-Fi scans. We have also added associated MAC address randomization, so that a device can use a different network address when connecting to a Wi-Fi network.

    On top of that, Android Pie added support for encrypting Android backups with the user's screen lock secret (that is, PIN, pattern, or password). By design, this means that an attacker would not be able to access a user's backed-up application data without specifically knowing their passcode. Auto backup for apps has been enhanced by providing developers a way to specify conditions under which their app's data is excluded from auto backup. For example, Android Pie introduces a new flag to determine whether a user's backup is client-side encrypted.

    As part of a larger effort to move all web traffic away from cleartext (unencrypted HTTP) and towards being secured with TLS (HTTPS), we changed the defaults for Network Security Configuration to block all cleartext traffic. We're protecting users with TLS by default, unless you explicitly opt-in to cleartext for specific domains. Android Pie also adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. This protects information about IP addresses visited from being sniffed or intercepted on the network level.

    We believe that the features described in this post advance the security and privacy posture of Android, but you don't have to take our word for it. Year after year our continued efforts are demonstrably resulting in better protection as evidenced by increasing exploit difficulty and independent mobile security ratings. Now go and enjoy some actual pie while we get back to preparing the next Android dessert release!

    Acknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

    December 20th 2018, 1:54 pm

    Wrapping up for 2018 with Google Play and Android

    Android Developers Blog

    Posted by Patricia Correa, Platforms & Ecosystems

    Earlier this year we highlighted some of Google Play's milestones and commitments in supporting the 1M+ developers on the Play Store, as well as those of you working on Android apps and games and looking to launch and grow your business on our platforms. We have been inspired and humbled by the achievements of app and game developers, building experiences that delight and help people everywhere, as some stories highlighted in #IMakeApps.

    We continue to focus on helping you grow thriving businesses and building tools and resources to help you reach and engage more users in more places, whilst ensuring a safe and secure ecosystem. Looking to 2019, we are excited about all the things to come and seeing more developers adopt new features and update to Android P.

    In the meantime let's share some of the 2018 highlights on Google Play and Android:

    Building for the future

    Along with Android P we have continued to help the Android developer ecosystem, launching Android Jetpack, the latest Android Studio, and Kotlin support. Developers are also now able to add rich and dynamic UI templates with Slices in places such as Google Search and Assistant, APIs for new screens support, and much more. Discover the latest from Android 9, API Level 28.

    Smaller apps have higher conversion rates and our research shows that a large app size is a key driver of uninstalls. At I/O we launched a new publishing format, the Android App Bundle, helping developers to deliver smaller and more efficient apps with a simplified release process, and with features on demand - saving on average 35% in download size! On devices using Android M and above, app bundles can reduce app size even further, by automatically supporting uncompressed native libraries, thereby eliminating duplication on devices.

    You can build app bundles in the Android Studio 3.2 stable release and in Unity 2018.3 beta, and upload larger bundles with installed APK sizes of up to 500MB without using expansion files, through an early access feature soon to be available to all developers.

    Richer experiences and discovery

    Discovery of your apps and games is important, so we launched Google Play Instant and increased the size limit to 10MB to enable TRY NOW on the Play Store, and removed the URL requirement for Instant apps. Android Studio 3.3 beta release, lets you publish a single app bundle and classify it or a particular module to be instant enabled (without maintaining separate code).

    For game developers, Unity introduced the Google Play Instant plug-in and instant app support is built into the new Cocos Creator. Our app pre-registration program, has seen nearly 250 million app pre-registrations, helping drive app downloads through richer discovery.

    Optimizing for quality and performance

    Android vitals are now more actionable, with a dashboard highlighting core vitals, peer benchmarks, start-up time and permission denials vitals, anomaly detection and alerts, and linking pre-launch reports - all so that you can better optimize and prioritize issues for improved quality and performance.

    There are more opportunities to get feedback and fix issues before launch. The Google Play Console expanded the functionality of automated device testing with a pre-launch report for games, and the launch of the internal and closed test tracks lets you push your app to up to 100 internal testers, before releasing them to production.

    Insights for your business, now and in the long term

    Metrics are critical to optimize your business and we've added new customizable tools in the Play Console, with downloadable reports to help you evaluate core metrics. Including cumulative data, 30-day rolling averages, and roll-ups for different time periods to better match the cadence of your business.

    You can now configure the statistics report to show how your instant apps are performing, analyze different dimensions and identify how many install the final app on their device. The acquisition report shows users discovery journey through to conversion - with average revenue per user and retention benchmarks against similar apps. You can also find the best performing search terms for your store listing with organic breakdown - helping to optimize efforts to grow and retain a valuable audience.

    Increasingly developers are adopting subscriptions as their core monetization model. The dedicated new subscriptions center means you can easily change subscription prices, offer partial refunds for in-app products and subscriptions, and also make plan changes in Play Billing Library version 1.2. Learn how to keep subscribers engaged; users can pause plans, giving you more control with order management and the cancellation survey.

    Discover how to use all the new features and best practices on the Academy for App Success, our interactive free e-learning platform, offering bite-sized courses that help you make the most of Play Console and improve your app quality.

    Make sure you follow @googleplaydev and sign up to our newsletter to stay ahead of all our updates in 2019! We hope these features and tools will enable us to continue a successful partnership with you in the New Year - follow our countdown for a daily highlight. From all of us at Google Play - happy holidays.

    How useful did you find this blog post?

    December 18th 2018, 1:46 pm

    In reviews we trust — Making Google Play ratings and reviews more trustworthy

    Android Developers Blog

    Posted by Fei Ye, Software Engineer and Kazushi Nagayama, Ninja Spamologist

    Google Play ratings and reviews are extremely important in helping users decide which apps to install. Unfortunately, fake and misleading reviews can undermine users' trust in those ratings. User trust is a top priority for us at Google Play, and we are continuously working to make sure that the ratings and reviews shown in our store are not being manipulated.

    There are various ways in which ratings and reviews may violate our developer guidelines:

    When we see these, we take action on the app itself, as well as the review or rating in question.

    In 2018, the Google Play Trust & Safety teams deployed a system that combines human intelligence with machine learning to detect and enforce policy violations in ratings and reviews. A team of engineers and analysts closely monitor and study suspicious activities in Play's ratings and reviews, and improve the model's precision and recall on a regular basis. We also regularly ask skilled reviewers to check the decisions made by our models for quality assurance.

    It's a big job. To give you a sense of the volume we manage, here are some numbers from a recent week:

    Our team can do a lot, but we need your help to keep Google Play a safe and trusted place for apps and games.

    If you're a developer, you can help us by doing the following:

    Example of a violation: incentivized ratings is not allowed

    If you're a user, you can follow these simple guidelines as well:

    Finally, if you find bad ratings and reviews on Google Play, help us improve by sending your feedback! Users can mark the review as "Spam" and developers can submit feedback through the Play Console.

    Tooltip to flag the review as Spam.

    Thanks for helping us keep Google Play a safe and trusted place to discover some of the world's best apps and games.

    How useful did you find this blog post?

    December 17th 2018, 3:44 pm

    More visibility into the Android Open Source Project

    Android Developers Blog

    Posted by Jeff Bailey, AOSP Team

    AOSP has been around for more than 10 years and visibility into the project has often been restricted to the Android Team and Partners. A lot of that has been rooted in business needs: we want to have fun things to show off at launches and the code wasn't factored in a way that let us do more in the open.

    At the Android Developer Summit last month, we demoed GSI running on a number of partner devices, enabled through Project Treble. The work done to make that happen has provided the separation needed, and has also made it easier to work with our partners to upstream fixes for Android into AOSP. As a result of this, more than 40% of the commits to our git repository came in through our open source tree in Q3 of this year.

    Publishing Android's Continuous Integration Dashboard

    In order to support the developers working directly in AOSP and our partners upstreaming changes, we have enabled more than 8000 tests in presubmit -- tests that are run before the code is checked in -- and are working to add other continuous testing like the Compatibility Test Suite which ensures that our AOSP trees are in a continuously releasable state. Today we are excited to open this up for you through https://ci.android.com/.

    On this dashboard, across the top are the targets that we are building, down the left are the revisions. As we add more targets (such as GSI), they will appear here. Each square in the table provides access to the build artifacts. An anchor on the left provides a permanent URL for that revision. Find out more at https://source.android.com/setup/build/dashboard.

    Our DroidCop team (similar to Chromium's Tree Sherrifs) watches this dashboard and works with developers to ensure the health of the tree. This is just the start for us and we are building on this tool to add more in the coming months.

    I'd like to thank the Android Engineering Productivity Team for embracing this and I'm excited for us to take this step! I'd love to hear how you use this. Contact me at @jeffbailey-aosp on Twitter, jeffbailey+aosp@google.com, or tag /u/jeffbailey in a post to reddit.com/r/androiddev.

    December 14th 2018, 1:08 pm
    Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا