Android Developers Blog

Android Studio 3.4

2019-04-17T11:19:00.000-07:00

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 - We have heard from you that asset management and navigation can be clunky and tedious in Android Studio, especially as your app grows in complexity. The resource manager is a new tool to visualize the drawables, colors, and layouts across your app project in a consolidated view. In addition to visualization, the panel supports drag & drop bulk asset import, and, by popular request, bulk SVG to VectorDrawable conversion. These accelerators will hopefully help manage assets you get from a design team, or simply help you have a more organized view of project assets. Learn more.

Resource Manager

Import Intentions - As you work with new Jetpack and Firebase libraries, Android Studio 3.4 will recognize common classes in these libraries and suggest, via code intentions, adding the required import statement and library dependency to your Gradle project files. This optimization can be a time saver since it keeps you in the context of your code. Moreover, since Jetpack libraries are modularized, Android Studio can find the exact library or minimum set of libraries required to use a new Jetpack class.

Jetpack Import Intentions

Layout Editor Properties Panel - To improve product refinement and polish we refreshed the Layout Editor Properties panel. Now we just have one single pane, with collapsible sections for properties. Additionally, errors and warnings have their own highlight color, we have a resource binding control for each property, and we have an updated color picker.

Layout Editor Properties Panel

IntelliJ Platform Update - Android Studio 3.4 includes Intellij 2018.3.4. This update has a wide range of improvements from support for multi-line TODOs to an updated search everywhere feature. Learn more.

Build

Project Structure Dialog - A long standing request from many developers is to have a user interface front end to manage Gradle project files. We have more plans for this area, but Android Studio 3.4 includes the next phase of improvement in the Product Structure Dialog (PSD). The new PSD allows you to see and add dependencies to your project at a module level. Additionally, the new PSD displays build variables, suggestions to improve your build file configuration, and more! Although the latest Gradle plugin v3.4 also has improvements, you do not have to upgrade your Gradle plugin version number to take advantage of the new PSD. Learn more.

Project Structure Dialogue

R8 by Default - Almost two years ago we previewed R8 as the replacement for Proguard. R8 code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space. Additionally, in comparison to Proguard, R8 combines shrinking, desugaring and dexing operations into one step, which ends up to be a more efficient approach for Android apps. After additional validation and testing last year, R8 is now the default code shinker for new projects created with Android Studio 3.4 and for projects using Android Gradle plugin 3.4 and higher. Learn more.

Test

Android Emulator Skin updates & Android Q Beta Emulator System Image - Inside of Android Studio 3.4 we released the latest Google Pixel 3 & Google Pixel 3 XL device skins. Also with this release, you can also download Android Q Beta emulator system images for app testing on Android Q. Please note that we do recommend running the canary version of Android Studio and the emulator to get the latest compatibility changes during the Android Q Beta program.

Android Emulator - Pixel 3 XL Emulator Skin

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

Develop

Resource Manager
Import Intentions
Layout Editor Properties Panel
IntelliJ 2018.3.4 Platform Update

Build

Project Structure Dialog
R8 by Default

Test

Emulator Device Skins
Android Q Beta Emulator System Image Support

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.

Indie Games Accelerator - Applications open for class of 2019

2019-04-16T23:00:00.000-07:00

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?

★ ★ ★ ★ ★

Improving the update process with your feedback

2019-04-15T11:16:00.000-07:00

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:

Permission declaration form. Some of you felt that the use case descriptions in our permissions declaration form were unclear and hard to complete correctly.
Timeliness in review and appeals process. For some of you, it took too long to get answers on whether apps met policy requirements. Others felt that the process for appealing a decision was too long and cumbersome.
Getting information from a ‘real human’ at Google. Some of you came away with the impression that our decisions were automated, without human involvement. And others felt that it was hard to reach a person who could help provide details about our policy decisions and about new use cases proposed by developers.

In response, we are improving and clarifying the process, including:

More detailed communication. We are revising the emails we send for policy rejections and appeals to better explain with more details, including why a decision was made, how you can modify your app to comply, and how to appeal.
Evaluations and appeals. We will include appeal instructions in all enforcement emails and the appeal form with details can also be found in our Help Center. We will also be reviewing and improving our appeals process.
Growing the team. Humans, not bots, already review every sensitive decision but we are improving our communication so responses are more personalized -- and we are expanding our team to help accelerate the appeals process.

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?

