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

Developer tips and guides: Common policy violations and how you can avoid them

Android Developers Blog

By Andrew Ahn, Product Manager, Google Play App Safety

At Google Play, we want to foster an ecosystem of safe, engaging, useful, and entertaining apps used and loved by billions of Android users worldwide. That’s why we regularly update and revise our Google Play Developer Policies and Developer Distribution Agreement, detailing the boundaries of app content and functionalities allowed on the platform, as well as providing latest guidance on how developers can promote and monetize apps.

In recent efforts in analyzing apps for policy compliance on Google Play we identified some common mistakes and violations that developers make, and we’re sharing these with the developer community with tips and guides on how to avoid them, mitigating the risks of apps and developer accounts being suspended for violating our policies.

Links that take users back to other apps on the Play Store

One of the most common mistakes we see are apps that have buttons and menus that link out to the Play Store -- either to apps by the same developer, or other apps that may be affiliated with the developer, but not being clear that these are ads or promotional links. Without this clarity, apps may get enforced for having deceptive / disguised ads. One of the ways to avoid such mistakes is by explicitly calling these out by labeling the buttons and links as ‘More Apps’, ‘More Games’, ‘Explore’, ‘Check out our other apps’, etc.

Example of app content that link out to app listing on Play

Spammy app descriptions

Another mistake we frequently observe is where developers ‘stuff’ keywords in the app description in hope for better discoverability and ranking against certain keywords and phrases. Text blocks or lists that contain repetitive or unrelated keywords or references violate our Store Listing and Promotion policy. Writing a clear app description intended and optimized for user’s readability and understanding is one of the best ways to avoid this violation.

Watch this video to learn how to avoid spammy store listings and efforts to artificially boost app visibility.

Abandoned and broken apps

There are apps that have been published by the developers a long time ago, and are no longer being maintained. Abandoned and unmaintained apps often create user experience issues -- broken app functionality, for example. Not only are such apps at risk of getting a low star rating and negative user reviews, they will also be flagged as violating the minimum functionality policy. To mitigate the negative impact to the developer reputation and app enforcement, consider unpublishing such apps from the Play Store. Note the updated unpublish action won’t affect existing users who already installed the app, and developers can always choose to re-publish them after addressing the broken experiences.

Example of an abandoned app that provides a broken app experience

Take the ‘Minimum and Broken Functionality Spam’ course on Play Academy



Apps vs. Webview

Lastly, we observe a large volume of app submissions that are just webviews of existing websites. Most of these apps are submitted with a primary purpose of driving traffic rather than providing engaging app experiences to Android users. Such apps are considered webview spam, and are removed from Play. Instead, consider thinking through what users can do or do better with the app than in a web experience and implement relevant features and functionalities that enrich the user experience.

Example of a webview without any app functionality

Take the ‘Webview Spam’ course on Play Academy



While the above are one of the most frequent mistakes, make sure to stay up to date with the latest policies by visiting the Play Developer Policy Center. Check out Google Play Academy’s Policy training, including our new Spam courses, and watch our Play PolicyBytes videos to learn more about recent policy updates.

October 16th 2020, 1:11 pm

Introducing the Android for Cars App Library

Android Developers Blog

Posted by Eric Bahna, Product Manager

In August, we announced plans to expand Android Auto’s app ecosystem to enable new navigation, parking, and electric vehicle charging apps. We’ve been hard at work collaborating with our early access partners to test and refine the Android for Cars App Library. Today, we’re releasing the library into an open beta, for any developer to use. This means you’ll now be able to design, develop, and test your navigation, parking or charging app on Android Auto. We’re looking forward to enabling Google Play Store publishing for your beta apps in the coming months.

Three of our early access partners: ChargePoint, SpotHero, and Sygic

The design phase is the time to familiarize yourself with our design guidelines and app quality guidelines. Driver safety is core to our mission and we want to help you optimize your app for the car.

When it comes time to build your app, our new library will hopefully make development easy. Get started with the developer guide and please give us feedback via our public issue tracker.

In the testing phase, see your app come alive on the Desktop Head Unit (DHU), our emulator that lets you simulate a car infotainment display. The DHU now supports multiple screen sizes, displaying information in the instrument cluster, and simulating vehicles with touchpad input.

The DHU simulating an instrument cluster, a widescreen head unit, and a touchpad

You can get started with the Android for Cars App Library here. We’re excited to see what you build next!

October 15th 2020, 3:02 pm

Optimize your app publishing process with new Google Play Console features

Android Developers Blog

Steve Suppe, Product Manager, Google Play

Publishing your app or game is one of the most important moments in your app’s lifecycle. You want everything to go smoothly, from making sure the production release is stable, to getting test releases out quickly, to getting your marketing message just right.

That’s why visibility is key. Knowing when your app is in review, when it’s been approved, and when it can go live on Google Play helps you set your own schedule.

Now, with two new features in the new Google Play Console, you can do just that. The Publishing overview page helps you better understand your publishing process and Managed publishing gives you better control of when your app updates go live on Google Play. When the new Play Console rolls out to everyone starting November 2, these features will be the recommended way to control your release timing, so let’s take a closer look.

Publishing overview

The new Publishing overview page displays all your recent changes to your releases, store listings, and more, including those that are currently being reviewed or processed by Google Play. For those of you with larger teams, this means you can now coordinate all your changes in one place and publish everything at the same time.

Unlike the developer activity log, the Publishing overview only shows changes that will be visible on Google Play, or what you’ve told us about how we should consider and review your app.

The “Changes in review” section lets you quickly see changes
that have not been published yet.

These changes are organized by the type of change or release track so it’s easy to understand at a glance.

Managed publishing

Many of you may be familiar with Timed publishing in the old Play Console. In the new Play Console, we’ve replaced Timed publishing with Managed publishing, to give you a clearer and more predictable publishing experience.


When you enable Managed publishing, approved changes will only go live when you decide instead of automatically after review and processing. This allows you to submit changes long before your intended release date, giving yourself time to review or make changes without sacrificing control over your publishing date.

See which changes have been reviewed and approved

When Managed publishing is on, the Publishing overview page contains two sections: one that shows which changes have been approved and are ready to publish, and another that shows changes that are still in review.

We’ve also made some improvements that many of you have been asking for:

See if Managed publishing is turned in the left-hand navigation menu

Soon, you’ll be able to see the Managed publishing icon in the left-hand nav next to Publishing overview. This way, you can tell Managed publishing is on from anywhere in the Play Console.

To learn more about publishing with the new Play Console, including scenarios when these features would be most useful, check out this course from Play Academy. And if you haven’t already, update to the new Play Console at play.google.com/console and give Managed publishing a try.

How useful did you find this blog post?

October 14th 2020, 9:46 am

Android Studio 4.1

Android Developers Blog

Posted by Scott Swarthout, Product Manager

Today, we’re excited to release the stable version of Android Studio 4.1, with a set of features addressing common editing, debugging, and optimization use cases. A major theme for this release was helping you be more productive while using Android Jetpack libraries, Android’s suite of libraries to help developers follow best practices and write code faster. Based on your feedback we made a number of improvements to the code editing experience with IDE integrations for popular Android libraries.

Some highlights of Android Studio 4.1 include a new Database Inspector for querying your app’s database, support for navigating projects that use Dagger or Hilt for dependency injection, and better support for on-device machine learning with support for TensorFlow Lite models in Android projects. We’ve also made updates to Apply Changes to make deployment faster. Based on your feedback, we’ve made several changes to help game developers with a new native memory profiler and standalone profiling tools.

Product quality continues to be a major focus for the team, and we’ve been hard at work tracking down bugs and performance issues. We’ve heard from many developers that they liked the focus on better performance and reliability, so we’re happy to report that during this release cycle we’ve fixed 2,370 bugs and closed 275 public issues. We stay committed to maintaining high quality since we know that is key to your developer productivity.

Thank you to those who gave your early feedback in preview releases. Your feedback helped us iterate and improve features in Android Studio 4.1. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 4.1 is ready to download for you to get started.

Below is a full list of new features in Android Studio 4.1, organized by key developer flows.

Design

Material Design Components updates

Android Studio templates in the create New Project dialog now use Material Design Components (MDC) and conform to updated guidance for themes and styles by default. These changes will make it easier to use recommended material styling patterns and support modern UI features like dark themes.

Material Design Components updates in Project Templates

Updates include:

Develop

Database Inspector

We wanted to make it easier to inspect, query, and modify your app's databases using the new Database Inspector. To get started, deploy your app to a device running API level 26 or higher and select View > Tool Windows > Database Inspector from the menu bar. Whether your app uses the Jetpack Room library or the Android platform version of SQLite directly, you can now easily inspect databases and tables in your running app or run custom queries.

Because Android Studio maintains a live connection while you’re inspecting your app, you can also modify values using the Database Inspector and see those changes in your running app. If you use the Room persistence library, Android Studio also places run buttons next to each query in the code editor to help you quickly run queries you define in your @Query annotations. Learn more

Inspect, query, and modify your app’s databases with the Database Inspector

Run Android Emulator directly in Android Studio

You can now run the Android Emulator directly in Android Studio. Use this feature to conserve screen real estate, to navigate quickly between the emulator and the editor window using hotkeys, and to organize your IDE and emulator workflow in a single application window. You can manage snapshots and common emulator actions like rotating and taking screenshots from within Studio, but access to the full set of options still requires running the stable emulator. You can opt-in to use this feature by going to File → SettingsToolsEmulator Launch in Tool Window.

Run the Android Emulator inside of Android Studio

Dagger Navigation Support

Dagger is a popular library for dependency injection on Android. Android Studio makes it easier to navigate between your Dagger-related code by providing new gutter actions and extending support in the Find Usages window. For example, clicking on the gutter action next to a method that consumes a given type navigates you to the provider of that type. Conversely, clicking on the gutter action navigates you to where a type is used as a dependency. Android Studio also supports navigation actions for dependencies defined with the Jetpack Hilt library. Learn more.

Navigate between Dagger-related code with gutter actions

Use TensorFlow Lite models

Android developers are using machine learning to create innovative and helpful experiences. TensorFlow Lite is a popular library for writing mobile machine learning models, and we wanted to make it easier to import these models into Android apps. Similar to view binding, Android Studio generates easy-to-use classes so you can run your model with less code and better type safety. The current implementation of ML Model Binding supports image classification and style transfer models, provided they are enhanced with metadata.

To see the details for an imported model and get instructions on how to use it in your app, double-click the .tflite model file in your project to open the model viewer page. Learn more.

View TensorFlow Lite model metadata in Android Studio 4.1

Build & Test

Android Emulator - Foldable Hinge Support

Android Studio

In addition to recently adding 5G cellular testing support, we’ve added support for foldables in the Android emulator. With Android emulator 30.0.26 and above, you can configure foldable devices with a variety of fold designs and configurations. When a foldable device is configured, the emulator will publish hinge angle sensor updates and posture changes, so you can test how your app responds to these form factors. See the Developing for Android 11 with the Android Emulator blogpost to read more.

Apply Changes updates

Faster builds help developers make changes to their app more easily and quickly. To help you be more productive as you iterate on your app, we've made multiple enhancements to Apply Changes for devices running Android 11 or higher.

We've invested heavily in optimizing your iteration speed by developing a method to deploy and persist changes on a device without installing the application. After an initial deploy, subsequent deploys to Android 11 devices using either Apply Code Changes or Apply Changes and Restart Activity are now significantly faster. We’ve also added support for additional code changes in Apply Changes. Now if you add a method, you can deploy those changes to a running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.

Export C/C++ dependencies from AARs

Android Gradle Plugin 4.0 added the ability to import Prefab packages in AAR dependencies. We wanted to extend the capability of this feature to support sharing native libraries as well. AGP version 4.1 enables exporting libraries from your external native build in an AAR for an Android Library project. To export your native libraries, add the following to the android block of your library project's build.gradle file:

buildFeatures {
    prefabPublishing true
}

prefab {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/include"
    }
}

Symbolication for native crash reports

When a crash or ANR occurs in native code, the system produces a stack trace, which is a snapshot of the sequence of nested functions called in your program up to the moment it crashed. These snapshots can help you to identify and fix any problems in the source, but they must first be symbolicated to translate the machine addresses back into human-readable function names.

If your app or game is developed using native code, like C++, you can now upload debug symbols files to the Play Console for each version of your app. The Play Console uses these debug symbols files to symbolicate your app's stack traces, making it easier to analyze crashes and ANRs. To include debug symbols in your app bundle, add the following line to your project’s build.gradle file:

android.buildTypes.release.ndk.debugSymbolLevel = 'SYMBOL_TABLE'

Optimize

System Trace UI improvements

In Android Studio 4.1 we’ve overhauled System Trace, an optimization tool that gives you a real-time look at how your app is using system resources. We made it easier to select a trace with box selection mode, added a new analysis tab, and added more frame rendering data to help you investigate rendering issues in your app’s UI. Learn more.

Box selection: In the Threads section, you can now drag your mouse to perform a box selection of a rectangular area, which you can zoom into by clicking the Zoom to Selection button on the top right (or use the M keyboard shortcut). When you drag and drop similar threads next to each other, you can select across multiple threads to inspect all of them at once.

Use box selection to more easily select traces.

Summary tab: The new Summary tab in the Analysis panel displays:

View aggregated statistics in the Summary tab

Display data: In the Display section, new timelines for SurfaceFlinger and VSYNC help you investigate rendering issues in your app's UI.

Standalone profilers

It's now possible to access the Android Studio Profilers in a separate window from the primary Android Studio window. This is useful when optimizing Android games built with other tools like Unity or Visual Studio.

To run the standalone profilers, do the following:

  1. Make sure the profilers in Android Studio are not already running on your system.
  2. Go to the installation directory and navigate to the bin directory:

Windows/Linux: <studio-installation-folder>\bin

macOS: <studio-installation-folder>/Contents/bin

  1. Depending on your OS, run profiler.exe or profiler.sh

The standalone profiler will allow you to connect to the Android emulator or any connected devices.

Optimize your app with the Standalone Android Studio Profilers

Native Memory Profiler

Tracking native memory usage is important for game developers and other developers using C++ to understand how to optimize their app’s memory consumption. The Android Studio Memory Profiler now includes a Native Memory Profiler for apps deployed to physical devices running Android 10 or later. The Native Memory Profiler tracks allocations/deallocations of objects in native code for a specific time period and provides information about total allocations and remaining system heap size.

To initiate a recording, click Record native allocations at the top of the Memory Profiler window:

View native memory allocations with the Native Memory Profiler

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

Design

Develop

Build & Test

Optimize

These materials are not sponsored by or affiliated with Unity Technologies or its affiliates. “Unity” is a trademark or registered trademark of Unity Technologies or its affiliates in the U.S. and elsewhere.

October 12th 2020, 1:15 pm

Announcing the launch of the Android Partner Vulnerability Initiative

Android Developers Blog

Posted by Kylie McRoberts, Program Manager and Alec Guertin, Security Engineer

Google’s Android Security & Privacy team has launched the Android Partner Vulnerability Initiative (APVI) to manage security issues specific to Android OEMs. The APVI is designed to drive remediation and provide transparency to users about issues we have discovered at Google that affect device models shipped by Android partners.

Another layer of security

Android incorporates industry-leading security features and every day we work with developers and device implementers to keep the Android platform and ecosystem safe. As part of that effort, we have a range of existing programs to enable security researchers to report security issues they have found. For example, you can report vulnerabilities in Android code via the Android Security Rewards Program (ASR), and vulnerabilities in popular third-party Android apps through the Google Play Security Rewards Program. Google releases ASR reports in Android Open Source Project (AOSP) based code through the Android Security Bulletins (ASB). These reports are issues that could impact all Android based devices. All Android partners must adopt ASB changes in order to declare the current month’s Android security patch level (SPL). But until recently, we didn’t have a clear way to process Google-discovered security issues outside of AOSP code that are unique to a much smaller set of specific Android OEMs. The APVI aims to close this gap, adding another layer of security for this targeted set of Android OEMs.

Improving Android OEM device security

The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology -- Security techniques -- Vulnerability disclosure recommendations. The initiative covers a wide range of issues impacting device code that is not serviced or maintained by Google (these are handled by the Android Security Bulletins).

Protecting Android users

The APVI has already processed a number of security issues, improving user protection against permissions bypasses, execution of code in the kernel, credential leaks and generation of unencrypted backups. Below are a few examples of what we’ve found, the impact and OEM remediation efforts.

Permission Bypass

In some versions of a third-party pre-installed over-the-air (OTA) update solution, a custom system service in the Android framework exposed privileged APIs directly to the OTA app. The service ran as the system user and did not require any permissions to access, instead checking for knowledge of a hardcoded password. The operations available varied across versions, but always allowed access to sensitive APIs, such as silently installing/uninstalling APKs, enabling/disabling apps and granting app permissions. This service appeared in the code base for many device builds across many OEMs, however it wasn’t always registered or exposed to apps. We’ve worked with impacted OEMs to make them aware of this security issue and provided guidance on how to remove or disable the affected code.

Credential Leak

A popular web browser pre-installed on many devices included a built-in password manager for sites visited by the user. The interface for this feature was exposed to WebView through JavaScript loaded in the context of each web page. A malicious site could have accessed the full contents of the user’s credential store. The credentials are encrypted at rest, but used a weak algorithm (DES) and a known, hardcoded key. This issue was reported to the developer and updates for the app were issued to users.

Overly-Privileged Apps

The checkUidPermission method in the PackageManagerService class was modified in the framework code for some devices to allow special permissions access to some apps. In one version, the method granted apps with the shared user ID com.google.uid.shared any permission they requested and apps signed with the same key as the com.google.android.gsf package any permission in their manifest. Another version of the modification allowed apps matching a list of package names and signatures to pass runtime permission checks even if the permission was not in their manifest. These issues have been fixed by the OEMs.

More information

Keep an eye out at https://bugs.chromium.org/p/apvi/ for future disclosures of Google-discovered security issues under this program, or find more information there on issues that have already been disclosed.

Acknowledgements: Scott Roberts, Shailesh Saini and Łukasz Siewierski, Android Security and Privacy Team

October 2nd 2020, 1:17 pm

Answering your FAQs about Google Play billing

Android Developers Blog

Posted by Mrinalini Loew, Group Product Manager

We are committed to providing powerful tools and services to help developers build and grow their businesses while ensuring a safe, secure and seamless experience for users. Today we are addressing some of the most common themes we hear in feedback from developers. Below are a few frequently asked developer questions that we thought would also be helpful to address.

Q: Can I distribute my app via other Android app stores or through my website?

A: Yes, you can distribute your app however you like! As an open ecosystem, most Android devices come preinstalled with more than one store - and users can install others. Android provides developers the freedom and flexibility to distribute apps through other Android app stores, directly via websites, or device preloads, all without using Google Play’s billing system.

Q: What apps need to use Google Play's billing system?

A: All apps distributed on Google Play that are offering in-app purchases of digital goods need to use Google Play’s billing system. Our payments policy has always required this. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. For those few developers that need to update their apps, they will have until September 30, 2021 to make those changes. New apps submitted after January 20, 2021 will need to be in compliance.

Q: Many businesses have needed to move their previously physical services online (e.g. digital live events). Will these apps need to use Google Play’s billing?

A: We recognize that the global pandemic has resulted in many businesses having to navigate the challenges of moving their physical business to digital and engaging audiences customers in a new way, for example, moving in-person experiences and classes online. For the next 12 months, these businesses will not need to comply with our payments policy, and we will continue to reassess the situation over the next year. For developers undergoing these changes, we're eager to hear from you and work with you to help you reach new users and grow your online businesses, while enabling a consistent and safe user experience online.

Q: Do Google’s apps have to follow this policy too?

A: Yes. Google Play’s developer policies - including the requirement that apps use Google Play’s billing system for in-app purchases of digital goods - apply to all apps on Play, including Google’s own apps.

Q: Can I communicate with my users about alternate ways to pay?

A: Yes. Outside of your app you are free to communicate with them about alternative purchase options. You can use email marketing and other channels outside of the app to provide subscription offers and even special pricing.

Q: Can I communicate with my users about promotions on other platforms?

A: Of course. We're an app developer too, and we know how important it is not to restrict your ability to communicate with your users. You can email them or otherwise communicate outside of the app information about your offerings, even if they are different on Google Play than in other places.

Q: Can I have different app features, prices and experience depending on the platform?

A: Yes. It is your service and business, it is up to you. We do not require parity across platforms. You can create different versions of your app to support different platforms, features and pricing models.

Q: Can I offer a consumption-only (reader) app on Play?

A: Yes. Google Play allows any app to be consumption-only, even if it is part of a paid service. For example, a user could login when the app opens and the user could access content paid for somewhere else.

Q: Does your billing policy change depending on what category my app is in?

A: No. Business or consumer apps, and verticals like music or email are all treated the same on Google Play.

Q: Can I offer my customers refunds directly?

A: Yes. We understand the importance of maintaining the relationship with your customers. You can continue to issue refunds to your customers and other customer support directly.

Q: Will Google Play allow cloud gaming apps?

A: Yes. Cloud game streaming apps that comply with Play’s policies from any developer are welcome on Google Play.

September 28th 2020, 1:10 pm

Listening to Developer Feedback to Improve Google Play

Android Developers Blog

Posted by Sameer Samat, Vice President, Product Management

Developers are our partners and by pairing their creativity and innovation with our platforms and tools, together we create delightful experiences for billions of people around the world. Listening carefully to their feedback is an important part of how we continue to make Android better with each release and improve how mobile app stores work. In an April 2019 blog post we shared some updates we made to Android APIs and Play Policies based on developer feedback. And today, we wanted to share some additional insights we’ve gained from developer feedback and how we’re taking that input to improve Google Play and Android. Some of the key themes we’ve heard include:

We’d like to share our perspective on each of these points.

Choice of stores

We believe that developers should have a choice in how they distribute their apps and that stores should compete for the consumer’s and the developer’s business. Choice has always been a core tenet of Android, and it’s why consumers have always had control over which apps they use, be it their keyboard, messaging app, phone dialer, or app store.

Android has always allowed people to get apps from multiple app stores. In fact, most Android devices ship with at least two app stores preinstalled, and consumers are able to install additional app stores. Each store is able to decide its own business model and consumer features. This openness means that even if a developer and Google do not agree on business terms the developer can still distribute on the Android platform. This is why Fortnite, for example, is available directly from Epic's store or from other app stores including Samsung's Galaxy App store.

That said, some developers have given us feedback on how we can make the user experience for installing another app store on their device even better. In response to that feedback, we will be making changes in Android 12 (next year’s Android release) to make it even easier for people to use other app stores on their devices while being careful not to compromise the safety measures Android has in place. We are designing all this now and look forward to sharing more in the future!

Clarity on billing policies

As we mentioned, each Android app store is able to decide its own business model and consumer features. For Google Play, users expect a safe, secure and seamless experience, and developers come to Play for powerful tools and services that help them build and grow their businesses. Our developer policies are designed to help us deliver on these expectations and Google Play's billing system is a cornerstone of our ongoing commitment. Consumers get the benefit of a trusted system that allows them to safely, securely, and seamlessly buy from developers worldwide. Google protects consumers’ payment info with multiple layers of security, using one of the world’s most advanced security infrastructures. For developers, Google Play’s billing system provides an easy way for billions of Android users to transact with them using their local, preferred method of payment.

We’ve always required developers who distribute their apps on Play to use Google Play’s billing system if they offer in-app purchases of digital goods, and pay a service fee from a percentage of the purchase. To be clear, this policy is only applicable to less than 3% of developers with apps on Google Play. We only collect a service fee if the developer charges users to download their app or they sell in-app digital items, and we think that is fair. Not only does this approach allow us to continuously reinvest in the platform, this business model aligns our success directly with the success of developers.

But we have heard feedback that our policy language could be more clear regarding which types of transactions require the use of Google Play’s billing system, and that the current language was causing confusion. We want to be sure our policies are clear and up to date so they can be applied consistently and fairly to all developers, and so we have clarified the language in our Payments Policy to be more explicit that all developers selling digital goods in their apps are required to use Google Play’s billing system.

Again, this isn’t new. This has always been the intention of this long standing policy and this clarification will not affect the vast majority of developers with apps on Google Play. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. But for those who already have an app on Google Play that requires technical work to integrate our billing system, we do not want to unduly disrupt their roadmaps and are giving a year (until September 30, 2021) to complete any needed updates. And of course we will require Google’s apps that do not already use Google Play’s billing system to make the necessary updates as well.

Equal treatment

Our policies apply equally to all apps distributed on Google Play, including Google’s own apps. We use the same standards to decide which apps to promote on Google Play, whether they're third-party apps or our own apps. In fact, we regularly promote apps by Google’s competitors in our Editors Choice picks when they provide a great user experience. Similarly, our algorithms rank third-party apps and games using the same criteria as for ranking Google's own apps.

Communicating with customers

Developers have told us it is very important to be able to speak directly with their customers without significant restrictions. As app developers ourselves, we agree wholeheartedly and our policies have always allowed this.

That said, developers have asked whether they can communicate with their customers directly about pricing, offers, and alternative ways to pay beyond their app via email or other channels. To clarify, Google Play does not have any limitations here on this kind of communication outside of a developer’s app. For example, they might have an offering on another Android app store or through their website at a lower cost than on Google Play.

We understand the importance of maintaining the customer relationship. As such, we have also always allowed developers to issue refunds to their customers and provide other customer support directly.

Enabling innovation

Developers are coming up with cool things all the time. Using their feedback, we are always trying to adjust our approach to ensure that we continue to help enable new forms of innovation. For example, recent innovations in game streaming have generated new game experiences that are available on Google Play, including Microsoft’s recent launch of Xbox cloud gaming in the Xbox Game Pass Android app.

Keep the feedback coming

We really appreciate all the feedback we have received from our developer community and believe the Android ecosystem has never been a more exciting place to be.

It is exciting to see developers such as Duolingo, Truecaller, Hyperconnect, Any.do, and Viber be so successful and grow their business on Android and reach a diverse audience. These kinds of services delight consumers and we are thrilled to have built a platform that can support them.

We’ve also published some additional frequently asked developer questions here.

September 28th 2020, 1:10 pm

All developers will get the new Google Play Console on November 2, 2020

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play Console

We hope you’re enjoying the new Google Play Console. With over 350,000 people now using it as their default experience and thousands more providing feedback, the new Play Console is ready to come out of beta. Thank you to everyone who has helped to get it here. This means that the old Play Console will be discontinued starting November 2, 2020. After this date, you’ll be automatically directed to the new Play Console when you log into your account.

If you haven't tried it already, we recommend that you switch to the new version now. To get started, visit play.google.com/console.

The new Play Console’s responsive design means that you can use it across all of your devices. The new navigation makes it easier to find and understand important features, and we’ve added areas to help you better understand your release status, acquisition performance, and guidance on policy changes.

Thanks to your feedback, we’ve already made a lot of improvements:

To learn more about the new Play Console, you can:

Thank you for being a part of our community, and we hope you enjoy the new Play Console!

How useful did you find this blog post?

September 24th 2020, 9:14 am

Lockscreen and authentication improvements in Android 11

Android Developers Blog

As phones become faster and smarter, they play increasingly important roles in our lives, functioning as our extended memory, our connection to the world at large, and often the primary interface for communication with friends, family, and wider communities. It is only natural that as part of this evolution, we’ve come to entrust our phones with our most private information, and in many ways treat them as extensions of our digital and physical identities.

This trust is paramount to the Android Security team. The team focuses on ensuring that Android devices respect the privacy and sensitivity of user data. A fundamental aspect of this work centers around the lockscreen, which acts as the proverbial front door to our devices. After all, the lockscreen ensures that only the intended user(s) of a device can access their private data.

This blog post outlines recent improvements around how users interact with the lockscreen on Android devices and more generally with authentication. In particular, we focus on two categories of authentication that present both immense potential as well as potentially immense risk if not designed well: biometrics and environmental modalities.

The tiered authentication model

Before getting into the details of lockscreen and authentication improvements, we first want to establish some context to help relate these improvements to each other. A good way to envision these changes is to fit them into the framework of the tiered authentication model, a conceptual classification of all the different authentication modalities on Android, how they relate to each other, and how they are constrained based on this classification.

The model itself is fairly simple, classifying authentication modalities into three buckets of decreasing levels of security and commensurately increasing constraints. The primary tier is the least constrained in the sense that users only need to re-enter a primary modality under certain situations (for example, after each boot or every 72 hours) in order to use its capability. The secondary and tertiary tiers are more constrained because they cannot be set up and used without having a primary modality enrolled first and they have more constraints further restricting their capabilities.

  1. Primary Tier - Knowledge Factor: The first tier consists of modalities that rely on knowledge factors, or something the user knows, for example, a PIN, pattern, or password. Good high-entropy knowledge factors, such as complex passwords that are hard to guess, offer the highest potential guarantee of identity.

    Knowledge factors are especially useful on Android becauses devices offer hardware backed brute-force protection with exponential-backoff, meaning Android devices prevent attackers from repeatedly guessing a PIN, pattern, or password by having hardware backed timeouts after every 5 incorrect attempts. Knowledge factors also confer additional benefits to all users that use them, such as File Based Encryption (FBE) and encrypted device backup.

  2. Secondary Tier - Biometrics: The second tier consists primarily of biometrics, or something the user is. Face or fingerprint based authentications are examples of secondary authentication modalities. Biometrics offer a more convenient but potentially less secure way of confirming your identity with a device.

    We will delve into Android biometrics in the next section.

  3. The Tertiary Tier - Environmental: The last tier includes modalities that rely on something the user has. This could either be a physical token, such as with Smart Lock’s Trusted Devices where a phone can be unlocked when paired with a safelisted bluetooth device. Or it could be something inherent to the physical environment around the device, such as with Smart Lock’s Trusted Places where a phone can be unlocked when it is taken to a safelisted location.

    Improvements to tertiary authentication

    While both Trusted Places and Trusted Devices (and tertiary modalities in general) offer convenient ways to get access to the contents of your device, the fundamental issue they share is that they are ultimately a poor proxy for user identity. For example, an attacker could unlock a misplaced phone that uses Trusted Place simply by driving it past the user's home, or with moderate amount of effort, spoofing a GPS signal using off-the-shelf Software Defined Radios and some mild scripting. Similarly with Trusted Device, access to a safelisted bluetooth device also gives access to all data on the user’s phone.

    Because of this, a major improvement has been made to the environmental tier in Android 10. The Tertiary tier was switched from an active unlock mechanism into an extending unlock mechanism instead. In this new mode, a tertiary tier modality can no longer unlock a locked device. Instead, if the device is first unlocked using either a primary or secondary modality, it can continue to keep it in the unlocked state for a maximum of four hours.

A closer look at Android biometrics

Biometric implementations come with a wide variety of security characteristics, so we rely on the following two key factors to determine the security of a particular implementation:

  1. Architectural security: The resilience of a biometric pipeline against kernel or platform compromise. A pipeline is considered secure if kernel and platform compromises don’t grant the ability to either read raw biometric data, or inject synthetic data into the pipeline to influence an authentication decision.
  2. Spoofability: Is measured using the Spoof Acceptance Rate (SAR). SAR is a metric first introduced in Android P, and is intended to measure how resilient a biometric is against a dedicated attacker. Read more about SAR and its measurement in Measuring Biometric Unlock Security.

We use these two factors to classify biometrics into one of three different classes in decreasing order of security:

Each class comes with an associated set of constraints that aim to balance their ease of use with the level of security they offer.

These constraints reflect the length of time before a biometric falls back to primary authentication, and the allowed application integration. For example, a Class 3 biometric enjoys the longest timeouts and offers all integration options for apps, while a Class 1 biometric has the shortest timeouts and no options for app integration. You can see a summary of the details in the table below, or the full details in the Android Android Compatibility Definition Document (CDD).

1 App integration means exposing an API to apps (e.g., via integration with BiometricPrompt/BiometricManager, androidx.biometric, or FIDO2 APIs)

2 Keystore integration means integrating Keystore, e.g., to release app auth-bound keys

Benefits and caveats

Biometrics provide convenience to users while maintaining a high level of security. Because users need to set up a primary authentication modality in order to use biometrics, it helps boost the lockscreen adoption (we see an average of 20% higher lockscreen adoption on devices that offer biometrics versus those that do not). This allows more users to benefit from the security features that the lockscreen provides: gates unauthorized access to sensitive user data and also confers other advantages of a primary authentication modality to these users, such as encrypted backups. Finally, biometrics also help reduce shoulder surfing attacks in which an attacker tries to reproduce a PIN, pattern, or password after observing a user entering the credential.

However, it is important that users understand the trade-offs involved with the use of biometrics. Primary among these is that no biometric system is foolproof. This is true not just on Android, but across all operating systems, form-factors, and technologies. For example, a face biometric implementation might be fooled by family members who resemble the user or a 3D mask of the user. A fingerprint biometric implementation could potentially be bypassed by a spoof made from latent fingerprints of the user. Although anti-spoofing or Presentation Attack Detection (PAD) technologies have been actively developed to mitigate such spoofing attacks, they are mitigations, not preventions.

One effort that Android has made to mitigate the potential risk of using biometrics is the lockdown mode introduced in Android P. Android users can use this feature to temporarily disable biometrics, together with Smart Lock (for example, Trusted Places and Trusted Devices) as well as notifications on the lock screen, when they feel the need to do so.

To use the lockdown mode, users first need to set up a primary authentication modality and then enable it in settings. The exact setting where the lockdown mode can be enabled varies by device models, and on a Google Pixel 4 device it is under Settings > Display > Lock screen > Show lockdown option. Once enabled, users can trigger the lockdown mode by holding the power button and then clicking the Lockdown icon on the power menu. A device in lockdown mode will return to the non-lockdown state after a primary authentication modality (such as a PIN, pattern, or password) is used to unlock the device.

BiometricPrompt - New APIs

In order for developers to benefit from the security guarantee provided by Android biometrics and to easily integrate biometric authentication into their apps to better protect sensitive user data, we introduced the BiometricPrompt APIs in Android P.

There are several benefits of using the BiometricPrompt APIs. Most importantly, these APIs allow app developers to target biometrics in a modality-agnostic way across different Android devices (that is, BiometricPrompt can be used as a single integration point for various biometric modalities supported on devices), while controlling the security guarantees that the authentication needs to provide (such as requiring Class 3 or Class 2 biometrics, with device credential as a fallback). In this way, it helps protect app data with a second layer of defenses (in addition to the lockscreen) and in turn respects the sensitivity of user data. Furthermore, BiometricPrompt provides a persistent UI with customization options for certain information (for example, title and description), offering a consistent user experience across biometric modalities and across Android devices.

As shown in the following architecture diagram, apps can integrate with biometrics on Android devices through either the framework API or the support library (that is, androidx.biometric for backward compatibility). One thing to note is that FingerprintManager is deprecated because developers are encouraged to migrate to BiometricPrompt for modality-agnostic authentications.

Improvements to BiometricPrompt

Android 10 introduced the BiometricManager class that developers can use to query the availability of biometric authentication and included fingerprint and face authentication integration for BiometricPrompt.

In Android 11, we introduce new features such as the BiometricManager.Authenticators interface which allows developers to specify the authentication types accepted by their apps, as well as additional support for auth-per-use keys within the BiometricPrompt class.

More details can be found in the Android 11 preview and Android Biometrics documentation. Read more about BiometricPrompt API usage in our blog post Using BiometricPrompt with CryptoObject: How and Why and our codelab Login with Biometrics on Android.

September 22nd 2020, 3:49 pm

Introducing Android 11 on Android TV

Android Developers Blog

Posted by Wolfram Klein, Product Manager, Android TV

We’ve been turning it up to 11 all summer long, leading up to the launch of Android 11 on mobile. Now, following right behind the mobile release, we are launching Android 11 on Android TV to bring the latest platform features to the big screen.

Android 11 on Android TV introduces performance and privacy improvements, new features tailored for the TV, and updated developer tools, in addition to enabling many of the features we announced during the #11WeeksOfAndroid.

Foundational Improvements

Android TV continues to bring many of the benefits that come with the core Android update to the TV. With Android 11, performance improvements, like enhanced memory management, and privacy features, like one-time permissions, are introduced to make sure TV devices work quickly and securely.

Tailored for the TV

Android 11 emphasizes media by bringing support for Auto Low Latency Mode, and low latency media decoding, along with a new Tuner Framework with updated Media CAS support and extensions to the HAL implementation of HDMI CEC.

With extended gamepad support, silent boot mode for system updates, inactivity prompts, and OEM configurable wake keys, Android 11 allows greater control over TV functions. New framework functionality for managing System LEDs and physical microphone mute buttons also facilitate integrations for far-field microphone enabled devices.

Faster Testing

Testing on the TV is now easier than ever. The addition of test harness mode on Android TV and Play Store support in the Android TV Emulator help you seamlessly inspect your apps as you develop.

Android TV OEM partners will be launching and upgrading devices to Android 11 over the coming months. To help you test your Android TV app implementations for the next generation of devices, Android 11 will be available as a system update to ADT-3 devices today. To learn more about getting your Android TV app ready for Android 11, visit our developers page.

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

September 22nd 2020, 9:04 am

Improve Your Game with Texture Compression Format Targeting

Android Developers Blog

Posted by Yafit Becher, Program Manager & Dan Galpin, Developer Advocate

Play Asset Delivery downloads the best supported texture for the device

Google Play Asset Delivery allows you to publish an Android App Bundle to Google Play containing all the resources your game needs. It offers multiple delivery modes, auto-updates, compression, and delta patching, all hosted at no cost to you.

As of today, you can use Google Play Asset Delivery to include textures in multiple texture compression formats in your Android App Bundle and Google Play will automatically deliver the assets with the best supported texture compression format for each device. With Texture Compression Format Targeting, you can start using ASTC for devices that support it while falling back to ETC2/ETC1 to devices that don’t. The Adaptive Scalable Texture Compression (ASTC) format offers advantages, such as improved rendering performance, faster load times, a smaller in-memory footprint, better battery life, and improved visual quality. You can even dramatically reduce your download size and on-device footprint by optimizing the tradeoff between size and quality.

Higher bandwidth version of much of this information

Android App Bundle will be the required publishing format for all new games and apps as of August 2021, which means that Google Play Asset Delivery will be required for new games that want Google Play to host more than 150MB of assets. Texture format targeting provides value even for smaller games due to the advantages of newer texture compression formats.

Texture compression

Texture compression is a form of lossy image compression that allows the GPU to render directly from the compressed texture using specialized silicon blocks, reducing the texture memory and memory bandwidth required to render the texture. As GPUs have gotten more advanced, more sophisticated texture compression formats have been developed, but not all GPUs can take advantage of them.

ASTC was released in 2012 to give developers more flexibility in trading compression size vs image quality. It compresses using fixed 128-bit block sizes, but allows for variable block footprints from 4x4 (8 bits per texel) to 12x12 (.89 bits per texel).

Googleplex from Google Earth at 12x12 (.89 BPT), 6x5 (4.27 BPT), 4x4 (8 BPT)

This allows almost any type of texture to be used in compressed form, and allows for textures to occupy much less space in RAM — up to 36x less space compared to uncompressed 2D textures depending on quality. Smaller textures also take less time to load, making games start faster.

Memory bandwidth

Since the GPU needs to do fewer reads from texture memory in order to render the texture, the memory bandwidth required to render the scene is reduced, often substantially when texture caches are taken into account.

Texture compression formats in Android

The top compression formats in Android are ETC1, ETC2, and ASTC.

Top texture compression formats with device penetration as of September 2020

ETC1 is supported on practically all devices. It has no transparency support; games can use a second texture for the alpha component. It has quality issues with sharp transitions such as edges and text.

ETC2 is supported by all devices that support GLES3. It supports multiple transparency modes and improves quality compared to ETC1.

ASTC is a more recent format that's more flexible; it supports many different kinds of textures, allowing for just about any texture in your game to benefit from compression. In addition, it supports various block sizes with different associated compression ratios. Using this format is a good way to optimize the size, image quality, and performance of your game.

When experimenting with ASTC on Asphalt Xtreme Gameloft found that they could reduce the size of their game by up to 30%

Using texture compression format targeting

Once you've implemented Google Play Asset Delivery in your game, adding texture format targeting is an incremental step. Inside your asset packs, make sure you have a directory that holds just your textures, such as [assetpackname]/textures. This directory will be used to hold default textures (probably in ETC1 or ETC2 format).

Then, create additional texture directories with a suffix representing the additional formats you wish to support.

[assetpackname]/textures#tcf_etc2
[assetpackname]/textures#tcf_astc

Finally, update your app build.gradle file to enable texture splits in asset packs:

// In the app build.gradle file:
android {
    ...
    bundle {
        texture {
            enableSplit true
        }
    }
}

Google Play strips off the texture suffixes so your game reads its assets from the default directory, regardless of what textures are delivered to the device.

If you're using Unity, our Play Asset Delivery plugin for Unity is ready to create app bundles with texture-targeted packs.

Texture compression format targeting is available now

We're committed to helping you serve your entire game through Play with customized dynamic delivery and features such as texture compression format targeting. Documentation at d.android.com will walk you through the integration process depending on the game engine you use. We have more information on all of our game related developer resources at d.android.com/games and stay up to date with Google Play Asset Delivery and other game developer tools by signing up for the games quarterly newsletter.

September 21st 2020, 12:33 pm

Android GPU Inspector Open Beta

Android Developers Blog

Posted by Jay Kong, Gaming and Graphics Product Manager

With the rollout of Android 11 on Pixel, Android GPU Inspector (AGI) has graduated from a limited developer preview to an open beta. During the preview, AGI has been helpful in finding performance bottlenecks for developers we've been working with, and we're looking forward to hearing your feedback.

What is Android GPU Inspector?

AGI is a graphics profiling tool that allows you to look into the GPU of Android devices to better understand graphics bottlenecks and optimize the performance of games and apps that leverage 3D graphics APIs. It shows a timeline of events for your running game or app, which includes system activities, high frequency GPU hardware counters, and, if you are using Vulkan, GPU activity information.

What devices can I use it on?

AGI relies on updated firmware and video drivers to get information it needs; the first devices to support it are the Pixel 4 and 4XL running Android 11. While we are working with device manufacturers and SoC vendors to enable more supported devices, the key insight we’ve learned on our journey is that being able to look into the GPU—even on a single device—creates a lot of value.

Working with Blizzard Entertainment Inc. and NetEase, Inc., AGI helped pinpoint 45% vertex bandwidth savings for the upcoming Diablo Immortal, a dark gothic action RPG game.

Diablo: Immortal

Working with King, AGI helped improve GPU frame time from 11-16ms to a stable 8ms for the upcoming Crash Bandicoot: On the Run!, allowing the game to reduce battery drain and run faster for a smoother experience.

Crash Bandicoot: On The Run

In collaboration with Jam City, AGI helped reduce GPU frametime by 45% on World War Doh: Real Time PvP.

World War Doh: Real Time PvP

Optimization tutorials

Stay tuned for more information on how to use the tool and address common issues we’ve seen when working with real games. We’ll begin by demonstrating using AGI to indicate optimizations to make in your game’s textures.

You can also read about this topic on Medium, here.

How do I get started?

You can download AGI here, and the setup instructions are here.

To learn about new device support, you can check this page. Stay up to date with AGI and all of our game developer tools by signing up for the games quarterly newsletter.

September 14th 2020, 3:08 pm

Turning it up to 11: Android 11 for developers

Android Developers Blog

Posted by Stephanie Cuthbertson, Director, Product Management

Android 11 is here! Today we’re pushing the source to the Android Open Source Project (AOSP) and officially releasing the newest version of Android. We built Android 11 with a focus on three themes: a People-centric approach to communication, Controls to let users quickly get to and control all of their smart devices, and Privacy to give users more ways to control how data on devices is shared. Read more in our Keyword post.

For developers, Android 11 has a ton of new capabilities. You’ll want to check out conversation notifications, device and media controls, one-time permissions, enhanced 5G support, IME transitions, and so much more. To help you work and develop faster, we also added new tools like compatibility toggles, ADB incremental installs, app exit reasons API, data access auditing API, Kotlin nullability annotations, and many others. We worked to make Android 11 a great release for you, and we can’t wait to see what you’ll build!

Watch for official Android 11 coming to a device near you, starting today with Pixel 2, 3, 3a, 4, and 4a devices. To get started, visit the Android 11 developer site.

People, Controls, Privacy

People

Android 11 is people-centric and expressive, reimagining the way we have conversations on our phones, and building an OS that can recognize and prioritize the most important people in our lives. For developers, Android 11 helps you build deeper conversational and personal interactions into your apps.

Bubbles and people-centric conversations.

Controls

Android 11 lets users quickly get to and control all of their smart devices in one space. Developers can use new APIs to help users surface smart devices and control media:

Device controls and media controls.

Privacy

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

One-time permission - Now users can give an app access to the device microphone, camera, or location, just for one time. The app can request permissions again the next time the app is used. More here.

One-time permission dialog in Android 11.

Background location - Background location now requires additional steps from the user beyond granting a runtime permission. If your app needs background location, the system will ensure that you first ask for foreground location. You can then broaden your access to background location through a separate permission request, and the system will take the user to Settings to complete the permission grant.

Also note that in February we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021.

Permissions auto-reset - if users haven’t used an app for an extended period of time, Android 11 will “auto-reset” all of the runtime permissions associated with the app and notify the user. The app can request the permissions again the next time the app is used. More here.

Scoped storage - We’ve continued our work to better protect app and user data on external storage, and made further improvements to help developers more easily migrate. More here.

Google Play system updates - Launched last year, Google Play system updates help us expedite updates of core OS components to devices in the Android ecosystem. In Android 11, we more than doubled the number of updatable modules, including 12 new modules that will help improve privacy, security, and consistency for users and developers.

BiometricPrompt API - Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. For backward compatibility, we’ve just added these capabilities to the Jetpack Biometric library. We’ll share further updates as the work progresses.

Identity Credential API - This will unlock new use cases such as mobile drivers licences, National ID, and Digital ID. We’re working with various government agencies and industry partners to make sure that Android 11 is ready for digital-first identity experiences.

You can read about all of the Android 11 privacy features here.

Helpful innovation

Enhanced 5G support - Android 11 includes updated developer support to help you take advantage of the faster speeds and lower latency of 5G networks. You can learn when the user is connected to a 5G network, check whether the connection is metered, and get an estimate of the connection bandwidth. To help you build experiences now for 5G, we’ve also added 5G support in the Android Emulator. To get started with 5G on Android, visit the 5G developer page.

Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses.

New screen types - Device makers are continuing to innovate by bringing exciting new device screens to market, such as hole-punch and waterfall screens. Android 11 adds support for these in the platform, with APIs to let you optimize your apps. You can manage both hole-punch and waterfall screens using the existing display cutout APIs. You can set a new window layout attribute to use the entire waterfall screen, and a new waterfall insets API helps you manage interaction near the edges.

Call screening support - Android 11 helps call-screening apps do more to manage robocalls. Apps can verify an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of the call details, and they can report a call rejection reason. Apps can also customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts.

Polish and quality

OS resiliency - In Android 11 we’ve made the OS more dynamic and resilient as a whole by fine-tuning memory reclaiming processes, such as forcing user-imperceptible restarts of processes based on RSS HWM thresholds. Also, to improve performance and memory, Android 11 adds Binder caching, which optimizes highly used IPC calls to system services by caching data for those that retrieve relatively static data. Binder caching also improves battery life by reducing CPU time.

Synchronized IME transitions - New APIs let you synchronize your app’s content with the IME (input method editor, or on-screen keyboard) and system bars as they animate on and offscreen, making it much easier to create natural, intuitive and jank-free IME transitions. For frame-perfect transitions, a new WindowInsetsAnimation.Callback API notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, you can use a new WindowInsetsAnimationController API to control system UI types like system bars, IME, immersive mode, and others. More here.

Synchronized IME transition through insets animation listener.

App-driven IME experience through WindowInsetsAnimationController.

HEIF animated drawables - The ImageDecoder API now lets you decode and render image sequence animations stored in HEIF files, so you can make use of high-quality assets while minimizing impact on network data and APK size. HEIF image sequences can offer drastic file-size reductions for image sequences when compared to animated GIFs.

Native image decoder - New NDK APIs let apps decode and encode images (such as JPEG, PNG, WebP) from native code for graphics or post processing, while retaining a smaller APK size since you don’t need to bundle an external library. The native decoder also takes advantage of Android’s process for ongoing platform security updates. See the NDK sample code for examples of how to use the APIs.

Low-latency video decoding in MediaCodec - Low latency video is critical for real-time video streaming apps and services like Stadia. Video codecs that support low latency playback return the first frame of the stream as quickly as possible after decoding starts. Apps can use new APIs to check and configure low-latency playback for a specific codec.

Variable refresh rate - Apps and games can use a new API to set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some support multiple refresh rates, such as 90Hz as well as 60Hz, with runtime switching. On these devices, the system uses the app’s preferred frame rate to choose the best refresh rate for the app. The API is available in both the SDK and NDK. See the details here.

Dynamic resource loader - Android 11 includes a new public API to let apps load resources and assets dynamically at runtime. With the Resource Loader framework you can include a base set of resources in your app or game and then load additional resources, or modify the loaded resources, as needed at runtime.

Neural Networks API (NNAPI) 1.3 - We continue to add ops and controls to support machine learning on Android devices. To optimize common use-cases, NNAPI 1.3 adds APIs for priority and timeout, memory domains, and asynchronous command queue. New ops for advanced models include signed integer asymmetric quantization, branching and loops, and a hard-swish op that helps accelerate next-generation on-device vision models such as MobileNetV3.

Developer friendliness

App compatibility tools - We worked to minimize compatibility impacts on your apps by making most Android 11 behavior changes opt-in, so they won’t take effect until you change the apps’ targetSdkVersion to 30. If you are distributing through Google Play, you’ll have more than a year to opt-in to these changes, but we recommend getting started testing early. To help you test, Android 11 lets you enable or disable many of the opt-in changes individually. More here.

App exit reasons - When your app exits, it’s important to understand why the app exited and what the state was at the time -- across the many device types, memory configurations, and user scenarios that your app runs in. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits.

Data access auditing - data access auditing lets you instrument your app to better understand how it accesses user data and from which user flows. For example, it can help you identify any inadvertent access to private data in your own code or within any SDKs you might be using. More here.

ADB Incremental - Installing very large APKs with ADB (Android Debug Bridge) during development can be slow and impact your productivity, especially those developers working on Android Games. With ADB Incremental in Android 11, installing large APKs (2GB+) from your development computer to an Android 11 device is up to 10x faster. More here.

Kotlin nullability annotations - Android 11 adds nullability annotations to more methods in the public API. And, it upgrades a number of existing annotations from warnings to errors. These help you catch nullability issues at build time, rather than at runtime. More here.

Get your apps ready for Android 11

With Android 11 on its way to users, now is the time to finish your compatibility testing and publish your updates.

Here are some of the top behavior changes to watch for (these apply regardless of your app’s targetSdkVersion):

Android 11 also includes opt-in behavior changes - these affect your app once it’s targeting the new platform. We recommend assessing these changes as soon as you’ve published the compatible version of your app. For more information on compatibility testing and tools, check out the resources we shared for Android 11 Compatibility week and visit the Android 11 developer site for technical details.

Enhance your app with new features and APIs

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

We recommend these for all apps:

We recommend these if relevant for your app:

Read more about all of the Android 11 features at developer.android.com/11.

Coming to a device near you!

Android 11 will begin rolling out today on select Pixel, OnePlus, Xiaomi, OPPO and realme phones, with more partners launching and upgrading devices over the coming months. If you have a Pixel 2, 3, 3a, 4, or 4a phone, including those enrolled in this year’s Beta program, watch for the over-the-air update arriving soon!

Android 11 factory system images for Pixel devices are also available through the Android Flash Tool, or you can download them here. As always, you can get the latest Android Emulator system images via the SDK Manager in Android Studio. For broader testing on other Treble-compliant devices, Generic System Images (GSI) are available here.

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

What’s next?

We’ll soon be closing the preview issue tracker and retiring open bugs logged against Developer Preview or Beta builds, but please keep the feedback coming! If you still see an issue that you filed in the preview tracker, just file a new issue against Android 11 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the preview program this year! You gave us great feedback to help shape the release, and you filed thousands of issues that have made Android 11 a better platform for everyone.

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

September 8th 2020, 1:21 pm

Prefer Storing Data with Jetpack DataStore

Android Developers Blog

Posted by Florina Muntenescu, Android Developer Advocate, Rohit Sathyanarayana, Software Engineer

Welcome Jetpack DataStore, now in alpha - a new and improved data storage solution aimed at replacing SharedPreferences. Built on Kotlin coroutines and Flow, DataStore provides two different implementations: Proto DataStore, that lets you store typed objects (backed by protocol buffers) and Preferences DataStore, that stores key-value pairs. Data is stored asynchronously, consistently, and transactionally, overcoming most of the drawbacks of SharedPreferences.

SharedPreferences vs DataStore

* SharedPreferences has a synchronous API that can appear safe to call on the UI thread, but which actually does disk I/O operations. Furthermore, apply() blocks the UI thread on fsync(). Pending fsync() calls are triggered every time any service starts or stops, and every time an activity starts or stops anywhere in your application. The UI thread is blocked on pending fsync() calls scheduled by apply(), often becoming a source of ANRs.

** SharedPreferences throws parsing errors as runtime exceptions.

In both implementations, DataStore saves the preferences in a file and performs all data operations on Dispatchers.IO unless specified otherwise.

While both Preferences DataStore and Proto DataStore allow saving data, they do this in different ways:

Room vs DataStore

If you have a need for partial updates, referential integrity, or support for large/complex datasets, you should consider using Room instead of DataStore. DataStore is ideal for small , simple datasets and does not support partial updates or referential integrity.

Using DataStore

Start by adding the DataStore dependency. If you’re using Proto DataStore, make sure you also add the proto dependency:

// Preferences DataStore
implementation "androidx.datastore:datastore-preferences:1.0.0-alpha01"


// Proto DataStore
implementation  "androidx.datastore:datastore-core:1.0.0-alpha01"

When working with Proto DataStore, you define your schema in a proto file in the app/src/main/proto/ directory. See the protobuf language guide for more information on defining a proto schema.

syntax = "proto3";

option java_package = "<your package name here>";
option java_multiple_files = true;

message Settings {
  int my_counter = 1;
}

Create the DataStore

Create the DataStore with the Context.createDataStore() extension functions.

// with Preferences DataStore
val dataStore: DataStore<Preferences> = context.createDataStore(
    name = "settings"
)

If you’re using Proto DataStore, you’ll also have to implement the Serializer interface to tell DataStore how to read and write your data type.

object SettingsSerializer : Serializer<Settings> {
    override fun readFrom(input: InputStream): Settings {
        try {
            return Settings.parseFrom(input)
        } catch (exception: InvalidProtocolBufferException) {
            throw CorruptionException("Cannot read proto.", exception)
        }
    }

    override fun writeTo(t: Settings, output: OutputStream) = t.writeTo(output)
}


// with Proto DataStore
val settingsDataStore: DataStore<Settings> = context.createDataStore(
    fileName = "settings.pb",
    serializer = SettingsSerializer
)

Read data from DataStore

DataStore exposes the stored data in a Flow, either in a Preferences object or as the object defined in your proto schema. DataStore ensures that data is retrieved on Dispatchers.IO so your UI thread isn’t blocked.

With Preferences DataStore:

val MY_COUNTER = preferencesKey<Int>("my_counter")
val myCounterFlow: Flow<Int> = dataStore.data
     .map { currentPreferences ->
        // Unlike Proto DataStore, there's no type safety here.
        currentPreferences[MY_COUNTER] ?: 0   
   }

With Proto DataStore:

val myCounterFlow: Flow<Int> = settingsDataStore.data
    .map { settings ->
        // The myCounter property is generated for you from your proto schema!
        settings.myCounter 
    }

Write data to DataStore

To write data, DataStore offers a suspending DataStore.updateData() function that gives you the current state of the stored data as a parameter—either as a Preferences object, or an instance of the object defined in the proto schema. The updateData() function updates the data transactionally in an atomic read-write-modify operation. The coroutine completes once the data is persisted on disk.

Preferences DataStore also provides a DataStore.edit() function to make it easier to update data. Instead of receiving a Preferences object, you receive a MutablePreferences object which you edit. As with updateData(), the changes are applied to disk after the transform block completes, and the coroutine completes once data is persisted to disk.

With Preferences DataStore:

suspend fun incrementCounter() {
    dataStore.edit { settings ->
        // We can safely increment our counter without losing data due to races!
        val currentCounterValue = settings[MY_COUNTER] ?: 0
        settings[MY_COUNTER] = currentCounterValue + 1
    }
}

With Proto DataStore:

suspend fun incrementCounter() {
    settingsDataStore.updateData { currentSettings ->
        // We can safely increment our counter without losing data due to races!
        currentSettings.toBuilder()
            .setMyCounter(currentSettings.myCounter + 1)
            .build()
    }
}

Migrate from SharedPreferences to DataStore

To migrate from SharedPreferences to DataStore, you need to pass in a SharedPreferencesMigration object to the DataStore builder. DataStore can automatically migrate from SharedPreferences to DataStore for you. Migrations are run before any data access can occur in DataStore. This means that your migration must have succeeded before DataStore.data returns any values and before DataStore.updateData() can update the data.

If you’re migrating to Preferences DataStore, you can use the default SharedPreferencesMigration implementation and just pass in the name used to construct your SharedPreferences.

With Preferences DataStore:

val dataStore: DataStore<Preferences> = context.createDataStore(
    name = "settings",
    migrations = listOf(SharedPreferencesMigration(context, "settings_preferences"))
)

When migrating to Proto DataStore, you’ll have to implement a mapping function that defines how to migrate from the key-value pairs used by SharedPreferences to the DataStore schema you defined.

With Proto DataStore:

val settingsDataStore: DataStore<Settings> = context.createDataStore(
    produceFile = { File(context.filesDir, "settings.preferences_pb") },
    serializer = SettingsSerializer,
    migrations = listOf(
        SharedPreferencesMigration(
            context,
            "settings_preferences"            
        ) { sharedPrefs: SharedPreferencesView, currentData: UserPreferences ->
            // Map your sharedPrefs to your type here
          }
    )
)

Wrap-up

SharedPreferences comes with several drawbacks: a synchronous API that can appear safe to call on the UI thread, no mechanism for signaling errors, lack of transactional API, and more. DataStore is a replacement for SharedPreferences that addresses most of these shortcomings. DataStore includes a fully asynchronous API using Kotlin coroutines and Flow, handles data migration, guarantees data consistency, and handles data corruption.

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

September 2nd 2020, 1:05 pm

11 Weeks of Android: That’s a wrap

Android Developers Blog

This is the final blog post for #11WeeksOfAndroid. Thank you for joining us over the past 11 weeks as we dove into key areas of Android development. In case you missed it, here’s a recap of everything we talked about during each week:

Week 1 - People and identity

Discover how to implement the conversation shortcut and bubbles with ‘conversation notifications’. Also, learn more about conversation additions and other System UI news, and discover the people and conversations developer documentation here. Finally, you can also listen to the Android Backstage podcast where the System UI team is interviewed on people and bubbles.

To tackle user and developer complexity that makes identity a challenge for developers, we've been working on One Tap and Block Store, part of our new Google Identity Services Library.

If you’re interested in learning more about Identity, we published the video “in Identity on Android: what’s new in sign-in,” where Vishal explains the new libraries in the Google Identity System.

Two teams that worked very early with us are the Facebook Messenger team and the direct messaging team from Twitter. Read the story from Twitter here and find out how we worked with Facebook on the implementation here.

Find out more with the People and Identity learning path, playlist, and the week’s wrap-up blog post.

Week 2 - Machine learning

We kicked off the week by announcing the winners of the #AndroidDevChallenge! Check out all the winning apps and see how they used ML Kit and TensorFlow Lite, all focused on demonstrating how machine learning can come to life in a powerful way to help users get things done, like an app to help visually impaired navigate crowded spaces or another to help students learn sign language.

We recently made ML Kit a standalone SDK and it no longer requires a Firebase account. Just one line in your build.gradle file and you can start bringing ML functionality into your app.

Another much anticipated addition is the support for swapping Google models with your own for both Image Labeling as well as Object Detection and Tracking.

Find out about the importance of finding the unique intersection of user problems and ML strengths and how the People + AI Guidebook can help you make ML product decisions. Check out the interview with the Read Along team for more inspiration.

This week we also highlighted how adding a custom model to your Android app has never been easier.

Finally, try out our codelabs:

Find out more with the Machine Learning pathway, playlist, and the week’s wrap-up blog post.

Week 3 - Privacy and security

As shared in the “Privacy and Security” blog post, we’re giving users even more control and transparency over user data access.

In Android 11, we introduced various privacy improvements such as one time permissions that let users give an app access to the device microphone, camera, or location, just that one time. Learn more about building privacy-friendly apps with these new changes. You can also learn about various Android security updates in this video.

Other notable updates include:

Find out more with the ‘privacy, trust and security’ learning pathway, playlist, and documentation on privacy and security best practices.

Week 4 - Android 11 compatibility

We shipped the second Beta of Android 11 and added a new release milestone called Platform Stability to clearly signal to developers that all APIs and system behaviors are complete. Find out more about Beta 2 and platform stability, including what this milestone means for developers, and the Android 11 timeline. Note: since week #4, we shipped the third and final beta and are getting close to releasing Android 11 to AOSP and the ecosystem. Be sure to check that your apps are working!

To get your apps ready for Android 11, check out some of these helpful resources:

In our “Accelerating Android updates” blog post, we looked at how we’re continuing to get the latest OS to reach critical mass by expanding Android’s updatability architecture.

We also highlighted Excelliance Tech, who recently moved their LeBian SDK away from non-SDK interfaces, toward stable, official APIs so they can stay more compatible with the Android OS over time. Check out the Excelliance Tech story.

Find out more with the Android 11 Compatibility learning pathway, playlist, and the week’s wrap-up blog post.

Week 5 - Languages

With the Android 11 beta, we further improved the developer experience for Kotlin on Android by officially recommending coroutines for asynchronous work. If you’re new to coroutines, check out:

Also, check out our new Kotlin case studies page for the latest case studies and data, including the new Google Home case study, and our state of Kotlin on Android video. For beginners, we announced the launch of our new Android basics in Kotlin course.

If you’re a Java language developer, watch support for newer Java APIs on how we’ve made newer OpenJDK libraries available across versions of Android. With Android 11, we also updated the Android runtime to make app startup even faster with I/O prefetching.

Android 11 included updates across the native toolchain, including better tools for profile-guided optimization (PGO) and improvements to native dependency management in Android Studio 4.0.

Finally, we continue to focus on improvements to the D8 and R8 compilers in Android Studio with better support for Kotlin in the R8 shrinker. Learn more.

Find out more with the languages learning pathway, playlist, and the week’s wrap-up blog post.

Week 6 - Android Jetpack

Interested in what’s new in Jetpack? Check out the #Android11 Beta launch with a quick fly-by introducing many of the updates to our libraries, with tips on how to get started.

This year, we've made several major improvements with the release of Navigation 2.3, which allows you to navigate between different screens of your app with ease while also allowing you to follow Android UI principles.

In Android 11, we continued our work to give users even more control over sensitive permissions. Now there are type-safe contracts for common intents and more via new ActivityResult APIs. These changes simplify how you request permissions, and we’ll continue to work on making permissions easier in the future.

Also learn about our recent releases of the AppStartup library as well as what’s new in WorkManager.

Find out more with the Jetpack learning pathway, playlist, and the week’s wrap-up blog post.

Week 7 - Android developer tools

We have brought together an overview of what is new in Android Developer tools.

Check out the latest updates in design tools, and go even deeper:

Also, find out about debugging your layouts, with updates to the layout inspector. Discover the latest developments for Jetpack Compose Design tools, and also how to use the new database inspector in Android Studio.

Discover the latest development tools we have in place for Jetpack Hilt in Android Studio.

Learn about the build system in Android developer tools:

To learn about the latest updates on virtual testing, read this blog on the Android Emulator. Lastly, to see the latest changes for performance tools, watch performance profilers content about System Trace. Additionally, check out more about C++ memory profiling with Android Studio 4.1.

Find out more with the Android developer tools learning pathway, playlist, and the week’s wrap-up blog post.

Week 8 - App distribution and monetization

Check out our webinars about the new Google Play Console beta if you weren’t able to tune in live.

We shared recent improvements we’ve made to app bundles, as well as our intention to require new apps and games to publish with this format in the second half of 2021. The new in-app review API means developers can now ask for ratings and reviews from within your app!

Don’t forget about our policy around more transparent subscriptions to help increase user trust in Google Play Billing. We also expanded our feature set to help you better reach and retain buyers, and launched Play Billing Library 3, which will be required by mid-2021.

Google Play Pass launched in nine new markets last month. Developers using both Google Play Pass and direct billing on Google Play have earned an average of 2.5 times US revenue with Google Play Pass, without diminishing Google Play store earnings. Learn more and express interest in joining.

Find out more with the app distribution and monetization learning pathway, playlist, and the week’s wrap-up blog post.

Week 9 - Android beyond phones

Check out some of the highlights from this week, including;

Find out more with the learning pathways for Android TV and Large Screens, Beyond phones playlist, and the week’s wrap-up blog post.

Week 10 - Games and media

We shared several games updates and presented a special "11 Weeks" episode of The Android Game Developer Show.

You can also take advantage of Android 11's new media controls by making sure your app is using MediaStyle with a valid MediaSession token. Learn how to support media resumption by making your app discoverable with a MediaBrowserServiceCompat, using the EXTRA_RECENT hint to help with resuming content, and handling the onPlay and onGetRoot callbacks. Then check out how to leverage the MediaRouter jetpack library and check out the updated version of the UAMP sample.

Finally, we covered some of the primary ways apps can benefit from 5G. Android 11 adds new APIs and updates existing APIs to help ensure you have all the tools you need to leverage the capabilities of 5G, such as an enhanced bandwidth estimation API, 5G detection capabilities, and a new meteredness flag from cellular carriers. The Android emulator now enables you to develop and test these APIs without needing a 5G device or network connection. All of this and more is available from our dedicated 5G page.

Find out more with the ‘games and media’ learning pathway, playlist, and the wrap-up blog post, and visit d.android.com/games to stay up to date on all of our tools and resources for game developers.

Week 11 - UI

In our final week, we released 4 new codelabs, 9 new samples, new documentation and a podcast from the Compose team. If you prefer videos; we’ve got you covered:

New in Android 11 is the ability for apps to create seamless transitions between the on screen keyboard being opened and closed. To find out how to add this to your app, slide on over to the video, blog posts and sample app

We recommend following the Material Design guidelines to ensure that apps operate consistently, enabling patterns learned in one app to be used in another. Find out more about Material Theming (color, type and shape), dark theme and Material’s motion system using the Material Design Components (MDC) library. If you haven’t already migrated to MDC, then check out our migration guide.

It even becomes possible to ease your migration with libraries like the new MDC-Android Compose Theme Adapter which converts an MDC XML theme into a Compose `MaterialTheme`.

Find out more with the Compose learning pathway, the Modern UI learning pathway, playlist, and the week’s wrap-up blog post.

Resources

You can find the entire playlist of #11WeeksOfAndroid video content here. Follow us on Twitter and YouTube, and subscribe to our email list to receive all the latest news and resources. Thanks so much for letting us be a part of this experience with you!

August 31st 2020, 3:13 pm

11 Weeks of Android: UI and Compose

Android Developers Blog

Posted by Chris Banes & Nick Butcher

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

The big news: Jetpack Compose Alpha

This week we released the first alpha of Jetpack Compose 🎉, Android’s modern UI toolkit with native access to the platform APIs. Compose combines the power of Kotlin with the reactive programming model to make it easier and faster to build UI. We want your feedback to help us build the APIs that you need in your apps, so now is the time to try it out.

To get you up to speed with Compose, this week we’ve released 4 new codelabs, 7 new samples, new documentation and a podcast from the Compose team. If you prefer videos; we’ve got you covered...

To understand the reactive mindset and how to think about building apps with Compose, check out ‘Thinking in Compose’:

Learn how Jetpack Compose makes Android UI easier by walking through concrete examples from our open-source sample apps in ‘Compose by Example’:

Finally, to understand how Jetpack Compose and View based UIs can co-exist and interact, making it easy to adopt Compose at your own pace, check out ‘Compose for Existing’ apps:

Keyboard (IME) animations

New in Android 11 is the ability for apps to create seamless transitions between the on screen keyboard being opened and closed, as well as a revamped WindowInsets API to enable control of things such as the keyboard (IME). To find out how to add this to your app, slide on over to the video, blog posts and sample app

Material Design Components

We recommend following the Material Design guidelines to ensure that apps operate consistently, that patterns learned in one app can be used in another. Check out our new blog posts on Material Theming (color, type and shape), dark theme and Material’s motion system using the Material Design Components (MDC) library.

Adopting MDC now will prepare your codebase for later adopting Jetpack Compose — it uses the same concepts, design vocabulary and components. It even becomes possible to ease your migration with libraries like the new MDC-Android Compose Theme Adapter which converts an MDC XML theme into a Compose `MaterialTheme`.

If you haven’t already migrated to MDC, then check out our migration guide.

Learning path

If you’re looking for an easy way to pick up the highlights of this week, you can check out the learning pathways. This week we have two pathways for you to go through: the Compose pathway, and the ‘Modern UI’ pathway.

A pathway is an ordered tutorial that allows users to complete a pre-defined module that culminates in a quiz. It may include codelabs, videos, articles and blog posts. A virtual badge is awarded to each user who passes the quiz. Test your knowledge in each pathway to earn a limited edition badge.

Key takeaways

Whether you're building with the current UI toolkit or getting ready for the next generation we hope that the resources that we’ve shared this week help you to create beautiful, engaging UIs that your users will love. Thanks to everyone who tuned in or joined us for the AMA. Follow the Modern UI pathway to learn how to leverage Material Design, animation or the latest Android 11 features. Take the Compose pathway to learn about the future of Android UI development and help shape it with your feedback.

Resources

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

August 28th 2020, 3:05 pm

Announcing Jetpack Compose Alpha!

Android Developers Blog

Posted by Karen Ng, Director, Product Management

Today, we’re releasing the alpha of Jetpack Compose, our modern UI toolkit designed to help you quickly and easily build beautiful apps across all Android platforms, with native access to the platform APIs. Bring your app to life with dramatically less code, interactive tools, and intuitive Kotlin APIs.

No matter where you’re working from -- whether it’s your kitchen table or an office, we know you need a programming language, an IDE and a powerful UI framework that can save you time and reduce how much code you need to write. So we built Jetpack Compose to make you (and us!) more productive with building UI.

We started with Android Jetpack — taking the hardest, most common developer problems on Android and creating a suite of libraries that ensure high quality apps that work across all versions of the platform. Today, 84% of the top 10,000 apps in the Play store are using a Jetpack library.

Then we heard how developers love Kotlin, with over 70% of the top 1000 apps and 60% of pro Android developers using Kotlin today. The Google Home app saw, in certain instances, an 80% reduction in lines of code by using Kotlin and a decrease of NullPointerExceptions by 33% compared to a similar past period. Duolingo, saw reduced line count by an average of 30%.

Finally, we heard strong feedback from the community that developers like the simplicity of declarative APIs for building UI. Jetpack Compose combines all three of these: APIs for high quality apps at scale, an intuitive language, and a reactive programming model.

Jetpack Compose: Now in Alpha

Jetpack Compose Alpha has what you need to build full-fledged Android apps, including powerful tools and interoperability with existing Android views so you don’t need to rewrite your app. Compose APIs are designed and developed hand-in-hand with a set of canonical sample apps that use Material Design that we’re excited to release today! You can import and explore the latest samples directly in Android Studio as well.

The alpha release includes:

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

Thinking in Compose

Compose uses a programming model that is quite different from the existing model of building UI on Android. Historically, an Android view hierarchy has been represented as a tree of UI widgets. As the state of the app changes, the UI hierarchy needs to be updated to display the current data. The most common way of updating the UI is to walk the tree using functions like findViewById(), and change nodes by calling methods like:

 button.setText(String) 
container.addView(View) 
 img.setImageBitmap(Bitmap) 
These methods change the internal state of the widget. Not only can this be tedious, but updating views manually increases the likelihood of errors (e.g. forgetting to update a view).

Jetpack Compose is a fully declarative component-based approach, meaning you describe your UI as functions that transform data into a UI hierarchy. When the underlying data changes, the Compose framework automatically updates the UI hierarchy for you, making it simple to build UIs easily and quickly.

Full interop with existing Android views

Adopting any new framework is a big change for existing projects and codebases, which is why we’ve designed Compose to be as easy to adopt as Kotlin — it is fully interoperable with existing Android code, from day one.

Migrating to Compose depends on you and your team. If you're building a new app, the best option might be to implement your entire UI with Compose. We know that most of you have large existing codebases, so rather than rewriting your app, you can combine Compose with your existing UI design.

There are two main ways you can combine Compose with a view-based UI:

We’ve also published a new library, MDC Compose Theme Adapter, which allows you to reuse your existing Material Components themes within your Compose UI.

To learn more, try the Compose for existing apps codelab or check out these two samples:

Powerful Tools

Jetpack Compose is built with powerful tooling in Android Studio, designed to help you iterate quickly on the piece of UI you’re working on.

The Compose layout preview enables you to preview your Compose components without having to deploy your app to a device or emulator. As you develop your app, your previews update to help you review your changes faster. To create a layout preview, write a composable function that does not take any parameters, and add the

 @Preview annotation 
After you build your app, the preview function's UI appears in Studio's Preview pane.

Android Studio provides an interactive preview mode. While you're in interactive preview mode, you can click or type in your UI elements, and the UI responds as if it were in the installed app.

You can also deploy a single composable to your physical device or Android Emulator. Android Studio creates a new activity containing the UI generated by that function, and deploys it to your app on the device. This lets you try out the UI on an actual device without needing to reinstall the entire app or navigate to its location.

Get started with Jetpack Compose

To get started with Jetpack Compose, try the Compose Tutorial and get setup. Or dive right into the sample apps and walk through those apps in ‘Compose by Example’:

To find a comprehensive set of Compose resources, from new codelabs and expanded documentation, see the Compose pathway.

Since we open-sourced Jetpack Compose last year, so many of you have given us invaluable feedback, logged bugs, or contributed CLs and have gotten us where we are today. Thank you!

Compose isn’t recommended for full production use yet, in particular as we work towards API stability and finish performance optimizations, but we’d love you to give it a try and share feedback. Join us in the discussion on the #compose channel at Kotlin Slack. Compose 1.0 is expected in 2021.

Happy Composing!

August 26th 2020, 1:20 pm

11 Weeks of Android: Games, media, and 5G

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

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

What's the buzz in Android 11?


Android 11 media

We covered how to take advantage of Android 11's new media controls by making sure your app is using MediaStyle with a valid MediaSession token. We showed how to support Media resumption by making your app discoverable with a MediaBrowserServiceCompat, using the EXTRA_RECENT hint to help with resuming content, and handling the onPlay and onGetRoot callbacks. Finally we showed you how to leverage the MediaRouter jetpack library to support seamless media transfer between devices. Check out the updated version of the UAMP sample which contains a reference implementation for media controls and playback resumption.

Android 11 and 5G

We covered some of the primary ways apps can benefit from 5g, including:

Android 11 adds new APIs and updates existing APIs to ensure you have all the tools you need to leverage the capabilities of 5G, such as an enhanced bandwidth estimation API, 5G detection capabilities, and a new meteredness flag from cellular carriers. The Android emulator now enables you to develop and test these APIs without needing a 5G device or network connection. All of this and more is available from our dedicated 5G page.

Catch up on what's happening with game development

We presented a special "11 Weeks" episode of The Android Game Developer Show providing an update on the tools, services, and technologies we're bringing to help you build, optimize, and distribute great games.

Check out d.android.com/games to learn about everything we've covered this week and more, and stay up to date by signing up for the games quarterly newsletter.

Android game development tooling

In Android Studio 4.1, we enhanced the System Trace view of the CPU Profiler and added the Native Memory Profiler, and both can now be launched standalone from Android Studio. The System Trace and Native Memory blog posts have more details on how to use them with your game or app.

You can sign up for developer previews of the Android Game Development Extension, and the Android GPU Inspector. The Android Game Development Extension helps with building multi-platform C/C++ games, while the GPU Inspector is used to profile and debug graphics. Stay tuned for the open beta of the Android GPU Inspector.

Reaching more devices and users with your game

We took a deep dive into the Android Performance Tuner, explaining annotations, quality levels, and fidelity parameters along with some best practices on how to use them. Once you've implemented that, we also covered how to use the new insights and analysis you'll get within Android Vitals.

We showed how Google Play Asset Delivery brings the benefits of app bundles to games with large asset sizes, flexible delivery modes, auto-updates, compression, and delta patching. Texture compression format targeting is coming very soon letting you tap into modern texture compression such as ASTC (now supported on over 50% of devices) allowing you to considerably cut your game size and in-memory footprint.

We published new codelabs to help you integrate Android Performance Tuner and Google Play Asset Delivery into your Unity or native C/C++ game.

We explained how we can help protect your game, players, and business by fighting monetization and distribution abuse.

Boost your games' go-to-market

We launched the open beta of Play Games Services - Friends to help you bootstrap and enhance your in-game friend networks while having your games surfaced in new clusters in the Play Games app.

We demonstrated the new release management experience in the Google Play Console beta and showed how it can help your testing and publishing workflow.

Day one auto-installs is a new Google Play feature that allows users to request the automatic installation of your game during pre-registration. Early experiments show a +20% increase in day 1 installs when using this feature. The new pre-registration menu in the beta Google Play Console makes it easier than ever to access this feature.

We showed how to optimize your store listing page to take advantage of the greatly improved games visual experience within Google Play, showcasing rich game graphics and engaging videos.

The new in-app review API lets you choose when to prompt users to write reviews from within your game, without heading back to the app details page. This API supports both public and private reviews for when your app is in beta.

Learning path

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

Key takeaways

Thank you for tuning in and learning about the latest in Android game, media, and 5G development.

Seamless media transfer and media resumption

MediaRouter API (UAMP Sample)

5G

Bandwidth estimation API

5G Detection (Android Emulator)

Meteredness flag

Features found in Android Studio 4.1 (Beta Channel)

System Trace in Android Studio CPU Profiler

Android Studio Native Memory Profiler

Pre-release standalone tools

Android Game Development Extension

Android GPU Inspector.

Features in the Android Game SDK

Android Frame Pacing Library

Android Performance Tuner (C/C++ Codelab) (Unity Codelab)

Google Play features

Play Asset Delivery (C/C++ Codelab) (Unity Codelab)

In App Review API

App Licensing

SafetyNet Attestation

Pre-registration

Google Play Games Services

Play Games Services Friends Beta

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

August 21st 2020, 3:27 pm

Getting ready for 5G on Android

Android Developers Blog

Posted by Stella Loh, Product Manager, Android 5G

Getting ready for 5G on Android

Connectivity is the lifeblood that makes all of the experiences on our phones come alive, helping us connect, communicate, and express ourselves to the people that we care about. As app developers, this mission is as important now as it’s ever been. You’ve probably heard the buzz around 5G and wondered: what does this mean for my app? As we dive into Media & Games as part of this weeks' #11WeeksofAndroid, two areas where 5G offers a lot of potential, we wanted to spotlight ways for you to think about taking advantage of 5G for your app or game.

Transforming your app or game with 5G: unlocking new experiences

5G isn’t just about faster connectivity: it’s about unlocking transformative new experiences, and we want to see how you continue to push the bar.

We’ve been hard at work building in support for 5G on Android, and have been working with 5G carriers starting with Verizon and AT&T in the U.S., as well as others in Europe and Asia to provide necessary Android features for app developers looking to build 5G experiences.

In addition to working with the carriers, we have been updating and adding new APIs to ensure you have all the tools you need to leverage the capabilities of 5G. First, we enhanced the functionality of our bandwidth estimation API. Then we added 5G detection capabilities, so you know when to take it up a notch. Lastly, we added a new meteredness flag from cellular carriers so you know when your user isn’t being charged for bandwidth, and can really bring it!

We’ve also added features to the Android SDK emulator to enable you to develop and test these APIs without needing a 5G device or network connection.

All of this means that 5G starts here and now. Check out our new page dedicated to 5G so you can start imagining how 5G can transform your app.

August 21st 2020, 9:23 am

Playing nicely with media controls

Android Developers Blog

Posted by Don Turner - Developer Advocate - Android Media

In Android 11 we've made it easier than ever for users to control media playback. This is achieved with three related features: media controls, playback resumption and seamless transfer.

This article will explain what these features are, how they work together and how you can take advantage of them in your apps.

Media Controls

Android 11's media controls are found below the Quick Settings panel and represent a dedicated persistent space for controlling media playback.

Media controls in Android 11

Part of the motivation for media controls is that users often have multiple media apps (music player, podcasts, video player etc) and regularly switch between them. Media controls display up to five current and recent media sessions in a carousel allowing the user to swipe between them.

On Android 10 and earlier, media notifications for multiple apps can occupy most of the notification area. All those control buttons can also be confusing. Moving the controls into a dedicated space means that there's more room for other notifications, and provides a more consistent user experience for controlling media apps.

Here's the comparison:

Android 10 media notifications (left) Android 11 media controls (right)

Displaying media controls for your app

Now, the really good news. As long as you're using MediaStyle with a valid MediaSession token (both available since Lollipop API 21), media controls will be displayed for your app automatically - no extra work for you!

In case you're not using a MediaStyle and MediaSession here's a quick recap in code:

// Create a media session. NotificationCompat.MediaStyle
// PlayerService is your own Service or Activity responsible for media playback.  
val mediaSession = MediaSessionCompat(this, "PlayerService")

// Create a MediaStyle object and supply your media session token to it. 
val mediaStyle = Notification.MediaStyle().setMediaSession(mediaSession.sessionToken)

// Create a Notification which is styled by your MediaStyle object. 
// This connects your media session to the media controls. 
// Don't forget to include a small icon.
val notification = Notification.Builder(this@PlayerService, CHANNEL_ID)
            .setStyle(mediaStyle)
            .setSmallIcon(R.drawable.ic_app_logo)
            .build()

// Specify any actions which your users can perform, such as pausing and skipping to the next track. 
val pauseAction: Notification.Action = Notification.Action.Builder(
            pauseIcon, "Pause", pauseIntent
        ).build()
notification.addAction(pauseAction)

The small icon and app name are shown in the upper left of the media controls. The actions are shown in the bottom center.

Media controls UI and corresponding Notification fields

The remaining UI fields, such as track title and playback position, are obtained from the media session's metadata and playback state.

Here's how the metadata fields map to the UI.

mediaSession.setMetadata(
    MediaMetadataCompat.Builder()
        
        // Title. 
        .putString(MediaMetadata.METADATA_KEY_TITLE, currentTrack.title)

        // Artist. 
        // Could also be the channel name or TV series.
        .putString(MediaMetadata.METADATA_KEY_ARTIST, currentTrack.artist)
        
        // Album art. 
        // Could also be a screenshot or hero image for video content
        // The URI scheme needs to be "content", "file", or "android.resource".
        .putString(
            MediaMetadata.METADATA_KEY_ALBUM_ART_URI, currentTrack.albumArtUri)
        )

        // Duration. 
        // If duration isn't set, such as for live broadcasts, then the progress
        // indicator won't be shown on the seekbar.
        .putLong(MediaMetadata.METADATA_KEY_DURATION, currentTrack.duration) // 4

        .build()
)

This screenshot shows how these metadata fields are displayed in the media controls.

Media controls UI and corresponding metadata fields

The seek bar is updated using the media session's playback state in a similar way:

mediaSession.setPlaybackState(
    PlaybackStateCompat.Builder()
        .setState(
            PlaybackStateCompat.STATE_PLAYING,
                        
            // Playback position.
            // Used to update the elapsed time and the progress bar. 
            mediaPlayer.currentPosition.toLong(), 
                        
            // Playback speed. 
            // Determines the rate at which the elapsed time changes. 
            playbackSpeed
        )

        // isSeekable. 
        // Adding the SEEK_TO action indicates that seeking is supported 
        // and makes the seekbar position marker draggable. If this is not 
        // supplied seek will be disabled but progress will still be shown.
        .setActions(PlaybackStateCompat.ACTION_SEEK_TO)
        .build()
)

This screenshot shows how these playback state fields are displayed in the media controls.

Media controls UI and corresponding playback state fields

Your media controls should now look and function perfectly!

Media resumption

Ever wanted to continue listening to a podcast, TV episode or DJ set but couldn't remember where you left off, or even the app that was playing it? Media resumption solves this problem.

There are two stages to media resumption: discovering recent media apps and resuming playback.

Discovering recent media apps

After booting, Android will look for recent media apps and ask them what their most recently played content was. It will then create media controls for that content.

To be discoverable your app must provide a MediaBrowserService, typically using the MediaBrowserServiceCompat library from Android Jetpack.

On boot, Android will call your MediaBrowserServiceCompat's onGetRoot method, so it's imperative that you return quickly. Usually you would return the root of your media tree from this method but the system also specifies the EXTRA_RECENT hint.

You should treat EXTRA_RECENT as a special case and instead return the root of a media tree that contains the most recently played media item as the first element.

The system will call your onLoadChildren method to obtain this media tree, which is a list of MediaItem objects.

Here's a diagram showing how the system and a media app interact to retrieve the most recently played item.

How the system retrieves the most recently played item from the MediaBrowserService

For the first playable media item in this list the system will create static media controls with just a play button.

Static media controls

At this point no media session has been created. This is to save resources - the system doesn't know whether the user actually wants to resume playing that content yet.

Resuming playback

If the user taps the play button the system will make another call to onGetRoot with the EXTRA_RECENT hint. This is so you can prepare your previously played content as before, just in case anything has changed since the static controls were created.

Android will then connect to your media session and issue a play command to it. You should override the media session onPlay callback in order to start playback of your media content and create your MediaStyle notification.

Once you post the notification the static media controls will be swapped with the media controls created from your notification.

Figure 7: Diagram showing interaction between System UI and media app when resuming playback

Seamless media transfer

As well as being able to resume media sessions, Android 11 also allows you to easily transfer playback from one device to another. This is known as "seamless media transfer", and is done through the output switcher. The output switcher is shown in the upper right corner of the media notification that appears below.

Output Switcher (upper right corner)

The output switcher shows the name and icon of the current media route; and when you tap on it you'll see a list of media routes which this app supports.

Media routes available to the current app

By default, only local media routes are shown. If your app supports other media routes, such as remote playback you'll need to let the system know.

To do this add the MediaRouter jetpack library to your app.

dependencies {
    implementation 'androidx.mediarouter:mediarouter:1.2.0-alpha02'`
}

Seamless media transfer is supported from 1.2.0-alpha02.

Then, add the MediaTransferReceiver class to your Android manifest.

<receiver android:name="androidx.mediarouter.media.MediaTransferReceiver" />

Now in your app, obtain the MediaRouter singleton - this is an object that maintains the state of all currently available media routes.

router = MediaRouter.getInstance(this)

Create a MediaRouteSelector and specify the route categories which your app supports. The categories you define here determine the routes which are displayed in the output switcher.

Here we'll just specify the "remote playback" category which is used for Cast devices.

routeSelector = MediaRouteSelector.Builder() // Add control categories that this media app is interested in.
            .addControlCategory(MediaControlIntent.CATEGORY_REMOTE_PLAYBACK)
            .build()

If you want to support transfer from remote to local devices, you need to explicitly enable this using setTransferToLocalEnabled:

router.routerParams = MediaRouterParams.Builder().setTransferToLocalEnabled(true).build()

We can now use our selector when adding a media router callback.

router.addCallback(routeSelector, MediaRouterCallback(),
             MediaRouter.CALLBACK_FLAG_REQUEST_DISCOVERY);

We also supply a callback object so we can be informed of changes to media routes.

Here's the callback class:

    private class MediaRouterCallback : MediaRouter.Callback() {
        override fun onRouteSelected(
            router: MediaRouter,
            route: MediaRouter.RouteInfo,
            reason: Int
        ) {
            if (reason == MediaRouter.UNSELECT_REASON_ROUTE_CHANGED) {
                Timber.d("Unselected because route changed, continue playback")
            } else if (reason == MediaRouter.UNSELECT_REASON_STOPPED) {
                Timber.d("Unselected because route was stopped, stop playback")
            }
        }
    }

The method we override is onRouteSelected which will be called whenever a new media route has been selected.

When this happens we need to take into account the reason why it was selected.

If the existing route was disconnected (for example, bluetooth headphones were switched off) we should pause or stop playback.

If the route was actively changed, for example when switching from a phone to a Cast device, then we should continue playing the media from its previous playback position - this is the "seamless" part of "seamless media transfer" :)

Get started

To get started with media controls and related features on Android 11 take a look at the official documentation. Also be sure to check out UAMP which contains a reference implementation for many of the features mentioned in this article.

Good luck and remember to play nicely!

August 20th 2020, 6:17 pm

New language features and more in Kotlin 1.4

Android Developers Blog

Posted by Wojtek Kaliciński, Developer Advocate, Android

When we adopted Kotlin as a supported language on Android, and then shifted to a Kotlin-first approach, one of the main drivers was the excitement and adoption from the developer community. As Kotlin has grown, we’ve seen continued investment in the language from JetBrains (Kotlin's creators), the open source community, and increasingly our own teams at Google.

Today we are excited to share the news about the Kotlin 1.4 release, the next milestone in the evolution of Kotlin, which contains new language features, improved compilers and tools. Below you'll find a brief rundown of some exciting new features in this release. You can read more about Kotlin 1.4 in the official announcement.

New language features

New language features introduced in Kotlin 1.4 improve the ergonomics of writing Kotlin code. Here's just one example:

SAM conversions for Kotlin interfaces

Previously, only functional interfaces (i.e. having just a Single Abstract Method - SAM) defined in the Java programming language benefited from the shorthand syntax in Kotlin:

executor.execute { println("This is shorthand for passing in a Runnable") }

In Kotlin 1.4 you can now mark your Kotlin interfaces as functional and get them to work in a similar manner by adding the fun keyword:

fun interface Transformer<T, U> {
   fun transform(x: T): U
}
val length = Transformer {
   x: String -> x.length
}

You can read more about new language features such as: mixing named and positional arguments, trailing comma, callable reference improvements, and using break and continue inside when included in loops on the Kotlin 1.4 release notes page.

Explicit API mode

One additional feature is the new Explicit API mode for authors of libraries written in Kotlin.

It enforces certain language properties of Kotlin that are normally optional, such as specifying visibility modifiers, as well as explicit typing for any public declarations, in order to prevent mistakes when designing the public API of your library. Refer to the linked documentation for instructions how to enable Explicit API mode and start using these additional checks.

Compiler improvements

The language features mentioned above are some of the most developer-facing changes in Kotlin 1.4, however the bulk of work went into improving the overall quality and performance of the Kotlin compiler.

One of the benefits all developers can take advantage of right now is the new, more powerful type inference algorithm, which is now enabled by default. It will help developers be more productive by supporting more smart-casts and cases where types can be inferred automatically.

Other than the type inference algorithm, Kotlin 1.4 also brings in optional, Alpha stability compiler backends for Kotlin/JVM and Kotlin/JS, which generate code in what's called internal representation (IR) also used in the Kotlin/Native backend.

The Kotlin/JVM IR backend is a requirement for Jetpack Compose, and Google engineers are working together with JetBrains to make it the default JVM compiler backend in the future.

That's why, even if you're not currently developing with Jetpack Compose, we encourage you to try out the new Kotlin/JVM backend, currently in alpha, and to file any issues and feature requests to the issue tracker.

To enable the new JVM IR backend, specify an additional compiler option in your Gradle build script:

kotlinOptions.useIR = true

Try Kotlin 1.4 now!

There are two steps to updating your projects and IDE to Kotlin 1.4.

First, make sure you are on the latest version of Android Studio to maximize the performance benefits and compatibility with the newest Kotlin plugin. Android Studio will prompt you when a Kotlin 1.4.0 plugin that is compatible with your IDE version is available. Alternatively, you can go to Preferences | Plugins and manually trigger the update.

Once the plugin is enabled, you can upgrade your app project to use Kotlin 1.4 by updating the Kotlin Gradle plugin version in your build.gradle scripts. Depending on how you manage your plugins, you either have to update the version in the top-level project's buildscript block:

buildscript {
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.0"
    }
}

Or change the version number in the plugins block in a module level build.gradle file:

plugins {
    id 'org.jetbrains.kotlin.android' version '1.4.0'
}

Make sure to read the language changes carefully and update your project's code to ensure compatibility with the latest release. Enjoy Kotlin 1.4!

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

August 17th 2020, 1:52 pm

What’s new for Android game developers: August update

Android Developers Blog

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

Welcome to our latest Android games update and the start of our #11WeeksOfAndroid week focused on games, media and 5G. With all of your interest and feedback in our developer previews, tools and services, we have lots to share in our ongoing efforts to help you better understand your game’s performance, expand your reach to more devices and new audiences, and support your go-to-market with Google Play.

Get the latest updates below and follow us at @AndroidDev for additional games resources and more.

Android tools for mobile game development

Reach more devices and users

Boost your go-to-market

Check out d.android.com/games to learn about these tools and more, and stay up to date by signing up for the games quarterly newsletter.


How useful did you find this blog post?

August 17th 2020, 12:22 pm

11 Weeks of Android: Beyond phones

Android Developers Blog

Posted by Product Leads for Android TV, Android for cars, Wear OS, and Chrome OS

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

With Android, people can experience the apps and services that they love across many devices & surfaces. Beyond phones, Android offers distinct yet familiar experiences on devices of all shapes and sizes, ranging from the smallest smartwatch screens, to larger displays on foldables and Chromebooks, to in-car entertainment systems, and all the way up to the largest television screens. For the past 4 days, we featured a daily deep dive into each of these exciting form factors that are providing developers with new and growing ways to engage people. Read on for a recap.

Android TV

We kicked off the week with Android TV, which is now partnering with 7 of the top 10 OEMs and over 160 television operators across the globe. The Android TV team highlighted 6 upcoming launches, like instant app trials right from Google Play and an updated Gboard, to help developers acquire more users, more easily monetize, and build even more engaging experiences. Then, new resources were published to help developers build their first Android TV app, or even go deep on new integrations like Cast Connect and frictionless subscriptions. If you’re excited about developing for TV, pick up an ADT-3, learn the latest from the training pathway, and bring your Android app to the biggest screen in the home!

Android for Cars

We shared new ways to reach more drivers on Android for cars. Android Auto, which allows you to connect your phone to your car display, is currently available with nearly every major car manufacturer and is on track to reach 100 million cars. Soon, new app categories including navigation, parking, and electric vehicle charging will be available and the experience for Android Auto users will become even more seamless as car manufacturers continue to add support for wireless connectivity. We also highlighted the launch of the first car powered by Android Automotive OS with Google apps and services built in — the Polestar 2. As more manufacturers ship cars with this embedded functionality, we’re making it even easier for developers to build media apps on Android Automotive OS with updated documentation and emulators. Get started today to bring your app to cars!

Large Screens

We covered large screens starting with the announcement of ChromeOS.dev — a dedicated resource for technical developers, designers, product managers, and business leaders. We’ve showcased our growth in device sales in Chrome OS, seeing Chromebook unit sales grew 127% year over year between March and June this year1, as well as some of the new features coming, such as customizable Linux Terminal and Android Emulator support. We’ve also continued to see growth in apps optimized for larger screen experiences, with over 1 million apps optimized for tablets and large screens available in the Google Play store. To help you develop the best-in-class apps for Chrome OS, foldables and tablets, we are continuing to release new features and updates. We released new design recommendations for your app as well as a few updates made in Android Studio. Check out the new sessions and some of the resurfaced content to learn more about bringing the best experiences to your users on these large-screen devices.

Wear OS

To round out the week, we talked about Wear OS where we are investing in the fundamentals with a focus on performance and faster app startup times, which you’ll see in the latest platform release coming in the fall. Wear OS will be launching updates to cornerstone features like Weather in the coming months, and is investing in helpful experiences, such as our recent hand-wash timer to help people maintain hand-hygiene in the Covid-19 pandemic. The team is working hard to bring the best of Android 11 to Wear OS.

Learning paths

Are you building your apps with different screen sizes and form factors in mind? Check out all the resources for Wear OS and Android for cars, and if you’re looking for an easy way to pick up the highlights of this week for Android TV and large screens, consider completing the pathway for each. These include codelabs, videos, articles and blog posts. A virtual badge is awarded to each user who passes the quiz.

We hope that you found the Android Beyond Phones week useful, and we're excited to see all the great experiences that you'll build on these platforms!

Resources

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

Sources:
1 The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on unit sales, April–June 2020 and March–June 2020​.

August 14th 2020, 1:16 pm

What’s happening in Wear OS by Google

Android Developers Blog

Posted by Karen Ng, Director of Product and Robert Simpson, Product Manager

This blog post is part of a weekly series for #11WeeksOfAndroid. For each week, we’re diving into a key area and this week we’re focusing on Android Beyond Phones. Today, we’ll share what’s happening with Wear OS by Google.

Wearable technologies help people lead healthier lives and connect with important, timely information. Today, we're sharing our areas of investment focusing on the fundamentals, bringing even more helpful experiences to more watches, and giving users more choice in a device ecosystem.

Focusing on fundamentals

Wearables are designed to instantly connect people with what's important throughout the day. That's why we're focused on fundamentals like performance and power.

In the next OTA update coming in the fall, we’re improving performance by making it faster to access your info and start your apps. We’re simplifying the pairing process to make onboarding easier. You’ll see improvements to our SysUI for more intuitive controls for managing different watch modes and workouts. And with CPU core improvements, you’ll also see up to a 20% speed improvement in startup time for your apps.

Finally, we continue to support advancements in technology to bring new functionality, such as LTE, and expand levels of performance with the new Qualcomm® Snapdragon Wear™ 4100 and 4100+ platforms. We are excited by the kinds of wearable experiences that can be enabled in the future.

More helpful experiences

Wearables showcase important information at a glance. Some of the most used features of Wear OS by Google are hands-free timers and tracking fitness metrics. In response to COVID-19, we built a handwashing timer that helps ensure users practice good hygiene.

And later this year, you’ll see a beautiful new weather experience for Wear OS by Google. It aims to be easier to read while on the go, with an hourly breakdown of today’s weather to help you plan ahead and provide information about important weather alerts in your area.

We’re always imagining new ways wearables can help people stay healthy, present and connected. Stay tuned for more in 2021!

More choice than ever

We’re excited to welcome new watch OEMs to the Wear OS by Google family -- Oppo, Suunto, and Xiaomi. This means new watches that fit your style and needs -- such as the Suunto 7 with rich sports capabilities, or the new LTE watches from Oppo that will keep you connected on the go.

Bringing the best of Android to wearables

We’re also working to bring the best of Android 11 to wearables. Many of the things you’ve seen in modern Android development -- from Android Studio, a great language with Kotlin, and Jetpack libraries to make common tasks easier will be part of what you can expect as a developer building wearable apps. We’ve just released a release candidate for androidx.wear 1.1.0, and would love feedback on things you’d like to see as you get started building a wearable app.

We can’t wait to see what helpful experiences you’ll build!

August 13th 2020, 9:18 am

ChromeOS.dev — A blueprint to build world-class apps and games for Chrome OS

Android Developers Blog

Posted by Iein Valdez, Head of Chrome OS Developer Relations

This article originally appeared on ChromeOS.dev.

While people are spending more time at home than on the go, they’re relying increasingly on personal desktops and laptops to make everyday life easier. Whether they’re video-chatting with friends and family, discovering entertaining apps and games, multitasking at work, or pursuing a passion project, bigger screens and better performance have made all the difference.

This trend was clear from March through June 2020: Chromebook unit sales grew 127% year over year (YOY) while the rest of the U.S. notebook category increased by 40% YOY.1 Laptops have become crucial to people at home who want to use their favorite apps and games, like Star Trek™ Fleet Command and Reigns: Game of Thrones to enjoy action-packed adventure, Calm to manage stress, or Disney+ to keep the whole family entertained.

To deliver app experiences that truly improve people’s lives, developers must be equipped with the right tools, resources, and best practices. That’s why we’re excited to introduce ChromeOS.dev — a dedicated resource for technical developers, designers, product managers, and business leaders.

ChromeOS.dev, available in English and Spanish (with other languages coming soon), features the latest news, product announcements, technical documentation, and code samples from popular apps. Whether you’re a web, Android, or Linux developer who’s just getting started or a certified expert, you’ll find all the information you need on ChromeOS.dev.

Hear from our experts at Google and Chrome OS, as well as a variety of developers, as they share practical tips, benefits, and the challenges of creating app experiences for today’s users. Plus, you can review the updated Chrome OS Layout and UX App Quality guidelines with helpful information on UI components, navigation, fonts, layouts, and everything that goes into creating world-class apps and games for Chrome OS.

Even better, as a fully open-source online destination, ChromeOS.dev is designed considering all the principles and methods for creating highly capable and reliable Progressive Web Apps (PWAs), ensuring developers always have quick, easy access to the information they need — even when they’re offline.

Check out a few of the newest updates and improvements below, and be sure to install the ChromeOS.dev PWA on your device to stay on top of the latest information.

New features for Chrome OS developers

Whether it’s developing Android, Linux, or web apps, every update on ChromeOS.dev is about making sure all developers can build better app experiences in a streamlined, easy-to-navigate environment.

Customizable Linux Terminal

The Linux (Beta) on Chrome OS Terminal now comes equipped with personalized features right out of the box, including:

Developers can now start using these and other customizable features in the Terminal app.

Android Emulator support

Supported Chromebooks can now run a full version of the Android Emulator, which allows developers to test apps on any Android version and device without needing the actual hardware. Android app developers can simulate map locations and other sensor data to test how an app performs with various motions, orientations, and environmental conditions. With the Android Emulator support in Chrome OS, developers can optimize for different Android versions and devices — including tablets and foldable smartphones — right from their Chromebook.

Deploy apps directly to Chrome OS

Building and testing Android apps on a single machine is simpler than ever. Now, developers who are running Chrome OS M81 and higher can deploy and test apps directly on their Chromebooks — no need to use developer mode or to connect different devices physically via USB. Combined with Android Emulator support, Chrome OS is equipped to support full Android development.

Improved Project Wizard in Android Studio

An updated Primary/Detail Activity Template in Android Studio offers complete support to build experiences for larger screens, including Chromebooks, tablets, and foldables. This updated option provides multiple layouts for both phones and larger-screen devices as well as better keyboard/mouse scaffolding. This feature will be available in Android Studio 4.2 Canary 8.

Updated support from Android lint checks

We’ve improved the default checks in Android’s lint tool to help developers identify and correct common coding issues to improve their apps on larger screens, such as non-resizable and portrait-locked activities. This feature is currently available for testing in Canary channel.

Unlock your app’s full potential with Chrome OS

From day one, our goal has been to help developers at every skill level create simple, powerful, and secure app experiences for all platforms. As our new reality creates a greater need for helpful and engaging apps on large-screen devices, we’re working hard to streamline the process by making Chrome OS more versatile, customizable, and intuitive.

Visit ChromeOS.dev and install it on your Chromebook to stay on top of the latest resources, product updates, thought-provoking insights, and inspiring success stories from Chrome OS developers worldwide.






Sources:
1 The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on unit sales, April–June 2020 and March–June 2020​.

August 12th 2020, 12:40 pm

New ways to reach more drivers on Android for cars

Android Developers Blog

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

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

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

Android Auto momentum

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

Expanding Android Auto’s app ecosystem

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

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

Early access partners for new apps on Android Auto

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

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

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

Android Automotive OS adoption

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

Extending the reach of media apps in cars

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

Making it easier to develop media apps for Android Automotive OS

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

Polestar 2 and Google Generic Automotive system images for Android emulator

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

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

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

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

Resources

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

August 11th 2020, 9:15 am

6 New ways to engage with users on Android TV

Android Developers Blog

Posted by Dan Aharon, Product Manager, Android TV

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

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

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

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

Easier acquisition and monetization

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

More engaging user experiences

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

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

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

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

August 10th 2020, 9:05 am

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

Android Developers Blog

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

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

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

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

Key takeaways

  1. We released several webinars about the new Google Play Console beta. Check out the videos if you weren’t able to tune in live.
  2. We shared recent improvements we’ve made to app bundles, as well as our intention to require new apps and games to publish with this format in the second half of 2021.
  3. Developers can now ask for ratings and reviews from within your app with the new in-app review API.
  4. To increase user trust in our billing platform, we made some product updates and reminded you of our policy around more transparent subscriptions. We also expanded our feature set to help you better reach and retain buyers, and launched Play Billing Library 3, which will be required by mid-2021.
  5. Google Play Pass launched in nine new markets last month. With an innovative revenue model, participating titles together have earned 2.5x the revenue of Google Play Store-only sales, without diminishing Play Store earnings. You can learn more and express interest in joining.

Google Play Console beta

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

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

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

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

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

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

Android App Bundle

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

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

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

In-app review API

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

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

Google Play Commerce

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

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

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

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

Google Play Pass

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

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

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

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

Learning path

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

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

Resources

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

August 7th 2020, 9:49 am

Android 11 final Beta update, official release coming soon!

Android Developers Blog

Posted by Dave Burke, VP of Engineering

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

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

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

What’s in Beta 3?

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

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

Get your apps ready for Android 11!

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

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

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

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

For more information on compatibility testing and tools, check out the resources we shared for Android 11 Compatibility week and visit the Android 11 developer site for technical details.

Explore the new features and APIs

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

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

How do I get Beta 3?

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

What’s next?

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

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

August 6th 2020, 1:04 pm

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

Android Developers Blog

Posted by Scott Lin, Product Manager, Google Play

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

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

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

Ask for a review at just the right time

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

Users can now give ratings and reviews within your app.

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

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

The integration consists of four main steps:

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

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

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

Gathering the best feedback

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

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

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

- Chris Scoville, Engineering Manager at Calm



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

- Nathaniel Khuana, Technical Architect, Tokopedia



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

- Welly Chandra, Associate Product Manager at Traveloka







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

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

How useful did you find this blog post?

August 5th 2020, 9:14 am

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

Android Developers Blog

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

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

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

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

Play Feature Delivery

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

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

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

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

Play Asset Delivery

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

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

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

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

Google Play’s best-in-class distribution

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

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

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

Requirement for new apps in the second half of 2021

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

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

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


How useful did you find this blog post?

August 4th 2020, 9:08 am

Protecting your Google Play Console account with 2-Step Verification

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play Console

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

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

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

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

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

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

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

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


How useful did you find this blog post?

August 3rd 2020, 11:43 am

11 Weeks of Android: Android Developer Tools

Android Developers Blog

Posted by Jamal Eason, Product Manager, Android

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

The big news

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

What to watch and read

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

What’s New in Android Development Tools

Design

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

What’s new in Design Tools

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

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

Debugging UI issues with Layout Inspector

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

What's new in Compose Design Tools

Coding & Deployment

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

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

Database Inspector

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

Build

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

Android Emulator

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

Performance Profilers

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

Troubleshooting app performance issues with System Trace in Android Studio

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

Learning path

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

Key takeaways

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

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

Features found in Android Studio 4.0 (Stable Channel)

Features found in Android Studio 4.1 (Beta Channel)

Features found in Android Studio 4.2 + (Canary Channel)

Resources

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

July 31st 2020, 7:10 pm

Introducing the Motion Editor

Android Developers Blog

Posted by Scott Swarthout, Product Manager

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

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

Animation running in the Motion Editor

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

Motion Editor

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

The Motion Editor has four main panels


Overview panel

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

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


Selection panel

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

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

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

MotionLayout selected

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

Check if components are properly constrained with the Selection panel

ConstraintSet selected

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

Select components to be included in the ConstraintSet


Transition selected

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

Preview animations on the Motion Editor timeline

Keyframes

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

Create keyframes with the selection panel


Attribute panel

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

Constraint visualization in the Attribute panel

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

Preview panel

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

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



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



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

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

For more information on MotionLayout, see the following links:

July 27th 2020, 9:16 pm

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

Android Developers Blog

Posted by Leticia Lago, Head of Developer Marketing, EMEA

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

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

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

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

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

Europe

(In alphabetical order)

Cookies Must Die by Rebel Twins (Poland)

inbento by Afterburn (Poland)

The White Door by Rusty Lake (Netherlands)

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

60 Parsecs! by Robot Gentleman (Poland)

Alien Escape by KORION Interactive (Germany)

Alt-Frequencies by Accidental Queens (France)

Doors: Awakening by Big Loop Studios (Bulgaria)

My Diggy Dog 2 by King Bird Games (Russia)

Traffix by WebAvenue Unipessoal Lda (Portugal)

Void Tyrant by Quite Fresh Ltd. (United Kingdom)


Japan

(In alphabetical order)

GIGAFALL by Shiki Game Studio

METBOY! by REBUILD GAMES

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

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


Boku to hakubutsukan by oridio Inc.

GummyShooter by simatten

Home Fighter by hap Inc.

MonsterTrader by Mitsuhiro Okada

Snowman Story by Odencat

World for Two by Seventh rank

Zelle by Odencat


South Korea

(In alphabetical order)

Heroes Restaurant by Team Tapas

Magic Survival by LEME

Project Mars by Moontm

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

CAT THE DJ by CATSBY STUDIO

Dust by I-eye studio

Extreme Football by 9M Interactive

Great Sword by olivecrow

QV by izzle

Sand Shark: The Boy and The Sea by GABANGMAN STUDIO

Sword Master Story by CodeCAT

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



How useful did you find this blog post?

July 27th 2020, 11:41 am

11 Weeks of Android: Jetpack

Android Developers Blog

Posted by Diana Wong, Product Manager, Android Jetpack

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

The big news

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

What to watch

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

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

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

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

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

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

This year, we've made several major improvements with the release of Navigation 2.3, which allows you to navigate between different screens of your app with ease while also allowing you to follow Android UI principles. Let us navigate you through them all here:

Spotlight on Permissions

In Android 11, we continued our work to give users even more control over sensitive permissions. At the same time, it's very important to us that we make it as easy as possible for you as developers to build for Android. With the changes in privacy over the past several releases, Android Jetpack is making it easier for your app to work with Permissions. Now there are type-safe contracts for common intents and more via new ActivityResult APIs. These changes simplify how you request permissions, and we’ll continue to work on making permissions easier in the future. Find out more in this post.

Learning path

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

Key takeaways

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

Resources

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

July 24th 2020, 1:13 pm

Improving inter-activity communication with Jetpack ActivityResult

Android Developers Blog

Posted by Yacine Rezgui, Developer Advocate

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

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

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

What are the ActivityResult APIs?

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

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

How to use it

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

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

repositories {
    google()
    maven()
}

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

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

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

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

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

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

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

    val selectButton = findViewById<Button>(R.id.select_button)

    selectButton.setOnClickListener {
        // Pass in the mime type you'd like to allow the user to select
        // as the input
        getContent.launch("image/*")
    }
}

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

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

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

July 23rd 2020, 5:47 pm

Decrease startup time with Jetpack App Startup

Android Developers Blog

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

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

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

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

App Startup supports API level 14 and above.

How to use it

Gradle setup

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

repositories {
    google()
    maven()
}

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

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

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

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

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

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

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

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

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <!-- This entry makes WorkManagerInitializer discoverable. -->
    <meta-data android:name="com.example.WorkManagerInitializer"
          android:value="androidx.startup" />
</provider>

How it works

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

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

Lazy initialization

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

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

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <!-- disables eager initialization -->
    <meta-data android:name="com.example.WorkManagerInitializer"
              tools:node="remove" />
</provider>

To lazily initialize WorkManagerInitializer you can then use:

// This returns an instance of WorkManager
AppInitializer.getInstance(context)
    .initializeComponent(WorkManagerInitializer.class);

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

Final thoughts

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

July 23rd 2020, 3:14 pm

What’s New in Navigation 2020

Android Developers Blog

Posted by Jeremy Woods, Software Engineer, Android UI Toolkit

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

Dynamic Navigation

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

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

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

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

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

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

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

NavBackStackEntry: Unlocked

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

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

See Navigation and the back stack for more information.

NavGraph ViewModels

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

val viewModel: MyViewModel by navGraphViewModels(R.id.my_graph)

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

Returning a Result from a destination

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

In destination A:

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

And in destination B:

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

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

Testing your Navigation Flow

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

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

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

val navController = TestNavHostController(ApplicationProvider.getApplicationContext())

// This allows fragments to use by navGraphViewModels()
navController.setViewModelStore(ViewModelStore())
navController.setGraph(R.navigation.main_nav)

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

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

val navController = TestNavHostController(ApplicationProvider.getApplicationContext())

navController.setGraph(R.navigation.main_nav)
navController.setCurrentDestination(R.id.destination_1)

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

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

Nav Deep Linking

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

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

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

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

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

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

<fragment android:id="@+id/a"
          android:name="com.example.myapplication.FragmentA"
          tools:layout="@layout/a">
        <deeplink app:url="www.example.com"
                app:action="android.intent.action.MY_ACTION"
                app:mimeType="type/subtype"/>
    </fragment>

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

val baseUri = "http://www.example.com/"

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

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

Adding a deep link to a destination in the Navigation Editor

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

val deepLinkRequest = NavDeepLinkRequest.Builder
        .fromUri(Uri.parse("http://www.example.com"))
        .setAction("android.intent.action.MY_ACTION")
        .setMimeType("type/subtype")
        .build()
navController.navigate(deeplinkRequest)

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

Navigation Editor

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

Viewing a navigation.xml file in split view mode

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

Navigating through a graph in the Navigation Editor

Additional Changes

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

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

Wrap up

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

For more information about the Jetpack Navigation library, check out the documentation at https://developer.android.com/guide/navigation

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

July 23rd 2020, 12:02 pm

Getting on the same page with Paging 3

Android Developers Blog

Posted by Florina Muntenescu, Android Developer Advocate

Getting on the same page with Paging 3

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

Paging 3 highlights

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

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

Adopting Paging 3 in your app

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

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

Paging components and their integration in the app architecture"

Defining the data source

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

PagingSource

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

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

PagingData and Pager

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

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

val doggosPagingFlow = Pager(PagingConfig(pageSize = 10)) {
  DogRemotePagingSource(goodDoggosService)
}.flow.cachedIn(viewModelScope)

PagingDataAdapter

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

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

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

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

val viewModel by viewModels<DoggosViewModel>()

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

lifecycleScope.launch {
  viewModel.doggosPagingFlow.collectLatest { pagingData ->
    pagingAdapter.submitData(pagingData)
  }
}

Paged data transformations

Displaying a filtered list

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

doggosPagingFlow.map { pagingData ->
        pagingData.filter { dog -> dog.isPlayful }
    }

List with separators

Adding list separators is also a paged data transformation where we transform the PagingData to insert separator objects into the list. For example, we can insert letter separators for our doggos’ names. When using separators, you will need to implement your own UI model class that supports the new separator items. To modify your PagingData to add separators, you will use the insertSeparators transformation:

pager.flow.map { pagingData: PagingData<Dog> ->
  pagingData.map { doggo ->
    // Convert items in stream to UiModel.DogModel.
    UiModel.DogModel(doggo)
  }
  .insertSeparators<UiModel.DogModel, UiModel> { before: Dog, after: Dog ->
      return if(after == null) {
          // we're at the end of the list
          null
      }  
      if (before == null || before.breed != after.breed) {
          // breed above and below different, show separator
          UiModel.SeparatorItem(after.breed)
       } else {
           // no separator
           null
       }
    }
  }
}.cachedIn(viewModelScope)

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

Advanced Paging work with RemoteMediator

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

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

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

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

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

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

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

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

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

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

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



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

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

July 21st 2020, 9:25 am

11 Weeks of Android: Languages

Android Developers Blog

Posted by David Winer, Product Manager

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

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

Kotlin and coroutines

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

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

Getting started with Kotlin

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

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

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

The Java programming language and C++

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

The C++ developer experience continues to get better, too. Android 11 included updates across the native toolchain, including better tools for profile-guided optimization (PGO) and improvements to native dependency management in Android Studio 4.0.

Ever-improving toolchains

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

Resources

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

July 17th 2020, 5:03 pm

Google Home reduces #1 cause of crashes by 33%

Android Developers Blog

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

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

What they did:

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

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

Results:

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

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

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

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

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

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

Get Started:

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

July 16th 2020, 11:13 am

Learn Android and Kotlin with no programming experience

Android Developers Blog

Posted by Kat Kuan, Developer Advocate, Android

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

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

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

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

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

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

App screenshots from the course

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

Badges you can earn

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

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

We can’t wait to see what you build!

*from US tech job postings on Indeed.com

July 16th 2020, 9:14 am

Preparing your build for package visibility in Android 11

Android Developers Blog


Posted by David Winer, Product Manager


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

Android Studio and Gradle support

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

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

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

Manifest merger failed with multiple errors, see logs

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

Error: Missing 'package' key attribute on element package

Android Gradle plugin fixes

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

 buildscript {

    repositories {
        google()
        jcenter()
    }

    dependencies {
        // classpath 'com.android.tools.build:gradle:4.0.0'
        classpath 'com.android.tools.build:gradle:4.0.1'
    }
}


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

July 14th 2020, 1:34 pm

11 Weeks of Android: Android 11 Compatibility

Android Developers Blog


Posted by Dirk Dougherty, Android Developer Relations

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

The big news

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

Taking center stage

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

What to watch

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

Learning path

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

Key takeaways

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

Resources

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

July 10th 2020, 5:37 pm

Accelerating Android Updates

Android Developers Blog

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

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

Android 10 Adoption

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

Updatability in Android 11

Below are the major themes in updatability this year:

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

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

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

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

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

Looking to the Future

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

July 9th 2020, 12:34 pm

Android 11 Beta 2 and Platform Stability

Android Developers Blog

Posted by Dave Burke, VP of Engineering

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

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

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

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

Platform Stability

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

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

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

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



Why app compatibility is important

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

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

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

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

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

Making app compatibility easier in Android 11

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



Get your apps ready for Android 11!

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

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

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

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

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

Explore the new features and APIs

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

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

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

How do I get Beta 2?

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

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

Android 11 compatibility week

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

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

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

July 8th 2020, 1:11 pm

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

Android Developers Blog

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

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

Helping game developers keep users engaged

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

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

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

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

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

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

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

Building the initial product

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

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

Working toward a sustainable solution

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

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

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

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

Improving performance

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

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

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

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

Co-creating the future

The Excelliance Tech team.

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

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

July 7th 2020, 1:01 pm

11 Weeks of Android: Testing app compatibility in Android 11

Android Developers Blog

Posted by Diana Wong, Product Manager, Android

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

Android 11 compatibility week

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

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

Making app compatibility easier in Android 11

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

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

Testing on Android 11

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

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

New tools for testing platform changes

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

What is the compatibility framework?

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

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

Choosing a change to test against

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

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

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

Isolate the change

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

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

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

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

Test and debug your app

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

Learn more

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

New tools in Android Studio for testing app compatibility

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

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

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

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

Learn more

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

Next steps

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

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

July 6th 2020, 2:01 pm

Bringing modern storage to Viber’s users

Android Developers Blog

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

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

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

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

Managing storage across Android versions

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

Media directories

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

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

Storage permissions

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

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

Accessing files outside of app-specific directory

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

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

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

App-specific files within external storage

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

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

Single interface to access storage

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

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

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

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

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

Summary

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

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

July 1st 2020, 1:04 pm

System hardening in Android 11

Android Developers Blog

Posted by Android Platform Hardening Team

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

Initializing memory

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

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

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

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

Initializing Userspace:

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

Initializing the Kernel:

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

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

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

Scudo is now Android's default native allocator

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

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

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

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

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

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

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

Software Tag-Based KASAN

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

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

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

Expanding existing compiler mitigations

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

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

The effectiveness of our software codec sandbox

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

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

June 30th 2020, 1:19 pm

11 Weeks of Android: Privacy and Security

Android Developers Blog

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

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

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

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

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

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

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

In February, we announced that Google Play developers will need to get approval to access background location in their app to prevent misuse. We're giving developers more time to make changes and won't be enforcing the policy for existing apps until 2021. Check out this helpful video to find possible background location usage in your code.

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

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

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

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

BiometricPrompt API: Developers can now use the BiometricPrompt API to specify the biometric authenticator strength required by their app to unlock or access sensitive parts of the app. We are planning to add this to the Jetpack Biometric library to allow for backward compatibility and will share further updates on this work as it progresses.

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

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

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

Resources

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

June 29th 2020, 1:10 pm

Full spectrum of on-device machine learning tools on Android

Android Developers Blog

Posted by Hoi Lam, Android Machine Learning



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

Design - ML as a differentiator

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



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

New ML Kit fully focused on on-device

When you decide that on-device machine learning is the solution, the easiest way to implement it will be through turnkey SDKs like ML Kit. Sophisticated Google-trained models and processing pipelines are offered through an easy to use interface in Kotlin / Java. ML Kit is designed and built for on-device ML: it works offline, offers enhanced privacy, unlocks high performance for real-time use cases and it is free. We recently made ML Kit a standalone SDK and it no longer requires a Firebase account. Just one line in your build.gradle file and you can start bringing ML functionality into your app.



The team has also added new functionalities such as Jetpack lifecycle support and the option to use the face contour models via Google Play Services saving as much as 20MB in app size. Another much anticipated addition is the support for swapping Google models with your own for both Image Labeling as well as Object Detection and Tracking. This provides one of the easiest ways to add TensorFlow Lite models to your applications without interacting with ByteArray!

Customise with TensorFlow Lite and Android tools

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



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

Time for on-device ML is now

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

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

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

Resources

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

June 26th 2020, 2:09 pm

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

Android Developers Blog

Posted by Di Dang, Design Advocate

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




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

Why Machine Learning and Voice UI?

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

False positives vs. false negatives

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

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

June 25th 2020, 1:13 pm

Android 11 Developer Preview on Android TV

Android Developers Blog

Posted by Xiaodao Wu, Developer Advocate

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

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

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

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

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

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

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

June 25th 2020, 11:13 am

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

Android Developers Blog

Posted by Hoi Lam, Android Machine Learning

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

Find alternative ML models

Crop disease models from the wider research community available on tfhub.dev

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

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

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

Train your own custom model

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

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

Using custom model in your Android app

New TFLite Model import screen in Android Studio 4.1 beta

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

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

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

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

Two examples of how these tools can fit together

Here are some resources to help you get started:

Customizing your model is easier than ever

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

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

June 24th 2020, 1:02 pm

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

Android Developers Blog

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

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

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

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

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

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

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

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

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

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

Shrink your app footprint with Google Play Services

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

// Face detection / Face contour model
// Delivered via Google Play Services outside your app's APK…
implementation 'com.google.android.gms:play-services-mlkit-face-detection:16.0.0'

// …or bundled with your app's APK
implementation 'com.google.mlkit:face-detection:16.0.0'

Jetpack Lifecycle / CameraX support

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

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

// ...

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

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

Codelab of the day - ML Kit x CameraX

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

Early access program

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

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

Tomorrow - Support for custom models

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

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

June 23rd 2020, 1:15 pm

New features to acquire and retain subscribers

Android Developers Blog

Posted by Angela Ying, Product Manager, Google Play

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

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

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

More targeted promotions

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

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

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

Remind users of the value of your subscription

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

Win back churned subscribers

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

Price decreases without opt-ins

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

Updated platform retention settings

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

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

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

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





How useful did you find this blog post?

June 23rd 2020, 11:45 am

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

Android Developers Blog

Posted by Jacob Lehrbaum, Director of Developer Relations, Android

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

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

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

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

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

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

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

What’s next in Android Machine Learning week?

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

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

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

June 22nd 2020, 11:33 am

11 Weeks of Android: People & Identity

Android Developers Blog

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

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

The big news

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

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

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

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

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

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

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

Another focus of this week was identity. To tackle user and developer complexity that makes identity a challenge for developers, we've been working on One Tap and Block Store, part of our new Google Identity Services Library. One Tap is our new cross-platform sign-in mechanism for Web and Android, supporting and streamlining multiple types of credentials. Block Store is our new token-based sign-in mechanism that’s built on top of Backup and Restore. It allows you to keep your user signed in across Android devices.

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

What to watch

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

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

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

Learning path

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

Key takeaways

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

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

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

Resources

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

June 18th 2020, 6:07 pm

Messenger and Conversations

Android Developers Blog


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


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

Bubbles

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

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


A Q&A with the Messenger team

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

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

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

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

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

A people-centric experience in Android 11

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

June 17th 2020, 5:24 pm

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

Android Developers Blog


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

Direct Messages for the conversation space

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

Conversation Notification API

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

A Q&A with the Twitter team

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

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

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

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

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

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

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

A people-centric experience in Android 11

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

June 16th 2020, 1:10 pm

Meet Google Play Billing Library Version 3

Android Developers Blog

Posted by Steve Hartford, Product Manager, Google Play

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

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

Paying with Cash

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

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

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

Cash Purchases using Billing Library 3

More places for users to discover and purchase

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

Purchase Attribution

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

Billing Library Version Requirements

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

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

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

Billing Library version support

Availability

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

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

Next Steps

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

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

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

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

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

June 11th 2020, 5:13 pm

What’s new in Android gaming

Android Developers Blog

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



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

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



Android tools for mobile game development

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



Reach more devices & users

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





Reach more devices and win go-to-market

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

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





How useful did you find this blog post?

June 11th 2020, 1:07 pm

Performance insights for Games, powered by Android Performance Tuner

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

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

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

Unity Boat Attack Sample with Different Optimizations

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

Frame rate performance

Frame Rate Performance by Quality Level and Device Model

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

Performance issues

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

Top Device Model/Annotation Issues

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

Underperforming Device Models by GPU

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

Device Model Impact, User Impact, GPU Time

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

Opportunities to make a good experience great

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

Frame Time Performance with Opportunities

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

Available (almost) everywhere

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

Integrating Android Performance Tuner

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

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

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

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

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

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

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

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

Activating Optimized Frame Pacing in Unity 2019.3

Providing contextual information

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

Annotation Parameters

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

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

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

Fidelity Parameters and Quality Levels

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

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

Example FidelityParams Proto Definition for an In-house Engine

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

Testing your integration

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

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

Available Now

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

June 11th 2020, 12:07 pm

Introducing the new Google Play Console beta

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play Console

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

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

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

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

Clearer and easier to use

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

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

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

New navigation

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

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

The new navigation organizes features based on your goals

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

Clearer overviews

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

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

Easier publishing

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

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

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

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

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

More ways to get the answers you need, fast

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

Clearer policy and compliance information

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

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

Inbox

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

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

Easier education

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

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

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

Visit the new educational pages at play.google.com/console/about

Understanding your performance

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

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

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

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

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

Better, safer team management

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

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

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

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

Try the new Play Console beta today

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

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

Thank you for being a part of our community, and we hope you enjoy the new Play Console!

How useful did you find this blog post?

June 10th 2020, 1:35 pm

Unwrapping the Android 11 Beta, plus more developer updates

Android Developers Blog

Posted by Stephanie Cuthbertson, Director, Product Management

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

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

Android 11 Beta: now available

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

People: we’re making Android more people-centric and expressive, reimagining the way we have conversations on our phones, and building an OS that can recognize and prioritize the most important people in your life:

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

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

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

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

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

Modern Android development

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

Android Studio

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

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

Kotlin and Jetpack

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

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

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

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

The latest on our new UI toolkit, Compose

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

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

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

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

An all-new Google Play Console

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

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

Wrapping it all up

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

June 10th 2020, 1:35 pm

Introducing Google Play Asset Delivery

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

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

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

Dynamic Delivery with App Bundle Produces Optimized APKs

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

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

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

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

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

Keeping assets up-to-date

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

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

Play Asset Delivery engine support


Customizing when asset packs are installed

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

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

Extending Android App Bundle for Games

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

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

Better retention with an improved install experience

Asphalt 8 by Gameloft

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

Improved user experience with cost savings

Puzzle Kids - Animals Shapes and Jigsaw Puzzles by RV AppStudios

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

Play Asset Delivery is available now

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

June 9th 2020, 1:03 pm

Android Studio 4.0

Android Developers Blog

Posted by Adarsh Fernando, Product Manager

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

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

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



Design

Motion Editor

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

Create, edit, and preview animations in the Motion Editor

Upgraded Layout Inspector

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

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

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

Layout Validation

Compare your UI across multiple screens with Layout Validation

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

Develop & Profile

CPU Profiler UI Upgrades

The improved UI of the CPU Profiler

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

Easier side-by-side analysis of thread activity

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

Smart editor features when writing rules for code shrinking

Smart editor feature when writing rules for R8

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

IntelliJ IDEA 2019.3 platform update

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

Kotlin Android live templates

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

Clangd support for C++

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

Build

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

Build Analyzer

Address bottlenecks in your build performance with Build Analyzer

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

Java 8 Language library desugaring in D8 and R8

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

Feature-on-feature dependencies

Feature-on-feature dependencies

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

New options to enable or disable build features

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

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

Android Gradle plugin DSL for enabling or disabling build features

Essential support for Kotlin DSL script files

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

Dependencies metadata

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

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

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

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

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

Design

Develop & Profile

Build

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

Getting Started

Download

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

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

May 28th 2020, 1:13 pm

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

Android Developers Blog

Posted by The #Android11 team

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

Get your #AskAndroid questions answered live

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

Check out the list of talks

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

Sketchnote with us

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

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

May 27th 2020, 1:17 pm

Answers to your questions about app signing by Google Play

Android Developers Blog

Posted by Dom Elliott, Product Manager, Google Play

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

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

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

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



May 7th 2020, 4:36 pm

Android 11: Beta Plans

Android Developers Blog

Posted by Dave Burke, VP of Engineering

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

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

Join us for #Android11: The Beta Launch Show

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

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

Android 11 schedule update

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

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

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

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

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

App compatibility

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

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

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

Get started with Android 11

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

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

May 6th 2020, 1:14 pm

High refresh rate rendering on Android

Android Developers Blog

Posted by Ady Abraham, Software Engineer

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

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

Rendering at high rates

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

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

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

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

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

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

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

Taking advantage of multiple refresh rates

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

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

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

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

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

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

On Older Android versions (before Android 11) where the setFrameRate API doesn’t exist, applications can still influence the refresh rate by directly setting WindowManager.LayoutParams.preferredDisplayModeId to one of the available modes from Display.getSupportedModes. This approach is discouraged starting with Android 11 since the platform doesn’t know the rendering intention of the app. For example, if a device supports 48Hz, 60Hz and 120Hz and there are two applications present on the screen that call setFrameRate(60, …) and setFrameRate(24, …) respectively, the platform can choose 120Hz and make both applications happy. On the other hand, if those applications used preferredDisplayModeId they would probably set the mode to 60Hz and 48Hz respectively, leaving the platform with no option to set 120Hz. The platform will choose either 60Hz or 48Hz, making one app unhappy.

Takeaways

Refresh rate is not always 60Hz - don’t assume 60Hz and don’t hardcode assumptions based on that historical artifact.

Refresh rate is not always constant - if you care about the refresh rate, you need to register a callback to find out when the refresh rate changes and update your internal data accordingly.

If you are not using the Android UI toolkit and have your own custom renderer, consider changing your rendering pipeline according to the current refresh rate. Deepening the pipeline can be done by setting a presentation timestamp using eglPresentationTimeANDROID on OpenGL or VkPresentTimesInfoGOOGLE on Vulkan. Setting a presentation timestamp indicates to SurfaceFlinger when to present the image. If it is set to a few frames in the future, it will deepen the pipeline by the number of frames it is set to. The Android UI in the example above is setting the present time to frameTimeNanos1 + 2 * vsyncPeriod2

Tell the platform your rendering intentions using the setFrameRate API. The platform will match different requests by selecting the appropriate refresh rate.

Use preferredDisplayModeId only when necessary, either when setFrameRate API is not available or when you need to use a very specific mode.

Lastly, familiarize yourself with the Android Frame Pacing library. This library handles proper frame pacing for your game and uses the methods described above to handle multiple refresh rates.

Notes


  1. frameTimeNanos received from Choreographer 

  2. vsyncPeriod received from Display.getRefreshRate()  

April 27th 2020, 2:46 pm

Android 11: Developer Preview 3

Android Developers Blog

Posted by Dave Burke, VP of Engineering

Our teams, like all of you, continue getting used to a new normal. For many of us, that means working from living rooms, kitchens, backyards and bedrooms. So, from our homes to yours, we wanted to take a moment to share our most recent developer preview for Android 11. This update includes bug fixes and a set of productivity improvements for developers.

You can see some of the highlights below, and visit the Android 11 developer site for details on all of the new features in Android 11. Today’s release is for developers and not intended for daily or consumer use, so we’re making it available by manual download and flash for Pixel 2, 3, 3a, or 4 devices. If you’re already running a Developer Preview build, you’ll receive an over-the-air (OTA) update to today’s release soon. As always, let us know what you think, and thank you for the helpful feedback you’ve shared so far.

What’s in Developer Preview 3

In today’s release there are a number of new features and changes for you to try, as well as the latest updates to existing features, APIs, and tools. Here are just a few:

App exit reasons updates - Apps can exit for a variety of reasons, from crash to system kill or user action. Across the many device types, memory configurations, and user scenarios that your app runs in, it’s important to understand why the app exited and what the state was at the time. Android 11 makes this easier with an exit reasons API that you can use to request details of the app’s recent exits. In DP3 we’ve updated the APIs based on your input, so please take a look. If you haven’t had a chance to check out this new API yet, we recommend giving it a try and please let us know what you think here.

GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible. For details, see the documentation.

ADB Incremental - Installing very large APKs with ADB (Android Debug Bridge) during development can be slow and impact your productivity, especially those developers working on Android Games. With ADB Incremental in Android 11, installing large APKs (2GB+) from your development computer to an Android 11 device is up to 10x faster. To use this new developer tool, first sign your APK with the new APK signature scheme v4 format, and then install your APK with the updated ADB command line tool found in the Android 11 Preview SDK. This new feature is part of a broad suite of new tools we're investing in to make you more productive in building games on Android. Note that in DP3, ADB Incremental only works with Pixel 4 / 4XL devices due to a required file system change at the device level. All new devices launching with Android 11 will include this change and will support ADB Incremental. Learn more here.

Wireless Debugging - In Android 11, we’ve completely revamped the debugging experience using ADB over a Wi-Fi connection. With limited USB ports on laptops, and a myriad of USB cables & connections to manage, the Wireless Debugging feature in Android 11 can help you be more productive. Unlike the existing TCP/IP debugging workflow, Wireless Debugging on Android 11 does not need a cable to set up, remembers connections over time, and can utilize the full speed of the latest Wi-Fi standards. In DP3, use the pairing code workflow to get started with this developer feature. We plan to add an integrated experience for Wireless Debugging with QR code scanning in a future Android Studio release, but we want to get your early feedback on the command line tool offered in Android 11 DP3. For details, see the documentation.

Try the new wireless debugging feature in Developer Options.

Data access auditing updates - In DP3 we renamed several of the APIs for this Android 11 developer feature. If you are already using the APIs, make sure to check out the changes. If you aren’t familiar, data access auditing lets you instrument your app to better understand how it accesses user data and from which user flows. For example, It can help you identify any inadvertent access to private data in your own code or within any SDKs you might be using. Give data access auditing a try in your apps - you can read more here or see an example in our sample app. Let us know your feedback here.

For details on everything that’s changed in Developer Preview 3, take a look at the DP3 diff report and read the release notes for details about known issues.

App compatibility

With Developer Preview 3, we’re well on the way to finalizing features and APIs and shifting our focus to polish and performance. If you haven’t already, now is the time to begin testing your app for compatibility and identify any work you’ll need to do. We recommend releasing a compatible app update by Android 11 Beta to get feedback from the larger group of Android Beta users.

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

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

To help you test, we’ve made many of the targetSdk changes toggleable, so you can force-enable or disable them individually from Developer options or ADB. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.

App compatibility toggles in Developer Options.

Get started with Android 11

Developer Preview 3 has everything you need to try the latest Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the latest Android 11 Preview SDK and tools, see the set up guide for details.

As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.

For complete information on Android 11, visit the Android 11 developer site.

April 23rd 2020, 1:19 pm

Developer tools to debug WebView in Beta

Android Developers Blog

Posted by Nate Fischer, Software Engineer, WebView team

Since 2014, Android WebView has paved the way as an updateable system component, delivering stability and performance improvements, modern web platform features, and security patches to Android apps and users. However, updates can be a double edged sword: as much as we strive for stability and backward compatibility, new crashes and breaking changes occasionally slip through. To solve these issues faster, today we're announcing WebView DevTools, a new set of on-device debugging tools to diagnose WebView-caused crashes and misbehaving web platform features.

For your convenience, WebView DevTools comes included as part of WebView itself. The easiest way to launch WebView Devtools is to try out WebView Beta. WebView's beta program is a way for app developers to get WebView several weeks before they reach users, for extra lead time to report compatibility bugs to our team. Starting with today's release (M83), WebView Beta includes a launcher icon for WebView DevTools. Just look for the blue and gray WebView gear icon to get started debugging WebView in your app.

Inspecting a crash in WebView DevTools.

No software is bug-free and loading web content can be challenging, so it's no surprise WebView crashes are a pain point for apps. Worse yet, these crashes are difficult to debug because WebView's Java and C++ stack traces are obfuscated (to minimize APK size for Android users). To help make these crashes more actionable, we're exposing first-class access to WebView's built-in crash reporter. Just open WebView DevTools, tap on "crashes," and you'll see a list of recent WebView-caused crashes from apps on your device. You can use this tool to see if the crash report has been uploaded to our servers, force-upload it if necessary, and subsequently file a bug. This ensures our team has all the information we need to swiftly resolve these crashes and ensure a smoother user experience in your app.

Using flags to highlight WebView usage in Android apps.

However, not all bugs cause crashes. A handful of past WebView releases have broken Android apps due to behavior changes caused by new features. While our team's policy is to roll back features which break compatibility, the chromium team launches several features for WebView in each release, and we often need time to identify the offending feature. WebView DevTools can help here too. Inspired by Google Chrome's chrome://flags tool, which enables compatibility testing with web platform features, we're offering app developers similar controls for experimental features. To get started, open WebView DevTools, tap on "flags," enable or disable any available features, then kill and restart the WebView-based app you're testing. Using WebView DevTools will help us work together to pin down the culprit so we can roll it back. We've also included flags for features slated for upcoming releases, so you can test compatibility even earlier by enabling these features on your test device.

We hope you find WebView DevTools helpful for reporting crashes and testing against new WebView features. Install WebView Beta today to get started with WebView DevTools, and check out the user guide for more tips and tricks.

April 17th 2020, 1:38 pm

Building user trust through more transparent subscriptions

Android Developers Blog

Posted by Angela Ying, Product Manager, Google Play

For many developers, subscriptions are an important part of your business. Google Play has continued to support the growth of subscription offerings through developer tools such as new insights in the Google Play Console, and an improved user experience, including the subscriptions center, where users can easily manage all of their subscriptions. Part of improving the subscription user experience comes from fostering a trustworthy platform for subscribers; making sure they feel fully informed when they purchase in-app subscriptions.

To continue to build this trust, we announced an updated subscriptions policy today, as part of a broader policy update to build user trust and enhance user safety across Google Play. This new policy requires you to be transparent about your subscription offering, to ensure every user evaluating your service has an informed choice.

When users lose trust in your app due to unclear subscription offers, they unsubscribe and often leave negative reviews, ultimately hurting your business. On the other hand, a clear and compelling offer gives users all the information they need to make a decision, increasing their trust in your service and hopefully encouraging them to stick around for a long time.

Complying with our subscriptions policy

The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation. You can read the full policy and see examples of best practices and common violations in the Policy Center, but the most important thing is to make sure you are clear about your subscription offering within your app. Consider the following best practices:

Be explicit about your subscription terms, such as:

If you offer free trials and introductory offers, clearly and accurately tell users:

Ensure your app clearly discloses how a subscriber can cancel and/or manage a subscription.

You have until June 16, 2020 to bring your existing apps into compliance with this policy.

A better user experience without additional development work for you

In conjunction with these policy updates, we’ve made several platform-level product changes to help increase user trust and build user confidence in subscribing.

We believe that although these changes may lead to fewer conversions or more subscription cancelations in the short term, they will also result in higher quality, more committed subscribers with lower refund and chargeback rates. Overall, this should result in a more stable recurring revenue.

Resources to help

We want to help you do the right thing for your subscribers, so we’ve created this checklist, video and training in Google Play’s Academy for App Success to use as a reference when you’re making any necessary app updates.

Thank you for continuing to partner with us to make Google Play a trustworthy platform for you and your users. Not only can we work together to create great experiences for users, but we can continue to grow subscription businesses as well.

How useful did you find this blog post?

April 16th 2020, 1:13 pm

Google Play Trust and Safety Update

Android Developers Blog

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

As part of our continuing efforts to enhance user trust and safety across Google Play, we regularly examine our policies to ensure a positive experience for developers and users. Today we are announcing policy updates that give users more control over their data, tighten subscription policies, and help prevent deceptive apps and media getting onto the Play Store.

We understand that many of you are adjusting to or actively supporting efforts in response to the current unprecedented circumstances. We want to assure you that we are mindful and supportive of those efforts, and have taken steps to minimize the potential short-term impact of these changes. You can read more about that in this blog post which shares resources for developers navigating the current context. We also wanted to briefly highlight two of the more impactful policies announced today.

More transparent subscription offers

Subscriptions continue to grow in popularity on Play; however, we hear user feedback that it isn’t always clear what you are signing up for. The goal of this policy update is to ensure users understand the subscription offer, the terms of free trials and introductory offers, and how to manage their subscription, including cancellation.

This blog post goes into more detail about the changes and gives examples of best practices and common violations. Developers have until June 16th to make any changes to their offer page.

Limiting unnecessary location access

Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Android users have always needed to grant explicit permission to any app that wants access to their location data. In Android 11, we’re granting additional user controls with the ability to grant a temporary “one-time” permission.

In February, we announced we would require that developers get approval if they want to access background location in their app. This ensures that only apps that really need access for core functionality can ask users for permission. This policy is now live and we encourage all developers who access location to view it.

We realize complying with certain aspects of this policy may require work for some developers so we are giving you an extended timeline to make changes. We suggest that you review location best practices and evaluate whether you have appropriate disclosures, and really need background location; however, no action will be taken for new apps until August 2020 or existing apps until November 2020. Additional details can be found in this help center article and we’ll keep you updated if processes or timelines change. Thanks for your continued support in making Google Play a trustworthy and valuable experience for everyone.

How useful did you find this blog post?

April 16th 2020, 1:13 pm

Promoting high-quality, teacher-approved kids content on Google Play

Android Developers Blog

Posted by Michael Watson, Product Manager, Google Play

With more kids spending time at home, parents are looking for ways to find apps and games for children that are both enriching and entertaining. Today, we’re announcing an update that will make it easier for parents to find this content on the Google Play Store. We’re launching the Teacher Approved program, an editorial program to highlight high-quality, teacher-approved apps for kids. This is part of our ongoing effort to create a safer Google Play for kids.


What’s changing

We consulted with academic experts to develop a framework for rating apps for kids. Specially trained teachers across the US will rate apps for kids based on this framework, evaluating things like:

  • Design quality
  • Appeal to children
  • Enrichment potential
  • Ads & in-app purchases
  • Age appropriateness

Teacher-approved apps will:

  • Be eligible to appear in the new Kids section on Google Play
  • Be eligible for featuring in banners or collections on Google Play
  • Display the new "Teacher approved" badge
  • Display information about what teachers found valuable on their app details page

The Google Play store featuring teacher-approved apps

As a result of these changes, we are removing the Family star badge and the Family section on Google Play. All apps that were in the Family section will continue to be discoverable on the Play Store and appear in search results. Note that this change will have no effect on Family Library.

Who’s eligible

Apps need to meet the requirements of the Designed for Families program before they’re eligible to be reviewed by teachers. All Designed for Families apps are automatically placed in the teacher review queue.

We made the decision to launch the Teacher Approved program a little early given the vast number of kids at home now. Teachers are working hard to review apps as quickly as possible, but it will take time to review all apps, so we appreciate your patience. Our initial launch will be limited to the US, to be followed by a global rollout in the coming months.

To help developers better understand what the teachers are looking for, we published a new learning path on Google Play’s Academy for App Success, including findings from Google Play’s research into technology usage by parents and kids.

Rewarding for all

We’re committed to improving the ecosystem and partnering with our developers. We look forward to continuing to work with you to create the best possible experience for children and families on Google Play. For more information on the Teacher Approved program, check out our FAQs.

How useful did you find this blog post?

April 15th 2020, 2:12 pm

Google Play updates and information: Resources for developers

Android Developers Blog


Posted by Sam Tolomei, Business Development Manager, Google Play

In these unprecedented times, Google Play's mission to support you, ensure your businesses continue to operate well, and help users get the content they need is more important than ever. With a surge in need for information, communications tools, entertainment, and more, we are striving to ensure our operations run smoothly, and we need your support.

Below, we’ve pulled together some important information to help you maintain business continuity, as well as best practices to help you stay nimble in the changing landscape.

Extended app review times

Like many of you, we've had to manage work disruptions as a result of changing business conditions. This has led to a temporary slowing down of the app review process, which now may take 7 days or longer. As the situation evolves, we will continue to make sure that the most important updates reach users quickly, which may result in fluctuating review times. Certain critical apps may receive prioritized review and may not experience an extended delay in review time. Please check the Google Play Console for the most up-to-date information and guidance.

At the same time, in order to help ensure we are providing users with accurate and timely information relating to COVID-19, we also are prioritizing the review of apps published, commissioned, or authorized by official government entities and public health organizations.

If you want to control when your app goes live, we recommend timed publishing. Just submit your app for review, and once it’s approved, click “Go live” in the Play Console to instantly publish your app. Note: If you already have a release submitted to the production track that is under review, you will not see the “timed publishing” option.

Store listing guidelines

At Google Play we take our responsibility to provide accurate and relevant information for our users very seriously. For that reason, we are currently only approving apps that reference COVID-19 or related terms in their store listing if the app is published, commissioned, or authorized by an official government entity or public health organization, and the app does not contain any monetization mechanisms such as ads, in-app products, or in-app donations. This includes references in places such as the app title, description, release notes, or screenshots.

Removing inappropriate reviews

With the recent increase in traffic, some apps are seeing a spike in inappropriate one-star reviews from users. If you are receiving reviews that are not related to your app experience, you can flag the review in the Play Console. We’ve expanded our ability to assess and remove inappropriate reviews so we can handle your request as quickly as possible.

Subscriptions support

While subscriptions are a large part of many app business models, two groups are currently seeing the largest impact: 1) those whose core businesses have been adversely affected by COVID-19 (such as live event ticketing), and 2) those who provide a public service with their content or services.

For developers whose business value proposition has been affected, features like deferred billing and subscription pauses can help retain users until after the crisis has passed. For developers who want to offer their content or services like medical, online learning, and wellbeing apps at reduced or no cost, features like price changes and refunds through Google Play Billing are available to help.

Learn more best practices in our Medium post.

How we’re helping the community

Google is also committed to helping our community at large. To help small businesses reconnect with their customers, Google is granting $340 million in ad credits to be used across our Google Ads platforms — learn more here.

Here’s what else we’re doing:

As the situation progresses, we will continue to gather more resources to help you. We’re also taking steps to limit changes and barriers because we know you have enough on your plate right now. Please stay tuned for more information, and thank you for being a part of the Google Play community. If you have any other suggestions about how we can support you during this time, please let us know by tweeting at us at @GooglePlayDev with #AskGooglePlay.

How useful did you find this blog post?

April 6th 2020, 4:41 pm

Meet the finalists of the Google Play Indie Games Festival

Android Developers Blog

Posted by Leticia Lago, Head of Developer Marketing, EMEA

At the start of this year we opened submissions for 2020’s Google Play Indie Games Festival - an international competition celebrating incredible indie games from Europe, Japan and South Korea.

We’ve received hundreds of fantastic submissions that showcase the technical abilities and groundbreaking creativity of independent studios. Many thanks to everyone who submitted their game. After some hard choices and late nights, we’re happy to announce our 20 finalists in each region.

Please check out the games below (in alphabetical order); each one is a true work of art. They will be receiving promotions and prizes to help them grow their business. They’ll also be competing in the Finals for the top prizes.

While this is a happy announcement, we must also inform you that we will be unable to hold the Finals as planned on April 25 in Poland, Japan and South Korea due to the COVID-19 situation. We will be postponing the events until further notice, as the health and safety of finalists, jury members, players and others involved is our top priority. Please stay tuned for further announcements.

Europe*

60 Parsecs! by Robot Gentleman

Aisle Trial by Jake Matthews-Belcher

Alien Escape by Korion Games

Alt-Frequencies by Accidental Queens

Bad North by Rawfury

Bounce that Bird! by Affinity Project

Cessabit: a Stress Relief Game by Tepes Ovidiu

Color Spots by US Apps

Cookies Must Die by Rebel Twins

Demons Never Lie by Maika Hernandez

Doors: Awakening by Big Loop

Faraway: Galactic Escape by Pine Studio

inbento by Afterburn

My Diggy Dog 2 by King Bird Games

The White Door by Rusty Lake

Tiny Tomb: Dungeon Explorer by Tinycorp

Traffix by Infinity Games

Tricky Castle by Team Tricky

Unhatched by Filip Loster

Void Tyrant by Quite Fresh

Japan

Amayadori by CHARON・Yanase

CUBE GARDEN by Fukudanuki

GIGAFALL by Shiki Game Studio

GummyShooter by simatten

Home Fighter by hap Inc.

Matsuro Palette by SleepingMuseum

METBOY! by REBUILD GAMES

Mocha - Dagsaw Puzzle - by Kotoriyama, Inc.

MonsterTrader by Mitsuhiro Okada

Overturn by Katsu Matsuda

Shiritori - The Word Chain Game by Baton

Snowman Story by Odencat

SOUND JOURNEY SCHOOL WANDERER by SOUND JOURNEY

TAP! DIG! MY MUSEUM! by oridio Inc.

Teiji Taisha Online by toru sugitani

The Final Taxi by Zxima.LLC

Uncrowned by NESTOPI Inc.

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

World for Two by Seventh rank

Zelle by Odencat Fuming

South Korea

Castle Defense Online by BlackHammer

CAT THE DJ by CATSBY STUDIO

DiceEmpire by Banjiha Games

Domino City by Bad Beans

DUST by I-eye studio

Electroad by Night Owl Studio

Extreme football by 9M Interactive

From Earth by Kentauros Entertainment

Great Sword - Stickman Action RPG by Olivecrow

Heroes Restaurant by Team Tapas

Little Boy by 39Studio

Magic Survival by LEME

Mayday Memory by StoryTaco.inc

Petrider by Ddookdak studio

Project Mars by Moontm

QV by Izzle

Sand Shark : The Boy and The Sea by GABANGMAN STUDIO

Staroid : Brick breaker shooter by Spring Games

Sword Master Story by CodeCAT

Undestroyed by Keymaker games

The competition was open to indie developers from the following European countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).

How useful did you find this blog post?

March 30th 2020, 12:50 pm

Run ARM apps on the Android Emulator

Android Developers Blog

Posted by Michael Hazard

As part of the Android 11 developer preview we’ve released Android 11 system images, which are capable of executing ARM binaries with significantly improved performance. Previously, developers who were dependent on ARM libraries and could not build an x86 variant of their app either had to use system images with full ARM emulation, which are much slower than x86 system images when run on x86-based computers, or resort to physical devices. The new Android 11 system images are capable of translating ARM instructions to x86 without impacting the entire system. This allows the execution of ARM binaries for testing without the performance overhead of full ARM emulation.

The new Android 11 (Google APIs) x86 system image supports ARM ABIs, while the older Android Oreo system image does not

Details

The significance of this may require a bit of context, especially if you build apps exclusively with Kotlin or the Java programming language. Unlike Kotlin or the Java programming language, both of which execute on the Android Runtime (ART), any C++ in your Android app compiles directly into machine instructions. This means that it needs to be compiled differently based on the architecture of the target device. Mobile phones tend to have ARM processors; consequently, many C++ dependencies you might add to your app, like a camera barcode scanner library, are only compatible with ARM processors. This is a problem if you develop on a computer with an x86-based processor, as it would prevent you from running your app.

Previously, if you wanted to get around this limitation and execute an app built for ARM on your x86 machine, you would have had to use an emulator system image with full ARM emulation. Due to the overhead of translating an entire system’s worth of ARM instructions to x86, emulator system images with full ARM emulation tend to run much slower than x86-based system images when run on x86 host machines. Additionally, emulator system images with full ARM emulation cannot take advantage of the hardware acceleration and CPU virtualization technologies provided by x86 processors.

The new ARM-compatible Android 11 system images allow the entire system to run x86 natively and take advantage of virtualization technologies as usual. When an app’s process requires an ARM binary, the binary is translated to x86 within that process exclusively. This allows the rest of the process to continue executing in x86, including the Android Runtime (ART), and other performance-critical libraries like libGLES and libvulkan. In addition to this, the translator avoids expensive memory access instrumentation and the associated performance hit by avoiding the execution of low-level hardware-specific libraries. These new emulator system images can be used both locally and on your own continuous integration infrastructure. This is possible thanks to collaboration with ARM Limited.

Going Forward

If you have previously chosen physical devices over the emulator due to the lack of performant ARM support, try out the Android 11 system images, which are now available alongside the Android 11 Developer Preview. These system images can be downloaded in Android Studio via either the SDK Manager or the Android Virtual Device Manager.

Using the Android Virtual Device Manager to create an AVD that runs Android 11

Once you get your app running on the emulator, consider adapting it for Chrome OS. Chrome OS also supports the execution of Android apps built for ARM on x86 laptops. Building for Chrome OS provides access to a substantial ecosystem of larger screen devices, allowing your application to reach even more users globally.

This technology should enable more developers to test with the Android Emulator. That said, we still recommend that developers publish both x86 and ARM ABI variants of their apps to achieve the best physical device performance and reach as many users as possible. Going forward, we plan to roll this technology out across a wider variety of API levels and ensure that it supports testing all use cases that a physical device would. Given that this is a new technology, please let us know of any problems via our Issue Tracker.

Note that the ARM to x86 translation technology enables the execution of intellectual property owned by Arm Limited. It will only be available on Google APIs and Play Store system images, and can only be used for application development and debug purposes on x86 desktop, laptop, customer on-premises servers, and customer-procured cloud-based environments. The technology should not be used in the provision of commercial hosted services.

Java is a registered trademark of Oracle and/or its affiliates.

March 26th 2020, 1:55 pm

Google for Games Developer Summit March 2020

Android Developers Blog


Posted by Greg Hartrell, Head of Product Management, Games on Android & Google Play


While we're sorry we didn't get to see you all in person at GDC, we hope you are all staying healthy and safe. As many of us look to press on with work as much as possible, we’d like to share with you what our teams have been working on at the digital Google for Games Developer Summit. We couldn’t be happier with the continued growth of the vibrant Android gaming ecosystem. In fact, Android remains the world's most popular mobile platform with more than 2.5 billion monthly active devices and great news for game developers, we’re seeing more than 1.4 trillion minutes played per month in your games on Google Play. It’s important to us that our platforms are highly useful to every kind of game developer, so our payment system helps games monetize in more than 65 countries. Moreover, we offer our users more than 275 local forms of payment, including more than 180 carrier billing options, with gift cards sold in over 900 thousand unique retail locations worldwide.
Across Android and Google Play, our mission is to deliver the best platform to build, discover, and experience games. Specifically, we’re working on ways to help you increase the reach of your games and manage the fragmentation of the Android ecosystem. We’re also focused on helping you access a wider player base, once you’ve made a great game and are ready to get it out there. Last year, we shared that we’re investing heavily in our games efforts to address your challenges in these areas, and now we are excited to share several new tools and services built specifically with game developers in mind.


Catch up on everything shared at g.co/gamedevsummit.


New Android tools for mobile game development

A major area of investment for us has been making it easier for developers to build and optimize games for Android. Here’s a round-up of several new tools we’re releasing:
  • Android Studio Profilers: We’ve overhauled our Android Studio System Trace profiler to allow you to inspect and visualize in fine detail how your code is being executed. We also added native memory profiling capabilities so you can see how your game is allocating memory and find memory leaks. Download Android Studio 4.1 Canary and watch the session.
  • Android Game Development Extension for Visual Studio: We’re introducing a new tool to make it easy to add Android support for your cross-platform games. This integrates easily with existing Visual Studio-based workflows so now you can conveniently generate APKs, deploy to Android devices or an emulator, and debug your Android game from within Visual Studio. Apply for the developer preview and watch the session.
  • Android GPU Inspector: Our new Android GPU Inspector enables you to look deeply into an Android GPU and see detailed information about your game’s render stages and GPU counters. Now graphics engineers are empowered with information and insights to optimize their game for better frame rates and more battery life. Apply for the developer preview and watch the session.
  • Game Package Registry for Unity by Google: Our new package registry consolidates various Google APIs, starting with Google Play Billing, Android App Bundles, Play Asset Delivery, Play Instant, and Firebase for Games, all in one place. Learn more and watch the session.
  • Crytek announces Android support: CRYENGINE is known as a high performance game engine for PCs and game consoles and will be adding a full Android pipeline to their engine this summer. Learn more.

New ways to reach more devices & users

We’ve been working to help developers scale their reach to a growing player-base across the Android ecosystem. Today, we’re introducing a few new tools to help your development process and provide greater insights into your game’s performance.
  • Google Play Asset Delivery: Introducing a new set of delivery features for games services, building on our App Bundle infrastructure to give you free, dynamic delivery of the right game assets to the right devices at the right time. All of this allows players to get into your game faster while assets are being downloaded, while you cut the costs of hosting and delivering d game resources. Learn more and watch the session.
  • Android vitals native crash symbolication: Now you can debug your native crashes more easily with support for native symbols in Play Console. Simply upload your native debug symbols to get the benefits in Android Vitals. Apply for the open beta and watch the session.
  • Android vitals performance insights with Android Performance Tuner: We’re making it possible to optimize your frame rate and fidelity across many devices at scale with new performance insights in Android vitals. For those in our developer preview, you can unlock this by integrating the new Android Performance Tuner into your game: a new library in the Android Game SDK. Apply for the developer preview and watch the session.
  • Play Billing Library 2 for Unity developers: Game developers using Unity can now access all of Play Billing Library 2's features, such as allowing users to pay with cash and surfacing IAPs outside of the game. This is the best way for Unity developers to prepare for Play’s Billing Library version requirements in 2021. Learn more.

New ways to reach more devices and win go-to-market

The Google Play store is shifting to be more gameplay centric by showing more visuals that demonstrate gameplay and a new system of tags to help users learn more about specific game traits and aid in exploration. Learn how you can ensure your game is of high-quality and leverage various features and new services to help you succeed in your go-to-market activities.
  • Emphasis on quality: We continue to emphasize high quality gaming experiences across Google Play, to encourage immersive gameplay with strong technical performance and being free of crashes. Learn more.
  • Pre-registration: Hundreds-of-millions of players use pre-registration campaigns on Google Play each year, making it an effective way to expand the reach on launch. We’ll soon be rolling out day 1 auto-installation for all pre-registration games, to help you build early consumer awareness and capture pre-launch demand.
  • Play Pass: Late last year we launched Play Pass in the US market as a subscription service providing users with access to hundreds of great apps and games on Google Play, completely free of ads and in-app purchases. Learn more and express interest.
Thanks for your support in continuing to build incredible games. Make sure to try some of the new tools and services we just released and catch the full playlist of mobile developer sessions. If you’re interested in sharing feedback to help shape the development of cutting edge features, apply to join our developer preview programs from Android and Google Play. You can also learn about all of the offerings we have to help game developers building on Android at d.android.com/games.
How useful did you find this blog post?



March 23rd 2020, 11:33 am

Android 11: Developer Preview 2

Android Developers Blog

Posted by Dave Burke, VP of Engineering

It’s been a difficult few months for many around the world. The Android team at Google is a global one, and we, like many of you, are learning how to adapt to these extraordinary times. We want to thank you, our developer community, who have given us valuable feedback on Android 11 amidst these circumstances. We hope you, your families and colleagues are all staying well.

Just as many of you are trying to press on with work where possible, we wanted to share the next milestone release of Android 11 for you to try. It’s still an early build, but you can start to see how the OS is enabling new experiences in this release, from seamless 5G connectivity to wrapping your UI around the latest screens, to a smarter keyboard and faster messaging experience.

There’s a lot to check out in Developer Preview 2 - read on for a few highlights and visit the Android 11 developer site for details. Today’s release is for developers only and not intended for daily or consumer use, so we’re making it available by manual download and flash only for Pixel 2, 3, 3a, or 4 devices. To make flashing a bit easier, you can optionally get today’s release from the Android Flash Tool. For those already running Developer Preview 1 or 1.1, we’re also offering an over-the-air (OTA) update to today’s release.

Let us know what you think, and thank you to everyone who has shared such great feedback so far.

New experiences

5G state API - DP2 adds a 5G state API to let you quickly check whether the user is currently on a 5G New Radio or Non-Standalone network. You can use this to highlight your app’s 5G experience or branding when the user is connected. You can use this API together with the 5G dynamic meteredness API and bandwidth estimator API, as well as existing connectivity APIs, to take advantage of 5G’s improved speeds and latency.

Hinge angle for foldables - A top request for foldable devices has been an API to get the angle of the device screen surfaces. Android 11 now supports a hinge angle sensor that lets apps query directly or through a new AndroidX API for the precise hinge angle, to create adaptive experiences for foldables.

Call screening service improvements - To help users manage robocalls, we’re adding new APIs to let call-screening apps do more to help users. In addition to verifying an incoming call’s STIR/SHAKEN status (standards that protect against caller ID spoofing) as part of its call details, call-screening apps can report a call rejection reason. Apps can also customize a system-provided post call screen to let users perform actions such as marking a call as spam or adding to contacts. We’ll have more to share on this soon.

New ops and controls in Neural Networks API - Activation functions control the output of nodes within a neural network. At Google AI, we discovered a swish activation function allowing for faster training time and higher accuracy across a wide variety of tasks. In Android 11, we’re adding a computationally efficient version of this function, the hard-swish op. This is key to accelerating next-generation on-device vision models such as MobileNetV3 which forms the base model for many transfer learning use cases. Another major addition is the Control ops enabling more advanced machine learning models that support branching and loops. Finally, we’ve also added new execution controls to help you minimize latency for common use cases: Asynchronous Command Queue APIs reduce the overhead when running small chained models. See the NDK sample code for examples using these new APIs.

Privacy and security

We’re adding several more features to help keep users secure and increase transparency and control. Give these a try with your apps right away and let us know what you think.

Foreground service types for camera and microphone - in Android 10 we introduced the manifest attribute foregroundServiceType as a way to help ensure more accountability for specific use-cases. Initially apps could choose from “location” and several others. Now in Android 11 we’re adding two new types - “camera” and “microphone”. If your app wants to access camera or mic data from a foreground service, you need to add the foregroundServiceType value to your manifest.

Scoped storage updates- We’re continuing to iterate on our work to better protect app and user data on external storage. In this release we’ve made further improvements and changes, such as support to migrate files from the legacy model to the new scoped storage model, and better management of cached files. Read more here and watch for more enhancements in subsequent updates.

Read more about these and other Android 11 privacy features here.

Polish and quality

Synchronized IME transitions - A new set of APIs let you synchronize your app’s content with the IME (input method editor, aka soft keyboard) and system bars as they animate on and offscreen, making it much easier to create natural, intuitive and jank-free IME transitions. For frame-perfect transitions, a new insets animation listener notifies apps of per-frame changes to insets while the system bars or the IME animate. Additionally, apps can take control of the IME and system bar transitions through the WindowInsetsAnimationController API. For example, app-driven IME experiences let apps control the IME in response to overscrolling the app UI. Give these new IME transitions a try and let us know what other transitions are important to you.

Synchronized IME transition through insets animation listener.

App-driven IME experience through WindowInsetsAnimationController.

Variable refresh rate - Apps and games can now set a preferred frame rate for their windows. Most Android devices refresh the display at 60Hz refresh rate, but some devices support multiple refresh rates, such as 90Hz as well as 60Hz, with runtime switching. On these devices, the system uses the app’s preferred frame rate to choose the best refresh rate for the app. The API is available in both the SDK and NDK. See the details here.

Resume on reboot - Android 11 improves the experience of scheduled overnight over-the-air software updates. Like in previous versions of Android, the device must still reboot to apply the OTA update, but with resume on reboot, apps are now able to access Credential Encrypted (CE) storage after the OTA reboot, without the user unlocking the device. This means apps can resume normal function and receive messages right away - important since OTA updates can be scheduled overnight while the device might be unattended. Apps can still support Direct Boot to access Device Encrypted (DE) immediately after all types of reboot. Give resume on reboot a try by tapping “Restart after 2AM” with your next Developer Preview OTA update, more details here.

Camera support in Emulator - The Android emulator now supports front and back emulated camera devices. The back camera supports Camera2 API HW Level 3 (includes YUV reprocessing, RAW capture). It’s a fully CTS-compliant LEVEL_3 device that you can use to test advanced features like ZSL and RAW/DNG support. The front camera supports FULL level with logical camera support (one logical device with two underlying physical devices). This camera emphasizes logical camera support, and the physical camera devices include narrow and wide field of view cameras. With this emulated camera support, you can build and test with any of the camera features added in Android 11. More details coming soon.

App compatibility

We’re working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, tools, and release milestones to minimize the impact of platform updates and make them easier for developers.

With Developer Preview 2, we’re well into the release and getting closer to Beta. so now is the time to start your compatibility testing and identify any work you’ll need to do. We recommend doing the work early, so you can release a compatible update by Android 11 Beta 1. This lets you get feedback from the larger group of Android 11 Beta users.

When we reach Platform Stability, system behaviors, non-SDK greylists, and APIs are finalized. At this time, plan on doing your final compatibility testing and releasing your fully compatible app, SDK, or library as soon as possible so that it is ready for the final Android 11 release. More on the timeline for developers is here.

You can start compatibility testing on a Pixel 2, 3, 3a, or 4 device, or you can use the Android Emulator. Just flash the latest build, install your current production app, and test all of the user flows. There’s no need to change the app’s targetSdkVersion at this time. Make sure to review the behavior changes that could affect your app and test for impacts.

To help you with testing, we’ve made many of the breaking changes toggleable, so you can force-enable or disable them individually from Developer options or adb. Check out the details here. Also see the greylists of restricted non-SDK interfaces, which can also be enabled/disabled.

App compatibility toggles in Developer Options.

Get started with Android 11

Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. Just download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device, or set up the Android Emulator through Android Studio. Next, update your Android Studio environment with the Android 11 Preview SDK and tools, see the set up guide for details.

As always, your feedback is crucial, so please continue to let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here.

March 18th 2020, 1:07 pm

Handling Nullability in Android 11 and Beyond

Android Developers Blog

Posted by David Winer, Kotlin Product Manager

Last May at Google I/O, we announced that Android was going Kotlin first, and now over 60% of the top 1000 Android apps use Kotlin. One feature we love about Kotlin is that nullability is baked into its type system — when declaring a reference, you say upfront whether it can hold null values. In this post, we’ll look at how the Android 11 SDK does more to expose nullability information in its APIs and show how you can prepare your Kotlin code for it.

How does nullability in Kotlin work?

When writing code in Kotlin, you can use the question mark operator to indicate nullability:

KOTLIN

var x: Int = 1
x = null // compilation error

var y: Int? = 1
y = null // okay

This aspect of Kotlin makes your code safer — if you later call a method or try to access a property on a non-null variable like x, you know you’re not risking a null pointer exception. We hear over and over again that this feature of Kotlin gives developers more peace of mind and leads to higher quality apps for end users.

How does nullability work with the Java programming language?

Not all of your (or Android’s) APIs are written in Kotlin. Fortunately, the Kotlin compiler recognizes annotations on Java programming languages methods that indicate whether they produce nullable or non-nullable values. For example:

JAVA

public @Nullable String getCurrentName() {
   return currentName;
}

The @Nullable annotation ensures that when using the result of getCurrentName in a Kotlin file, you can’t dereference it without a null check. If you try, Android Studio will notify you of an error, and the Kotlin compiler will throw an error in your build. The opposite is true of @NonNull — it tells the Kotlin compiler to treat the method result as a non-null type, forbidding you from assigning that result to null later in your program.

The Kotlin compiler also recognizes two similar annotations, @RecentlyNullable and @RecentlyNonNull, which are the exact same as @Nullable and @NonNull, only they generate warnings instead of errors1.

Nullability in Android 11

Last month, we released the Android 11 Developer Preview, which allows you to test out the new Android 11 SDK. We upgraded a number of annotations in the SDK from @RecentlyNullable and @RecentlyNonNull to @Nullable and @NonNull (warnings to errors) and continued to annotate the SDK with more @RecentlyNullable and @RecentlyNonNull annotations on methods that didn’t have nullability information before.

What’s next

If you are writing in Kotlin, when upgrading from the Android 10 to the Android 11 SDK, you may notice that there are some new compiler warnings and that previous warnings may have been upgraded to errors. This is intended and a feature of the Kotlin compiler — these warnings tell you that you may be writing code that crashes your app at runtime (a risk you would miss entirely if you weren’t writing in Kotlin). As you encounter these warnings and errors, you can handle them by adding null checks to your code.

As we continue to make headway annotating the Android SDK, we’ll follow this same pattern — @RecentlyNullable and @RecentlyNonNull for one numbered release (e.g., Android 10), and then upgrade to @Nullable and @NonNull in the next release (e.g., Android 11). This practice will give you at least a full release cycle to update your Kotlin code and ensure you’re writing high-quality, robust code.

1. Due to rules regarding handling of annotations in Kotlin, there is currently a small set of cases where the compiler will throw an error for @Nullable references but not for @RecentlyNullable references.

Java is a trademark of Oracle and/or its affiliates.

March 12th 2020, 12:03 pm

Join us for the digital Google for Games Developer Summit

Android Developers Blog

Posted by the Google for Games Team

Last month, Game Developers Conference (GDC) organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community. GDC is one of our most anticipated times of the year to connect with the gaming industry. Though we won’t be bringing the news in-person this year, we’re hosting the Google for Games Developer Summit, a free, digital-only experience where developers can watch the announcements and session content that was planned for GDC.

Google for Games Developer Summit

The Developer Summit kicks off on March 23rd at 9:00AM PT with our broadcasted keynote. Immediately following, we’ll be releasing a full lineup of developer sessions with over 10 hours of content to help take your games to the next level.

Here are some types of sessions to expect:

Sign up to stay informed at g.co/gamedevsummit.

Support for the game developer community

We recognize every developer is impacted differently by this situation. We’re coordinating with the GDC Relief Fund to sponsor and assist developers who’ve invested in this moment to further grow their games.

We also understand many developers were looking forward to sharing their content with peers. To help with this, developers can use YouTube to stream events from small to large using tools like Live Streaming and Premieres.

We can’t wait to share what we have in store for gaming. Discover the solutions our teams have been building to support the success of this community for years to come.

This article was cross-posted from the Google Developer Blog. Google Play will be participating in the Google for Games Developer Summit on March 23rd at 9:00AM PT to share how we're making Google Play even more powerful for game developers!

March 10th 2020, 2:35 pm

Android Platform Codelab Kickstarts OS Development

Android Developers Blog

Posted by Clay Murphy, Technical Writer

The Android Platform Codelab has been published to take developers from bare metal to a (virtual) device under test in a single page. This document will help new Android operating system engineers quickly learn the tools and processes needed to establish a build environment, sync the repository, build a virtual device image, and load that image onto an Android virtual device (AVD), allowing quick iteration of platform changes.

The codelab walks through:

  1. Environment setup
  2. Downloading of code
  3. Creating a Cuttlefish Android Virtual Device (AVD) image
  4. Building the OS
  5. Using Acloud to set up and render the Cuttlefish AVD
  6. Creating and testing changes
  7. Uploading, reviewing, and reverting those modifications

If you encounter errors during this codelab, please report them using the Site feedback link on the bottom of any page. Send questions to the android-building group.

March 5th 2020, 8:59 pm

Unveiling expert insights in our new podcast series: Apps, Games, & Insights

Android Developers Blog

Posted by Lily Sheringham, Global Marketing, Platforms & Ecosystems

This is a cross-post from The Google Keyword blog.

Today we’re launching the Apps, Games, & Insights podcast series, bringing together insights, stories, and learnings from industry experts, on some of today's hottest topics surrounding mobile, apps and games businesses, and the wider industry.

The series has eight episodes which aim to challenge, provoke thought, and enlighten listeners - from designers and developers, through to product managers and marketers, and those interested in the apps and games industry.

The podcast is hosted by Googlers Tamzin Taylor, who heads up Apps & Games Business Development for Google Play in Western Europe, and Dirk Primbs, who leads the Ecosystem Developer Relations team in EMEA. Together, they have many years of experience working with partners to assist with Android development, mobile, app, game, and business growth. Every week they will be joined by different guests for each of the episodes.

Sneak peek at what’s coming up

Kicking off the series are Judy Chen and Sarah Fuchs from Crowdstar, the developers of Covet Fashion and Design Home. They join us for episode 1 to discuss how to build a long-term games business by taking a holistic approach to the game, its players, and the people who create the game.

Ever wonder if it's worth selling your app or game business, and if so how to approach it? It's not all about pocketing the cash and walking away. For episode 2, game mergers and acquisitions expert Chris Petrovic from Zynga will talk about how acquisition can free developers to focus on what they love: creating great apps and games.

The popularity of subscriptions continues to grow, with developers who used subscriptions earning 4X more in 2018, than in 2016. Holly Ackerman and David Berlin, from the sports streaming platform DAZN, join us for episode 3 to provide some fascinating insights into how they have grown their subscription business in this industry.

Whether you are a startup in search of funding or an established business looking to accelerate your investment, venture capital can often be a good source of funds. In episode 4, venture capital expert Matteo Vallone from Cherry Ventures offers insights into the investment process and how to maximize your appeal to investors.

For episode 5, we have what is possibly one of the biggest topics in mobile and throughout the tech industry: privacy. Bruce Gustafson, CEO of Developers Alliance brings us up to speed on trust and safety, platform value, respecting the user, and ultimately building privacy friendly apps and games.

Successful game developers put players front and center of everything they do. When over 270 million people have played your games, you must be doing something right. Ben Clarke, Senior Global Marketing Director at Jagex, joins us for episode 6 to discuss some of the innovative approaches to player engagement and retention taken in their RuneScape games.

Figuring out how to make your app or game accessible to all can often be a challenge, sometimes both from an organizational and technical perspective. However, many developers have made accessibility a core part of their app development process and company culture. For episode 7, we’re joined by Ceri Lindsay and Rosalind Whittam from the BBC to discover how they address accessibility.

Today, Android is not just about smartphones, Android apps and games can run on a range of devices with larger screens, such as Chromebooks. At the same time, mature mobile game franchises are looking for opportunities beyond mobile. In our final episode 8, we’ll be joined by Maximiliano Rodriguez of Gameloft to talk about the challenge of taking games to big screens and new platforms.

We hope you’ll join us over the next eight weeks to dive deeper and hear what our thought leader guests have to say on each topic.

How to stay tuned in

To listen to our first podcast and find out more about what’s coming, check out our new Apps, Games, & Insights podcast homepage.

Listen to our first episode here, or on Spotify, Apple Podcasts, Google Play Music, Google Podcasts, Deezer, iHeartRadio, and also on LibSyn. Keep an eye out on @GooglePlayDev and @AndroidDev on Twitter where we will be announcing the launch of the new episodes each week.

How useful did you find this blog post?

March 5th 2020, 2:06 pm

Update on Google at GDC 2020

Android Developers Blog

Posted by the Google for Games Team

Last Friday, GDC 2020 organizers made the difficult decision to postpone the conference. We understand this decision, as we have to prioritize the health and safety of our community.

Every year, we look forward to the Game Developers Conference and surrounding events because it gives our teams a chance to connect with game developers, partners, and friends in the industry.

Although we won’t be connecting in-person this year, we’re still excited to share the latest announcements from Google with everyone through our digital experience. We'll be sharing plans for our digital experience in the coming days.

Thank you to all who keep this community thriving and check back soon at g.co/gdc2020 for more details.

March 3rd 2020, 12:13 pm

Data Encryption on Android with Jetpack Security

Android Developers Blog

Posted by Jon Markoff, Staff Developer Advocate, Android Security

Have you ever tried to encrypt data in your app? As a developer, you want to keep data safe, and in the hands of the party intended to use. But if you’re like most Android developers, you don’t have a dedicated security team to help encrypt your app’s data properly. By searching the web to learn how to encrypt data, you might get answers that are several years out of date and provide incorrect examples.

The Jetpack Security (JetSec) crypto library provides abstractions for encrypting Files and SharedPreferences objects. The library promotes the use of the AndroidKeyStore while using safe and well-known cryptographic primitives. Using EncryptedFile and EncryptedSharedPreferences allows you to locally protect files that may contain sensitive data, API keys, OAuth tokens, and other types of secrets.

Why would you want to encrypt data in your app? Doesn’t Android, since 5.0, encrypt the contents of the user's data partition by default? It certainly does, but there are some use cases where you may want an extra level of protection. If your app uses shared storage, you should encrypt the data. In the app home directory, your app should encrypt data if your app handles sensitive information including but not limited to personally identifiable information (PII), health records, financial details, or enterprise data. When possible, we recommend that you tie this information to biometrics for an extra level of protection.

Jetpack Security is based on Tink, an open-source, cross-platform security project from Google. Tink might be appropriate if you need general encryption, hybrid encryption, or something similar. Jetpack Security data structures are fully compatible with Tink.

Key Generation

Before we jump into encrypting your data, it’s important to understand how your encryption keys will be kept safe. Jetpack Security uses a master key, which encrypts all subkeys that are used for each cryptographic operation. JetSec provides a recommended default master key in the MasterKeys class. This class uses a basic AES256-GCM key which is generated and stored in the AndroidKeyStore. The AndroidKeyStore is a container which stores cryptographic keys in the TEE or StrongBox, making them hard to extract. Subkeys are stored in a configurable SharedPreferences object.

Primarily, we use the AES256_GCM_SPEC specification in Jetpack Security, which is recommended for general use cases. AES256-GCM is symmetric and generally fast on modern devices.

val keyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

For apps that require more configuration, or handle very sensitive data, it’s recommended to build your KeyGenParameterSpec, choosing options that make sense for your use. Time-bound keys with BiometricPrompt can provide an extra level of protection against rooted or compromised devices.

Important options:

Note: If your app needs to encrypt data in the background, you should not use time-bound keys or require that the device is unlocked, as you will not be able to accomplish this without a user present.

// Custom Advanced Master Key
val advancedSpec = KeyGenParameterSpec.Builder(
    "master_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
).apply {
    setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    setKeySize(256)
    setUserAuthenticationRequired(true)
    setUserAuthenticationValidityDurationSeconds(15) // must be larger than 0
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        setUnlockedDeviceRequired(true)
        setIsStrongBoxBacked(true)
    }
}.build()

val advancedKeyAlias = MasterKeys.getOrCreate(advancedSpec)

Unlocking time-bound keys

You must use BiometricPrompt to authorize the device if your key was created with the following options:

After the user authenticates, the keys are unlocked for the amount of time set in the validity seconds field. The AndroidKeystore does not have an API to query key settings, so your app must keep track of these settings. You should build your BiometricPrompt instance in the onCreate() method of the activity where you present the dialog to the user.

BiometricPrompt code to unlock time-bound keys

// Activity.onCreate

val promptInfo = PromptInfo.Builder()
    .setTitle("Unlock?")
    .setDescription("Would you like to unlock this key?")
    .setDeviceCredentialAllowed(true)
    .build()

val biometricPrompt = BiometricPrompt(
    this, // Activity
    ContextCompat.getMainExecutor(this),
    authenticationCallback
)

private val authenticationCallback = object : AuthenticationCallback() {
        override fun onAuthenticationSucceeded(
            result: AuthenticationResult
        ) {
            super.onAuthenticationSucceeded(result)
            // Unlocked -- do work here.
        }
        override fun onAuthenticationError(
            errorCode: Int, errString: CharSequence
        ) {
            super.onAuthenticationError(errorCode, errString)
            // Handle error.
        }
    }

To use:
biometricPrompt.authenticate(promptInfo)

Encrypt Files

Jetpack Security includes an EncryptedFile class, which removes the challenges of encrypting file data. Similar to File, EncryptedFile provides a FileInputStream object for reading and a FileOutputStream object for writing. Files are encrypted using Streaming AEAD, which follows the OAE2 definition. The data is divided into chunks and encrypted using AES256-GCM in such a way that it's not possible to reorder.

val secretFile = File(filesDir, "super_secret")
val encryptedFile = EncryptedFile.Builder(
    secretFile,
    applicationContext,
    advancedKeyAlias,
    FileEncryptionScheme.AES256_GCM_HKDF_4KB)
    .setKeysetAlias("file_key") // optional
    .setKeysetPrefName("secret_shared_prefs") // optional
    .build()

encryptedFile.openFileOutput().use { outputStream ->
    // Write data to your encrypted file
}

encryptedFile.openFileInput().use { inputStream ->
    // Read data from your encrypted file
}

Encrypt SharedPreferences

If your application needs to save Key-value pairs - such as API keys - JetSec provides the EncryptedSharedPreferences class, which uses the same SharedPreferences interface that you’re used to.

Both keys and values are encrypted. Keys are encrypted using AES256-SIV-CMAC, which provides a deterministic cipher text; values are encrypted with AES256-GCM and are bound to the encrypted key. This scheme allows the key data to be encrypted safely, while still allowing lookups.

EncryptedSharedPreferences.create(
    "my_secret_prefs",
    advancedKeyAlias,
    applicationContext,
    PrefKeyEncryptionScheme.AES256_SIV,
    PrefValueEncryptionScheme.AES256_GCM
).edit {
    // Update secret values
}

More Resources

FileLocker is a sample app on the Android Security GitHub samples page. It’s a great example of how to use File encryption using Jetpack Security.

Happy Encrypting!

February 25th 2020, 6:43 pm

Android Studio 3.6

Android Developers Blog

Posted by Scott Swarthout, Product Manager

We are excited to announce the stable release of Android Studio 3.6 with a targeted set of features addressing quality in primarily code editing and debugging use cases. This is our first release after the end of Project Marble, which was focused on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. We learned a lot from Project Marble and in Android Studio 3.6 we introduce a small set of features, polished existing features, and spent a notable effort addressing bugs and improving underlying performance to ensure we meet the high quality bar we set in the past year.

Some highlights of Android Studio 3.6 include a new way to quickly design, develop and preview app layouts using XML, with a new Split View in the design editors. Additionally, you no longer have to manually type in GPS coordinates to test location with your app because we now embedded Google Maps right into the Android Emulator extended control panel. Finally, we’ve made it easier to optimize your app and find bugs with automatic memory leak detection for Fragments and Activities. We hope all of these features help you be happier and more productive while developing on Android.

Thank you to those who gave your early feedback in preview releases. Your feedback helped us iterate and improve features in Android Studio 3.6. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 3.6 is ready to download for you to get started.

Below is a full list of new features in Android Studio 3.6, organized by key developer flows.

Design

Split view in design editors

Design editors, such as the Layout Editor and Navigation Editor, now provide a Split view that enables you to see both the Design and Code views of your UI at the same time. Split view replaces and improves upon the earlier Preview window, and can be configured on a file-by-file basis to preserve context information like zoom factor and design view options, so you can choose the view that works best for each use case. To enable split view, click the Split icon in the top-right corner of the editor window. Learn more.

Split view for design editors

Color picker resource tab

In this release we wanted to make it easier to apply colors you have defined as color resources. In Android Studio 3.6, the color picker populates the color resources in your app for you to quickly choose and replace color resources values. The color picker is accessible in the design tools as well as in the XML editor.

Color picker resource tab

Develop

View binding

View binding is a feature that allows you to more easily write code that interacts with views by providing compile-time safety when referencing views in your code. When enabled, view binding generates a binding class for each XML layout file present in that module. In most cases, view binding replaces findViewById. You can reference all views that have an ID with no risk of null pointer or class cast exceptions.These differences mean that incompatibilities between your layout and your code will result in your build failing at compile time rather than at runtime. To enable view binding in your project, include the following in each module’s build.gradle file:

android {
    viewBinding.enabled = true
}

For more information, check out this blog post by one of our developer experts.

Android NDK updates

The following Android NDK features in Android Studio, previously supported in Java, are now also supported in Kotlin:

Learn more

IntelliJ Platform Update

Android Studio 3.6 includes the IntelliJ 2019.2 platform release. This IntelliJ release includes many improvements from a new services tool window to much improved startup times. Learn more

Add classes with Apply Changes

You can now add a class and then deploy that code change to your running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.

To learn more about the difference between these two actions, see Apply Changes.

Build

Android Gradle Plugin (AGP) updates

Android Gradle plugin 3.6 and higher includes support for the Maven Publish Gradle plugin, which allows you to publish build artifacts to an Apache Maven repository. The Android Gradle plugin creates a component for each build variant artifact in your app or library module that you can use to customize a publication to a Maven repository. This change will make it easier to manage the release lifecycle for your various targets. Learn more

Additionally, Android Gradle plugin has made significant performance improvement for annotation processing/KAPT for large projects. This is caused by AGP now generating R class bytecode directly, instead of .java files.

New packaging tool

The Android build team is continuously working on changes to improve build performance, and in this release we changed the default packaging tool to zipflinger for debug builds. Users should see an improvement in build speed, but you can also revert to using the old packaging tool by setting android.useNewApkCreator=false in your gradle.properties file.

Edit your gradle.properties file to disable the new packaging tool

Test

Android Emulator - Google Maps UI

Android Emulator 29.2.12 includes a new way for app developers to interface with the emulated device location. We embedded the Google Maps user interface in the extended controls menu to make it easier to specify locations and also to construct routes from pairs of locations. Individual points can be saved and re-sent to the device as the virtual location, while routes can be generated through typing in addresses or clicking two points. These routes can be replayed in real time as locations along the route are sent to the guest OS.

Android Emulator location UI with real-time location streaming

Multi-display support

Emulator 29.1.10 includes preliminary support for multiple virtual displays. As more devices are available that have multiple displays, it is important to test your app on a variety of multi-display configurations. Users can configure multiple displays through the settings menu (Extended Controls > Settings).

Multi-display support in Android Emulator

Configure secondary displays in the Android Emulator Extended Controls Panel

Resumable SDK downloads

When downloading Android SDK components and tools using the Android Studio SDK Manager, Android Studio now allows you to resume downloads that were interrupted (for example, due to a network issue) instead of restarting the download from the beginning. This enhancement is especially helpful for large downloads, such as the Android Emulator or system images, when internet connectivity is unreliable.

Pause and resume SDK downloads

In-place updates for imported APKs

Android Studio allows you to import externally-built APKs to debug and profile them. Previously, when changes to those APKs were made, you would have to manually import them again and reattach symbols and sources. Android Studio 3.6 now automatically detects changes made to the imported APK file and gives you an option to re-import it in-place.

Attach Kotlin sources to imported APKs

We added support for attaching Kotlin source files to imported APKs. To learn more, see Attach Kotlin/Java sources.

Attach Kotlin/Java sources to imported APKs

Optimize

Leak detection in Memory Profiler

Based on your feedback, we’ve added in the Memory Profiler the ability to detect Activity and Fragment instances which may have leaked. To get started, capture or import a heap dump file in the Memory Profiler, and check the Activity/Fragment Leaks checkbox to generate the results. For more information on how Android Studio detects leaks, please see our documentation.

Detect leaked Activities and Fragments in the Memory Profiler

Deobfuscate class and method bytecode in APK Analyzer

When using the APK Analyzer to inspect DEX files, you can now deobfuscate class and method bytecode. While in the DEX file viewer, load the ProGuard mappings file for the APK you’re analyzing. When loaded, you will be able to right-click on the class or method you want to inspect by selecting Show bytecode. Learn more

Deobfuscate class and method bytecode by selecting Show Bytecode in the APK Analyzer

To recap, Android Studio 3.6 includes these new enhancements & features:

Design

Develop

Build

Test

Optimize

Getting Started

Download

Download Android Studio 3.6 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.2.12 downloaded via the Android Studio SDK Manager.

As mentioned above, we appreciate any feedback on things you like, and issues or features you would like to see. If you find a bug or issue, feel free to file an issue. Follow us -- the Android Studio development team ‐ on Twitter and on Medium.

February 24th 2020, 1:06 pm

Native Dependencies in Android Studio 4.0

Android Developers Blog

By Dan Albert, Software Engineer

One thing that NDK users struggle with is managing native dependencies:

With version 4.0 of the Android Gradle Plugin, we’ve addressed these issues by adding support for distributing and exposing native libraries through the same mechanism that you do for Java libraries: Android Archives (AARs).

Here’s how you’d use curl and jsoncpp for example (and automatically pull in the implicit OpenSSL dependency that curl has):

// build.gradle
dependencies {
    implementation 'com.android.ndk.thirdparty:curl:7.68.0-alpha-1'
    implementation 'com.android.ndk.thirdparty:jsoncpp:1.8.4-alpha-1'
}

Note: With AGP 4.0 this is still experimental, so to enable this functionality you must set the following properties in your project's gradle.properties file:

# Enables Prefab
android.enablePrefab=true
# Work around https://issuetracker.google.com/149575364
android.enableParallelJsonGen=false
# 4.0.0 canary 9 defaults to Prefab 1.0.0-alpha3, which is not the latest.
android.prefabVersion=1.0.0-alpha5

Importing packages into your build

Declaring the dependencies in your build.gradle will cause Gradle to download those dependencies from Maven, but you must still instruct CMake or ndk-build how those dependencies should be used. Fortunately, the necessary CMake package config or ndk-build module will be automatically generated on your behalf. All you need to do is import and use them.

Here’s an example with CMake:

    cmake_minimum_required(VERSION 3.6)
    project(app VERSION 1.0.0 LANGUAGES CXX)

    find_package(curl REQUIRED CONFIG)
    find_package(jsoncpp REQUIRED CONFIG)

    add_library(app SHARED app.cpp)
    target_link_libraries(app curl::curl jsoncpp::jsoncpp)

And here’s the same example with ndk-build:

    LOCAL_PATH := $(call my-dir)

    include $(CLEAR_VARS)
    LOCAL_MODULE := libapp
    LOCAL_SRC_FILES := app.cpp
    LOCAL_SHARED_LIBRARIES := jsoncpp curl
    include $(BUILD_SHARED_LIBRARY)

    $(call import-module,prefab/curl)
    $(call import-module,prefab/jsoncpp)

And that’s it. In app.cpp you can now do the following:

#include "curl/curl.h"
#include "json/json.h"

A very common issue that people have is building OpenSSL to use with curl. While not explicitly mentioned in the build scripts above, the curl package itself depends on OpenSSL so this support is available automatically.

For the complete example, see the curl-ssl sample.

Prefab

The tool that facilitates all of this is called Prefab. Each AAR that exposes C++ libraries to its consumers packages their libraries, headers, and a small amount of metadata into the prefab directory in the AAR. If the prefab directory is found in an AAR dependency, the Android Gradle Plugin automatically runs Prefab to generate build system scripts from the contained information.

Each AAR might contain a large number of prebuilts for different configurations, so Prefab will perform a number of compatibility checks to find a suitable library for your build configuration. The selected library will match your build’s ABI, minSdkVersion, STL choice, and be the best fit for the version of the NDK that you’re using.

What libraries are available?

We’ve already published the following libraries:

For an up to date list, search https://maven.google.com/web/index.html for “com.android.ndk.thirdparty”.

How can I distribute my own libraries?

For the libraries we currently distribute, we wrote ndkports. This is a good fit if the library you’re building is a typical Linux or cross-platform project that doesn’t fit naturally into a typical Android build. If that’s a fit for the library you want, feel free to use ndkports for it, and consider sending us the patch!

If you’d like to request that Google maintain and publish an open source library in Prefab, use the “Package request” bug template on https://github.com/google/prefab/issues. Please keep in mind that each package does come with an ongoing cost, and we will be adding support on a limited basis so we will not be able to support everything.

Coming next is support for exposing your libraries in AARs using the existing Android Library publishing workflow.

Links

For more information about using native dependencies with the Android Gradle Plugin, see the documentation. For more examples, see the NDK samples.

If you’d like to learn more about Prefab itself, see its documentation on GitHub.

If you encounter any issues, file bugs in our Issue Tracker.

February 21st 2020, 1:25 pm

Turning it up to 11: the first Developer Preview of Android 11

Android Developers Blog

Posted by Dave Burke, VP of Engineering



Android has led the way towards the future of mobile, with new technologies like 5G to foldable displays to machine learning built into the core. A hallmark of our approach is a strong developer community that provides early and thoughtful feedback, helping us deliver a robust platform for apps and games that delight billions of users around the world. So today, we’re releasing the first Developer Preview of Android 11, and building on a strong feedback cycle last year, we’re making this year’s preview available to you earlier than ever.

With Android 11 we’re keeping our focus on helping users take advantage of the latest innovations, while continuing to keep privacy and security a top priority. We’ve added multiple new features to help users manage access to sensitive data and files, and we’ve hardened critical areas of the platform to keep the OS resilient and secure. For developers, Android 11 has a ton of new capabilities for your apps, like enhancements for foldables and 5G, call-screening APIs, new media and camera capabilities, machine learning, and more.

This is just a first look; like prior years, we’ll continue to share new features and updates over the coming months and into Google I/O as we work through your feedback. The most important thing for you to do right now is this: visit the Android 11 developer site, download a system image for your Pixel 2, 3, 3a, or 4 device, and let us know what you think!

Today’s release is an early baseline build for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Remember, getting early input from you is crucial in helping us evolve the platform to meet your needs. Read on for a taste of what’s new in Android 11, and visit the developer site for details on timeline, how to test, and how to give feedback.

Helpful innovation

5G experiences

5G brings consistently faster speeds and lower latency to more users around the world. With 5G you can extend your Wi-Fi app experiences -- such as streaming 4K video or loading higher-res game assets -- to mobile users, or you can build new experiences designed specifically for 5G. In Android 11 we’re enhancing and updating the existing connectivity APIs so you can take advantage of 5G’s improved speeds.



Moving beyond the home, 5G can for example let you enhance your “on-the-go” experience by providing seamless interactions with the world around you from friends and family to businesses.



New screen types

Device makers are continuing to innovate by bringing exciting new form-factors and device screens to market. We’ve extended support for these in the platform, with APIs to let you optimize your apps.



People and conversations

Communicating with your friends and colleagues is the most important thing many people do on their phones. In Android 11, we are introducing changes that help developers create deeper conversational experiences, a few of which you’ll see early versions of in DP1:

Real-time, bilateral communication apps should use the sharing/conversation shortcuts API to provide People targets that Android will surface throughout the phone as well as Bubble APIs to allow users to carry on conversations while using the device in other capacities.

Neural Networks API 1.3

Neural Networks API (NNAPI) is designed for running computationally intensive operations for machine learning on Android devices. In Android 11, we’re expanding the operations and controls available to developers. In this release, we’ve added new operations and execution controls to help optimize common use cases:

See the NDK sample code for examples using these new APIs.

Watch for more coming in later preview updates. We’re working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.3.

Privacy and security

Privacy

Privacy has always been at the core of Android, and each year we’ve added more ways to keep users secure and increase transparency and control. These changes have been popular with users - for example in Android 10 we added the “While app is in use” permission option to give users more granular control over their location and limit background location access. So far, when given the “While app is in use” option, about half of users select it.

In Android 11 we’re continuing our focus on user privacy with new permission options, updates to scoped storage, and more. Please give these features a try with your apps right away and let us know what you think.



One-time permission dialog in Android 11.



In addition to these platform changes, users tell us that they want more protection on earlier versions of Android and more transparency around how apps will use this data, so we are updating Google Play Policy to ensure that apps only request location permissions when truly necessary. Read more

Security

We focus on raising the bar for security with each version of Android -- from reaching more devices with monthly security updates to building more protections into the latest platform. In Android 11, we’ve extended Android’s defense-in-depth strategies to more areas of the platform and added new features and APIs for apps.



Updates and compatibility

Google Play System Updates

Since Android 10, we’ve been scaling up our investment in Google Play System Updates (Project Mainline) to improve security, privacy, and consistency across the ecosystem. Thanks to strong collaboration with device makers, we’ve made significant progress towards this goal and have expanded our infrastructure to reach a wider range of devices more safely and quickly.

In Android 11, we’ve added 12 new updatable modules, for a total of 22 modules. Highlights include a permissions module that standardizes user and developer access to critical privacy controls on Android devices, a media provider module that’s integral to our privacy efforts around Scoped Storage, and an NNAPI (Neural Networks API) module that optimizes performance and guarantees consistent APIs across devices. To learn more about Google Play System Updates, check out the Project Mainline blog post.

App compatibility

We’re also working to make updates faster and smoother by prioritizing app compatibility as we roll out new platform versions. In Android 11 we’ve added new processes, developer tools, and release milestones to minimize the impact of platform updates.



App compatibility toggles in Developer Options.





Polish and quality

Connectivity

Image and camera improvements

Low latency



Get started with Android 11

The Developer Preview has everything you need to try the Android 11 features, test your apps, and give us feedback. To get started, download and flash a device system image to a Pixel 2 / 2 XL, Pixel 3 / 3 XL, Pixel 3a / 3a XL, or Pixel 4 / 4 XL device. Additionally, you can set up the Android Emulator through Android Studio. The Android Emulator running Android 11 system images includes experimental support to run ARM 32-bit & 64-bit binary app code directly on 64-bit x86 Android Emulator system images. Lastly, for broader testing, GSI images are also available.

Next, update your Android Studio environment with the Android 11 Preview SDK and tools - you can do this from inside Android Studio. See the set up guide for complete details. To take advantage of the latest Android Studio features, we recommend installing the latest version of Android Studio from the canary channel.

When you’re set up, here are some of the things you can do:

For more information, visit the Android 11 developer site. You’ll find an overview of what’s new in this release, details on behavior changes, setup and migration guides, release notes, feedback channels, and more.

Preview updates

We plan to update the preview system images and SDK regularly throughout the Android 11 release cycle. This initial preview release is for developers only and not intended for daily or consumer use, so we're making it available by manual download and flash only. Downloads are here and instructions are here.

As we get closer to a final product, we'll be inviting consumers to try it out as well, and we'll open up enrollments through Android Beta at that time. Stay tuned for details, but for now please note that Android Beta is not currently available for Android 11.

Give us your feedback!

As always, your feedback is crucial, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate, and because of timelines, we’re giving priority to input we receive in the next several weeks. When you find issues, please report them here.

February 19th 2020, 1:13 pm

Safer and More Transparent Access to User Location

Android Developers Blog

Posted by Krish Vitaldevara, Director of Product Management Trust & Safety, Google Play

Last year, we made several changes to our platform and policies to increase user trust and safety. We’re proud of the work we’ve done to improve family safety, limit use of sensitive permissions, and catch bad actors before they ever reach the Play Store.

We realize that changes can lead to work for developers. Last year, you told us that you wanted more detailed communications about impactful updates, why we’re making them, and how to take action. You also asked for as much time as possible to make any changes required.

With that feedback in mind, today, we’re previewing Android and Google Play policy changes that will impact how developers access location in the background.

Giving users more control over their location data

Users consistently tell us that they want more control over their location data and that we should take every precaution to prevent misuse. Since the beginning of Android, users have needed to grant explicit permission to any app that wants access to their location data.

In Android 10, people were given additional control to only grant access when the app is in use, which makes location access more intentional. Users clearly appreciated this option as over half of users select “While app is in use.”

Now in Android 11, we’re giving users even more control with the ability to grant a temporary “one-time” permission to sensitive data like location. When users select this option, apps can only access the data until the user moves away from the app, and they must then request permission again for the next access. Please visit the Android 11 developer preview to learn more.

Preventing unnecessary access to background location

Users tell us they also want more protection on earlier versions of Android - as well as more transparency around how apps use this data.

As we took a closer look at background location usage, we found that many of the apps that requested background location didn’t actually need it. In fact, many of these apps could provide the same user experience by only accessing location when the app is visible to the user. We want to make it easier for users to choose when to share their location and they shouldn't be asked for a permission that the app doesn't need.

Later this year, we will be updating Google Play policy to require that developers get approval if they want to access location data in the background. Factors that will be looked at include:

All apps will be evaluated against the same factors, including apps made by Google, and all submissions will be reviewed by people on our team. Let’s take a look at three examples:

An app that sends emergency or safety alerts as part of its core functionality - and clearly communicates why access is needed to the user - would have a strong case to request background location.

A social networking app that allows users to elect to continuously share their location with friends would also have a strong case to access location in the background.

An app with a store locator feature would work just fine by only accessing location when the app is visible to the user. In this scenario, the app would not have a strong case to request background location under the new policy.

When we spoke to developers for feedback, the vast majority understood user concerns over their information falling into the wrong hands and were willing to change their location usage to be safer and more transparent.

Getting approval for background access

We know that when we update our policies, you want to get actionable feedback and have ample time to make changes. Before we implement this policy change, you will be able to submit your use case via the Play Console and receive feedback on whether it will be allowed under the new policy.

We anticipate the following timeline for this policy rollout; however, it is subject to change.

Review and evaluate your location access

We encourage all developers to review the following best practices for accessing location data in their apps:

We hope you found this policy preview useful in planning your roadmap for the year and we appreciate your efforts to build privacy-friendly apps. Together, we can keep the Android ecosystem safe and secure for everyone.

February 19th 2020, 1:00 pm

Handling Device Orientation Efficiently in Vulkan With Pre-Rotation

Android Developers Blog

By Omar El Sheikh, Android Engineer

Francesco Carucci, Developer Advocate

Vulkan provides developers with the power to specify much more information to devices about rendering state compared to OpenGL. With that power though comes some new responsibilities; developers are expected to explicitly implement things that in OpenGL were handled by the driver. One of these things is device orientation and its relationship to render surface orientation. Currently, there are 3 ways that Android can handle reconciling the render surface of the device with the orientation of the device :

  1. The device has a Display Processing Unit (DPU) that can efficiently handle surface rotation in hardware to match the device orientation (requires a device that supports this)
  2. The Android OS can handle surface rotation by adding a compositor pass that will have a performance cost depending on how the compositor has to deal with rotating the output image
  3. The application itself can handle the surface rotation by rendering a rotated image onto a render surface that matches the current orientation of the display

What Does This Mean For Your Apps?

There currently isn't a way for an application to know whether surface rotation handled outside of the application will be free. Even if there is a DPU to take care of this for us, there will still likely be a measurable performance penalty to pay. If your application is CPU bound, this becomes a huge power issue due to the increased GPU usage by the Android Compositor which usually is running at a boosted frequency as well; and if your application is GPU bound, then it becomes a potentially large performance issue on top of that as the Android Compositor will preempt your application's GPU work causing your application to drop its frame rate.

On Pixel 4XL, we have seen on shipping titles that SurfaceFlinger (the higher-priority task that drives the Android Compositor) both regularly preempts the application’s work causing 1-3ms hits to frametimes, as well as puts increased pressure on the GPU’s vertex/texture memory as the Compositor has to read the frame to do its composition work.

Handling orientation properly stops GPU preemption by SurfaceFlinger almost entirely, as well as sees the GPU frequency drop 40% as the boosted frequency used by the Android Compositor is no longer needed.

To ensure surface rotations are handled properly with as little overhead as possible (as seen in the case above) we recommend implementing method 3 - this is known as pre-rotation. The primary mechanism with which this works is by telling the Android OS that we are handling the surface rotation by specifying in the orientation during swapchain creation through the passed in surface transform flags, which stops the Android Compositor from doing the rotation itself.

Knowing how to set the surface transform flag is important for every Vulkan application, since applications tend to either support multiple orientations, or support a single orientation where its render surface is in a different orientation to what the device considers its identity orientation; For example a landscape-only application on a portrait-identity phone, or a portrait-only application on a landscape-identity tablet.

In this post we will describe in detail how to implement pre-rotation and handle device rotation in your Vulkan application.

Modify AndroidManifest.xml

To handle device rotation in your app, change the application’s AndroidManifest.xml to tell Android that your app will handle orientation and screen size changes. This prevents Android from destroying and recreating the Android activity and calling the onDestroy() function on the existing window surface when an orientation change occurs. This is done by adding the orientation (to support API level <13) and screenSize attributes to the activity’s configChanges section:

<activity android:name="android.app.NativeActivity"
          android:configChanges="orientation|screenSize">

If your application fixes its screen orientation using the screenOrientation attribute you do not need to do this. Also if your application uses a fixed orientation then it will only need to setup the swapchain once on application startup/resume.

Get the Identity Screen Resolution and Camera Parameters

The next thing that needs to be done is to detect the device’s screen resolution that is associated with the VK_SURFACE_TRANSFORM_IDENTITY_BIT_KHR as this resolution is the one that the Swapchain will always need to be set to. The most reliable way to get this is to make a call to vkGetPhysicalDeviceSurfaceCapabilitiesKHR() at application startup and storing the returned extent - swapping the width and height based on the currentTransform that is also returned in order to ensure we are storing the identity screen resolution:

    VkSurfaceCapabilitiesKHR capabilities;
    vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);

    uint32_t width = capabilities.currentExtent.width;
    uint32_t height = capabilities.currentExtent.height;
    if (capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR ||
        capabilities.currentTransform & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) {
      // Swap to get identity width and height
      capabilities.currentExtent.height = width;
      capabilities.currentExtent.width = height;
    }

    displaySizeIdentity = capabilities.currentExtent;

displaySizeIdentity is a VkExtent2D that we use to store said identity resolution of the app's window surface in the display’s natural orientation.

Detect Device Orientation Changes (Android 10+)

To know when the application has encountered an orientation change, the most reliable means of tracking this change involves checking the return value of vkQueuePresentKHR() and seeing if it returned VK_SUBOPTIMAL_KHR

  auto res = vkQueuePresentKHR(queue_, &present_info);
  if (res == VK_SUBOPTIMAL_KHR){
    orientationChanged = true;
  }

One thing to note about this solution is that it only works on devices running Android Q and above as that is when Android started to return VK_SUBOPTIMAL_KHR from vkQueuePresentKHR()

orientationChanged is a boolean stored somewhere accessible from the applications main rendering loop

Detecting Device Orientation Changes (Pre-Android 10)

For devices running older versions of Android below 10, a different implementation is needed since we do not have access to VK_SUBOPTIMAL_KHR.

Using Polling

On pre-10 devices we can poll the current device transform every pollingInterval frames, where pollingInterval is a granularity decided on by the programmer. The way we do this is by calling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() and then comparing the returned currentTransform field with that of the currently stored surface transformation (in this code example stored in pretransformFlag)

  currFrameCount++;
  if (currFrameCount >= pollInterval){
    VkSurfaceCapabilitiesKHR capabilities;
    vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);

    if (pretransformFlag != capabilities.currentTransform) {
      window_resized = true;
    }
    currFrameCount = 0;
  }

On a Pixel 4 running Android Q, polling vkGetPhysicalDeviceSurfaceCapabilitiesKHR() took between .120-.250ms and on a Pixel 1XL running Android O polling took .110-.350ms

Using Callbacks

A second option for devices running below Android 10 is to register an onNativeWindowResized() callback to call a function that sets the orientationChanged flag to signal to the application an orientation change has occurred:

void android_main(struct android_app *app) {
  ...
  app->activity->callbacks->onNativeWindowResized = ResizeCallback;
}

Where ResizeCallback is defined as:

void ResizeCallback(ANativeActivity *activity, ANativeWindow *window){
  orientationChanged = true;
}

The drawback to this solution is that onNativeWindowResized() only ever gets called on 90 degree orientation changes (going from landscape to portrait or vice versa), so for example an orientation change from landscape to reverse landscape will not trigger the swapchain recreation, requiring the Android compositor to do the flip for your application.

Handling the Orientation Change

To actually handle the orientation change, we first have a check at the top of the main rendering loop for whether the orientationChanged variable has been set to true, and if so we'll go into the orientation change routine:

bool VulkanDrawFrame() {
 if (orientationChanged) {
   OnOrientationChange();
 }

And within the OnOrientationChange() function we will do all the work necessary to recreate the swapchain. This involves destroying any existing Framebuffers and ImageViews; recreating the swapchain while destroying the old swapchain (which will be discussed next); and then recreating the Framebuffers with the new swapchain’s DisplayImages. Note that attachment images (depth/stencil images for example) usually do not need to be recreated as they are based on the identity resolution of the pre-rotated swapchain images.

void OnOrientationChange() {
 vkDeviceWaitIdle(getDevice());

 for (int i = 0; i < getSwapchainLength(); ++i) {
   vkDestroyImageView(getDevice(), displayViews_[i], nullptr);
   vkDestroyFramebuffer(getDevice(), framebuffers_[i], nullptr);
 }

 createSwapChain(getSwapchain());
 createFrameBuffers(render_pass, depthBuffer.image_view);
 orientationChanged = false;
}

And at the end of the function we reset the orientationChanged flag to false to show that we have handled the orientation change.

Swapchain Recreation

In the previous section we mention having to recreate the swapchain. The first steps to doing so involves getting the new characteristics of the rendering surface:

void createSwapChain(VkSwapchainKHR oldSwapchain) {
   VkSurfaceCapabilitiesKHR capabilities;
   vkGetPhysicalDeviceSurfaceCapabilitiesKHR(physDevice, surface, &capabilities);
   pretransformFlag = capabilities.currentTransform;

With the VkSurfaceCapabilities struct populated with the new information, we can now check to see whether an orientation change has occurred by checking the currentTransform field and store it for later in the pretransformFlag field as we will be needing it for later when we make adjustments to the MVP matrix.

In order to do so we must make sure that we properly specify some attributes within the VkSwapchainCreateInfo struct:

VkSwapchainCreateInfoKHR swapchainCreateInfo{
  ...                        
  .sType = VK_STRUCTURE_TYPE_SWAPCHAIN_CREATE_INFO_KHR,
  .imageExtent = displaySizeIdentity,
  .preTransform = pretransformFlag,
  .oldSwapchain = oldSwapchain,
};

vkCreateSwapchainKHR(device_, &swapchainCreateInfo, nullptr, &swapchain_));

if (oldSwapchain != VK_NULL_HANDLE) {
  vkDestroySwapchainKHR(device_, oldSwapchain, nullptr);
}

The imageExtent field will be populated with the displaySizeIdentity extent that we stored at application startup. The preTransform field will be populated with our pretransformFlag variable (which is set to the currentTransform field of the surfaceCapabilities). We also set the oldSwapchain field to the swapchain that we are about to destroy.

It is important that the surfaceCapabilities.currentTransform field and the swapchainCreateInfo.preTransform field match because this lets the Android OS know that we are handling the orientation change ourselves, thus avoiding the Android Compositor.

MVP Matrix Adjustment

The last thing that needs to be done is actually apply the pre-transformation. This is done by applying a rotation matrix to your MVP matrix. What this essentially does is apply the rotation in clip space so that the resulting image is rotated to the device current orientation. You can then simply pass this updated MVP matrix into your vertex shader and use it as normal without the need to modify your shaders.

glm::mat4 pre_rotate_mat = glm::mat4(1.0f);
glm::vec3 rotation_axis = glm::vec3(0.0f, 0.0f, 1.0f);

if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(90.0f), rotation_axis);
}

else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(270.0f), rotation_axis);
}

else if (pretransformFlag & VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR) {
 pre_rotate_mat = glm::rotate(pre_rotate_mat, glm::radians(180.0f), rotation_axis);
}

MVP = pre_rotate_mat * MVP;

Consideration - Non-Full Screen Viewport and Scissor

If your application is using a non-full screen viewport/scissor region, they will need to be updated according to the orientation of the device. This requires that we enable the dynamic Viewport and Scissor options during Vulkan’s pipeline creation:

VkDynamicState dynamicStates[2] = {
  VK_DYNAMIC_STATE_VIEWPORT,
  VK_DYNAMIC_STATE_SCISSOR,
};

VkPipelineDynamicStateCreateInfo dynamicInfo = {
  .sType = VK_STRUCTURE_TYPE_PIPELINE_DYNAMIC_STATE_CREATE_INFO,
  .pNext = nullptr,
  .flags = 0,
  .dynamicStateCount = 2,
  .pDynamicStates = dynamicStates,
};

VkGraphicsPipelineCreateInfo pipelineCreateInfo = {
  .sType = VK_STRUCTURE_TYPE_GRAPHICS_PIPELINE_CREATE_INFO,
  ...
  .pDynamicState = &dynamicInfo,
  ...
};

VkCreateGraphicsPipelines(device, VK_NULL_HANDLE, 1, &pipelineCreateInfo, nullptr, &mPipeline);

The actual computation of the viewport extent during command buffer recording looks like this:

int x = 0, y = 0, w = 500, h = 400;
glm::vec4 viewportData;

switch (device->GetPretransformFlag()) {
  case VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR:
    viewportData = {bufferWidth - h - y, x, h, w};
    break;
  case VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR:
    viewportData = {bufferWidth - w - x, bufferHeight - h - y, w, h};
    break;
  case VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR:
    viewportData = {y, bufferHeight - w - x, h, w};
    break;
  default:
    viewportData = {x, y, w, h};
    break;
}

const VkViewport viewport = {
    .x = viewportData.x,
    .y = viewportData.y,
    .width = viewportData.z,
    .height = viewportData.w,
    .minDepth = 0.0F,
    .maxDepth = 1.0F,
};

vkCmdSetViewport(renderer->GetCurrentCommandBuffer(), 0, 1, &viewport);

Where x and y define the coordinates of the top left corner of the viewport, and w and h define the width and height of the viewport respectively.

The same computation can be used to also set the scissor test, and is included below for completeness:

int x = 0, y = 0, w = 500, h = 400;
glm::vec4 scissorData;

switch (device->GetPretransformFlag()) {
  case VK_SURFACE_TRANSFORM_ROTATE_90_BIT_KHR:
    scissorData = {bufferWidth - h - y, x, h, w};
    break;
  case VK_SURFACE_TRANSFORM_ROTATE_180_BIT_KHR:
    scissorData = {bufferWidth - w - x, bufferHeight - h - y, w, h};
    break;
  case VK_SURFACE_TRANSFORM_ROTATE_270_BIT_KHR:
    scissorData = {y, bufferHeight - w - x, h, w};
    break;
  default:
    scissorData = {x, y, w, h};
    break;
}

const VkRect2D scissor = {
    .offset =
        {
            .x = (int32_t)viewportData.x,
            .y = (int32_t)viewportData.y,
        },
    .extent =
        {
            .width = (uint32_t)viewportData.z,
            .height = (uint32_t)viewportData.w,
        },
};

vkCmdSetScissor(renderer->GetCurrentCommandBuffer(), 0, 1, &scissor);

Consideration - Fragment Shader Derivatives

If your application is using derivative computations such as dFdx and dFdy, additional transformations may be needed to account for the rotated coordinate system as these computations are executed in pixel space. This requires the app to pass some indication of the preTransform into the fragment shader (such as an integer representing the current device orientation) and use that to map the derivative computations properly:

Conclusion

In order for your application to get the most out of Vulkan on Android, implementing pre-rotation is a must. The most important takeaways from this blogpost are:

  1. Ensure that during swapchain creation or recreation, the pretransform flag is set so that it matches the flag returned by the Android operating system. This will avoid the compositor overhead
  2. Keep the swapchain size fixed to the identity resolution of the app's window surface in the display’s natural orientation
  3. Rotate the MVP matrix in clip space to account for the devices orientation since the swapchain resolution/extent no longer update with the orientation of the display
  4. Update viewport and scissor rectangles as needed by your application

Here is a link to a minimal example of pre-rotation being implemented for an android application:

https://github.com/google/vulkan-pre-rotation-demo

February 14th 2020, 4:36 pm

Detecting Memory Corruption Bugs With HWASan

Android Developers Blog

Posted by Evgenii Stepanov, Staff Software Engineer, Dynamic Tools

Native code in memory-unsafe languages like C and C++ is often vulnerable to memory corruption bugs. Our data shows that issues like use-after-free, double-free, and heap buffer overflows generally constitute more than 65% of High & Critical security bugs in Chrome and Android.

In previous years our memory bug detection efforts were focused on Address Sanitizer (ASan). ASan catches these errors but causes your app to use 2x-3x extra memory and to run slower.

To better tackle these problems we’ve developed Hardware-Assisted Address Sanitizer (HWASan). HWASan typically only requires 15% more memory. It’s also a lot faster than ASan. HWASan’s performance makes it usable not only for unit testing, but also for interactive human-driven testing. We use this to find memory issues in the Android OS itself, and now we've made it easy for app developers to use it too. HWASan is fast enough that some Android developers use it on their development devices for everyday tasks.

Under the hood

HWASan is based on memory tagging and depends on the Top Byte Ignore feature present in all 64-bit ARM CPUs and the associated kernel support. Every memory allocation is assigned a random 8-bit tag that is stored in the most significant byte (MSB) of the address, but ignored by the CPU. As a result, this tagged pointer can be used in place of a regular pointer without any code changes.

Under the hood, HWASan uses shadow memory - a sparse map that assigns a tag value to each 16 byte block of program memory. Compile time code instrumentation is used to insert checks that compare pointer and memory tags for every memory access, and raise an error if they do not match.

This approach allows us to detect both use-after-free and buffer-overflow types of bugs. The memory tag in the shadow is changed to a random value during allocation and deallocation. As a result, attempting to access deallocated memory with a dangling pointer will almost certainly fail due to a tag mismatch. The same is true for an attempt to access memory outside of the allocated region, which is very likely to have a different tag. Stack and global variables are similarly protected.

Use-after-free bug detection with memory tagging.

This approach is non deterministic: because of the limited number of possible tags, an invalid memory access has 1 chance out of 256 (approximately 0.4%) to pass undetected. We have not observed this as a problem in practice, but, due to the tag randomness, running the program the second time is very likely to find any bugs that the first run has missed.

An advantage of HWASan over ASan is its ability to find bugs that happen far from their origination point - for example, a use-after-free where the memory is accessed long after it has been deallocated, or a buffer overflow with a large offset. This is not the case with ASan, which uses red zones around memory allocations, and a quarantine for the temporary storage of recently deallocated memory blocks. Both redzones and the quarantine are of limited size, and error detection is unlikely beyond that. HWASan uses a different approach that does not have these limitations.

Usage

When a bug is discovered the process is terminated and a crash dump is printed to logcat. The “Abort message” field contains a HWASan report, which shows the access type (read or write), access address, thread id and the stack trace of the bad memory access. This is followed by a stack trace for the original allocation, and, for use-after-free bugs, a stack trace showing where the deallocation took place. Advanced users can find extra debugging information below this, including a map of memory tags for nearby locations.

signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '==21586==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0042a0807af0 at pc 0x007b23b8786c
WRITE of size 1 at 0x0042a0807af0 tags: db/19 (ptr/mem) in thread T0
    #0 0x7b23b87868 (/data/app/com.example.myapp/lib/arm64/native.so+0x2868)
    #1 0x7b8f1e4ccc (/apex/com.android.art/lib64/libart.so+0x198ccc)
[...]

0x0042a0807af0 is located 0 bytes to the right of 16-byte region [0x0042a0807ae0,0x0042a0807af0)
allocated here:
    #0 0x7b92a322bc (/path/to/libclang_rt.hwasan-aarch64-android.so+0x212bc)
    #1 0x7b23b87840 (/data/app/com.example.myapp/lib/arm64/native.so+0x2840)
[...]

An example snippet from a HWASan crash report.

Google uses HWASan extensively in Android development, and now you can too. Find out more -- including the details of how to rebuild your app for use with HWASan -- at https://developer.android.com/ndk/guides/hwasan. Prebuilt HWASan system images are available on the AOSP build server (or you can build your own). They can be easily flashed onto a compatible device using the recently announced web flash tool.

February 13th 2020, 4:03 pm

How we fought bad apps and malicious developers in 2019

Android Developers Blog

Posted by Andrew Ahn, Product Manager, Google Play + Android App Safety

Google Play connects users with great digital experiences to help them be more productive and entertained, as well as providing app developers with tools to reach billions of users around the globe. Such a thriving ecosystem can only be achieved and sustained when trust and safety is one of its key foundations. Over the last few years we’ve made the trust and safety of Google Play a top priority, and have continued our investments and improvements in our abuse detection systems, policies, and teams to fight against bad apps and malicious actors.

In 2019, we continued to strengthen our policies (especially to better protect kids and families), continued to improve our developer approval process, initiated a deeper collaboration with security industry partners through the App Defense Alliance, enhanced our machine learning detection systems analyzing an app’s code, metadata, and user engagement signals for any suspicious content or behaviors, as well as scaling the number and the depth of manual reviews. The combination of these efforts have resulted in a much cleaner Play Store:

In addition we’ve launched a refreshed Google Play Protect experience, our built-in malware protection for Android devices. Google Play Protect scans over 100B apps everyday, providing users with information about potential security issues and actions they can take to keep their devices safe and secure. Last year, Google Play Protect also prevented more than 1.9B malware installs from non-Google Play sources.

While we are proud of what we were able to achieve in partnership with our developer community, we know there is more work to be done. Adversarial bad actors will continue to devise new ways to evade our detection systems and put users in harm's way for their own gains. Our commitment in building the world's safest and most helpful app platform will continue in 2020, and we will continue to invest in the key app safety areas mentioned in last year’s blog post:

Our teams of passionate product managers, engineers, policy experts, and operations leaders will continue to work with the developer community to accelerate the pace of innovation, and deliver a safer app store to billions of Android users worldwide.

February 11th 2020, 1:09 pm

The path to DX deprecation

Android Developers Blog

Posted by Leo Sei, Product Manager on Android

Back in 2017, we released D8, a new faster dexing compiler to replace DX, producing smaller APKs. In April 2018, we announced D8 as the default option in Android Studio 3.1.

In that announcement, we laid out 3 phases to deprecate DX and we are now entering phase 2:

“Once we've seen a six month window without major regressions from DX to D8, we'll enter the second phase. This phase will last for a year, and is intended to ensure that even complex projects have lots of time to migrate. During this phase, we'll keep DX available, but we'll treat it as fully deprecated; we won't be fixing any issues.”

If you haven’t already, it is now the time to migrate to D8 (see details in the previous post). As always, if you encounter issues, please do let us know!

Next steps

On Feb 1st, 2021, we’ll move to step 3, removing DX fully from Android Studio and any other build environments.

Note: This post is about DX only (and does not include shrinking tools)

February 4th 2020, 12:13 pm

Flashing Builds from the Android Open Source Project

Android Developers Blog

Posted by Mitchell Wills, Android Build Software Engineer

AOSP has been around for a while, but flashing builds onto a development device has always required a number of manual steps. A year ago we launched Android's Continuous Integration Dashboard, which gives more visibility into the continuous build status of the AOSP source tree. However, these builds were not available for phones and flashing devices still required a manual command line process.

In order to support developers working in AOSP we are launching Android Flash Tool, which allows developers to flash devices with builds listed on the Continuous Integration Dashboard. This can be used by developers working on the Android OS to test changes or App developers to test compatibility with the latest AOSP build.

A device being flashed.

Android Flash Tool allows anyone to use a browser supporting WebUSB, such as Chrome 79 or Edge 79, to flash an Android device entirely from the browser (Windows requires installing a driver). After connecting a device and authorizing the page to connect to it users will be presented with a list of available builds. After choosing a build click flash and the tool does the rest. You can flash recent Pixel devices and the HiKey reference boards with builds based on aosp-master.

Try Android Flash Tool yourself at https://flash.android.com.

Find out more at https://source.android.com/setup/contribute/flash.

January 28th 2020, 12:23 pm

Get ready for the Game Developers Conference

Android Developers Blog

Posted by Kacey Fahey, Games Developer Marketing, Google

Cross-posting from the Google Developers Blog.

Join us online or live* at the Google Developer Summits during the Game Developers Conference on March 16 and 17 to learn about the latest tools and updates to build great games, reach more players, and improve discovery of your game.

Google has lots to share with the game development community at the Game Developers Conference (GDC) in March. Check out our plans and sign up to keep up to date with the latest GDC news and announcements from Android, Google Play, Firebase, and more.

For one week, tens of thousands of creators from the gaming community come together at GDC to hear the latest industry innovations and network with peers to enable better gaming experiences for players around the world.

Below is a preview of what to expect from Google, and remember, it’s just the beginning. Don’t forget to sign up for our newsletter as we reveal more leading up to the event, or you can check out our website, Google for Games at GDC.

Google for Games Keynote

We will start the week with the Google for Games Keynote on Monday, March 16 at 9:30 am PST. Join the livestream and learn about the latest tools and solutions to help game developers create great games, connect with players, and scale their businesses.

Google Developer Keynote photo at GDC 2019

Google Developer Summit

We have two days of in-depth sessions where you can uplevel your skills across Google products and solutions. Topics range from new tools to optimize game development, how to reach more devices and players, using new Firebase features to alleviate infrastructure management challenges, and much more.

Learn more about the Google Developer Summit we’ll be hosting on March 16 -17 and how you can join in person with an official GDC ticket or via livestream.

We’ll be sharing more details about everything we have planned at GDC in the coming weeks so be sure to sign up to be among the first to hear the latest updates, and save the date to watch the keynote and other Developer Summit sessions at g.co/gdc2020.

More to come soon!

The Google for Games team

*On-site events are part of the official Game Developers Conference and require a pass to attend.

January 27th 2020, 1:59 pm

Enter the Indie Games Festival from Google Play

Android Developers Blog

Posted by Patricia Correa, Director, Developer Marketing

The indie developer community released several fantastic titles on Google Play during 2019, showing the technical skill and innovative design that makes them an essential part of the gaming landscape.

To continue helping indie developers thrive, today we’re announcing the 2020 edition of our annual Google Play Indie Games Festival. This year we will host three competitions for developers from several European countries*, Japan, and South Korea.

Prizes:

Prizes are designed to help you grow your business, including:

Eligibility:

The contests are open to developers from selected countries, with no more than 50 employees. The submitted game must be new, released at least in open beta between May 7, 2019 and March 2, 2020. See other requirements in the terms and conditions for each of the contests.

Process:

Simply fill out the relevant form by clicking here. Submissions are open until March 2, 2020, at 3pm CET.

The Top 20 entries in each region will be announced in March and invited to showcase at the Festival events where the field will be narrowed to 10 by the event audience, industry experts and the Google team. The Top 10 will present their games on stage and the 3 winners will be selected.

Not submitting a game? Come and take part:

Even if you’re not submitting a game to the competitions, we’d love to see you at one of the Festival events on the 25th of April 2020.

Learn more and sign up on g.co/play/indiefestival

* The European competition is open to developers from the following countries: Austria, Belgium, Belarus, Bulgaria, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hungary, Israel, Italy, Latvia, Lithuania, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Slovenia, Spain, Sweden, Turkey, Ukraine, and the United Kingdom (including Northern Ireland).

How useful did you find this blog post?

January 9th 2020, 3:08 am
Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا