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

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

Kotlin/Everywhere - it’s a wrap!

Android Developers Blog

Posted by Florina Muntenescu, Developer Advocate (@FMuntenescu)

At Google I/O 2019 we announced that Android development will become increasingly Kotlin-first. Together with JetBrains, we also launched Kotlin/Everywhere - a global series of community led events focusing on the potential of using Kotlin everywhere; on Android, servers, web front-end and other platforms.

Kotlin/Everywhere events took place from May through December and we want to thank everyone for getting involved

👨‍💻👩‍💻30,000+ developers participated in-person at Kotlin/Everywhere events

🎥🍿200,000 views of live-streams and event recordings like Kotlin/Everywhere Bengaluru, Minsk, Chicago, Buenos Aires and more.

📅 500+ events: from short evening meetups, half-day sessions, and full day events, to Kotlin/Everywhere tracks at larger events like DevFests, or even StudyJams that spanned several weeks.

🎤~30 speakers from Google and JetBrains gave ~70 talks at events around the world.

🌎 85+ countries: from United States to Chile, Kenya, Greece, Taiwan, New Zealand and so many more, with some countries hosting 1-2 events to some hosting dozens: Nigeria - 38, China - 27, India - 25 just to name a few.

💻 Many of the resources used or created for Kotlin/Everywhere by Google and JetBrains are available online:

General Kotlin:

Kotlin in Android:

Kotlin in Google Cloud Platform:

Multi-platform Kotlin:

We’re grateful for this engagement with Kotlin from communities around the world, as well as for all the organisers, speakers and attendees who made these events possible! To participate in more Kotlin events, check out JetBrains’ KotlinConf’19 Global initiative, happening through March 2020.

With all of the resources available, there’s never been a better time to adopt Kotlin… Everywhere!

December 18th 2019, 12:18 pm

Our highlights from Android & Google Play in 2019 - building for the next decade

Android Developers Blog

Posted by Patricia Correa, P&E Developer Marketing Director

The last 12 months have seen Google Play continue to grow, with over 116 billion downloads of the apps and games that you created.

We’ve been working hard to build the latest technology and tools for modern Android development and distribution, improving Google Play and the Play Console to offer you new and better ways for your app to be discovered, promoted, and monetized.

A key focus has been addressing the challenge of keeping users safe and maintaining trust in Google Play.

Modern Android development

We are focused on building great tools and services and your feedback is crucial in helping us do so. You have told us that you love Android’s openness, but we have also heard that you would like us to marry it with an opinion about the right way to do things. We call this approach modern Android development: opinionated and powerful, for fast, easy development, taking away everything that slows you down so you can focus on building incredible experiences. You can see modern Android development come to life in a number of investments we made this year:

Android 10

Android 10, released earlier this year, is built around three important themes. First, Android 10 is shaping the leading edge of mobile innovation with advanced machine-learning and support for emerging devices like foldables and 5G enabled phones. Next, Android 10 has a central focus on privacy and security, with almost 50 features that give users greater protection, transparency, and control. Finally, Android 10 expands users' digital wellbeing controls so individuals and families can find a better balance with technology.

Modern app and game distribution

We introduced Android App Bundles last year as a mechanism to simplify and streamline app distribution, overcome the constraints of APK publishing, and introduce advanced distribution features such as dynamic delivery. There are now over 300K app bundle apps and games in production, covering nearly 30% of all active installs. If this doesn’t include your app or game, check out 16 reasons to publish your apps and games with the Android App Bundle.

This year we’ve made it much easier to test and implement app bundles and dynamic delivery. Internal app sharing makes it easy to share test builds with others. You can easily grant anyone on your team the ability to upload a test build to Play and get a download link to share with your testers. With internal app sharing, you can be sure that each device is receiving exactly what Play would deliver in the wild. You don’t need to use version codes or the prod signing key, and can even upload debuggable artifacts.You can also get download links for old versions of your app from the Play Console, whether they’re app bundles or APKs.

Protecting the ecosystem

In 2019, you helped us make Google Play even safer, building user trust in your apps and Google Play as a whole. Thanks to your hard work, we have:

To help you protect your apps, we’ve improved our ability to detect impersonators, repackaging, bad content, and other forms of abuse. Additionally, we’re investing in resources like policy-focused Play Academy courses to help you better understand and navigate our policy changes.

Because the threats are always changing, it’ll take all of us working together to keep users safe and our platform secure. Thank you for continuing to work with us on this.

Building better app businesses

During 2019 we continued to look for new ways to help you market and monetize your apps and games:

And that’s a wrap

With such scale comes responsibility. We’re committed to ensuring our users’ safety for the future, to making development easier and distribution faster, and to offering you more effective ways for your app to be discovered and monetized.

On this note, we hope we can all continue working together to make Android and Google Play better for billions of people around the world, in 2020, and the years to come. From everyone on our team, we wish you all a happy holiday season and a prosperous new year.

How useful did you find this blog post?

December 17th 2019, 3:03 pm

Code Search with Cross References for the Android Open Source Project

Android Developers Blog

Posted by Jeff Bailey, AOSP Engineering Manager; Ally Sillins, AOSP Program Manager; Kris Hildrum, Open Source Code Search Tech Lead; Jay Sachs, Kythe Tech Lead/Manager

Searching for "it's all about the code" open source on Google returns more than a million hits. Today we’re introducing a public code search tool for the Android Open Source Project (AOSP).

Link: https://cs.android.com

The Android repository is made up of a collection of git repositories which are managed together using our ‘repo’ tool. Because of this, most tools (such as github, gitweb, etc) can’t see the source code the way that it’s laid out when it’s checked out on the system. In partnership with our colleagues who run Google’s internal Code Search and Kythe, we’re pleased to present a code search tool that presents a view of all of the Android source code as you actually use it.

Here are some features you can take advantage of starting today:

This is the beginning of our journey, and while today not all parts of the Android code base are cross-referenced, you can expect to see this grow over time.

We hope this makes it easier to engage with the Android code base!

December 10th 2019, 5:09 pm

Android 10 on Android TV

Android Developers Blog

Posted by Paul Lammertsma, Developer Advocate

Technology has changed the way media and entertainment is accessed and consumed in the home. While the living room experience is evolving with the addition of smart devices, TVs still remain the largest and most frequently used screen for watching content.

When Android TV was first introduced in 2014, we set out to bring the best of Android into the connected home on the TV. We worked closely with the developer community to grow our content and app ecosystem and bring users the content they want. Since then, we’ve seen tremendous momentum with OEM and operator partners as well as consumer adoption worldwide.

Today, we are bringing Android API level 29 with the recent performance and security updates made with Android 10 to Android TV. We’re excited to provide faster updates through Project Treble and more secure storage with encrypted user data. TLS 1.3 by default also brings better performance benefits and is up to date with the TLS standard. In addition, Android 10 includes hardening for several security-critical areas of the platform.

ADT-3

To make sure developers have the ability to build and test Android TV app implementations on Android 10 prior to rollout, we’re introducing a new, developer-focused streaming media device called ADT-3.

With a quad-core A53, 2GB of DDR3 memory and 4Kp60 HDR HDMI 2.1 output, we’ve designed this pre-certified TV dongle with updates and security patches to help developers design for the next generation of Android TV devices. By providing a way to test on physical and up to date hardware, developers can better validate their Android TV app’s compatibility.

ADT-3 will be made available to developers in the coming months for purchase online through an OEM partner.

December 10th 2019, 12:06 pm

Android’s commitment to Kotlin

Android Developers Blog

Posted by David Winer, Kotlin Product Manager

When we announced Kotlin as a supported language for Android, there was a tremendous amount of excitement among developers. Since then, there has been a steady increase in the number of developers using Kotlin. Today, we’re proud to say nearly 60% of the top 1,000 Android apps contain Kotlin code, with more and more Android developers introducing safer and more concise code using Kotlin.

During this year’s I/O, we announced that Android development will be Kotlin-first, and we’ve stood by that commitment. This is one of the reasons why Android is the gold partner for this year’s KotlinConf.

Seamless Kotlin on Android

In 2019, we focused on making programming in Kotlin on Android a seamless experience, with modern Kotlin-first APIs across the Android platform. Earlier this year, we launched a developer preview of Jetpack Compose, a modern UI toolkit for Android built using a Kotlin domain-specific language (DSL). We also incorporated coroutines into several of the flagship Jetpack libraries, including Room and Lifecycle. Finally, we brought Kotlin extensions (KTX) to even more major Google libraries, including Firebase and Play Core.

On the tooling side, we strengthened our commitment to Kotlin in Android Studio and the Android build pipeline. Significant updates to R8 (the code shrinker for Android) brought the ability to detect and handle Kotlin-specific bytecode patterns. Support was added for .kts Gradle build scripts in Android Studio, along with improved Kotlin support in Dagger. We worked closely with the JetBrains team to optimize support for the Kotlin plugin, and make the Kotlin editing experience in Android Studio fluid and fast.

Better Kotlin learning

This year we’ve also invested in quality Kotlin on Android learning content.

We released two free video learning courses in partnership with Udacity: Developing Android Apps in Kotlin and Advanced Android in Kotlin. This content was also released as the Codelab courses Android Kotlin Fundamentals and Advanced Android in Kotlin, for those who prefer text-based learning. The popular Kotlin Bootcamp for Programmers Udacity course was also published as a Codelabs course, helping provide a Kotlin foundation for non-Kotlin developers. Kotlin-based instructional Codelabs were also created for topics including Material Design, Kotlin coroutines, location, refactoring to Kotlin, billing in Kotlin, and Google Pay in Kotlin. It hasn’t been just about new content: we've updated Kotlin Codelab favorites to take advantage of important features such as coroutines.

Looking ahead

In 2020, Android development will continue to be Kotlin-first. We’ve been listening to your feedback, and will continue partnering with JetBrains to improve your experience with Kotlin.

This includes working with JetBrains to improve the Kotlin compiler over the next year. Our teams are making the compiler more extensible with a new backend, and making your builds faster with a significantly faster frontend. We’re also working with many of the largest annotation processors to make compilation faster for Kotlin code. You can also expect more Kotlin-first updates to Android, including more Jetpack libraries that make use of Kotlin features such as coroutines.

Thank you for letting us be part of your app development journey this year. We look forward to continuing the journey with you in 2020.

December 6th 2019, 2:16 pm

Android Game SDK

Android Developers Blog

Posted by Dan Galpin, Developer Advocate