★ ★ ★ ★ ★

Optimize your subscriptions with new insights in the Play Console

2019-04-11T10:00:00.000-07:00

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?

★ ★ ★ ★ ★

A simpler experience for instant apps

2019-04-09T11:33:00.000-07:00

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:

multiple non-base feature modules, which contained the instant app entry points,
an application module, which contained the code and activities required only for your main installed application, and
an instant app module, which represented the instant app and mapped its dependencies.

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.

ML Kit expands into NLP with Language Identification and Smart Reply

2019-04-05T10:00:00.000-07:00

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 Kotlin in this example):

val smartReply = FirebaseNaturalLanguage.getInstance().smartReply
smartReply.suggestReplies(conversation)
        .addOnSuccessListener { result ->
            if (result.status == SmartReplySuggestionResult.STATUS_NOT_SUPPORTED_LANGUAGE) {
                // The conversation's language isn't supported, so the
                // the result doesn't contain any suggestions.
            } else if (result.status == SmartReplySuggestionResult.STATUS_SUCCESS) {
                // Task completed successfully
                // ...
            }
        }
        .addOnFailureListener {
            // Task failed with an exception
            // ...
        }

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 110 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 Kotlin in this example):

val languageIdentification =
    FirebaseNaturalLanguage.getInstance().languageIdentification
languageIdentification
    .identifyLanguage("¿Cómo estás?")
    .addOnSuccessListener { identifiedLanguage ->
        Log.i(TAG, "Identified language: $identifiedLanguage")
    }
    .addOnFailureListener { e ->
        Log.e(TAG, "Language identification error", e)
    }

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.

Android Q Beta 2 update

2019-04-03T10:05:00.000-07:00

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. For example, you might see issues with apps that access photos, videos, media, or other files stored on your device, such as when browsing or sharing in social media apps.

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. Here's a video highlighting many of the changes for developers in Beta 1 and Beta 2. 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.

Improving app performance with ART optimizing profiles in the cloud

2019-04-01T10:09:00.000-07:00

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:

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

Classes loaded during startup
Hot methods that the runtime deemed worthy of optimizations
The layout of the code (e.g. code that executes during startup or post-startup)

Using this information, we use a variety of optimization techniques, out of which the following three provide most of the benefits:

App Images: We use the start up classes to build a pre-populated heap where the classes are pre-initialized (called an app image). When the application starts, we map the image directly into memory so that all the startup classes are readily available.
- The benefit here is that the app's execution saves cycles since it doesn't need to do the work again, leading to a faster startup time.

Code pre-compilation: We pre-compile all the hot code. When the apps execute, the most important parts of the code are already optimized and ready to be natively executed. The app no longer needs to wait for the JIT compiler to kick in.

The benefit is that the code is mapped as clean memory (compared to the JIT dirty memory) which improves the overall memory efficiency. The clean memory can be released by the kernel when under memory pressure while the dirty memory cannot, lessening the chances that the kernel will kill the app.

More efficient dex layout: We reorganize the dex bytecode based on method information the profile exposes. The dex bytecode layout will look like: [startup code, post startup code, the rest of non profiled code].
- The benefit of doing this is a much higher efficiency of loading the dex byte code in memory: The memory pages have a better occupancy, and since everything is together, we need to load less and we can do less I/O.

Improvements & Observations

We rolled out profiles in the cloud to all apps on the playstore at the end of last year.

More than 30,000 apps have shown improvement
On average the cold startup is 15% faster across a variety of devices
- with many top apps getting 20%+ (e.g. Youtube) or even 30% (e.g. Google Search) on selected devices.
90%+ of the app installs on Android Pie get profiles
Little increase in install time for the extra optimization
Available to all Pie devices.

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.

AOSP Application Updates

2019-03-28T11:00:00.000-07:00

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:

to provide a usable set of applications for someone building an Android device from our AOSP
to serve as a demonstration for the nascent Android app developer community, showcasing how they should build some of these applications
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.

Changes to the Google Play Developer API

2019-03-26T16:27:00.000-07:00

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?

★ ★ ★ ★ ★

The latest Android App Bundle updates including the additional languages API

2019-03-21T14:54:00.000-07:00

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:

A new additional languages install API, which supports in-app language pickers
A streamlined publishing process for instant-enabled app bundles
A new enrollment option for app signing by Google Play
The ability to permanently uninstall dynamic feature modules that are included in your app's initial install

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.

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?

★ ★ ★ ★ ★

Google Mobile Developer Day at Game Developers Conference 2019

2019-03-18T10:30:00.000-07:00

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.

Watch the session recordings and product updates shared during Google Mobile Developer Day.

How useful did you find this blog post?

★ ★ ★ ★ ★

Introducing a new Google Play app and game icon specification

2019-03-15T10:05:00.000-07:00

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:

Update your icon to the new specification.
Upload your icon to Play Console.
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?

Icon assets will remain the same size (512 x 512), but transparent backgrounds will no longer be allowed.
Google Play on Android and Chrome OS will dynamically apply rounded corners and drop shadows to icons. The corner radius will be 20% of the icon size, to ensure consistency at different sizes.
There will be no changes to Google Play on other form factors (TV, Wear, Auto).
Note this does not affect your APK launcher icons for Android.

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?
★ ★ ★ ★ ★

Giving users more control over their location data

2019-03-14T12:03:00.000-07:00

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:

"All the time" - this means an app can access location at any time
"While in use" - this means an app can access location only while the app is being used
"Deny" - this means an app cannot access location

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.

Android Jetpack Navigation Stable Release

2019-03-14T10:00:00.000-07:00

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:

Handle basic user actions like Up & Back buttons so that they work consistently across devices and screens.
Allow users to land on any part of your app via deep links and build consistent and predictable navigation within your app.
Improve type safety of arguments passed from one screen to another, decreasing the chances of runtime crashes as users navigate in your app.
Add navigation experiences like navigation drawers and bottom navigation consistent with the Material Design guidelines.
Visualize and manipulate your navigation flows easily with the Navigation Editor in Android Studio 3.3

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:

For issues related to the Navigation Editor: Issue Tracker
For all other Navigation-related issues: Issue Tracker

Introducing Android Q Beta

2019-03-13T12:34:00.000-07:00

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, WPA3 and Enhanced Open, 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.

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.

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.

Grow your indie game with Google Play

2019-03-12T23:00:00.000-07:00

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:

A paid trip and accommodation to the final event in your region to showcase your game.
Promotion on the Google Play Store.
Promotion on Android and Google Play marketing channels.
Dedicated consultations with the Google Play team.
Google hardware.
And more...

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?

★ ★ ★ ★ ★

Supplement your earnings with rewarded products

2019-03-06T10:00:00.000-08:00

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?

★ ★ ★ ★ ★

Android Jetpack WorkManager Stable Release

2019-03-05T10:00:00.000-08:00

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:

Lets you set constraints, such as network status or charge state, on when the task runs
Supports asynchronous one-off and periodic tasks
Supports chained tasks with input & output
Ensures task execution, even if the app or device restarts
Supports Android 4.0+ (API 14+)

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 doWork(): Result {
    //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()
                .setConstraints(constraints).build()

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.

Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerability at a time

2019-02-28T10:13:00.000-08:00

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:

SQL Injection
File-based Cross-Site Scripting
Cross-App Scripting
Leaked Third-Party Credentials
Scheme Hijacking
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.

Google Play Protect in 2018: New updates to keep Android users secure

2019-02-26T10:26:00.000-08:00

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.

Expanding target API level requirements in 2019

2019-02-21T11:21:00.000-08:00

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:

August 2019: New apps are required to target API level 28 (Android 9) or higher.
November 2019: Updates to existing apps are required to target API level 28 or higher.

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:

August 2019: New apps will receive warnings during installation if they do not target API level 26 or higher.
November 2019: New versions of existing apps will receive warnings during installation if they do not target API level 26 or higher.
2020 onwards: The target API level requirement will advance annually.

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.

How we fought bad apps and malicious developers in 2018

2019-02-13T10:01:00.000-08:00

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?

★ ★ ★ ★ ★

An Update on Android Things

2019-02-12T11:00:00.000-08:00

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.

Google releases source code of Santa Tracker for Android 2018

2019-01-29T10:00:00.000-08:00

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.