With over 2.5 billion monthly active devices, the Android Platform gives incredible reach for game developers. Taking advantage of that opportunity can be a challenge, particularly if your game really tries to push the limits of what mobile can do. We've spent years working with game developers to try to both capture and address the biggest issues, and we're just beginning to see the fruits of that effort with the launch of the Android Game SDK. The Android Game SDK is a set of libraries that you can use to enhance your Android game.

The first library we are launching in the Android Game SDK helps developers with frame pacing, the synchronization of a game's rendering loop with the OS display subsystem and underlying display hardware. Android's display subsystem is designed to avoid tearing that occurs when the display hardware switches to a new frame in the middle of an update. To this end, it buffers past frames, detects late frame submissions, and repeats the display of past frames when late frames are detected. When a game render loop renders at a different rate than the native display hardware, such as a game running at 30 frames-per-second attempting to render on a device that natively supports 60 FPS, the optimal display flow involves synchronization between the game render loop, the system compositor, and the display hardware.

Optimal Display Flow

Any mismatch in synchronization can create substantial inconsistencies in frame times. If a frame takes substantially less time to render, it can shorten the presentation of the previous frame, causing something like a 33ms, 16ms, and a 50ms sequence.

Synchronization Mismatch: Rendering too Fast

If a frame takes too long to render, a similar problem occurs. The frame will be presented for an extra frame, causing something like a 50ms, 16ms, and 33ms sequence.

Synchronization Mismatch: Slow Frame

In either of these two scenarios, the game player will experience inconsistent delays between game input and screen updates. Visually, things will look less smooth and polished. Both visuals and game play can be impacted.

The Frame Pacing library uses Android's Choreographer API for synchronization with the display subsystem, using presentation timestamp extensions on both OpenGL and Vulkan APIs to make sure frames are presented at the proper time, and sync fences to avoid buffer stuffing. Multiple refresh rates are handled if supported by the device, giving a game more flexibility in presenting a frame. For a device that supports a 60 Hz refresh rate as well as 90 Hz, a game that cannot produce 60 frames per second can drop to 45 FPS instead of 30 FPS to remain smooth. The library detects the expected game frame rate and auto-adjusts frame presentation times accordingly. The Frame Pacing library allows games to take advantage of higher refresh rate 90 and 120 Hz displays, while also making it easy to lock the refresh rate to a desired value, regardless of the underlying display refresh rate.

The Frame Pacing library is built into Unity versions 2019.2 and beyond. Just select the optimized Frame Pacing checkbox under Android Settings to enable smoother frame rates for your game. If you have source to your game engine, it's straightforward to integrate the library into your OpenGL or Vulkan renderer. We've just added library binaries for download at developer.android.com/games/sdk/, or you can download the source code from the Android Open Source Project.

To learn more about Frame Pacing, check out the documentation at developer.android.com, along with the Frame Pacing section of the Optimizing Android Games Performance talk from Google I/O 2019. Be sure to subscribe to our Twitter channel and stay tuned for our announcements at GDC 2020 for more on how we're working to make Android game development better, so you can bring the best game experience to billions of devices.

December 5th 2019, 3:55 pm

An Update on Android TLS Adoption

Android Developers Blog

Posted by Bram Bonné, Senior Software Engineer, Android Platform Security & Chad Brubaker, Staff Software Engineer, Android Platform Security

Android is committed to keeping users, their devices, and their data safe. One of the ways that we keep data safe is by protecting network traffic that enters or leaves an Android device with Transport Layer Security (TLS).

Android 7 (API level 24) introduced the Network Security Configuration in 2016, allowing app developers to configure the network security policy for their app through a declarative configuration file. To ensure apps are safe, apps targeting Android 9 (API level 28) or higher automatically have a policy set by default that prevents unencrypted traffic for every domain.

Today, we’re happy to announce that 80% of Android apps are encrypting traffic by default. The percentage is even greater for apps targeting Android 9 and higher, with 90% of them encrypting traffic by default.

Percentage of apps that block cleartext by default.

Since November 1 2019, all app (updates as well as all new apps on Google Play) must target at least Android 9. As a result, we expect these numbers to continue improving. Network traffic from these apps is secure by default and any use of unencrypted connections is the result of an explicit choice by the developer.

The latest releases of Android Studio and Google Play’s pre-launch report warn developers when their app includes a potentially insecure Network Security Configuration (for example, when they allow unencrypted traffic for all domains or when they accept user provided certificates outside of debug mode). This encourages the adoption of HTTPS across the Android ecosystem and ensures that developers are aware of their security configuration.

Example of a warning shown to developers in Android Studio.

Example of a warning shown to developers as part of the pre-launch report.

What can I do to secure my app?

For apps targeting Android 9 and higher, the out-of-the-box default is to encrypt all network traffic in transit and trust only certificates issued by an authority in the standard Android CA set without requiring any extra configuration. Apps can provide an exception to this only by including a separate Network Security Config file with carefully selected exceptions.

If your app needs to allow traffic to certain domains, it can do so by including a Network Security Config file that only includes these exceptions to the default secure policy. Keep in mind that you should be cautious about the data received over insecure connections as it could have been tampered with in transit.

<network-security-config>
    <base-config cleartextTrafficPermitted="false" />
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">insecure.example.com</domain>
        <domain includeSubdomains="true">insecure.cdn.example.com</domain>
    </domain-config>
</network-security-config>

If your app needs to be able to accept user specified certificates for testing purposes (for example, connecting to a local server during testing), make sure to wrap your element inside a element. This ensures the connections in the production version of your app are secure.

<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="user"/>
        </trust-anchors>
    </debug-overrides>
</network-security-config>

What can I do to secure my library?

If your library directly creates secure/insecure connections, make sure that it honors the app's cleartext settings by checking isCleartextTrafficPermitted before opening any cleartext connection.

Android’s built-in networking libraries and other popular HTTP libraries such as OkHttp or Volley have built-in Network Security Config support.

Giles Hogben, Nwokedi Idika, Android Platform Security, Android Studio and Pre-Launch Report teams

December 3rd 2019, 2:41 pm

#AndroidDevChallenge: today is the last day to apply!

Android Developers Blog

Today is the last day to apply for the Android Developer Challenge! And to spark your imagination, we wanted to take a look at one of the original Android Developer Challenge winners, from over 10 years ago. Meet Maurizio Leo:

Maurizio and team have been working on Android for a while now. In fact, he was one of the winners of the original Android Developer Challenge, which launched with the start of Android over ten years ago. Their app, which won 3rd place worldwide at the time, has gone on to be downloaded over 30 million times!

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the deadline today! Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

December 2nd 2019, 5:59 pm

3 things to know about Jetpack from Android Dev Summit 2019

Android Developers Blog

Posted by Jisha Abubaker, Product Manager

Last month’s #AndroidDevSummit was jam-packed with announcements and technical news...so much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. We previously spotlighted Jetpack Compose, Kotlin and Android Studio, and today, we’re highlighting the rest of Android Jetpack, with the top three things you should know:

#1: A number of new & updated Jetpack libraries ready to use:

WorkManager 2.2 (Stable) has landed significant updates in the last releases with features like on-demand initialization improving app startup time when using WorkManager and improved testing support. Hear more of the new features and best practices.

Room 2.2 (Stable) is packed with features you asked for too : pre-packaged databases, improved relationship support and now better support for Kotlin Flow as well. Check out the What’s new in Room session to catch up.

Benchmarking (Stable) helps you measure the performance of tasks in your app with confidence. Here’s a deep dive on how you can exercise the library in fighting performance regressions in CI, like we do ourselves for Jetpack libraries and Compose.

LiveData w/ support for Kotlin coroutines & Flow (RC) : Kotlin coroutines and Flows has been the Android developer community’s interest in simplify async patterns in your apps. Learn how best to take advantage of the liveData builder in your app:

View binding (Beta) is type-safe solution bundled with Android Studio 3.6 Beta with minimal build-time impact, no more findViewById(), no more annotation processors. Check out What’s new in Studio for a demo !

#2: We’re busy baking more libraries

CameraX (Alpha) simplifies the development experience and lets you focus on your app instead by addressing the differences between the many devices in the Android ecosystem, like Samsung, Xiaomi, Oppo, Motorola, LG who are already unifying behind CameraX. Expected in Beta soon, learn what the Camera team has been up to since I/O 2019.

Security (Alpha) helps you simplify data at rest encryption for your app needs. Hear of best practices with encryption on Android from the Security library team.

#3:It’s time to migrate to androidx!

With all the new and updated Jetpack libraries and upcoming release of Jetpack Compose, it is time to get your app updated and ready. Nick and Tiem share a great step by step plan and best practices from the community in migrating to androidx namespace.

...and we also heard from you!

But Android Dev Summit isn’t just about what we’ve got to say; it’s also about you telling us what you’d like to see worked on to make your life easier. And this year, one thing that we heard strongly from our community was the need to provide a simplified Dependency injection developer experience for Jetpack libraries and expand improved Kotlin support to other Jetpack libraries! We’re on it!

You can find the entire playlist of Jetpack sessions at the Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 27th 2019, 1:10 pm

Our panel of experts for the #AndroidDevChallenge (apply by Dec. 2)

Android Developers Blog

Just a little over a week left to finish your submission for the Android Developer Challenge, due December 2! Technology is enabling us to create a whole new era of helpful innovation by helping people get things done more quickly and surfacing patterns that would be difficult to detect using traditional methods. Ultimately, this helpful innovation is enabling us to live better, more productive, and safer lives.

Earlier this week, we highlighted the type of helpful innovation ideas powered by machine learning which are the sort of examples we’re looking for, to help inspire you. Today, we wanted to share the names of the panel of experts we’ve assembled to help bring your projects to life as part of the Android Developer Challenge. These experts will be making the final decision on the 10 finalists of the Android Developer Challenge, and if you’re selected as one of those finalists, we plan to have you meet them when we bring you to Google HQ for a bootcamp next year:

If you’ve got a great idea that can help users get things done, we want to hear! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition, in part from this amazing set of experts we’ve assembled. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. Submitting your idea is as simple as creating a repository on GitHub, telling us what you’d build and how we can help (we’ve included all of the materials here), and then officially submitting your repository here. Ideas can be in a concept phase to something that’s already complete; we can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by machine learning to more and more users!

November 22nd 2019, 10:35 am

Android Developer Challenge: here’s what we’re looking for! (Apply by Dec. 2)

Android Developers Blog

Last month, we kicked off the next Android Developer Challenge, and asked you to submit your ideas focused on helpful innovation, powered by on-device machine learning. But what exactly do we mean when we say helpful innovation? We’re glad you asked! We rounded up a few of Google’s on-device machine learning offerings, together with some great recent examples of this technology in action, to help inspire your submission. Don’t forget, submit your idea by December 2!

Using machine learning to tackle Fall Armyworm

Take Nazirini Siraji. When she and a team of developers noticed a crop-pest threatening the livelihood of Ugandan farmers, they taught themselves TensorFlow to combat this pest. They collected training data from nearby fields in the form of images. With TensorFlow, they re-trained a MobileNet, a technique known as transfer learning and then used the TensorFlow Converter to generate a TensorFlow Lite FlatBuffer file which they deployed in an Android app. With the app, a farmer can snap a picture of their crop and the image frame is analysed to look for Fall armyworm damage. Depending on the results from this phase, a suggestion of a possible solution is given. It’s pretty cool!

Helping doctors detect respiratory diseases using machine learning

Tambua Health is helping doctors determine the likelihood of respiratory diseases by turning any smartphone into a powerful non-invasive screening tool. They developed an app using TensorFlow Lite that can help doctors analyze lung sounds for the presence of abnormal sounds like wheezes, crackles, stridor, and other adventitious sounds.

adidas uses machine learning to make the shopping experience easier

Even brands are tapping the power of machine learning. Take adidas, who recently launched a new “Bring It to Me” experience for their London store. Shoppers can use Visual Lookup to scan products on their phones while they are in the store, and the app lets them check stock and request their size without the need for queues. Under the hood, ML Kit is helping power the experience. It’s another way machine learning is helping users get things done more quickly.

The benefits of on-device machine learning

Running machine learning on a user’s device comes with a number of benefits. First, you reduce the amount of data you send to your server, enhancing user privacy. And because it runs on device, it can also work offline - perfect for inaccessible areas such as the middle of a rainforest, a desert or the London Underground. Last but not least, the most exciting aspect of running your model on device is low latency and this can enable all kinds of new user experiences. Machine learning is not just for automating tasks, it can work alongside your users and give them super powers too!

At Google, we offer a number of different technologies to help you take advantage of this:

If you’ve got a great idea that can help users get things done, we want to hear from you! We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. You can read more about all of the prizes here.

There’s still time to submit your idea before the December 2 deadline. We can’t wait to hear what you come up with, and to work with you on bringing helpful innovation powered by on-device machine learning to more and more users!

November 20th 2019, 4:46 pm

Unifying Background Task Scheduling on Android

Android Developers Blog

Posted by Caren Chang, Developer Programs Engineer, @calren24

Android users care a lot about the battery life on their phones. In particular, how your app schedules deferrable background tasks play an important role in battery life. To help you build more battery-friendly apps, we introduced WorkManager as the unified solution for all deferrable background processing needs.

Starting November 1, 2020, we are unifying deferrable background tasks on Android around WorkManager, and GCMNetworkManager will be deprecated and no longer supported.

Why WorkManager

The WorkManager API incorporates the features of Firebase Job Dispatcher (FJD) and GcmNetworkManager solutions, providing a consistent job scheduling service back to API level 14 while being conscious of battery life. For example, if your app needs to send log files up to the server, it would be more efficient to wait until the device is both charging and connected to WiFi. In this case, WorkManager will ensure that the sync will execute when the given constraints (charging and connected to WiFi) are met. Additionally, it does not require Google Play Services, unlike FJD and GcmNetworkManager.

Some of the other key features of WorkManager include:

What it means for developers

Now that the WorkManager library has reached maturity, we have decided to deprecate alternative solutions to simplify the developer story and focus on WorkManager stability and features.

Migrating to WorkManager

Now is the time to migrate your apps to WorkManager if you haven't already done so! You can start by reading the official documentation for WorkManager.

If your app is still using FirebaseJobDispatcher, you can migrate your app to WorkManager by following the migration guide. A similar migration guide from GCMNetworkManager to WorkManager is also available.

YouTube recently moved over to WorkManager for their background scheduling needs and has reported improvements in app startup time as well as an 8% drop in crash rates.

Going forward

The team is dedicated to improving and continuing feature development on WorkManager. If you encounter issues using the library, have proposals for features you would like to see, or have any feedback about the library, please file an issue.

November 19th 2019, 1:39 pm

New! Learn advanced skills for developing Android apps in Kotlin

Android Developers Blog

Posted by Aleks Haecky

Advanced Android in Kotlin, developed by Google together with Udacity, is our newly-released, free, self-paced online course. In this course expert instructors from the Android team at Google will introduce you to some of the advanced features you can build into your Android apps.

This course is intended for developers who have mastered the basics of building an Android app in Kotlin, and want to dive deeper into advanced functionality. To benefit most from this course, you need skills equivalent to what's taught in our Android Fundamentals Udacity or codelab courses.

Advanced Android in Kotlin teaches you about notifications, graphics and animations on Android, using third-party authentication for login, and how to add maps to your apps. Learn how to create custom views that can look like anything you want, draw to a canvas, and have eye-catching animations. And, most importantly, you will learn how to properly test your apps!

Here is a sample of apps you will build:

Check out the YouTube course trailer below for additional information about the course and apps:

Different people like to learn in different ways, so we are offering this course as both a Udacity video-based course and as a series of codelabs with topics that you can explore in any order. Whether you prefer to work on your own with just the text and code, or to have an instructor help walk through the code with you on video, we’ve got you covered; just choose your path and get learning!

November 18th 2019, 4:23 pm

3 things to know about Android Studio from Android Dev Summit 2019

Android Developers Blog

Posted by Deepanshu Madan, Product Manager

Last month’s #AndroidDevSummit was jam-packed with announcements and technical news...so much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. Earlier this week, we spotlighted Kotlin and Jetpack Compose, and today, we’re highlighting Android Studio, with the top three things you should know:

#1: Support for Jetpack Compose

For the best experience developing with Jetpack Compose, you can now use the latest version of Android Studio 4.0 in the canary channel, and benefit from smart editor features, such as New Project templates, code completion and the ability to immediately preview your Jetpack Compose UI.

#2: What’s new in Android Studio session

We covered both new features and successes of our quality initiative called Project Marble. On the quality aspect, we discuss improvements around hangs and latency, memory leak detection, automatic IDE heap sizing and build speed. Also during the session you will find demos on new developments & features in Android Studio such as Build Attribution tool which helps you understand and diagnose problems with your build system, Java 8 library desugaring, View binding, Kotlin Android live templates, an updated live Layout inspector which allows you to drill into resources right from the view to find where a property value originates in the source code with a 3D visualization of your view hierarchy.

#3: Android Studio Design tools

We introduced new features of Layout & Navigation editor including a new split view, new tools such as Multi-preview which allows you to visualize your layout in different configurations and MotionEditor, visual design editor for the MotionLayout layout type, making it easier to create and preview animations. The Motion Editor provides a simple interface for manipulating elements from the MotionLayout library that serves as the foundation for animation in Android apps. In previous releases, creating and altering these elements required manually editing constraints in XML resource files. Now, the Motion Editor can generate this XML for you, with support for start and end states, keyframes, transitions, and timelines.

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 15th 2019, 2:47 pm

Still Using InstallBroadcast? Switch to the Play Referrer API by March 1, 2020

Android Developers Blog

Posted by Marcus Leal, Product Manager, Google Play Ads

How do people find your app? It’s the million-dollar question for any developer, and the answer can help you make the right choices about your marketing strategy and budget. Accurate install referral data is crucial for understanding which traffic sources send users to download your app from the Google Play Store, as well as identifying fraudulent attempts to claim install attributions.

That’s why in 2017, we launched the Play Install Referrer API, which provides a reliable and robust mechanism for apps to retrieve referral information directly from the Play Store. It was a big step forward from the old install_referrer intent broadcast, so many developers made the switch right away, including App Attribution Program partners like Adjust, AppsFlyer, and Kochava. Now, because it’s been replaced by the new API, we’ve decided to deprecate the install_referrer intent broadcast mechanism on March 1, 2020. After this date, new versions of the Play Store app will no longer broadcast the install_referrer intent after app installs.

We are asking developers who still rely on the install_referrer to use the Play Install Referrer API instead. Among other advantages, the Install Referrer API offers better performance. uses a secure communication channel between your app and the Play store, and offers a more robust solution against spoof and attribution fraud.

If you still use the Broadcast API and the install_referrer intent to track your referrals, be sure to make the switch by March 1, 2020. Migration is easy, and the cost of adoption is low. Learn how to use the Play Install Referrer API to track your app installs today.

November 15th 2019, 12:47 pm

3 things to know about Kotlin from Android Dev Summit 2019

Android Developers Blog

Last month’s #AndroidDevSummit was jam-packed with announcements and technical news...so much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. First up, we’re spotlighting Kotlin, with the top things you should know:

#1: Kotlin momentum on Android

Kotlin is at the heart of modern Android development — and we’ve been excited to see how quickly it has won over developers around the world. At Android Dev Summit we announced that nearly 60% of the top 1000 Android apps on the Play Store now use Kotlin, and we’re seeing more developers adopt it every day. Kotlin has helpful features like null safety, data classes, coroutines, and complete interoperability with the Java programming language. We’re doubling down on Kotlin with more Kotlin-first APIs even beyond AndroidX — we just released KTX extensions, including coroutines support, for Play Core. There’s never been a better time to give Kotlin a try.

#2: Learn more: Getting started with Kotlin & diving into advanced Kotlin with coroutines

If you’re introducing Kotlin into an existing codebase, chances are that you’ll be calling the Java programming language from Kotlin and vice versa. At Android Dev Summit, developer advocates Murat Yener, Nicole Borrelli, and Wenbo Zhu took a look at how nullability, getters, setters, default parameters, exceptions, and more work across the two languages.

For those looking into more advanced Kotlin topics, we recommend watching Jose Alcérreca's and Yigit Boyar's talk that explains how coroutines and Flow can fit together with LiveData in your app's architecture and one on testing coroutines by Sean McQuillan and Manuel Vivo.

#3: Get certified in Kotlin

We announced the launch of our Associate Android Developer certification in Kotlin. Now you can prove your proficiency with modern Kotlin development on Android to your coworkers, your professional network, or even your future employer. As part of this launch, you can take this exam at a discount when using the code ADSCERT99 through January 25.

It’s especially great to hear from you, the Android community, at events like Android Dev Summit: what do you want to hear more about, and how can we help with something you’re working on. We asked you to submit your burning questions on Twitter and the livestream, and developer advocates Florina Muntenescu and Sean McQuillan answered your Kotlin and coroutines questions live during our #AskAndroid segment:

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow Android Developers on Twitter. Thanks so much for letting us be a part of this experience with you!

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

November 13th 2019, 4:42 pm

3 things to know about Jetpack Compose from Android Dev Summit 2019

Android Developers Blog

Posted by Anna-Chiara Bellini, @dr0nequeen

Last month’s #AndroidDevSummit was jam-packed with announcements and technical news...so much that we wouldn’t be surprised if you missed something. So all this month, we’ll be diving into key areas from throughout the summit so you don’t miss anything. Earlier today, we spotlighted Kotlin and now we’re diving into Jetpack Compose, with the top three things you should know:

#1: Jetpack Compose is available in Developer Preview!

Jetpack Compose is Android’s modern toolkit for building native UI. It allows developers to write beautiful Android apps in an intuitive way, writing less code and accelerating development. It's powerful, because when writing code is a pleasure, you can focus on making your apps look beautiful and giving your users the best experience. At #AndroidDevSummit, we released the Developer Preview, to enable more feedback as we work towards bringing Jetpack Compose to beta next year. All you need to do is download the Android Studio 4.0 Canary build to try it out. To give feedback, feel free to reach out through the Kotlinlang Slack channel or our Bug Tracker to let us know what you think. It's your chance to help us build the right thing!

#2: See what's new in Jetpack Compose

At Android Dev Summit we showed how we've designed Compose to simplify development of Android apps, details on the new Material UI components we are building, and insights on some of the learnings that are informing the way we think about Compose. We also showcased how to write a small app, including layout and state management for a list of elements, in just a few lines of code.

Watch the Android Dev Summit session video to learn more:

Embed: what's new in Jetpack Compose

If you want to take a look behind the scenes, we also had a tech deep dive into the inner workings of Compose:

Embed: Understanding Compose

#3: Try it out, with our tutorial, sample app, and codelab!

Jetpack Compose is still in Developer Preview, which means it's a great time to try it out and let us know what you think about it. To help you with that, you can follow our tutorial, which will take you through the first steps of building a Compose app, and also take a look at our sample app, Jetnews, that shows what is currently possible with Jetpack Compose. We also have a popular codelab available to take you through how to build UIs with Compose, how to manage state in composable functions, and data flow principles in Compose.

Jetnews sample app

...and we also heard from you!

But Android Dev Summit isn’t just about what we’ve got to say; it’s also about you telling us what you’d like to see worked on to make your life easier. And this year, one thing we heard strongly from our community was how important it is to have the right tools to manage your layouts on so many different form factors and devices. Jetpack Compose has full Android Studio support and you can iterate fast with live Previews.

Android Dev Summit is over for this year, but you can keep giving us your feedback through the Kotlinlang Slack channel and Bug Tracker.

You can find the entire playlist of Android Dev Summit sessions and videos here. We’ll continue to spotlight other areas later this month, so keep an eye out and follow AndroidDevelopers on Twitter. Thanks so much for letting us be a part of this experience with you!

November 13th 2019, 12:07 pm

A modern approach to Android development, with Jetpack Compose and more!

Android Developers Blog

Posted by Stephanie Cuthbertson, Director, Product Management

Modern Android Development today

Perhaps as a consequence of Android's flexibility, we often get asked by developers what does the Android team recommend when it comes to building apps? You’ve told us: you love our openness..but you’d also love us to marry it with an opinion about the right way to do things. And, to make sure the right way is also the easiest way. And so today, at the Android Dev Summit, the team wanted to answer that question for you.

We call our recommendation “modern Android development". Opinionated and powerful, for fast, easy development. Taking away everything that slows you down so you can focus on building incredible experiences. You can see it in the investments we’ve made like creating Android Studio and Jetpack. (Over 90% of our pro developers are using Android Studio today.) Kotlin and Compose are especially great recent examples. Kotlin is a modern, concise language -- something you asked us for and is now the recommended language for Android. Compose is a modern declarative UI toolkit built for the next 10 years. And this might sound a little strange, but we chose and designed these tools to be enjoyable to use: we think that’s important too. Both Kotlin and Compose also have a critically important property. They are designed to be compatible with your existing apps. This means you can phase in Kotlin code and Compose views on your timeline.

It all starts with a great modern language: Kotlin

Modern Android starts with fantastic language support.In fact, we recently passed a milestone where almost 60% of our top 1000 apps are using Kotlin. And we’re working with JetBrains to make it even better: faster kotlin compile speeds, incremental annotation processing with KAPT, better IDE typing latency, more lint checks, desugaring in D8 and R8, new optimizations in R8 that are aware of Kotlin-specific bytecode patterns. And we’re releasing full IDE support for Kotlin build scripts today. If you want to grow your skills, we are launching an Advanced Android course with Kotlin on Udacity. And, for those who are already experts, we’re also launching a new Android Developer Certification in Kotlin, available at a discount for the next three months. We’re working to make all of our supported first-class languages — Kotlin, the Java programming language, and C++ — better for you and your team, with Java8 library desugaring, NDK r21 with updated LLVM, GNU Make, Fortify enabled by default, and more.

Jetpack: Build high quality, powerful apps with less code

Jetpack is designed to solve real-world problems you face every day, and is used by over 84% of the top 10,000 Play Store apps. And we continue to make Jetpack even more helpful:

Compose: Android’s new UI toolkit to build beautiful, native apps, now in developer preview

Compose makes it easy to build beautiful, native apps. It provides a declarative way to build UIs which makes your code more intuitive and concise. Inspired by Kotlin, you can adopt Compose at your own pace thanks to seamless compatibility with the existing UI toolkit.

Today we are releasing the Jetpack Compose Developer Preview. All you need to do is download the latest Preview build of Android Studio. Compose is being developed completely in the open, in AOSP. The continuous feedback we receive has led to many API improvements and we want to thank you for providing feedback in our developer studies and the Kotlinlang Slack group. As we enter developer preview, we need even more feedback as we work towards bringing Jetpack Compose to beta next year and ready for use in production apps.

Android Studio 4.0 Canary

Today we also released the first canary of Android Studio 4.0 - built hand in hand with Compose for powerful, integrated tooling support. Android Studio 4.0 includes Compose Live Preview, Code Completion, and a full sample of a Compose app. You’ll also find the new Motion Editor, Java 8 Language library desugaring, full support for KTS files, Kotlin live templates, and more.

Android App Bundles and dynamic delivery testing improvements

In just eighteen months after launch, over 270K Android App Bundles are now in production covering 25% of all active installs. Based on your feedback, we’re making App Bundles and Dynamic Delivery much easier to test. Internal app sharing lets you share test builds of your app bundle as easily as you share APKs. You can now grant anyone in the team ability to upload artifacts. You don’t need to sign test versions with your production app signing key, you don’t need to use version codes, and you can upload debuggable artifacts. We’re also making it possible to get download links for old versions of your app from the Play Console, whether they’re app bundles or APKs. And starting today, we’re launching offline testing of dynamic delivery with the fake split install manager so can replicate splits being installed by the Play Store while testing locally.

A modern distribution platform, centered around user trust

User trust and safety has always been a top priority at Google Play, with human reviewers, constant improvements to play protect, and policy updates to evolve with the threats we see. As a result, apps that are installed from Google Play are an order of magnitude safer than from any other source. This year, we’ve been increasing all our detection capabilities for impersonators, repackaging, bad content and other forms of abuse, but we know there's more we can do, and the threats are constantly changing. With your help, we’ve reduced access to sensitive data and have made Play even safer for children and families. We restricted SMS/Call log permissions to only apps that need them as part of their core functionality, and as a result 98% fewer apps access this sensitive data. Thanks to your hard work, users are safer, and know they are safer when they download apps that request fewer permissions.

The Android Developer Challenge!

Over ten years ago, we announced the first Android Developer Challenge. Today, modern Android is shaping the next generation platform. So it seems kind of fitting to announce: the Android Developer Challenge is back! The first Developer Challenge we’re announcing is Helpful Innovation and Machine Learning. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today. You can read more about the challenge here.

So - that’s a quick tour of Modern Android and the road ahead across our developer experience! Whether you’re joining us for Android Dev Summit in person or on the livestream, we have nearly 60 sessions from over 100 speakers where we’ll go deep on everything you need to know about Android. Thank you!

November 12th 2019, 10:50 am

Introducing Google Play Points in the U.S.

Android Developers Blog

Posted by Paul Feng, Product Manager, Google Play

At Google Play, we continue to build new experiences to delight users and help developers succeed. Today, we’re excited to announce that the Google Play Points rewards program is expanding to the United States following successful launches in Japan and Korea, where millions of people have already enrolled. The program is designed to show appreciation to our users and help increase engagement with your games and apps.

Google Play Points rewards users for any purchase they make on Play — including apps, games, in-app items, music, movies, books, and subscriptions - and for downloading select apps and games. For all developers, if you’re on Play billing, users will earn points on your apps and games immediately.

Play Points can then be redeemed for unique rewards like special items and discounts in Candy Crush, Homescapes, Lords Mobile and many others. We’re fortunate to be working with a select group of developers to offer these rewards for the U.S. launch — including Niantic, King, Electronic Arts, Playrix, Jam City, Kabam, Ludia, Kongregate, and others. Users can also redeem their points for Google Play Credit, and spend it on your app or game just as they do today.

Users are finding value in our initial Play Points markets, Japan and Korea, and developers there are incredibly happy with the results. In the future, we look forward to working with additional partners to deliver more unique rewards to users as Google Play Points evolves.

Google Play Points is rolling out in the US over the next few days. If you’d like to enroll as a user in the program, open the Play Store app on your Android device, tap menu, then tap Play Points to get started.

How useful did you find this blog post?

November 12th 2019, 10:50 am

High engagement, larger screens: How Android developers can reach users on any device

Android Developers Blog

Posted by Allan Livingston, Product Management Director, Chrome OS App Ecosystem

Android fuels mobile apps on devices that range far beyond your typical small-screen smartphone, from new Chromebooks like the lightweight, high-performance Google Pixelbook Go to multi-display devices and foldable phones like the Samsung Galaxy Fold. Not to mention the more than 175M Android tablets that have the Google Play store installed.1

These large-screen devices set the stage for more engaging and visually immersive experiences, whether by creating a larger canvas for creativity or by giving users faster, more flexible ways to work. As we’ve continued to prioritize large-screen devices with OEM partners like Samsung, Asus, and Lenovo, we’ve been able to expand our reach to a huge new audience of users.

During the week of Black Friday in 2018, 1 in 3 notebooks sold in the U.S. were Chromebooks.2 Chromebook unit sales also increased 22% YoY, while the rest of the notebook category decreased -6.1%.3 And we’re not just reaching more users — we’re reaching more engaged users. In fact, in just the last year, the total amount of time spent in Android apps on Chrome OS has grown 4X.4

By making adjustments for larger screens, you can provide richer experiences across all these devices and tap into a wider audience of app users. Development teams around the world — including Adobe Lightroom, Evernote, and Gameloft, among many others — have already seen some incredible results:

App developers driving engagement on larger screens

With the goal of allowing users to play any video file, anywhere, on any device or screen size, the developers at VideoLAN project decided to adapt VLC — an open source, cross-platform multimedia player — for all screens. The team started by adding keyboard and mouse support before designing multiple versions of the layout to allow users to easily scale and resize the app.

Users can now enjoy the same immersive experience across a range of different devices and form factors, and VideoLAN has already received overwhelmingly positive feedback from users around the world.

War Robots — a 12-player real-time battle game developed by Pixonic — was originally designed for early-generation phones. The team enabled windowed gameplay so users could play in one window while watching their favorite streamers or upgrading their robots in another, created new tutorials and controls that appear whenever players switch between desktop and tablet mode, and added support for keyboard and mouse input.

More than 100,000 players have already played War Robots on Chrome OS since Pixonic rolled out the latest optimizations, which made War Robots’ battles even more thrilling and engaging on larger screens, and Pixonic has seen 25% longer user sessions on Chromebooks as a result.

Is your app optimized for large-screen devices? Here are a few things to consider:

1) Laptop and tablet mode
Test your core app functions to make sure everything works smoothly without crashing as users switch between different modes.

2) Window management and layout
Support multi-window mode and free-form window resizing, and be sure to design optimized layouts for both landscape and portrait orientations. Set up your app to correctly handle configuration changes to avoid crashes when people rotate their devices.

3) Keyboard and mouse input
Make sure your app is fully functional without touch input, and add support for keyboards, mice, and game controllers (if applicable).

4) Hardware support
If you’re using NDK, be sure to support x86 (32 and 64bit) ABIs to ensure the highest possible performance.

Build, test, and run Android apps on a Chromebook

From the start, our goal has been to make the Chromebook a simple, secure, and speedy environment for everyone. The launch of Linux (Beta) on Chrome OS allowed Android developers to build and test apps with a Chromebook. And earlier this year at I/O, we announced that Android Studio 3.5 now fully supports Chrome OS with a simple one-click installation.

Since then, we’ve been working on a few improvements that make Chromebooks an even better place for safe and seamless Android app development. Let’s start with the biggest one:

Deploying an app directly to Chrome OS to enable full Android development
In the past, you could only test your apps by deploying them to Android phones. With Chrome OS’s upcoming M80 release, you’ll be able to deploy Android apps directly to your Chromebook. That way, you can develop and test your app on the same machine, all without a connected device or needing to put your laptop in developer mode. Developers can start testing this feature in developer channel in November.

GPU acceleration for a snappier, jank-free UI (now in beta channel)
We’ve enabled GPU support to reduce latency and deliver a snappier UI. That goes for developer apps such as Android Studio, Unity Editor, or Visual Studio Code. And for developers who also work on web apps, GPU acceleration means faster testing with Chrome Canary or Firefox.

Container backup and restore to easily move between devices
Previously, Linux files and apps were tied entirely to the device — if you lost your device, you lost all the work inside of it. Now, Chrome OS’s container-based architecture allows you to pack up your entire workspace and export it to external storage or Drive. The backup file can be restored at any point, either on the same machine — which is helpful when jumping back to a previous state — or to move to another Chromebook.

You can now find import and export buttons in your Linux settings.

Picture-in-picture (PiP) support

If you’ve built PIP support into your Android apps, you’ll see that function work seamlessly in Chrome OS in 2020. But you can start testing this feature now by enabling PiP in Android settings → Developer options.

Build your apps with larger screens in mind

With millions of users on Chromebooks, tablets, foldables, and now multi-display devices, designing app experiences with larger screens in mind is crucial. Seize this opportunity to engage more users by optimizing your existing apps to work great across all screens. And the latest Linux features on Chrome OS give you the power to use a single machine to build and run Android apps. Don’t hesitate to take action to ensure your apps work seamlessly on larger screens with Linux on Chrome OS.









Sources

1. The number of tablets only accounts for devices that have the Google Play Store installed (e.g., excluding tablets in China); the actual number of tablets capable of running Android applications is much larger.

2. The NPD Group, Inc., Retail Tracking Service, U.S., Notebook Computers, Chrome OS, based on units, Nov. 18, 2018–Nov. 24, 2018 vs. Nov. 19, 2017–Nov. 25, 2017.

3. The NPD Group, Inc., U.S. Retail Tracking Service, Notebook Computers, based on units, Sept. 2018–Aug. 2019. Sales are adjusted for 5 weeks in Jan. 2018 vs. 4 weeks in Jan. 2019.

4. Google Internal Data, March 2018–March 2019.

November 12th 2019, 10:50 am

Privacy protections for physical activity in Android 10

Android Developers Blog

Since Google Fit was released in 2015, apps with an abundance of features for health and fitness tracking have integrated with the Google Fit APIs. Over the years, the number of users using Google Fit as a central repository for their fitness and wellness data has grown significantly.

With Android 10, we're making further updates to give users even more control over this personal data. One key change concerns how Android apps can monitor a user’s physical activity and retrieve data from Android sensor APIs and the Google Fit platform.

In Android 10: Activity recognition permission

Android 10 introduces a new runtime permission for activity recognition for apps that make use of the user's step and calorie count or classify the user's physical activity, such as walking, biking, or moving in a vehicle through one of the following APIs:

If your app relies only on raw data from other built-in sensors on the device, such as the accelerometer and gyroscope, you don't need to declare this new permission in your app.

Activity Recognition Permission Enforcement

Google Fit physical activity APIs

This new permission affects a subset of data types available in the Google Fit APIs on Android. If your app accesses these types from Google Fit today, then you need to update your app inline with the new permissions.

The activity recognition runtime permission is required for accessing the following APIs / data types:

With Android 10 now launched and SDK 29 becoming your primary development target, now is the time to make sure your apps are compatible with the new runtime permission.

November 12th 2019, 10:50 am

Modern app and game distribution on Google Play

Android Developers Blog

Posted by Kobi Glick, Product Lead, Google Play

Today we’re kicking off Playtime, our annual event series where we host developers from all over the world to discuss features and best practices to help you grow your apps and games businesses. Last month’s Android Dev Summit focused on modern Android development. Here on the Google Play team, we’re focusing on modern app and game distribution — our set of powerful and customizable distribution features and tools that work together to power your success on Google Play.

The future of Android distribution

The Android App Bundle is foundational to modern app and game distribution, replacing the monolithic APK. Since it launched 18 months ago, over 270K apps and games have made the switch, representing over 25% of active installs. Those that switched have seen an average size savings of 20% compared to a universal APK and more efficient releases as a result.

A recent internal analysis revealed that users with storage-constrained devices are much more likely to uninstall apps, so optimizing how much space your app needs is important. Our new metrics on the app size report in the Play Console can show you how many of your active users have little free storage on their devices and if they’re uninstalling more than other users.

New tools to speed up your workflows and engineering velocity

Testing app bundles is now much easier with internal app sharing. Make anyone in your company an uploader without giving them access to the Play Console and they’ll be able to share test builds of your app as easily as they used to share APKs. With internal app sharing, you can be sure that each device is receiving exactly what Play would deliver in the wild. You don’t need to use version codes or the prod signing key, you can upload debuggable artifacts, and you’ll soon be able to get install links for old versions of your app, too.

The app bundle also lets you modularize your app with dynamic feature modules. Modularization speeds up build times and engineering velocity, since different teams can design, build, test, and debug features in parallel rather than working on the same complex code for a monolithic app. Based on your feedback, we’ve made it easier to develop modular apps with tools such as the new Dynamic Feature Navigator library and FakeSplitInstallManager, which lets you test on-demand delivery while offline instead of waiting for the Play Store.

Get more users on your latest release with improved in-app updates

In-app updates let you prompt users to update to the latest version of your app, without them having to leave your app. More than 10% of the top apps and games are already using in-app updates with an average acceptance rate of 24%. Based on your feedback, we’re also giving you more control over how and when you show update prompts:

Modern game distribution

For some games with rich content, the 150MB app bundle size limit is not enough. Using expansion files or content delivery networks can get around this but could introduce complexity when you’re building and releasing your game, and can result in a poor user experience. That’s why we’re extending the app bundle format to support asset delivery with a new delivery construct called asset packs which can go up to multiple gigabytes.

Asset packs are packaged in the app bundle alongside your binary, so you can publish a single artifact to Play that contains everything your game needs, giving you full control of your asset delivery. Play’s asset delivery will also enable texture compression targeting, so that your users only get the assets suitable for their device with no wasted space or bandwidth. And you can rely on Play to keep your assets up to date, just as it does with your game binary. We’re currently testing this with some early partners and hope to make it more widely available soon.

Here’s to another successful Playtime

Look out for the sessions from this year’s Playtime, which will be added to the Android Developers YouTube channel. We look forward to sharing more tools and services for your apps and games, made possible by the app bundle and our new dynamic framework. And as always, please give us your feedback and let us know what you think.

How useful did you find this blog post?

November 12th 2019, 10:50 am

One Biometric API Over all Android

Android Developers Blog

Posted by Isai Damier, Android Developer Platform Engineering (@isaidamier)

Kevin Chyn, Android Framework

Curtis Belmonte, Android Framework

With the launch of Android 10 (API level 29), developers can now use the Biometric API, part of the AndroidX Biometric Library, for all their on-device user authentication needs. The Android Framework and Security team has added a number of significant features to the AndroidX Biometric Library, which makes all of the biometric behavior from Android 10 available to all devices that run Android 6.0 (API level 23) or higher. In addition to supporting multiple biometric authentication form factors, the API has made it much easier for developers to check whether a given device has biometric sensors. And if there are no biometric sensors present, the API allows developers to specify whether they want to use device credentials in their apps.

The features do not just benefit developers. Device manufacturers and OEMs have a lot to celebrate as well. The framework is now providing a friendly, standardized API for OEMs to integrate support for all types of biometric sensors on their devices. In addition, the framework has built-in support for facial authentication in Android 10 so that vendors don’t need to create a custom implementation.

A bit of background

The FingerprintManager class was introduced in Android 6.0 (API level 23). At the time -- and up until Android 9 (API level 28) -- the API provided support only for fingerprint sensors, and with no UI. Developers needed to build their own fingerprint UI.

Based on developer feedback, Android 9 introduced a standardized fingerprint UI policy. In addition, BiometricPrompt was introduced to encompass more sensors than just fingerprint. In addition to providing a safe, familiar UI for user authentication, it enabled a small, maintainable API surface for developers to access the variety of biometric hardware available on OEM devices. OEMs can now customize the UI with necessary affordances and iconography to expose new biometrics, such as outlines for in-display sensors. With this, app developers don’t need to worry about implementing customized, device-specific implementations for biometric authentication.

Then, in Android 10, the team introduced some pivotal features to turn the biometric API into a one-stop-shop for in-app user authentication. BiometricManager enables developers to check whether a device supports biometric authentication. Furthermore, the setDeviceCredentialAllowed() method was added to allow developers the option to use a device’s PIN/pattern/password instead of biometric credentials, if it makes sense for their app.

The team has now packaged every biometric feature you get in Android 10 into the androidx.biometric Gradle dependency so that a single, consistent, interface is available all the way back to Android 6.0 (API level 23).

How it works

The androidx.biometric Gradle dependency is a support library for the Android framework Biometric classes. On API 29 and above, the library uses the classes under android.hardware.biometrics, FingerprintManager back to API 23, and Confirm Credential all the way back to API 21. Because of the variety of APIs, we strongly recommend using the androidx support library regardless of which API level your app targets.

To use the Biometric API in your app, do the following.

1. Add the Gradle dependency to your app module

$biometric_version is the latest release of the library

def biometric_version= '1.0.0-rc02'
implementation "androidx.biometric:biometric:$biometric_version"

2. Check whether the device supports biometric authentication

The BiometricPrompt needs to be recreated every time the Activity/Fragment is created; this should be done inside onCreate() or onCreateView() so that BiometricPrompt.AuthenticationCallback can start receiving callbacks properly.

To check whether the device supports biometric authentication, add the following logic:

val biometricManager = BiometricManager.from(context)
if (biometricManager.canAuthenticate() == BiometricManager.BIOMETRIC_SUCCESS){
   // TODO: show in-app settings, make authentication calls.
}

3. Create an instance of BiometricPrompt

The BiometricPrompt constructor requires both an Executor and an AuthenticationCallback object. The Executor allows you to specify a thread on which your callbacks should be run.

The AuthenticationCallback has three methods:

  1. onAuthenticationSucceeded() is called when the user has been authenticated using a credential that the device recognizes.
  2. onAuthenticationError() is called when an unrecoverable error occurs.
  3. onAuthenticationFailed() is called when the user is rejected, for example when a non-enrolled fingerprint is placed on the sensor, but unlike with onAuthenticationError(), the user can continue trying to authenticate.

The following snippet shows one way of implementing the Executor and how to instantiate the BiometricPrompt:

private fun instanceOfBiometricPrompt(): BiometricPrompt {
   val executor = ContextCompat.getmainExecutor(context)

   val callback = object: BiometricPrompt.AuthenticationCallback() {
       override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
           super.onAuthenticationError(errorCode, errString)
           showMessage("$errorCode :: $errString")
       }

       override fun onAuthenticationFailed() {
           super.onAuthenticationFailed()
           showMessage("Authentication failed for an unknown reason")
       }

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

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

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

4. Build a PromptInfo object

Once you have a BiometricPrompt object, you ask the user to authenticate by calling biometricPrompt.authenticate(promptInfo). If your app requires the user to authenticate using a Strong biometric or needs to perform cryptographic operations in KeyStore, you should use authenticate(PromptInfo, CryptoObject) instead.

This call will show the user the appropriate UI, based on the type of biometric credential being used for authentication – such as fingerprint, face, or iris. As a developer you don’t need to know which type of credential is being used for authentication; the API handles all of that for you.

This call requires a BiometricPrompt.PromptInfo object. A PromptInfo is where you define the text that appears in the prompt: such as title, subtitle, description. Without a PromptInfo, it is not clear to the end user which app is asking for their biometric credentials. PromptInfo also allows you to specify whether it’s OK for devices that do not support biometric authentication to grant access through the device credentials, such as password, PIN, or pattern that are used to unlock the device.

Here is an example of a PromptInfo declaration:

private fun getPromptInfo(): BiometricPrompt.PromptInfo {
   val promptInfo = BiometricPrompt.PromptInfo.Builder()
       .setTitle("My App's Authentication")
       .setSubtitle("Please login to get access")
       .setDescription("My App is using Android biometric authentication")
              .setDeviceCredentialAllowed(true)
       .build()
   return promptInfo
}

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

Figure 1. Example face authentication flow using BiometricPrompt with setConfirmationRequired(false).

Figure 2. Example face authentication flow using BiometricPrompt with setConfirmationRequired(true) (default behavior).

5. Ask the user to authenticate

Now that you have all the required pieces, you can ask the user to authenticate.

val canAuthenticate = biometricManager.canAuthenticate()
if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) {
   biometricPrompt.authenticate(promptInfo)
} else {
   Log.d(TAG, "could not authenticate because: $canAuthenticate")
}

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

Going forward

Because the ecosystem continues to evolve rapidly, the Android Framework team is constantly thinking about how to provide long-term support for both OEMs and developers. Given the biometric library’s consistent, system-themed UI, developers don’t need to worry about device-specific requirements, and users get a more trustworthy experience.

We welcome any feedback from developers and OEMs on how to make it more robust, easier to use, and supportive of a wider range of use cases.

For in-depth examples that showcase additional use cases and demonstrate how you might integrate this library into your app, check out our repo, which contains functional sample apps that make use of the library. You can also read the associated developer guide and API reference for more information.

November 12th 2019, 10:50 am

Android Developer Challenge: helpful innovation, powered by On-Device Machine Learning + you!

Android Developers Blog

Posted by The Android team

Developers like you have always played an important role in shaping the direction of Android, fueling the wave of Android innovation. It’s the reason that when we first launched the SDK for Android 10+ years ago, we simultaneously announced the Android Developer Challenge: a way to help reward model apps and show us what user problems you wanted to solve. As Android continues to push the boundaries into emerging areas like ML, 5G, foldables and more, we need your help to bring to life the consumer experiences that will define these new frontiers.

So we’re bringing back the Android Developer Challenge and asking you to help us unlock new experiences on Android, and help inspire other developers around these emerging technologies.

As we kick off this challenge, the first area we’ll be focusing on is On-Device Machine Learning. At Google, we’re big believers in how this new technology can open up a world of helpful innovation so you can get things done in ways you never thought possible. Take Live Captions: for the almost 500 million people who are deaf and hard of hearing, Live Captions bring content to life and is exactly the type of machine learning-powered innovation we expect to see more of someday, and with your help we can turn someday into today!

Bringing your idea to life in front of billions of eyes

Got an idea? Whether it’s still a concept or ready for users, tell us how you could use Google’s help, and how it supports the mission of using machine learning to help people get something done. Join the #AndroidDeveloperChallenge topic on GitHub, and share your idea as a repository under this topic. Don’t forget to come back here and officially submit your concept.

We’ll pick 10 concepts and provide expertise and guidance to those developers to help in their plans to bring their ideas to fruition. And once the app is ready, we’ll help showcase it in front of the billions of users on Google Play, through a collection and more. Here’s what those 10 developers will get:

Expertise and development support bootcamp: We’ll work with you to provide expertise and guidance to help in your plans to bring your app from concept to reality, including:

Exposure and street cred! Once your idea is ready for prime-time, we’ll help you get users, and celebrate you to the broader Android community, including:

Helpful innovation is an important investment area for us on the Android team, and On-Device Machine Learning has played a critical role in powering new features in the last several releases of Android. We’re just beginning to scratch the surface, and we can’t wait to see what you come up with!

November 12th 2019, 10:50 am

All About Updates: More Treble

Android Developers Blog

Posted by Iliyan Malchev, Project Treble Architect

Android 10, our newest release, brings helpful tools for both developers and consumers like suggested actions in Smart Reply to help you multitask faster, Dark theme for battery saving, Focus mode that keeps you from digital distractions, and more. And with almost 50 changes related to privacy and security, Android 10 gives you greater protection, transparency, and control over your data than ever before. It is important to both users and developers that these new releases find their way to mobile devices as fast as possible. In this post, we’ll share an update on the progress we’ve made with Project Treble, an initiative to help manufacturers update devices to new versions of Android more quickly.

Wait and See

When we launched Project Treble with Android 8.0 Oreo, we asked ourselves if our investment would pay off. There were two factors to consider in measuring the effectiveness of the program:

The Partner Beta Program

One of the earliest indications that Project Treble was having a positive effect was our ability to run the Beta program for Android 9 Pie on many more devices from more manufacturers. In addition to Google Pixels, we had 7 device models from 7 OEMs supporting Android 9 Pie Beta.

With Android 10, this year, we increased the number of devices to 18 (again, in addition to Pixels), representing 12 OEMs. This represents a significant increase over the previous year and shows that Project Treble is having an impact.

Distribution Chart

Beta releases are great, but how did we fare on actual upgrades? To answer this question, we considered two points in time. The first point is right before we released Android 9. The second point is right before we released Android 10. By each of these points in time, the previous release had had a year to reach devices.

In late July, 2018, just before Android 9 Pie was launched in AOSP, Android 8.0 (Oreo) accounted for 8.9% of the ecosystem. By comparison, in late August 2019, just before we launched Android 10, Android 9 (Pie) accounted for 22.6% of the ecosystem. This makes it the largest fraction of the ecosystem, and shows that Project Treble has had a positive effect on updatability.

The adoption of Android Pie has been much higher than that of Android Oreo and Oreo MR1 when measured relative to the launch date.

Continuous Improvements in Updatability

The progress shown above results from work we did in Android 8.0 Oreo. We have made serious improvements with Android 9 Pie as well. The most significant one was our behind-the-scenes collaboration with silicon manufacturers. This work had the effect of reducing the average time to upgrade by more than 3 months, and we expect to see upgrades from Android 9 to Android 10 noticeably sooner this year.

There is also the sheer amount of hardening work on the architecture. We completed the seal between the vendor and system components of Android, which ensures that new versions of the top part of the OS run on older versions provided by our partners. We formalized the interface to the Android Linux kernel, expanded the Treble test suite (VTS), and did so much more. As a result, upgrades from Android 9 to Android 10 are going much more smoothly, as evidenced by direct feedback from our OEM and silicon partners.

We are beginning to see the effects already. This year, we saw two OEMs issue software updates to Android 10 on the day we announced it: Xiaomi and Essential. On the same day, OnePlus started a public beta program, and just a few days later, they started updating devices. HMD Global’s Nokia 8.1 just started receiving the update this week. In addition to these partners, many manufacturers such as ASUS, LG, Motorola, OPPO, Realme, Samsung, Sharp, Sony, Transsion, and Vivo have committed to updating some of their devices to Android 10 by the end of the year. Plus, new devices are already hitting shelves with Android 10, such as the OnePlus 7T. We are very excited that Samsung announced an open beta for Android 10 on their devices and started the rollout on October 12th, compared to November 15th last year.

The ROM developer community benefits from improved updatability as well. Mere days after the Android 10 launch, external developers ported it to 15 devices that launched on Android 8 and 9. This work was made much easier thanks to Project Treble, and we are very excited about the potential for open-source development on the OS. We made this even easier by publishing Google-signed Generic System Images (GSIs) and GMS binaries on android.com, as well as posting detailed instructions for developers to try them on their own.

DSU and Project Mainline

In Android 10, we delivered Dynamic System Updates (DSU). For every device launching on Android 10 that supports DSU, developers are able to install Google-signed Generic System Images and boot into them without having to touch the factory ROMs on their devices. We showcased this work at Google I/O, switching painlessly between GSIs and Factory ROMs on Pixel devices.

We also implemented Project Mainline, which allows Google to update directly, via the Play Store, components of the OS that are critical to security and app compatibility. Project Mainline is to the core of the Android OS what Project Treble is to its foundation. It is a dramatic improvement in the velocity of updates of the OS components that fall under its umbrella.

Project Mainline also builds on the work we've done on a less obvious part of Android, called Google Mobile Services (GMS), which has been receiving updates in this way for years. GMS is the part of your Android device that makes it work seamlessly with all of Google's services. Yet another piece, called Webview, is at the core of your browser and every application that interacts with the web. This security- and correctness-critical component also gets updated via Play Store.

Looking Forward

The Android ecosystem is truly vast. There are hundreds of phone manufacturers, dozens of SoC (mobile CPU) models, and thousands of very different devices. Creating an updatability architecture that covers all of them is a complex task. Android is committed to updatability in all forms, whether it’s real-time updates to first- and third-party apps, developer libraries such as Jetpack, or regular security updates for Android devices.

It has been exciting to see the impact of our efforts on updatability. We have a lot more work to do, and we are tirelessly investing on improving updates. I am proud of the progress we all—Android, Google at large, and our many partners—have made so far. I am very optimistic about the future and look forward to sharing our work for the next release of Android.

November 12th 2019, 10:50 am

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

Android Developers Blog

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

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

New content and features

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

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

Google Play policy

Subscription model for games

Track installs, uninstalls, and upgrades


What's next?

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

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

Start learning now!

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

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

How useful did you find this blog post?

October 22nd 2019, 1:34 pm

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

Android Developers Blog

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

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

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

#AskAndroid your pressing questions!

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

October 22nd 2019, 11:17 am

Android Automotive OS updates for developers

Android Developers Blog

Posted by Madan Ankapura, Product Manager, Android

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

Volvo XC40 Recharge & its infotainment unit

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

Concept image from GM on Maps & Media integration

Developing & testing media apps on emulator

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

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

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

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

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

We hope to see you there!

October 21st 2019, 1:24 pm

Introducing NDK r21: our first Long Term Support release

Android Developers Blog

Posted by Dan Albert, Android NDK Tech Lead

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

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

New Minimum System Requirements

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

Release Cycle Changes and LTS

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

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

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

New Features and Updates

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

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

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

Updated LLVM

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

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

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

libc++ has been updated to r369764.

Fortify

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

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

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

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

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

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

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

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

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

Other updates

64-bit requirement

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

Neon by default

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

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

Up Next

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

October 17th 2019, 1:46 pm

Previewing #AndroidDevSummit: Sessions, App, & Livestream Details

Android Developers Blog

Posted by The #AndroidDevSummit team

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

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

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

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

Get the Android Dev Summit app on Google Play!

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

2019 #AndroidDevSummit app

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

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

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

October 9th 2019, 6:54 pm

Continuous testing with new Android emulator tools

Android Developers Blog

Posted by Lingfeng Yang, Android Studio team

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

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

Deployability

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

To address this we have launched:

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

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

Debuggability

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

  1. ADB
  2. Remote streaming

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

Remote streaming

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

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

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

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

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

Let’s scale testing!

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

October 2nd 2019, 5:22 pm

Unlock your creativity with Google Play Pass

Android Developers Blog

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

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

Letting diverse, high-quality content shine

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

A new way to make money

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

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

Play Pass on Google Play

Little work, lots of opportunity

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

Express interest

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

How useful did you find this blog post?

September 23rd 2019, 12:40 pm

New! Android Kotlin codelab courses are here

Android Developers Blog

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

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

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

Kotlin Bootcamp

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

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

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

Start the Kotlin Bootcamp now!

Building Android apps in Kotlin

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

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

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

Get started now!

September 20th 2019, 4:11 pm

Trust but verify attestation with revocation

Android Developers Blog

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

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

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

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

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

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

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

September 6th 2019, 2:51 pm

Expand your app beyond mobile to reach Android users at large

Android Developers Blog

Posted by Sameer Samat, Vice President, Platforms & Ecosystems

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

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

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

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

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

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


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

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

Sources:

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

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

September 5th 2019, 3:03 pm

Welcoming Android 10!

Android Developers Blog

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

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

Android 10 is built around three important themes. First, Android 10 is shaping the leading edge of mobile innovation with advanced machine-learning and support for emerging devices like foldables and 5G enabled phones. Next, Android 10 has a central focus on privacy and security, with almost 50 features that give users greater protection, transparency, and control. Finally, Android 10 expands users' digital wellbeing controls so individuals and families can find a better balance with technology.

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

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

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

What’s in Android 10?

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

Innovation and new experiences

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

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

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

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

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

Smart Reply can suggest actions based on notification content.

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

Dark theme in Google Keep

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

Gesture navigation gives apps the full screen for content

Privacy for users

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

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

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

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

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

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

Security

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

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

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

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

Camera and media

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

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

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

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

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

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

Connectivity

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

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

Android foundations

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

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

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

Faster updates, fresher code

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

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

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

Get your apps ready for Android 10!

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

Here’s how to do it:

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

Enhance your app with Android 10 features and APIs

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

We recommend these for every app:

We recommend these if relevant for your app:

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

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

Coming to a device near you!

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

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

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

What’s next?

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

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

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

September 3rd 2019, 1:17 pm

Committed to a safer Google Play for Families

Android Developers Blog

Posted by Kanika Sachdeva, Product Manager, Google Play

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

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

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

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

How useful did you find this blog post?

August 30th 2019, 2:53 pm

Expanding bug bounties on Google Play

Android Developers Blog

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

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

Google Play Security Reward Program Scope Increases

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

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

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

Introducing the Developer Data Protection Reward Program

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

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

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

August 29th 2019, 12:47 pm

The Google Play store’s visual refresh

Android Developers Blog

Boris Valusek, Design Lead, Google Play

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

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

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

How useful did you find this blogpost?

August 21st 2019, 1:01 pm

Android Studio 3.5: Project Marble goes into stable

Android Developers Blog

Posted by Jamal Eason, Product Manager, Android

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

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

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

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

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

System Health

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

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

Auto-recommend Memory Settings

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

Memory Settings

User Interface Freezes

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

Code Editing Before - Android Studio 3.4

Code Editing After - Android Studio 3.5

Build Speed

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

Disk I/O File Access Speed

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

System Health Notification - Anti-virus Check

Feature Polish

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

Apply Changes

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

Apply Changes Buttons

App Deployment User Flow

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

System Health

Feature Polish

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

Opt-In & Feedback

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

IDE Data Sharing

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

IDE User Feedback

Getting Started

Download

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

To use the mentioned Android Emulator features make sure you are running at least Android Emulator v29.1.9 downloaded via the Android Studio SDK Manager.

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

August 20th 2019, 1:15 pm

Improving Accessibility in the Android Ecosystem

Android Developers Blog

Posted by Ian Stoba, Program Manager, Accessibility Engineering

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

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

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

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

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

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

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

August 15th 2019, 4:31 pm

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

Android Developers Blog

Posted by Takeshi Hagikura, Developer Programs Engineer

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

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

Android Q out of the box

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

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

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

Gesture navigation navigating back and to the home screen

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

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

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


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

Schedule UI in dark theme

Improved schedule screen

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

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

This year’s schedule UI jumping to another conference day

Navigation component

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

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

All transitions in the navigation editor

Full Text Search with Room

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

Searching for a session and a speaker

Lots of improvements

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

Home UI and Codelabs UI

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

Go explore the code

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


August 14th 2019, 2:00 pm

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

Android Developers Blog

Posted by Kacey Fahey, Google Play Developer Marketing

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

What they did

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

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

Results

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

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

Get started

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

August 13th 2019, 2:43 pm

Gesture Navigation: A Backstory

Android Developers Blog

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

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

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

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

Why gestures?

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

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

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

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

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

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

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

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

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

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

So why these gestures?

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

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

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

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

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

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


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


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


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

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

App Drawers and other App Swipes

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

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

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

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

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

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

So What Does This Mean for Developers?

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

There are three key steps to support gesture navigation:

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

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

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

August 8th 2019, 4:27 pm

Final Beta update, official Android Q coming soon!

Android Developers Blog

Posted by Dave Burke, VP of Engineering

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

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

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

What’s in Beta 6?

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

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

Get your apps ready for Android Q!

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

Here’s how to do it:

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

Enhance your app with Android Q features and APIs

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

We recommend these for every app:

We recommend these if relevant for your app:

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

Publish your app updates to Google Play

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

How do I get Beta 6?

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

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

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

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

August 7th 2019, 1:09 pm

Make stronger decisions with new Google Play Console data

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play

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

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

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

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

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

Here’s what else is new:

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

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

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

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

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

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

How useful did you find this blog post?

July 31st 2019, 7:02 am

What’s new with Fast Pair

Android Developers Blog

Posted by Catherina Xu (Product Manager)

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

The Fast Pair team presenting at I/O 2019.

Upcoming experiences

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

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

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

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

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

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

    Compatible Devices

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

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

    Interested in Fast Pair?

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

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

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

    Android Developers Blog

    Posted by Wojtek Kaliciński, Developer Advocate, Android

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

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

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

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

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

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

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

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

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

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

    July 18th 2019, 2:21 pm

    Android Dev Summit 2019 Registration is Open

    Android Developers Blog

    Posted by Sean McQuillan, Developer Advocate, Android

    Registration is now open for Android Dev Summit 2019!

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

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

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

    Conference details

    When: October 23-24

    Where: Google Event Center (MP7)

    Unable to attend?

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

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

    Register now

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

    July 16th 2019, 12:10 pm

    What’s new for text in Android Q

    Android Developers Blog

    Posted by Florina Muntenescu, Android Developer Advocate

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

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

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

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

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

    As a TextAppearance attribute in styles.xml:

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

    As a TextView attribute:

    <TextView android:hyphenationFrequency="normal" />
    

    Directly in code:

    textView.hyphenationFrequency = Layout.HYPHENATION_FREQUENCY_NORMAL
    

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

    Use multiple custom fonts in the same TextView

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

    Button with icon and Latin fonts

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

    Our icon font example can be implemented like this:

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

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

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

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

    Text styling API updates

    Android Q brings several updates to different text styling APIs:

    Improved support for variable fonts

    TextAppearance now supports the fontVariationSettings attribute:

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

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

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

    Improved spans APIs

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

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

    Access system fonts

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

    System fonts that can render this text

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

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

    The FontMatcher API never returns nullptr:

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

    Font updates

    New Myanmar font

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

    New emojis

    New emojis in Android Q

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

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

    July 11th 2019, 1:22 pm

    Android Q Beta 5 Update

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

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

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

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

    What’s in Beta 5?

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

    Gestural navigation updates

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

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

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

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

    Get your apps ready for Android Q!

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

    Here’s how to do it:

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

    Enhance your app with Android Q features and APIs

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

    We recommend these for every app:

    We recommend these if relevant for your app:

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

    Publish your app updates to Google Play

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

    How do I get Beta 5?

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

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

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

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

    July 10th 2019, 1:08 pm

    Capturing Audio in Android Q

    Android Developers Blog

    Posted by Don Turner, Developer Advocate for Android Media

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

    Some examples include:

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

    What does the user see?

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

    AUDIO_RECORD permissions dialog

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

    Screen capture intent dialog

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

    Cast icon showing red in status bar

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

    Can my app's audio be captured?

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

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


    Disallowing capture by third party apps

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

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


    Disallowing capture of all audio by third party apps

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

    Add the following to your AndroidManifest.xml

    ...

    android:allowAudioPlaybackCapture="false"/>

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


    Disallowing capture on a per player basis by third party apps

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

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)
    

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


    Disallowing capture by system apps and components

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

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


    Disallowing capture of all audio

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

    AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    Disallowing capture on a per player basis

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

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    What next?

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

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

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

    July 3rd 2019, 10:17 am

    Indie Games Showcase from Google Play - meet the winners!

    Android Developers Blog

    Posted by Patricia Correa, Director, Developer Marketing

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

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

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

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

    Europe

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Ordia by Loju (United Kingdom)

    Photographs by EightyEight Games (United Kingdom)


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

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Golf Peaks by Afterburn (Poland)

    Rest in Pieces by Itatake (Sweden)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

    Japan

    Infection - 感染 - by CanvasSoft

    MeltLand by 個人

    Bear's Restaurant by 個人


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

    Lunch Time Fish by SoftFunk HULABREAKS

    ReversEstory by 個人

    Kamiori - カミオリ by TeamOrigami

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

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

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

    Persephone by Momo-pi

    South Korea

    ROOMS: The Toymaker's Mansion by HandMade Game

    Seoul2033: Backer by Banjiha Games

    Cartoon Craft by Studio NAP


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

    Hexonia by Togglegear

    Hexagon Dungeon by Bleor Games

    7Days - Decide your story by Buff Studio

    WhamBam Warriors by DrukHigh

    Onslot Car by Wondersquad

    Maze Cube by IAMABOY

    언노운 나이츠 by teamarex

    How useful did you find this blog post?

    July 2nd 2019, 12:50 pm

    Advanced in-app billing: handling alternative purchase flows

    Android Developers Blog

    Posted by Oscar Rodriguez, Developer Advocate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    June 26th 2019, 1:39 pm

    Moving Android Studio and Android Emulator to 64-bit versions

    Android Developers Blog

    Posted by Sam Lin, Product Manager, Android

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

    Timeline

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

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

    Advantages of a 64-bit development environment

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

    Next steps

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

    June 11th 2019, 2:25 pm

    Android Q Beta 4 and Final APIs!

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

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

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

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

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

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

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

    What’s in Beta 4?

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

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

    Make your apps compatible with Android Q!

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

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

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

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

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

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

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

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

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

    Enhance your app with Android Q features and APIs

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

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

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

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

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

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

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

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

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

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

    Publish your app updates to Google Play

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

    How do I get Beta 4?

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

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

    As always, your input is critical, so please continue to let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.

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

    June 5th 2019, 1:30 pm

    Indie Games Accelerator - Introducing class of 2019!

    Android Developers Blog

    Posted by Vineet Tanwar, Business Development Manager, Google Play

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

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

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

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

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

    How useful did you find this blog post?

    June 5th 2019, 2:03 am

    Improved app quality and discovery on Google Play

    Android Developers Blog

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

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

    Good in-app user experience

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

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

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

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

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

    Strong app stability and technical performance

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

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

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

    Effective store listing page

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

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

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

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

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

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

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

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

    How useful did you find this blog post?

    June 4th 2019, 12:11 pm

    Google Play services and Firebase migrating to AndroidX

    Android Developers Blog

    Posted by Doug Stevenson, Developer Advocate

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

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

    android.useAndroidX=true
    android.enableJetifier=true

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

    June 3rd 2019, 2:42 pm

    Building a safer Google Play for kids

    Android Developers Blog

    Posted by Kanika Sachdeva, Product Manager, Google Play

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

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

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

    What’s changing for developers

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

    Declaring a target audience

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

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

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

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

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

    Rolling out these changes

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

    Our commitment to you

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

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

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

    How useful did you find this blog post?

    May 29th 2019, 10:17 am

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

    Android Developers Blog

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

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

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

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

    Europe

    AntVentor by LoopyMood (Ukraine)

    CHUCHEL by Amanita Design (Czech Republic)

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Fobia by Tapteek (Russia)

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Gold Peaks by Afterburn (Poland)

    Grayland by 1DER Entertainment (Slovakia)

    Hexologic by MythicOwl (Poland)

    Lucid Dream Adventure by Dali Games (Poland)

    OCO by SPECTRUM48 (United Kingdom)

    Ordia by Loju (United Kingdom)

    Peep by Taw (Russia)

    Photographs by EightyEight Games (United Kingdom)

    Rest in Pieces by Itatake (Sweden)

    Returner Zhero by Fantastic, yes (Denmark)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

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

    Japan

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

    Infection - 感染 - by CanvasSoft

    Jumpion - Make a two-step jump ! by Comgate

    Lunch Time Fish by SoftFunk HULABREAKS

    MeltLand by 個人

    ReversEstory by 個人

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

    SumoRoll - Road to the Yokozuna by Studio Kingmo

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

    Kamiori - カミオリ by TeamOrigami

    Bear's Restaurant by 個人

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

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

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

    タシテケス by 個人

    Destination: Dragons! by GAME GABURI

    Cute cat's cake shop by 個人

    Persephone by Momo-pi

    Hamcorollin' by illuCalab.

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

    South Korea

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

    Bad 2 Bad: Extinction by Dawinstone

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

    Cartoon Craft by Studio NAP

    Catch Idle by HalftimeStudio

    Hexagon Dungeon by Bleor Games

    Hexonia by Togglegear

    Mahjong - Magic Fantasy by Aquagamez

    Maze Cube by IAMABOY

    Road to Valor: World War II by Dreamotion Inc.

    Onslot Car by Wondersquad

    ROOMS: The Toymaker's Mansion by HandMade Game

    Rhythm Star: Music Adventure by Anbsoft

    7Days - Decide your story by Buff Studio

    Seoul2033: Backer by Banjiha Games

    Super Jelly Pop by STARMONSTER

    UNLINK Daily Puzzle by Supershock

    몬스터파크 온라인 by OVENCODE

    WhamBam Warriors by DrukHigh

    언노운 나이츠 by teamarex

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

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

    Congratulations to all finalists!

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

    How useful did you find this blog post?

    May 23rd 2019, 2:01 am

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

    Android Developers Blog

    Posted by Peiyong Lin, Software Engineer

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

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

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

    Display P3

    SRGB

    Display P3

    SRGB

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

    Color Tests

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

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

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

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

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

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

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

    What you should do to prepare

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

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

    Mandatory: Be Color Correct

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

    Using BitmapFactory

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

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

    Using ImageDecoder

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

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

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

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

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

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

    Known bad practices

    Some typical bad practices include but are not limited to:

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

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

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

    Optional: Be wide color capable

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

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

    android:colorMode="wideColorGamut"

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

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

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

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

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

    APIs design guideline for image library

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

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

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

    May 20th 2019, 3:22 pm

    Kotlin Is Everywhere! Join the global event series

    Android Developers Blog

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

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

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

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

    Who can attend the events?

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

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

    How to host your Kotlin/Everywhere event?

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

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

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

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

    May 16th 2019, 2:07 pm

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

    Android Developers Blog

    Posted by Dan Galpin

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

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

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

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

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

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

    May 15th 2019, 5:23 pm

    Supporting Google Play developers regarding local market withholding tax regulations

    Android Developers Blog

    Posted by Gloria On, Program Manager, Google Play

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

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

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

    How useful did you find this blog post?

    May 15th 2019, 12:34 pm

    Queue the Hardening Enhancements

    Android Developers Blog

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

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

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

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

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

    A Constrained Sandbox for Software Codecs

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

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

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

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

    Bound Sanitizer

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

    BoundSan instrumentation

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

    More integer sanitizer in more places

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

    IntSan Instrumentation

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

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

    Shadow Call Stack

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

    SCS Instrumentation

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

    eXecute-Only Memory

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

    Tombstone from a XOM abort

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

    Scudo Hardened Allocator

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

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

    Tombstone from Scudo aborts

    Contributing security improvements to Open Source

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

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

    May 9th 2019, 11:32 am

    What’s New in Android Q Security

    Android Developers Blog

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

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

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

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

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

    Encryption

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

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

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

    Platform Hardening

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

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

    Authentication

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

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

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

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

    What’s Next?

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

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

    May 9th 2019, 11:32 am

    What’s New with Android Jetpack

    Android Developers Blog

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

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

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

    What’s New in Jetpack

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

    Now in Alpha

    CameraX

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

    LiveData and Lifecycles w/ coroutines

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

    Benchmark

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

    Security

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

    ViewModel with SavedState

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

    ViewPager2

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

    Now in Beta

    ConstraintLayout 2.0

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

    Biometrics Prompt

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

    Enterprise

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

    Android for Cars

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

    Now in Stable

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

    Jetpack Compose

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

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

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

    We are building Compose with a few core principles:

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

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

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

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

    Happy Jetpacking!

    May 8th 2019, 3:44 pm
    Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا