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

New! Android Kotlin codelab courses are here

Android Developers Blog

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

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

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

Kotlin Bootcamp

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

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

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

Start the Kotlin Bootcamp now!

Building Android apps in Kotlin

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

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

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

Get started now!

September 20th 2019, 4:11 pm

Trust but verify attestation with revocation

Android Developers Blog

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

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

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

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

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

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

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

September 6th 2019, 2:51 pm

Expand your app beyond mobile to reach Android users at large

Android Developers Blog

Posted by Sameer Samat, Vice President, Platforms & Ecosystems

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

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

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

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

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

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


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

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

Sources:

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

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

September 5th 2019, 3:03 pm

Welcoming Android 10!

Android Developers Blog

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

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

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

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

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

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

What’s in Android 10?

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

Innovation and new experiences

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

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

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

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

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

Smart Reply can suggest actions based on notification content.

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

Dark theme in Google Keep

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

Gesture navigation gives apps the full screen for content

Privacy for users

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

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

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

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

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

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

Security

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

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

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

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

Camera and media

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

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

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

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

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

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

Connectivity

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

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

Android foundations

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

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

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

Faster updates, fresher code

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

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

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

Get your apps ready for Android 10!

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

Here’s how to do it:

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

Enhance your app with Android 10 features and APIs

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

We recommend these for every app:

We recommend these if relevant for your app:

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

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

Coming to a device near you!

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

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

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

What’s next?

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

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

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

September 3rd 2019, 1:17 pm

Committed to a safer Google Play for Families

Android Developers Blog

Posted by Kanika Sachdeva, Product Manager, Google Play

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

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

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

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

How useful did you find this blog post?

August 30th 2019, 2:53 pm

Expanding bug bounties on Google Play

Android Developers Blog

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

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

Google Play Security Reward Program Scope Increases

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

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

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

Introducing the Developer Data Protection Reward Program

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

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

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

August 29th 2019, 12:47 pm

The Google Play store’s visual refresh

Android Developers Blog

Boris Valusek, Design Lead, Google Play

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

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

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

How useful did you find this blogpost?

August 21st 2019, 1:01 pm

Android Studio 3.5: Project Marble goes into stable

Android Developers Blog

Posted by Jamal Eason, Product Manager, Android

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

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

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

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

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

System Health

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

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

Auto-recommend Memory Settings

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

Memory Settings

User Interface Freezes

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

Code Editing Before - Android Studio 3.4

Code Editing After - Android Studio 3.5

Build Speed

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

Disk I/O File Access Speed

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

System Health Notification - Anti-virus Check

Feature Polish

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

Apply Changes

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

Apply Changes Buttons

App Deployment User Flow

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

System Health

Feature Polish

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

Opt-In & Feedback

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

IDE Data Sharing

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

IDE User Feedback

Getting Started

Download

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

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

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

August 20th 2019, 1:15 pm

Improving Accessibility in the Android Ecosystem

Android Developers Blog

Posted by Ian Stoba, Program Manager, Accessibility Engineering

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

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

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

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

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

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

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

August 15th 2019, 4:31 pm

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

Android Developers Blog

Posted by Takeshi Hagikura, Developer Programs Engineer

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

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

Android Q out of the box

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

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

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

Gesture navigation navigating back and to the home screen

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

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

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


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

Schedule UI in dark theme

Improved schedule screen

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

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

This year’s schedule UI jumping to another conference day

Navigation component

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

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

All transitions in the navigation editor

Full Text Search with Room

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

Searching for a session and a speaker

Lots of improvements

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

Home UI and Codelabs UI

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

Go explore the code

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


August 14th 2019, 2:00 pm

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

Android Developers Blog

Posted by Kacey Fahey, Google Play Developer Marketing

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

What they did

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

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

Results

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

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

Get started

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

August 13th 2019, 2:43 pm

Gesture Navigation: A Backstory

Android Developers Blog

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

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

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

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

Why gestures?

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

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

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

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

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

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

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

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

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

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

So why these gestures?

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

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

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

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

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

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


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


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


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

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

App Drawers and other App Swipes

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

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

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

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

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

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

So What Does This Mean for Developers?

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

There are three key steps to support gesture navigation:

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

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

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

August 8th 2019, 4:27 pm

Final Beta update, official Android Q coming soon!

Android Developers Blog

Posted by Dave Burke, VP of Engineering

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

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

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

What’s in Beta 6?

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

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

Get your apps ready for Android Q!

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

Here’s how to do it:

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

Enhance your app with Android Q features and APIs

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

We recommend these for every app:

We recommend these if relevant for your app:

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

Publish your app updates to Google Play

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

How do I get Beta 6?

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

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

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

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

August 7th 2019, 1:09 pm

Make stronger decisions with new Google Play Console data

Android Developers Blog

Posted by Tom Grinsted, Product Manager, Google Play

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

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

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

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

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

Here’s what else is new:

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

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

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

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

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

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

How useful did you find this blog post?

July 31st 2019, 7:02 am

What’s new with Fast Pair

Android Developers Blog

Posted by Catherina Xu (Product Manager)

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

The Fast Pair team presenting at I/O 2019.

Upcoming experiences

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

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

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

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

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

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

    Compatible Devices

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

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

    Interested in Fast Pair?

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

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

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

    Android Developers Blog

    Posted by Wojtek Kaliciński, Developer Advocate, Android

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

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

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

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

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

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

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

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

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

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

    July 18th 2019, 2:21 pm

    Android Dev Summit 2019 Registration is Open

    Android Developers Blog

    Posted by Sean McQuillan, Developer Advocate, Android

    Registration is now open for Android Dev Summit 2019!

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

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

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

    Conference details

    When: October 23-24

    Where: Google Event Center (MP7)

    Unable to attend?

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

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

    Register now

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

    July 16th 2019, 12:10 pm

    What’s new for text in Android Q

    Android Developers Blog

    Posted by Florina Muntenescu, Android Developer Advocate

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

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

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

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

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

    As a TextAppearance attribute in styles.xml:

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

    As a TextView attribute:

    <TextView android:hyphenationFrequency="normal" />
    

    Directly in code:

    textView.hyphenationFrequency = Layout.HYPHENATION_FREQUENCY_NORMAL
    

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

    Use multiple custom fonts in the same TextView

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

    Button with icon and Latin fonts

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

    Our icon font example can be implemented like this:

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

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

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

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

    Text styling API updates

    Android Q brings several updates to different text styling APIs:

    Improved support for variable fonts

    TextAppearance now supports the fontVariationSettings attribute:

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

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

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

    Improved spans APIs

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

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

    Access system fonts

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

    System fonts that can render this text

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

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

    The FontMatcher API never returns nullptr:

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

    Font updates

    New Myanmar font

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

    New emojis

    New emojis in Android Q

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

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

    July 11th 2019, 1:22 pm

    Android Q Beta 5 Update

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

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

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

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

    What’s in Beta 5?

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

    Gestural navigation updates

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

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

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

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

    Get your apps ready for Android Q!

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

    Here’s how to do it:

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

    Enhance your app with Android Q features and APIs

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

    We recommend these for every app:

    We recommend these if relevant for your app:

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

    Publish your app updates to Google Play

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

    How do I get Beta 5?

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

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

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

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

    July 10th 2019, 1:08 pm

    Capturing Audio in Android Q

    Android Developers Blog

    Posted by Don Turner, Developer Advocate for Android Media

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

    Some examples include:

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

    What does the user see?

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

    AUDIO_RECORD permissions dialog

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

    Screen capture intent dialog

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

    Cast icon showing red in status bar

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

    Can my app's audio be captured?

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

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


    Disallowing capture by third party apps

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

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


    Disallowing capture of all audio by third party apps

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

    Add the following to your AndroidManifest.xml

    ...

    android:allowAudioPlaybackCapture="false"/>

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


    Disallowing capture on a per player basis by third party apps

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

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_SYSTEM)
    

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


    Disallowing capture by system apps and components

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

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


    Disallowing capture of all audio

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

    AudioManager.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    Disallowing capture on a per player basis

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

    AudioAttributes.Builder.setAllowedCapturePolicy(ALLOW_CAPTURE_BY_NONE)
    


    What next?

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

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

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

    July 3rd 2019, 10:17 am

    Indie Games Showcase from Google Play - meet the winners!

    Android Developers Blog

    Posted by Patricia Correa, Director, Developer Marketing

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

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

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

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

    Europe

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Ordia by Loju (United Kingdom)

    Photographs by EightyEight Games (United Kingdom)


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

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Golf Peaks by Afterburn (Poland)

    Rest in Pieces by Itatake (Sweden)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

    Japan

    Infection - 感染 - by CanvasSoft

    MeltLand by 個人

    Bear's Restaurant by 個人


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

    Lunch Time Fish by SoftFunk HULABREAKS

    ReversEstory by 個人

    Kamiori - カミオリ by TeamOrigami

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

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

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

    Persephone by Momo-pi

    South Korea

    ROOMS: The Toymaker's Mansion by HandMade Game

    Seoul2033: Backer by Banjiha Games

    Cartoon Craft by Studio NAP


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

    Hexonia by Togglegear

    Hexagon Dungeon by Bleor Games

    7Days - Decide your story by Buff Studio

    WhamBam Warriors by DrukHigh

    Onslot Car by Wondersquad

    Maze Cube by IAMABOY

    언노운 나이츠 by teamarex

    How useful did you find this blog post?

    July 2nd 2019, 12:50 pm

    Advanced in-app billing: handling alternative purchase flows

    Android Developers Blog

    Posted by Oscar Rodriguez, Developer Advocate

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    June 26th 2019, 1:39 pm

    Moving Android Studio and Android Emulator to 64-bit versions

    Android Developers Blog

    Posted by Sam Lin, Product Manager, Android

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

    Timeline

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

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

    Advantages of a 64-bit development environment

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

    Next steps

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

    June 11th 2019, 2:25 pm

    Android Q Beta 4 and Final APIs!

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

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

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

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

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

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

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

    What’s in Beta 4?

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

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

    Make your apps compatible with Android Q!

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

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

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

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

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

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

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

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

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

    Enhance your app with Android Q features and APIs

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

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

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

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

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

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

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

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

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

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

    Publish your app updates to Google Play

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

    How do I get Beta 4?

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

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

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

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

    June 5th 2019, 1:30 pm

    Indie Games Accelerator - Introducing class of 2019!

    Android Developers Blog

    Posted by Vineet Tanwar, Business Development Manager, Google Play

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

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

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

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

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

    How useful did you find this blog post?

    June 5th 2019, 2:03 am

    Improved app quality and discovery on Google Play

    Android Developers Blog

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

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

    Good in-app user experience

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

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

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

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

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

    Strong app stability and technical performance

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

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

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

    Effective store listing page

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

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

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

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

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

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

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

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

    How useful did you find this blog post?

    June 4th 2019, 12:11 pm

    Google Play services and Firebase migrating to AndroidX

    Android Developers Blog

    Posted by Doug Stevenson, Developer Advocate

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

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

    android.useAndroidX=true
    android.enableJetifier=true

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

    June 3rd 2019, 2:42 pm

    Building a safer Google Play for kids

    Android Developers Blog

    Posted by Kanika Sachdeva, Product Manager, Google Play

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

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

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

    What’s changing for developers

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

    Declaring a target audience

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

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

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

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

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

    Rolling out these changes

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

    Our commitment to you

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

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

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

    How useful did you find this blog post?

    May 29th 2019, 10:17 am

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

    Android Developers Blog

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

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

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

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

    Europe

    AntVentor by LoopyMood (Ukraine)

    CHUCHEL by Amanita Design (Czech Republic)

    #DRIVE by Pixel Perfect Dude (Poland)

    Fly THIS! By Northplay (Denmark)

    Fobia by Tapteek (Russia)

    G30 - A Memory Maze by Ivan Kovalov (Russia)

    Gold Peaks by Afterburn (Poland)

    Grayland by 1DER Entertainment (Slovakia)

    Hexologic by MythicOwl (Poland)

    Lucid Dream Adventure by Dali Games (Poland)

    OCO by SPECTRUM48 (United Kingdom)

    Ordia by Loju (United Kingdom)

    Peep by Taw (Russia)

    Photographs by EightyEight Games (United Kingdom)

    Rest in Pieces by Itatake (Sweden)

    Returner Zhero by Fantastic, yes (Denmark)

    see/saw by Kamibox (Germany)

    STAP by Overhead Game Studio (United Kingdom)

    Tesla vs. Lovecraft by 10tons (Finland)

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

    Japan

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

    Infection - 感染 - by CanvasSoft

    Jumpion - Make a two-step jump ! by Comgate

    Lunch Time Fish by SoftFunk HULABREAKS

    MeltLand by 個人

    ReversEstory by 個人

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

    SumoRoll - Road to the Yokozuna by Studio Kingmo

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

    Kamiori - カミオリ by TeamOrigami

    Bear's Restaurant by 個人

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

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

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

    タシテケス by 個人

    Destination: Dragons! by GAME GABURI

    Cute cat's cake shop by 個人

    Persephone by Momo-pi

    Hamcorollin' by illuCalab.

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

    South Korea

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

    Bad 2 Bad: Extinction by Dawinstone

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

    Cartoon Craft by Studio NAP

    Catch Idle by HalftimeStudio

    Hexagon Dungeon by Bleor Games

    Hexonia by Togglegear

    Mahjong - Magic Fantasy by Aquagamez

    Maze Cube by IAMABOY

    Road to Valor: World War II by Dreamotion Inc.

    Onslot Car by Wondersquad

    ROOMS: The Toymaker's Mansion by HandMade Game

    Rhythm Star: Music Adventure by Anbsoft

    7Days - Decide your story by Buff Studio

    Seoul2033: Backer by Banjiha Games

    Super Jelly Pop by STARMONSTER

    UNLINK Daily Puzzle by Supershock

    몬스터파크 온라인 by OVENCODE

    WhamBam Warriors by DrukHigh

    언노운 나이츠 by teamarex

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

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

    Congratulations to all finalists!

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

    How useful did you find this blog post?

    May 23rd 2019, 2:01 am

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

    Android Developers Blog

    Posted by Peiyong Lin, Software Engineer

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

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

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

    Display P3

    SRGB

    Display P3

    SRGB

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

    Color Tests

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

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

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

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

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

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

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

    What you should do to prepare

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

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

    Mandatory: Be Color Correct

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

    Using BitmapFactory

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

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

    Using ImageDecoder

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

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

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

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

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

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

    Known bad practices

    Some typical bad practices include but are not limited to:

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

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

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

    Optional: Be wide color capable

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

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

    android:colorMode="wideColorGamut"

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

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

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

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

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

    APIs design guideline for image library

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

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

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

    May 20th 2019, 3:22 pm

    Kotlin Is Everywhere! Join the global event series

    Android Developers Blog

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

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

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

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

    Who can attend the events?

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

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

    How to host your Kotlin/Everywhere event?

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

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

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

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

    May 16th 2019, 2:07 pm

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

    Android Developers Blog

    Posted by Dan Galpin

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

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

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

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

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

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

    May 15th 2019, 5:23 pm

    Supporting Google Play developers regarding local market withholding tax regulations

    Android Developers Blog

    Posted by Gloria On, Program Manager, Google Play

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

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

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

    How useful did you find this blog post?

    May 15th 2019, 12:34 pm

    Queue the Hardening Enhancements

    Android Developers Blog

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

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

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

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

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

    A Constrained Sandbox for Software Codecs

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

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

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

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

    Bound Sanitizer

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

    BoundSan instrumentation

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

    More integer sanitizer in more places

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

    IntSan Instrumentation

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

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

    Shadow Call Stack

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

    SCS Instrumentation

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

    eXecute-Only Memory

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

    Tombstone from a XOM abort

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

    Scudo Hardened Allocator

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

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

    Tombstone from Scudo aborts

    Contributing security improvements to Open Source

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

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

    May 9th 2019, 11:32 am

    What’s New in Android Q Security

    Android Developers Blog

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

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

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

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

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

    Encryption

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

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

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

    Platform Hardening

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

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

    Authentication

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

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

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

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

    What’s Next?

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

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

    May 9th 2019, 11:32 am

    What’s New with Android Jetpack

    Android Developers Blog

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

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

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

    What’s New in Jetpack

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

    Now in Alpha

    CameraX

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

    LiveData and Lifecycles w/ coroutines

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

    Benchmark

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

    Security

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

    ViewModel with SavedState

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

    ViewPager2

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

    Now in Beta

    ConstraintLayout 2.0

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

    Biometrics Prompt

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

    Enterprise

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

    Android for Cars

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

    Now in Stable

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

    Jetpack Compose

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

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

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

    We are building Compose with a few core principles:

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

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

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

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

    Happy Jetpacking!

    May 8th 2019, 3:44 pm

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

    Android Developers Blog

    Posted by Kobi Glick, Product Lead, Google Play

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

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

    Efficient, modular apps and customizable feature delivery

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

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

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

    Seamless internal testing and increased security

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

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

    Easier for users to update

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

    The API currently supports two flows:

    Stronger decision-making with new Google Play Console data

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

    Making it easier to respond to and improve user reviews

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

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

    Better Google Play Store listing targeting and customization

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

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

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

    How useful did you find this blog post?

    May 8th 2019, 2:44 pm

    Android Studio 3.5 Beta

    Android Developers Blog

    Posted by Jamal Eason, Product Manager, Android

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

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

    System Health - Memory

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

    Memory Settings

    Memory Usage Report

    System Health - Exceptions

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

    Android Studio Exception Bubble

    System Health - User Interface Freezes

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

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

    System Health - Build Speed

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

    System Health - IDE Speed

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

    System Health - Lint Code Analysis

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

    System Health - I/O File Access for Windows

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

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

    System Health Notification - Anti-virus Check

    System Health - Emulator CPU Usage

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

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

    Feature Polish - Apply Changes

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

    Apply Changes Buttons

    Feature Polish - Gradle Sync

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

    Feature Polish - Project Upgrades

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

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

    Feature Polish - Layout Editor

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

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

    Feature Polish - Data Binding

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

    Feature Polish - App Deployment Flow

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

    App Deployment User Flow

    Feature Polish - C++ Improvements

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

    Single Variant Selection by ABI

    Feature Polish - Intellij Platform Update

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

    Feature Polish - Conditional Delivery for Dynamic Feature Support

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

    Module Selection for Conditional Delivery

    Feature Polish - Emulator Foldables & Pixel Device Support

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

    Android Emulator - Foldable Support

    Feature Polish - Chrome OS Support

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

    Android Studio on Chrome OS

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

    System Health

    Feature Polish

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

    Opt-In & Feedback

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

    IDE Data Sharing

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

    IDE User Feedback

    Getting Started

    Download

    Download the beta version of Android Studio 3.5 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and beta release versions of Android Studio at the same time. Learn more.

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

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

    May 8th 2019, 1:44 pm

    Fresher OS with Projects Treble and Mainline

    Android Developers Blog

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

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

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

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

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

    Safer and more secure devices with Project Mainline

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

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

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

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

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

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

    How does this work?

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

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

    May 8th 2019, 1:14 pm

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

    Android Developers Blog

    Posted by Chet Haase

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

    Developer Productivity

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

    Kotlin

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

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

    Android Jetpack

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

    Android Studio

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

    Machine Learning at Android scale

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

    Dynamic Updates and Inline Updates

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

    User privacy and security in Android Q

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

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

    Be a part of Google I/O!

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

    May 7th 2019, 4:15 pm

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

    Android Developers Blog

    Posted by Dave Burke, VP, Engineering

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

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

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

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

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

    Privacy and security

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

    Privacy

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

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

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

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

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

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

    Security

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

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

    Project Mainline

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

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

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

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

    Innovation and new experiences

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

    Foldables

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

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

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

    5G networks

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

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

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

    Live Caption

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

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

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

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

    Suggested actions in notifications

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

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

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

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

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

    Dark theme

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

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

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

    Gestural navigation

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

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

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

    Digital wellbeing

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

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

    Focus Mode

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

    Family Link

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

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

    Android Foundations

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

    Improved peer-to-peer and internet connectivity

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

    Wi-Fi performance modes

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

    Full support for Wi-Fi RTT accurate indoor positioning

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

    Audio playback capture

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

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

    Dynamic depth for photos

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

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

    New audio and video codecs

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

    Vulkan 1.1 and ANGLE

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

    Neural Networks API 1.2

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

    Thermal API

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

    ART optimizations

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

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

    More Android Q Beta devices, more Treble momentum than ever

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

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

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

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

    Explore the new features and APIs

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

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

    How do I get Beta 3?

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

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

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

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

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

    May 7th 2019, 3:28 pm

    Developing Apps for Android Automotive OS

    Android Developers Blog

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

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

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

    Polestar 2 with Android Automotive OS

    Starting with media apps

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

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

    Media app user experience in Android Automotive OS

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

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

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

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

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

    See you at Google I/O 2019!

    May 1st 2019, 12:03 pm

    Android Q Scoped Storage: Best Practices and Updates

    Android Developers Blog

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

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

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

    Updates to help you adopt Scoped Storage

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

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

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

    Best practices for common feedback areas

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

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

    What’s ahead

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

    April 25th 2019, 4:30 pm

    And the 2019 Google Play Award nominees are...

    Android Developers Blog

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

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

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

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

    Standout Well-Being App

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

    Best Accessibility Experience

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

    Best Social Impact

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

    Most Beautiful Game

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

    Best Living Room Experience

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

    Most Inventive

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

    Standout Build for Billions Experience

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

    Best Breakthrough App

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

    Best Breakthrough Game

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

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

    How useful did you find this blog post?

    April 25th 2019, 1:01 pm

    Android Studio 3.4

    Android Developers Blog

    Posted by Jamal Eason, Product Manager, Android

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

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

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

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

    Develop

    Resource Manager

    Jetpack Import Intentions

    Layout Editor Properties Panel

    Build

    Project Structure Dialogue

    Test

    Android Emulator - Pixel 3 XL Emulator Skin

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

    Develop

    Build

    Test

    Check out the Android Studio release notes, Android Gradle plugin release notes, and the Android Emulator release notes for more details.

    Getting Started

    Download

    Download the latest version of Android Studio 3.4 from the download page. If you are using a previous release of Android Studio, you can simply update to the latest version of Android Studio. If you want to maintain a stable version of Android Studio, you can run the stable release version and canary release versions of Android Studio at the same time. Learn more.

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

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

    April 17th 2019, 2:30 pm

    Indie Games Accelerator - Applications open for class of 2019

    Android Developers Blog

    Posted by Anuj Gulati, Developer Marketing Manager and Sami Kizilbash, Developer Relations Program Manager

    Last year we announced the Indie Games Accelerator, a special edition of Launchpad Accelerator, to help top indie game developers from emerging markets achieve their full potential on Google Play. Our team of program mentors had an amazing time coaching some of the best gaming talent from India, Pakistan, and Southeast Asia. We’re very encouraged by the positive feedback we received for the program and are excited to bring it back in 2019.

    Applications for the class of 2019 are now open, and we’re happy to announce that we are expanding the program to developers from select countries* in Asia, Middle East, Africa, and Latin America.

    Successful participants will be invited to attend two gaming bootcamps, all-expenses-paid at the Google Asia-Pacific office in Singapore, where they will receive personalized mentorship from Google teams and industry experts. Additional benefits include Google hardware, invites to exclusive Google and industry events and more.

    Find out more about the program and apply to be a part of it.

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

    How useful did you find this blog post?

    April 17th 2019, 2:03 am

    Improving the update process with your feedback

    Android Developers Blog

    Posted by Sameer Samat, VP of Product Management, Android & Google Play

    Thank you for all the feedback about updates we’ve been making to Android APIs and Play policies. We’ve heard your requests for improvement as well as some frustration. We want to explain how and why we’re making these changes, and how we are using your feedback to improve the way we roll out these updates and communicate with the developer community.

    From the outset, we’ve sought to craft Android as a completely open source operating system. We’ve also worked hard to ensure backwards compatibility and API consistency, out of respect and a desire to make the platform as easy to use as possible. This developer-centric approach and openness have been cornerstones of Android’s philosophy from the beginning. These are not changing.

    But as the platform grows and evolves, each decision we make comes with trade-offs. Everyday, billions of people around the world use the apps you’ve built to do incredible things like connect with loved ones, manage finances or communicate with doctors. Users want more control and transparency over how their personal information is being used by applications, and expect Android, as the platform, to do more to provide that control and transparency. This responsibility to users is something we have always taken seriously, and that’s why we are taking a comprehensive look at how our platform and policies reflect that commitment.

    Taking a closer look at permissions

    Earlier this year, we introduced Android Q Beta with dozens of features and improvements that provide users with more transparency and control, further securing their personal data. Along with the system-level changes introduced in Q, we’re also reviewing and refining our Play Developer policies to further enhance user privacy. For years, we’ve required developers to disclose the collection and use of personal data so users can understand how their information is being used, and to only use the permissions that are really needed to deliver the features and services of the app. As part of Project Strobe, which we announced last October, we are rolling out specific guidance for each of the Android runtime permissions, and we are holding apps developed by Google to the same standard.

    We started with changes to SMS and Call Log permissions late last year. To better protect sensitive user data available through these permissions, we restricted access to select use cases, such as when an app has been chosen by the user to be their default text message app. We understood that some app features using this data would no longer be allowed -- including features that many users found valuable -- and worked with you on alternatives where possible. As a result, today, the number of apps with access to this sensitive information has decreased by more than 98%. The vast majority of these were able to switch to an alternative or eliminate minor functionality.

    Learning from developer feedback

    While these changes are critical to help strengthen privacy protections for our users, we’re sensitive that evolving the platform can lead to substantial work for developers. We have a responsibility to make sure you have the details and resources you need to understand and implement changes, and we know there is room for improvement there. For example, when we began enforcing these new SMS and Call Log policies, many of you expressed frustration about the decision making process. There were a number of common themes that we wanted to share:

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

    Evaluating developer accounts

    We have also heard concerns from some developers whose accounts have been blocked from distributing apps through Google Play. While the vast majority of developers on Android are well-meaning, some accounts are suspended for serious, repeated violation of policies that protect our shared users. Bad-faith developers often try to get around this by opening new accounts or using other developers’ existing accounts to publish unsafe apps. While we strive for openness wherever possible, in order to prevent bad-faith developers from gaming our systems and putting our users at risk in the process, we can’t always share the reasons we’ve concluded that one account is related to another.

    While 99%+ of these suspension decisions are correct, we are also very sensitive to how impactful it can be if your account has been disabled in error. You can immediately appeal any enforcement, and each appeal is carefully reviewed by a person on our team. During the appeals process, we will reinstate your account if we discover that an error has been made.

    Separately, we will soon be taking more time (days, not weeks) to review apps by developers that don’t yet have a track record with us. This will allow us to do more thorough checks before approving apps to go live in the store and will help us make even fewer inaccurate decisions on developer accounts.

    Thank you for your ongoing partnership and for continuing to make Android an incredibly helpful platform for billions of people around the world.

    How useful did you find this blog post?

    April 16th 2019, 10:47 pm

    Optimize your subscriptions with new insights in the Play Console

    Android Developers Blog

    Posted by Daniel Schramm, Product Manager, Google Play

    Since launching on Google Play nearly 7 years ago, subscriptions have proven to be an essential element in creating sustainable mobile app businesses; 89 of the top 100 highest grossing apps on Google Play in the US now provide subscription products. As the market matures, it is becoming increasingly important for subscription developers to optimize both subscriber conversion and retention in order to maintain growth. To help you do that, we're rolling out new insights available directly in the Play Console.

    Subscription retention report

    Example subscription retention report data in the Play Console. Source: Google Internal Data.

    The recently updated subscription retention report shows how well you are retaining subscribers, along with how well subscribers convert from free trial, introductory price, and first to second payment.

    You can configure two cohorts based on SKU, country, and subscription start date. This is particularly useful for evaluating the success of A/B tests; for example, to determine if changing the duration of a free trial has an impact on free trial conversion.

    Example free trial conversion data in the Play Console. Source: Google Internal Data.

    Cancellation survey results

    Retaining your existing subscribers is just as important as acquiring new subscribers, so we have updated the subscription cancellations report to give more insight into voluntary and involuntary cancellations.

    The launch of the subscriptions center last year introduced a cancellation survey allowing users to give developers feedback as to why they were cancelling, with results available through the Google Play Developer API. To make these results easier to access and monitor, we now surface daily aggregates directly within the Play Console, along with the ability to download written responses in a CSV.

    Example cancellation survey responses in the Play Console. Source: Google Internal Data.

    Recover more users

    Involuntary cancellations, which occur when a user's form of payment fails, account for over a third of all cancellations. The new recovery performance cards in the cancellation report helps you understand how effectively you are recovering users with grace period and account hold, and the day the subscriptions were recovered to help you evaluate the effectiveness of recovery messaging.

    Example account hold performance recovery card in the Play Console. Source: Google Internal Data.

    Make sure you've set up grace periods and account hold for your apps! We've seen that developers who use both grace period and account hold see more than a 3x increase in decline recovery rate from 10% to 33%. Discover more information on grace period and account hold.

    You can find the subscription retention and cancellation reports linked from the bottom of the Subscriptions page, in the Financial reports section of the Play Console. If you don't have access to financial reporting, ask your developer account owner for permission to view financial data.

    Example account hold performance recovery card in the Play Console. Source: Google Internal Data.

    We hope this new reporting gives you new insights to optimize your subscription business, and we look forward to sharing more with you at Google I/O in May.

    How useful did you find this blog post?

    April 11th 2019, 1:00 pm

    Google Play Instant feature plugin deprecation

    Android Developers Blog

    Posted by Miguel Montemayor and Diana García Ríos

    As of Android Gradle plugin 3.4.0 (included in Android Studio 3.4), we are starting the deprecation process of the feature plugin (com.android.feature) and instant app plugin (com.android.instantapp) as a way to build your instant app. When building your app, you will receive a warning flagging com.android.feature as deprecated. If you have an existing instant app built with the feature plugin, migrate your existing app to an instant-enabled app bundle as soon as possible.

    What is changing?

    Last year, we introduced Android App Bundles—a new way to build and publish your Android apps. App bundles simplify delivering optimized APKs, including instant delivery, by unifying uploads into a single artifact. Google Play handles distribution by serving the correct APKs to your instant and installed app users—this is called Dynamic Delivery. To learn more about app bundles, visit the documentation site.

    Dynamic Delivery is based on the idea of shipping dynamic features (com.android.dynamic-feature) to app users when they need them and only if they need them. There are currently three delivery types, based on the different values you will give the dist:module tag attributes on the dynamic feature module’s manifest file:

        <dist:module
           dist:instant="..."
           dist:onDemand="..."
           ...
        </dist:module>
    
    dist:instant="false" dist:instant="true"
    dist:onDemand="false" Dynamic feature delivered at install time Dynamic feature delivered instantly and at install time
    dist:onDemand="true" Dynamic feature delivered on demand (beta) N/A

    By migrating your instant app to an instant-enabled app bundle with dynamic features, you will be ready to leverage the full power of this new paradigm and you will be able to simplify your app’s modular design.

    The migration

    Previously, instant apps required creating a feature module that acted as the base module for your app. This base feature module contained the shared code and resources for both your instant and installed application. The rest of your codebase was comprised of:

    With the new app bundle implementation, your base feature module takes the role as your app module (com.android.application), hosting the code and resources common to all features (instant and installed). You organize additional, modular features as one of three types of dynamic feature modules, based on when you want to deliver them to the user. The instant app module disappears, since the dist:instant attributes in the manifest are enough to identify which features will be included as part of the instant experience.

    If you don’t have an instant experience added to your app and you’d like to create one, use Android Studio 3.3+ to create an instant-enabled app bundle.

    April 9th 2019, 2:49 pm

    ML Kit expands into NLP with Language Identification and Smart Reply

    Android Developers Blog

    Posted by Christiaan Prins and Max Gubin

    Today we are announcing the release of two new features to ML Kit: Language Identification and Smart Reply.

    You might notice that both of these features are different from our existing APIs that were all focused on image/video processing. Our goal with ML Kit is to offer powerful but simple-to-use APIs to leverage the power of ML, independent of the domain. As such, we are excited to expand ML Kit with solutions for Natural Language Processing (NLP)!

    NLP is a category of ML that deals with analyzing and generating text, speech, and other kinds of natural language data. We're excited to start out with two APIs: one that helps you identify the language of text, and one that generates reply suggestions in chat applications. Both of these features work fully on-device and are available on the latest version of the ML Kit SDK, on iOS (9.0 and higher) and Android (4.1 and higher).

    Generate reply suggestions based on previous messages

    A new feature popping up in messaging apps is to provide the user with a selection of suggested responses, either as actions on a notification or inside the app itself. This can really help a user to quickly respond when they are busy or a handy way to initiate a longer message.

    With the new Smart Reply API you can now quickly achieve the same in your own apps. The API provides suggestions based on the last 10 messages in a conversation, although it still works if only one previous message is available. It is a stateless API that fully runs on-device, so we don't keep message history in memory nor send it to a server.

    textPlus app providing response suggestions using Smart Reply

    We have worked closely with partners like textPlus to ensure Smart Reply is ready for prime time and they have now implemented in-app response suggestions with the latest version of their app (screenshot above).

    Adding Smart Reply to your own app is done with a simple function call (using Swift in this example):

    let smartReply = NaturalLanguage.naturalLanguage().smartReply()
    smartReply.suggestReplies(for: conversation) { result, error in
        guard error == nil, let result = result else {
            return
        }
        if (result.status == .success) {
            for suggestion in result.suggestions {
                print("Suggested reply: \(suggestion.text)")
            }
        }
    }

    After you initialize a Smart Reply instance, call suggestReplies with a list of recent messages. The callback provides the result which contains a list of suggestions.

    For details on how to use the Smart Reply API, check out the documentation.

    Tell me more ...

    Although as a developer, you can just pick up this new API and easily get it integrated in your app, it may be interesting to reveal a bit on how it works under the hood. At the core of Smart Reply is a machine-learned model that is executed using TensorFlow Lite and has a state-of-the-art modern architecture based on SentencePiece text encoding[1] and Transformer[2].

    However, as we realized when we started development of the API, the core suggestion model is not all that's needed to provide a solution that developers can use in their apps. For example, we added a model to detect sensitive topics, so that we avoid making suggestions in response to profanity or in cases of personal tragedy/hardship. Also, we included language identification, to ensure we do not provide suggestions for languages the core model is not trained on. The Smart Reply feature is launching with English support first.

    Identify the language of a piece of text

    The language of a given text string is a subtle but helpful piece of information. A lot of apps have functionality with a dependency on the language: you can think of features like spell checking, text translation or Smart Reply. Rather than asking a user to specify the language they use, you can use our new Language Identification API.

    ML Kit recognizes text in 103 different languages and typically only requires a few words to make an accurate determination. It is fast as well, typically providing a response within 1 to 2 ms across iOS and Android phones.

    Similar to the Smart Reply API, you can identify the language with a function call (using Swift in this example):

    let languageId = NaturalLanguage.naturalLanguage().languageIdentification()
    languageId.identifyLanguage(for: "¿Cómo estás?") { languageCode, error in
      guard error == nil, let languageCode = languageCode else {
        print("Failed to identify language with error: \(error!)")
        return
      }
    
      print("Identified Language: \(languageCode)")
    }

    The identifyLanguage functions takes a piece of a text and its callback provides a BCP-47 language code. If no language can be confidently recognized, ML Kit returns a code of und for undetermined. The Language Identification API can also provide a list of possible languages and their confidence values.

    For details on how to use the Language Identification API, check out the documentation.

    Get started today

    We're really excited to expand ML Kit to include Natural Language APIs. Give the two new NLP APIs a spin today and let us know what you think! You can always reach us in our Firebase Talk Google Group.

    As ML Kit grows we look forward to adding more APIs and categories that enables you to provide smarter experiences for your users. With that, please keep an eye out for some exciting ML Kit announcements at Google I/O.

    April 5th 2019, 1:06 pm

    Android Q Beta 2 update

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    A few weeks ago we Introduced Android Q Beta, a first look at the next version of Android. Along with new privacy features for users, Android Q adds new capabilities for developers - like enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 graphics, and more.

    Android's program of early, open previews is driven by our core philosophy of openness, and collaboration with our community. Your feedback since Beta 1 proves yet again the value of that openness - it's been loud, clear, and incredibly valuable. You've sent us thousands of bug reports, giving us insights and directional feedback, changing our plans in ways that make the platform better for users and developers. We're taking your feedback to heart, so please stay tuned. We're fortunate to have such a passionate community helping to guide Android Q toward the final product later this year.

    Today we're releasing Android Q Beta 2 and an updated SDK for developers. It includes the latest bug fixes, optimizations, and API updates for Android Q, along with the April 2019 security patches. You'll also notice isolated storage becoming more prominent as we look for your wider testing and feedback to help us refine that feature.

    We're still in early Beta with Android Q so expect rough edges! Before you install, check out the Known Issues. In particular, expect the usual transitional issues with apps that we typically see during early Betas as developers get their app updates ready.

    You can get Beta 2 today by enrolling any Pixel device here. If you're already enrolled, watch for the Beta 2 update coming soon. Stay tuned for more at Google I/O in May.

    What's new in Beta 2?

    Privacy features for testing and feedback

    As we shared at Beta 1, we're making significant privacy investments in Android Q in addition to the work we've done in previous releases. Our goals are improving transparency, giving users more control, and further securing personal data across platform and apps. We know that to reach those goals, we need to partner with you, our app developers. We realize that supporting these features is an investment for you too, so we'll do everything we can to minimize the impact on your apps.

    For features like Scoped Storage, we're sharing our plans as early as possible to give you more time to test and give us your input. To generate broader feedback, we've also enabled Scoped Storage for new app installs in Beta 2, so you can more easily see what is affected.

    With Scoped Storage, apps can use their private sandbox without permission, but they need new permissions to access shared collections for photos, videos and audio. Apps using files in shared collections -- for example, photo and video galleries and pickers, media browsing, and document storage -- may behave differently under Scoped Storage.

    We recommend getting started with Scoped Storage soon -- the developer guide has details on how to handle key use-cases. For testing, make sure to enable Scoped Storage for your app using the adb command. If you discover that your app has a use-case that's not supported by Scoped Storage, please let us know by taking this short survey. We appreciate the great feedback you've given us already, it's a big help as we move forward with the development of this feature.

    Bubbles: a new way to multitask

    In Android Q we're adding platform support for bubbles, a new way for users to multitask and re-engage with your apps. Various apps have already built similar interactions from the ground up, and we're excited to bring the best from those into the platform, while helping to make interactions consistent, safeguard user privacy, reduce development time, and drive innovation.

    Bubbles will let users multitask as they move between activities.

    Bubbles help users prioritize information and take action deep within another app, while maintaining their current context. They also let users carry an app's functionality around with them as they move between activities on their device.

    Bubbles are great for messaging because they let users keep important conversations within easy reach. They also provide a convenient view over ongoing tasks and updates, like phone calls or arrival times. They can provide quick access to portable UI like notes or translations, and can be visual reminders of tasks too.

    We've built bubbles on top of Android's notification system to provide a familiar and easy to use API for developers. To send a bubble through a notification you need to add a BubbleMetadata by calling setBubbleMetadata. Within the metadata you can provide the Activity to display as content within the bubble, along with an icon (disabled in beta 2) and associated person.

    We're just getting started with bubbles, but please give them a try and let us know what you think. You can find a sample implementation here.

    Foldables emulator

    As the ecosystem moves quickly toward foldable devices, new use-cases are opening up for your apps to take advantage of these new screens. With Beta 2, you can build for foldable devices through Android Q enhanced platform support, combined with a new foldable device emulator, available as an Android Virtual device in Android Studio 3.5 available in the canary release channel.

    7.3" Foldable AVD switches between the folded and unfolded states

    On the platform side, we've made a number of improvements in onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. You can read more in the foldables developer guide.

    To set up a runtime environment for your app, you can now configure a foldable emulator as a virtual device (AVD) in Android Studio. The foldable AVD is a reference device that lets you test with standard hardware configurations, behaviors, and states, as will be used by our device manufacturer partners. To ensure compatibility, the AVD meets CTS/GTS requirements and models CDD compliance. It supports runtime configuration change, multi-resume and the new resizeableActivity behaviors.

    Use the canary release of Android Studio 3.5 to create a foldable virtual device to support either of two hardware configurations 7.3" (4.6" folded) and 8" (6.6" folded) with Beta 2. In each configuration, the emulator gives you on-screen controls to trigger fold/unfold, change orientation, and quick actions.

    Android Studio - AVD Manager: Foldable Device Setup

    Try your app on the foldable emulator today by downloading the canary release of Android Studio 3.5 and setting up a foldable AVD that uses the Android Q Beta 2 system image.

    Improved sharesheet

    Following on the initial Sharing Shortcuts APIs in Beta 1, you can now offer a preview of the content being shared by providing an EXTRA_TITLE extra in the Intent for the title, or by setting the Intent's ClipData for a thumbnail image. See the updated sample application for the implementation details.

    Directional, zoomable microphones

    Android Q Beta 2 gives apps more control over audio capture through a new MicrophoneDirection API. You can use the API to specify a preferred direction of the microphone when taking an audio recording. For example, when the user is taking a "selfie" video, you can request the front-facing microphone for audio recording (if it exists) by calling setMicrophoneDirection(MIC_DIRECTION_FRONT).

    Additionally, this API introduces a standardized way of controlling zoomable microphones, allowing your app to have control over the recording field dimension using setMicrophoneFieldDimension(float).

    Compatibility through public APIs

    In Android Q we're continuing our long-term effort to move apps toward only using public APIs. We introduced most of the new restrictions in Beta 1, and we're making a few minor updates to those lists in Beta 2 to minimize impact on apps. Our goal is to provide public alternative APIs for valid use-cases before restricting access, so if an interface that you currently use in Android 9 Pie is now restricted, you should request a new public API for that interface.

    Get started with Android Q Beta

    Today's update includes Beta 2 system images for all Pixel devices and the Android Emulator, as well updated SDK and tools for developers. These give you everything you need to get started testing your apps on the new platform and build with the latest APIs.

    First, make your app compatible and give your users a seamless transition to Android Q, including your users currently participating in the Android Beta program. To get started, just install your current app from Google Play onto a device or emulator running Beta 2 and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. See the migration guide for steps and a recommended timeline.

    With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you'll want to test against scoped storage, new location permissions, restrictions on background Activity starts, and restrictions on device identifiers. See the privacy checklist as a starting point.

    Next, update your app's targetSdkVersion to 'Q' as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.

    Explore the new features and APIs

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

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

    How do I get Beta 2?

    It's easy - you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we're supporting all three generations of Pixel -- Pixel 3, Pixel 2, and even the original Pixel!). If you're already enrolled, you'll receive the update to Beta 2 soon, no action is needed on your part. Downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

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

    April 3rd 2019, 1:16 pm

    Improving app performance with ART optimizing profiles in the cloud

    Android Developers Blog

    Posted by Calin Juravle, Software Engineer

    In Android Pie we launched ART optimizing profiles in Play Cloud, a new optimization feature that greatly improves the application startup time after a new install or update. On average, we have observed that apps start 15% faster (cold startup) across a variety of devices. Some hero cases even show 30%+ faster startup times. One of the most important aspects is that users get this for free, without any effort from their side or from developers!

    Source: Google internal data

    ART optimizing profiles in Play Cloud

    The feature builds on previous Profile Guided Optimization (PGO) work, which was introduced in Android 7.0 Nougat. PGO allows the Android Runtime to help improve an app's performance by building a profile of the app's most important hot code and focusing its optimization effort on it. This leads to big improvements while reducing the traditional memory and storage impact of a fully compiled app. However, it relies on the device to optimize apps based on these code profiles in idle maintenance mode, which means it could be a few days before a user sees the benefits - something we aimed to improve.

    Source: Google internal data

    ART optimizing profiles in Play Cloud leverages the power of Android Play to bring all PGO benefits at install/update time: most users can get great performance without waiting!

    The idea relies on two key observations:

    1. Apps usually have many commonly used code paths (hot code) between a multitude of users and devices, e.g. classes used during startup or critical user paths. This can often be discovered by aggregating a few hundred data points.
    2. App developers often roll-out their apps incrementally, starting with alpha/beta channels before expanding to a wider audience. Even if there isn't an alpha/beta set, there is often a ramp-up of users to a new version of an app.

    This means we can use the initial rollout of an app to bootstrap the performance for the rest of users. ART analyzes what part of the application code is worth optimizing on the initial devices, and then uploads the data to Play Cloud, which will build a core-aggregated code profile (containing information relevant to all devices). Once there is enough information, the code profile gets published and installed alongside the app's APKs.

    On a device, the code profile acts as a seed, enabling efficient profile-guided optimization at install time. These optimizations help improve cold startup time and steady state performance, all without an app developer needing to write a single line of code.

    Step 1: Building the code profile

    One of the main goals is to build a quality, stable code profile out of aggregated & anonymized data as fast as possible (to maximize the number of users that can benefit), while also making sure we have enough data to accurately optimize an app's performance. Sampling too much data takes up more bandwidth and time at installation. In addition, the longer we take to build the code profile, the fewer users get the benefits. Sampling too little data, and the code profile won't have enough information on what to properly optimize in order to make a difference.

    The outcome of the aggregation is what we call a core code profile, which only contains anonymous data about the code that is frequently seen across a random sample of sessions per device. We remove outliers to ensure we focus on the code that matters for most users.

    Experiments show that the most commonly used code paths can be calculated very quickly, over a small amount of time. That means we are able to build a code profile fast enough that the majority of users will benefit from.

    *Data averaged from Google apps, Source: Google internal data

    Step 2: Installing the code profile

    In Android 9.0 Pie, we introduced a new type of installation artifact: dex metadata files. Similar to the APKs, the dex metadata files are regular archives that contain data about how the APK should be optimized - like the core code profiles that have been built in the cloud. A key difference is that the dex metadata are managed solely by the platform and the app stores, and are not directly visible to developers.

    There is also built-in support for App Bundles / Google Play Dynamic Delivery: without any developer intervention, all the app's feature splits are optimized.

    Step 3: Using the code profiles to optimize performance

    To understand how these code profiles achieve better performance, we need to look at their structure. Code profiles contain information about:

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

    Improvements & Observations

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

    A very interesting observation is that, on average, ART profiles about 20% of the application methods (even less if we count the actual size of the code). For some apps, the profile covers only 2% of the code while for some the number goes up to 60%.

    Source: Google internal data

    Why is this an important observation? It means that the runtime has not seen a lot of the application code, and is thus not investing in the code's optimization. While there are a lot of valid use-cases where the code will not be executed (e.g. error handling or backwards compatibility code), this may also be due to unused features or unnecessary code. The skew distribution is a strong signal that the latter could play an important role in further optimizations (e.g. lowering APK size by removing unneeded dex bytecode).

    Future Development

    We're excited about the improvements that ART optimizing profiles has shown, and we'll be growing this concept more in the future. Building a profile of code per app opens opportunities for even more application improvements. Data can be used by developers to improve the app based on what's relevant and important for their end users. Using the information collected in Profiles, code can be re-organized or trimmed for better efficiency. Developers can potentially use App Bundles to split their features based on their use and avoid shipping unnecessary code to their users. We've already seen great improvements in app startup time, and hope to see additional benefits coming from profiles to make developer's lives easier while providing better experiences for our users.

    April 1st 2019, 1:27 pm

    AOSP Application Updates

    Android Developers Blog

    Posted by Raman Tenneti, AOSP Software Engineer and Ally Sillins, AOSP Program Manager

    When we started the Android Open Source Project (AOSP) 10 years ago, we included some basic applications in the AOSP build for three main purposes:

    1. to provide a usable set of applications for someone building an Android device from our AOSP
    2. to serve as a demonstration for the nascent Android app developer community, showcasing how they should build some of these applications
    3. to, as part of the platform, provide functionality to other Android applications that would interact with them through the standard Android APIs like the common intents

    However, as the Android ecosystem has matured over time, we've noticed a healthy growth of alternative applications - both as open source and proprietary implementations - developed by the developer community. These alternative applications are not only capable to serve the first two purposes, but often times showcase richer set of features demonstrating the power of Android. Late last year, we began to clean up these applications in AOSP to focus more effectively on the last purpose — their role to provide functionality to other Android applications as part of the platform.

    To date, the following 3 apps have been cleaned up: Music, Calendar, and Calculator. See below for details on these updates. Going forward, you can expect to see similar efforts with the other applications in the AOSP repository.

    As always, we're excited to hear your feedback on the developer website or through our AOSP forum.

    Music Application

    AOSP's Music app can now playback music, one file at a time, and exposes itself as an intent handler for the android.media.browse.MediaBrowserService. The app has controls to play and pause, and a slider moving forward and backward. Features removed include: Music Icon, Artists, Albums, Songs, Playlists, Search, and Settings.

    Calendar Application

    AOSP's Calendar app now exposes itself as an intent handler for the calendar events. New events cannot be created and existing events cannot be edited or deleted. The following features have been deleted: support for multiple accounts, reminders and settings. In addition, some features remain that are not needed for providing a part of the platform functionality: views for day, week, and month. This app may be further simplified in the future.

    Calculator App

    The calculator application is a standalone app, and does not function as part of the platform and hence has been removed from the AOSP build. However, the application will continue to exist as an open source project separately.

    March 28th 2019, 2:06 pm

    Changes to the Google Play Developer API

    Android Developers Blog

    Posted by Vlad Radu, Product Manager and Nicholas Lativy, Software Engineer

    The Google Play Developer API allows you to automate your in-app billing and app distribution workflows. At Google I/O '18, we introduced version 3 of the API, which allows you to transactionally start, manage, and halt staged releases on all tracks, through production, open testing, closed testing (including the new additional testing tracks), and internal testing.

    Updating from versions 1 and 2 to the latest version 3

    In addition to these new features, version 3 also supports all the functionality of previous versions, improving and simplifying how you manage workflows. Starting December 1, 2019, versions 1 and 2 of the Google Play Developer API will no longer be available so you need to update to version 3 ahead of this date.

    Migrating to version 3

    If you use the Google Play API client libraries (available for Java, Python, and other popular languages), we recommend upgrading to their latest versions, which already support version 3 of the API. In many cases, changing the version of the client library should be all that is necessary. However, you may also need to update specific code references to the version of the API in use - see examples in our samples repository.

    Many third-party plugins are already using version 3 of the API. If you use a plugin that does not support version 3 you will need to contact the maintainer. You will start seeing warnings in the Google Play Console in mid-May if we detect that your app is still using version 1 and version 2 endpoints.

    For version 1 users

    If you currently use version 1 of the API, you may also need to link your API project to the Google Console before converting to version 3. Learn more about this process.

    Going forward

    We hope you benefit from the new features of the Google Play Developer Publishing API and are looking forward to your continued feedback to help us improve the publishing experience on Google Play.

    How useful did you find this blog post?

    March 26th 2019, 7:36 pm

    The latest Android App Bundle updates including the additional languages API

    Android Developers Blog

    Posted by Wojtek Kaliciński, Developer Advocate, Android

    Last year, we launched Android App Bundles and Google Play's Dynamic Delivery to introduce modular development, reduce app size and streamline the release process. Since then, we've seen developers quickly adopt this new app model in over 60,000 production apps. We've been excited to see developers experience significant app size savings and reductions in the time needed to manage each release, and have documented these benefits in case studies with Duolingo and redBus.

    Thank you to everyone who took the time to give us feedback on our initial launch. We're always open to new ideas, and today, we're happy to announce some new improvements based on your suggestions:

    Additional languages API

    When you adopt the Android App Bundle as the publishing format for your app, Google Play is able to optimize the installation by delivering only the language resources that match the device's system locales. If a user changes the system locale after the app is installed, Play automatically downloads the required resources.

    Some developers choose to decouple the app's display language from the system locale by adding an in-app language switcher. With the latest release of the Play Core library (version 1.4.0), we're introducing a new additional languages API that makes it possible to build in-app language pickers while retaining the full benefits of smaller installs provided by using app bundles.

    With the additional languages API, apps can now request the Play Store to install resources for a new language configuration on demand and immediately start using it.

    Get a list of installed languages

    The app can get a list of languages that are already installed using the SplitInstallManager#getInstalledLanguages() method.

    val splitInstallManager = SplitInstallManagerFactory.create(context)
    val langs: Set<String> = splitInstallManager.installedLanguages

    Requesting additional languages

    Requesting an additional language is similar to requesting an on demand module. You can do this by specifying a language in the request through SplitInstallRequest.Builder#addLanguage(java.util.Locale).

    val installRequestBuilder = SplitInstallRequest.newBuilder()
    installRequestBuilder.addLanguage(Locale.forLanguageTag("pl"))
    splitInstallManager.startInstall(installRequestBuilder.build())

    The app can also monitor install success with callbacks and monitor the download state with a listener, just like when requesting an on demand module.

    Remember to handle the SplitInstallSessionStatus.REQUIRES_USER_CONFIRMATION state. Please note that there was an API change in a recent Play Core release, which means you should use the new SplitInstallManager#startConfirmationDialogForResult() together with Activity#onActivityResult(). The previous method of using SplitInstallSessionState#resolutionIntent() with startIntentSender() has been deprecated.

    Check out the updated Play Core Library documentation for more information on how to access the newly installed language resources in your activity.

    We've also updated our dynamic features sample on GitHub with the additional languages API, including how to store the user's language preference and apply it to your activities at startup.

    Please note that while the additional languages API is now available to all developers, on demand modules are in a closed beta for the time being. You can experiment with on demand modules in your internal, open, and closed test tracks, while we work with our partners to make sure this feature is ready for production apps.

    Instant-enabled App Bundle

    In Android Studio 3.3, we introduced a way to build app bundles that contain both the regular, installed version of your app as well as a Google Play Instant experience for modules marked with the dist:instant="true" attribute in their AndroidManifest.xml:

    <manifest ... xmlns:dist="http://schemas.android.com/apk/distribution">
        <dist:module dist:instant="true" />
        ...
    </manifest>

    Even though you could use a single project to generate the installed and instant versions of your app, up until now, developers were still required to use product flavors in order to build two separate app bundles and upload both to Play.

    We're happy to announce that we have now removed this restriction. It's now possible to upload a single, unified app bundle artifact, containing modules enabled for the instant experience. This functionality is now available for everyone.

    After you build an instant-enabled app bundle, upload it to any track on the Play Console, and you'll be able to select it when creating a new instant app release. This also means that the installed and instant versions of your app no longer need different version codes, which will simplify the release workflow.

    Opt in to app signing by Google Play

    You need to enable app signing by Google Play to publish your app using an Android App Bundle and automatically benefit from Dynamic Delivery optimizations. It is also a more secure way to manage your signing key, which we recommend to everyone, even if you want to keep publishing regular APKs for now.

    Based on your feedback, we've revamped the sign-up flow for new apps to make it easier to initialize the key you want to use for signing your app.

    Now developers can explicitly choose to upload their existing key without needing to upload a self-signed artifact first. You can also choose to start with a key generated by Google Play, so that the key used to locally sign your app bundle can become your upload key.

    Read more about the new flow.

    Permanent uninstallation of install time modules

    We have now added the ability to permanently uninstall dynamic feature modules that are included in your app's initial install.


    This is a behavior change, which means you can now call the existing SplitInstallManager#deferredUninstall() API on modules that set onDemand="false". The module will be permanently uninstalled, even when the app is updated.

    This opens up new possibilities for developers to further reduce the installed app size. For example, you can now uninstall a heavy sign-up module or any other onboarding content once the user completes it. If the user navigates to a section of your app that has been uninstalled, you can reinstall it using the standard on demand modules install API.

    We hope you enjoy these improvements and test them out in your apps. Continue to share your feedback as we work to make these features even more useful for you!

    How useful did you find this blog post?

    March 21st 2019, 6:13 pm

    Google Mobile Developer Day at Game Developers Conference 2019

    Android Developers Blog

    Posted by Kacey Fahey, Developer Marketing, Google Play & Android

    We're excited to host the Google Mobile Developer Day at Game Developers Conference 2019. We are taking this opportunity to share best practices and our plans to help your games businesses, which are fuelling incredible growth in the global mobile games market. According to Newzoo, mobile games revenue is projected to account for nearly 60% of global games revenue by 2021. The drivers of this growth come in many forms, including more developers building great games, new game styles blurring the lines of traditional genres, and the explosion of gaming in emerging markets - most notably in India.

    Image Source: GamesIndustry.biz

    To support your growth, Google is focused on improving the game development experience on Android. We are investing in tools to give you better insights into what is happening on devices, as well as in people and teams to address your feedback about the development process, graphics, multiplayer experiences, and more.

    We have some great updates and new tools to improve game discovery and monetization on Google Play, which we also shared today during our Mobile Developer Day:

    Pre-registration now in general availability

    Starting today, we are launching pre-registration for general availability. Set up a pre-registration campaign in the Google Play Console and start marketing your games to build awareness before launch. Users who pre-register receive a notification at launch, which helps increase day one installs.

    Google Play Instant gaining adoption

    We have seen strong adoption of Google Play Instant with 3x growth in the number of instant games and 5x growth in the number of instant sessions over the last six months. Instant experiences allow players to tap the 'Try Now' button on your store listing page and go straight to a demo experience in a matter of seconds, without installing. Now, they're even easier to build with Cocos and Unity plug-ins and an expanded implementation partner program. Discover the latest updates on Google Play Instant.

    Android App Bundles momentum and new large download size threshold

    Over 60K apps and games on Google Play are now using the Android App Bundle publishing format, which is supported in Android Studio, Unity, and Cocos Creator. The app bundle uses Google Play's Dynamic Delivery to deliver a smaller, optimized APK containing only the resources needed for a specific device.

    To better support high quality game experiences and reflect improved devices, we've also increased the size limit for APKs generated from app bundles to 150MB and raised the threshold for large download user warnings on the Google Play Store to 150MB, from 100MB.

    Improved tools in the Google Play Console

    Store listing experiments let you A/B test changes to your store listing on actual Play Store visitors. We recently rolled out improvements, introducing two new metrics - first time installers and D1 retained users - to more accurately reflect the performance of your store listings. These two new metrics are now reported with hourly intervals and are available via email notifications, letting you see results faster and track performance better.

    Country targeted store listings allow you to tailor your app's store listing to appeal to users in different countries. You can customize the app title, icon, descriptions and graphic assets, allowing you to better appeal to users in specific target markets. For example, you can now tailor your store listing with different versions of the English language for users in India versus the United States.

    Rewarded ads give players the choice to watch an advertisement in exchange for in-app items. With rewarded ads in Google Play, you can now create and manage rewarded ads through the Google Play Console. No additional SDK integrations are required.

    We hope you try some of these new tools and keep sharing ideas so we can make Android and Google Play a better place to grow your business. We are committed to continue improving the platform and building tools that better serve the gaming community.

    Get started today by visiting two new resources, a hub for developers interested in creating games on Android and games.withgoogle.com, for developers looking to connect and scale their business across Google. Many of these updates and resources come from community suggestions, so sign up for our monthly newsletter to stay informed.

    How useful did you find this blog post?

    March 18th 2019, 1:36 pm

    Introducing a new Google Play app and game icon specification

    Android Developers Blog


    Posted by Steve Suppe, Product Manager, Google Play
    As part of our focus and dedication to improving the Google Play Store experience for our users, we are introducing new design specifications for your app icons.

    Left to right: original icon, new icon (example), original icon in legacy mode


    As of early April, you will be able to upload new icons to the Google Play Console and confirm you are compliant with the new specification. Original icons are still accepted in the Google Play Store during this time. As of May 1st, developers will no longer be able to upload icons in the Play Console which do not meet the new specifications, although existing original icons in the Google Play Store during this period can remain unchanged.
    By June 24, we require you to:
    1. Update your icon to the new specification.
    2. Upload your icon to Play Console.
    3. Confirm in Play Console that your icon meets the new specification.
    We highly recommend that you update your icons and confirm they meet the new specification as soon as possible to ensure that you provide the highest quality experience for users.

    What exactly is changing?

    Timelines Changes
    Early April You can start uploading your new icons in Play Console and confirm they meet the new specification.
    • Original icons will continue to display correctly in Google Play.
    • New icons will display correctly in Google Play.
    May 1st Any new icons uploaded in Play Console must be confirmed as meeting the new specification.
    • Original icons will continue to display correctly in Google Play.
    • New icons will display correctly in Google Play.
    June 24th Original icons are converted to "legacy mode." You must confirm that any new icons uploaded in Play Console meet the new specification.
    • Original icons will be automatically converted to "legacy mode" icons.
    • New icons render correctly in the Google Play Store.

    These updates will help us all provide a more unified and consistent look and feel for Google Play, allowing us to better showcase your apps and games and provide a higher quality user experience.
    We will be keeping you up-to-date with these changes in the coming months - so look out for more updates. In the meantime, check out our new icon design specifications.
    How useful did you find this blog post?


    March 15th 2019, 1:15 pm

    Giving users more control over their location data

    Android Developers Blog

    Posted by Jen Chai, Product Manager

    Location data can deliver amazing, rich mobile experiences for users on Android such as finding a restaurant nearby, tracking the distance of a run, and getting turn-by-turn directions as you drive. Location is also one of the most sensitive types of personal information for a user. We want to give users simple, easy-to-understand controls for what data they are providing to apps, and yesterday, we announced in Android Q that we are giving users more control over location permissions. We are delighted by the innovative location experiences you provide to users through your apps, and we want to make this transition as straightforward for you as possible. This post dives deeper into the location permission changes in Q, what it may mean for your app, and how to get started with any updates needed.

    Previously, a user had a single control to allow or deny an app access to device location, which covered location usage by the app both while it was in use and while it wasn't. Starting in Android Q, users have a new option to give an app access to location only when the app is being used; in other words, when the app is in the foreground. This means users will have a choice of three options for providing location to an app:

    Some apps or features within an app may only need location while the app is being used. For example, if a feature allows a user to search for a restaurant nearby, the app only needs to understand the user's location when the user opens the app to search for a restaurant.

    However, some apps may need location even when the app is not in use. For example, an app that automatically tracks the mileage you drive for tax filing, without requiring you to interact with the app.

    The new location control allows users to decide when device location data is provided to an app and prevents an app from getting location data that it may not need. Users will see this new option in the same permissions dialog that is presented today when an app requests access to location. This permission can also be changed at any time for any app from Settings-> Location-> App permission.

    Here's how to get started

    We know these updates may impact your apps. We respect our developer community, and our goal is to approach any change like this very carefully. We want to support you as much as we can by (1) releasing developer-impacting features in the first Q Beta to give you as much time as possible to make any updates needed in your apps and (2) providing detailed information in follow-up posts like this one as well as in the developer guides and privacy checklist. Please let us know if there are ways we can make the guides more helpful!

    If your app has a feature requiring "all the time" permission, you'll need to add the new ACCESS_BACKGROUND_LOCATION permission to your manifest file when you target Android Q. If your app targets Android 9 (API level 28) or lower, the ACCESS_BACKGROUND_LOCATION permission will be automatically added for you by the system if you request either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. A user can decide to provide or remove these location permissions at any time through Settings. To maintain a good user experience, design your app to gracefully handle when your app doesn't have background location permission or when it doesn't have any access to location.

    Users will also be more likely to grant the location permission if they clearly understand why your app needs it. Consider asking for the location permission from users in context, when the user is turning on or interacting with a feature that requires it, such as when they are searching for something nearby. In addition, only ask for the level of access required for that feature. In other words, don't ask for "all the time" permission if the feature only requires "while in use" permission.

    To learn more, read the developer guide on how to handle the new location controls.

    March 14th 2019, 3:13 pm

    Android Jetpack Navigation Stable Release

    Android Developers Blog

    Posted by Ian Lake, Software Engineering Lead & Jisha Abubaker, Product Manager

    Cohesive tooling and guidance for implementing predictable in-app navigation

    Today we're happy to announce the stable release of the Android Jetpack Navigation component.

    The Jetpack Navigation component's suite of libraries, tooling and guidance provides a robust, complete navigation framework, freeing you from the challenges of implementing navigation yourself and giving you certainty that all edge cases are handled correctly.

    With the Jetpack Navigation component you can:

    The Jetpack Navigation component adheres to the Principles of Navigation, providing consistent and predictable navigation no matter how simple or complex your app may be.

    Simplify navigation code with Jetpack Navigation Libraries

    The Jetpack Navigation component provides a framework for in-app navigation that makes it possible to abstract away the implementation details, keeping your app code free of navigation boilerplate.

    To get started with the Jetpack Navigation component in your project, add the Navigation artifacts available on Google's Maven repository in Java or Kotlin to your app's build.gradle file:

     dependencies {
        def nav_version = 2.0.0
    
        // Java
        implementation "androidx.navigation:navigation-fragment:$nav_version"
        implementation "androidx.navigation:navigation-ui:$nav_version"
    
        // Kotlin KTX 
        implementation "androidx.navigation:navigation-fragment-ktx:$nav_version"
        implementation "androidx.navigation:navigation-ui-ktx:$nav_version"
      }

    Note: If you have not yet migrated to androidx.*, the Jetpack Navigation stable component libraries are also available as android.arch.* artifacts in version 1.0.0.

    navigation-runtime : This core library powers the navigation graph, which provides the structure of your in-app navigation: the screens or destinations that make up your app and the actions that link them. You can control how you navigate to destinations with a simple navigate() call. These destinations may be fragments, activities or custom destinations.

    navigation-fragment: This library builds upon navigation-runtime and provides out-of-the-box support for fragments as destinations. With this library, fragment transactions are now handled for you automatically.

    navigation-ui: This library allows you to easily add navigation drawers, menus and bottom navigation to your app consistent with the Material Design guidelines.

    Each of these libraries provide an Android KTX artifact with the -ktx suffix that builds upon the Java API, taking advantage of Kotlin-specific language features.

    Tools to help you build predictable navigation workflows

    Available in Android Studio 3.3 and above, the Navigation Editor lets you visually create your navigation graph , allowing you to manage user journeys within your app.

    With integration into the manifest merger tool, Android Studio can automatically generate the intent filters necessary to enable deep linking to a specific screen in your app. With this feature, you can associate URLs with any screen of your app by simply setting an attribute on the navigation destination.

    Navigation often requires passing data from one screen to another. For example, your list screen may pass an item ID to a details screen. Many of the runtime exceptions during navigation have been attributed to a lack of type safety guarantees as you pass arguments. These exceptions are hard to replicate and debug. Learn how you can provide compile time type safety with the Safe Args Gradle Plugin.

    Guidance to get it right on the first try

    Check out our brand new set of developer guides that encompass best practices to help you implement navigation correctly:

    What developers say

    Here's what Emery Coxe, Android Lead @ HomeAway, has to say about the Jetpack Navigation component :

    "The Navigation library is well-designed and fully configurable, allowing us to integrate the library according to our specific needs.

    With the Navigation Library, we refactored our legacy navigation drawer to support a dynamic, runtime-based configuration using custom views. It allowed us to add / remove new screens to the top-level experience of our app without creating any interdependencies between discreetly packaged modules.

    We were also able to get rid of all anti-patterns in our app around top-level navigation, removing explicit casts and hardcoded assumptions to instead rely directly on Navigation. This library is a fundamental component of modern Android development, and we intend to adopt it more broadly across our app moving forward.

    Get started

    Check out the migration guide and the developer guide to learn how you can get started using the Jetpack Navigation component in your app. We also offer a hands-on codelab and a sample app.

    Also check out Google's Digital Wellbeing to see another real-world example of in-app navigation using the Android Jetpack Navigation component.

    Feedback

    Please continue to tell us about your experience with the Navigation component. If you have specific feedback on features or if you run into any issues, please file a bug via one of the following links:

    March 14th 2019, 1:13 pm

    Introducing Android Q Beta

    Android Developers Blog

    Posted by Dave Burke, VP of Engineering

    In 2019, mobile innovation is stronger than ever, with new technologies from 5G to edge to edge displays and even foldable screens. Android is right at the center of this innovation cycle, and thanks to the broad ecosystem of partners across billions of devices, Android's helping push the boundaries of hardware and software bringing new experiences and capabilities to users.

    As the mobile ecosystem evolves, Android is focused on helping users take advantage of the latest innovations, while making sure users' security and privacy are always a top priority. Building on top of efforts like Google Play Protect and runtime permissions, Android Q brings a number of additional privacy and security features for users, as well as enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 support, faster app startup, and more.

    Today we're releasing Beta 1 of Android Q for early adopters and a preview SDK for developers. You can get started with Beta 1 today by enrolling any Pixel device (including the original Pixel and Pixel XL, which we've extended support for by popular demand!) Please let us know what you think! Read on for a taste of what's in Android Q, and we'll see you at Google I/O in May when we'll have even more to share.

    Building on top of privacy protections in Android

    Android was designed with security and privacy at the center. As Android has matured, we've added a wide range of features to protect users, like file-based encryption, OS controls requiring apps to request permission before accessing sensitive resources, locking down camera/mic background access, lockdown mode, encrypted backups, Google Play Protect (which scans over 50 billion apps a day to identify potentially harmful apps and remove them), and much more. In Android Q, we've made even more enhancements to protect our users. Many of these enhancements are part of our work in Project Strobe.

    Giving users more control over location

    With Android Q, the OS helps users have more control over when apps can get location. As in prior versions of the OS, apps can only get location once the app has asked you for permission, and you have granted it.

    One thing that's particularly sensitive is apps' access to location while the app is not in use (in the background). Android Q enables users to give apps permission to see their location never, only when the app is in use (running), or all the time (when in the background).

    For example, an app asking for a user's location for food delivery makes sense and the user may want to grant it the ability to do that. But since the app may not need location outside of when it's currently in use, the user may not want to grant that access. Android Q now offers this greater level of control. Read the developer guide for details on how to adapt your app for this new control. Look for more user-centric improvements to come in upcoming Betas. At the same time, our goal is to be very sensitive to always give developers as much notice and support as possible with these changes.

    More privacy protections in Android Q

    Beyond changes to location, we're making further updates to ensure transparency, give users control, and secure personal data.

    In Android Q, the OS gives users even more control over apps, controlling access to shared files. Users will be able to control apps' access to the Photos and Videos or the Audio collections via new runtime permissions. For Downloads, apps must use the system file picker, which allows the user to decide which Download files the app can access. For developers, there are changes to how your apps can use shared areas on external storage. Make sure to read the Scoped Storage changes for details.

    We've also seen that users (and developers!) get upset when an app unexpectedly jumps into the foreground and takes over focus. To reduce these interruptions, Android Q will prevent apps from launching an Activity while in the background. If your app is in the background and needs to get the user's attention quickly -- such as for incoming calls or alarms -- you can use a high-priority notification and provide a full-screen intent. See the documentation for more information.

    We're limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to help you choose the right identifiers for your use case, and see the details here. We're also randomizing the device's MAC address when connected to different Wi-Fi networks by default -- a setting that was optional in Android 9 Pie.

    We are bringing these changes to you early, so you can have as much time as possible to prepare. We've also worked hard to provide developers detailed information up front, we recommend reviewing the detailed docs on the privacy changes and getting started with testing right away.

    New ways to engage users

    In Android Q, we're enabling new ways to bring users into your apps and streamlining the experience as they transition from other apps.

    Foldables and innovative new screens

    Foldable devices have opened up some innovative experiences and use-cases. To help your apps to take advantage of these and other large-screen devices, we've made a number of improvements in Android Q, including changes to onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. To you get started building and testing on these new devices, we've been hard at work updating the Android Emulator to support multiple-display type switching -- more details coming soon!

    Sharing shortcuts

    When a user wants to share content like a photo with someone in another app, the process should be fast. In Android Q we're making this quicker and easier with Sharing Shortcuts, which let users jump directly into another app to share content. Developers can publish share targets that launch a specific activity in their apps with content attached, and these are shown to users in the share UI. Because they're published in advance, the share UI can load instantly when launched.

    The Sharing Shortcuts mechanism is similar to how App Shortcuts works, so we've expanded the ShortcutInfo API to make the integration of both features easier. This new API is also supported in the new ShareTarget AndroidX library. This allows apps to use the new functionality, while allowing pre-Q devices to work using Direct Share. You can find an early sample app with source code here.

    Settings Panels

    You can now also show key system settings directly in the context of your app, through a new Settings Panel API, which takes advantage of the Slices feature that we introduced in Android 9 Pie.

    A settings panel is a floating UI that you invoke from your app to show system settings that users might need, such as internet connectivity, NFC, and audio volume. For example, a browser could display a panel with connectivity settings like Airplane Mode, Wi-Fi (including nearby networks), and Mobile Data. There's no need to leave the app; users can manage settings as needed from the panel. To display a settings panel, just fire an intent with one of the new Settings.Panel actions.

    Connectivity

    In Android Q, we've extended what your apps can do with Android's connectivity stack and added new connectivity APIs.

    Connectivity permissions, privacy, and security

    Most of our APIs for scanning networks already require COARSE location permission, but in Android Q, for Bluetooth, Cellular and Wi-Fi, we're increasing the protection around those APIs by requiring the FINE location permission instead. If your app only needs to make peer-to-peer connections or suggest networks, check out the improved Wi-Fi APIs below -- they simplify connections and do not require location permission.

    In addition to the randomized MAC addresses that Android Q provides when connected to different Wi-Fi networks, we're adding new Wi-Fi standard support, WP3 and OWE, to improve security for home and work networks as well as open/public networks.

    Improved peer-to-peer and internet connectivity

    In Android Q we refactored the Wi-Fi stack to improve privacy and performance, but also to improve common use-cases like managing IoT devices and suggesting internet connections -- without requiring the location permission.

    The network connection APIs make it easier to manage IoT devices over local Wi-Fi, for peer-to-peer functions like configuring, downloading, or printing. Apps initiate connection requests indirectly by specifying preferred SSIDs & BSSIDs as WiFiNetworkSpecifiers. The platform handles the Wi-Fi scanning itself and displays matching networks in a Wi-Fi Picker. When the user chooses, the platform sets up the connection automatically.

    The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity. Apps initiate connections indirectly by providing a ranked list of networks and credentials as WifiNetworkSuggestions. The platform will seamlessly connect based on past performance when in range of those networks.

    Wi-Fi performance mode

    You can now request adaptive Wi-Fi in Android Q by enabling high performance and low latency modes. These will be of great benefit where low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use-cases.

    To use the new performance modes, call WifiManager.WifiLock.createWifiLock() with WIFI_MODE_FULL_LOW_LATENCY or WIFI_MODE_FULL_HIGH_PERF. In these modes, the platform works with the device firmware to meet the requirement with lowest power consumption.

    Camera, media, graphics

    Dynamic depth format for photos

    Many cameras on mobile devices can simulate narrow depth of field by blurring the foreground or background relative to the subject. They capture depth metadata for various points in the image and apply a static blur to the image, after which they discard the depth metadata.

    Starting in Android Q, apps can request a Dynamic Depth image which consists of a JPEG, XMP metadata related to depth related elements, and a depth and confidence map embedded in the same file on devices that advertise support.

    Requesting a JPEG + Dynamic Depth image makes it possible for you to offer specialized blurs and bokeh options in your app. You can even use the data to create 3D images or support AR photography use-cases in the future. We're making Dynamic Depth an open format for the ecosystem, and we're working with our device-maker partners to make it available across devices running Android Q and later.

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

    New audio and video codecs

    Android Q introduces support for the open source video codec AV1. This allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android Q supports audio encoding using Opus - a codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.

    The MediaCodecInfo API introduces an easier way to determine the video rendering capabilities of an Android device. For any given codec, you can obtain a list of supported sizes and frame rates using VideoCodecCapabilities.getSupportedPerformancePoints(). This allows you to pick the best quality video content to render on any given device.

    Native MIDI API

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

    ANGLE on Vulkan

    To enable more consistency for game and graphics developers, we are working towards a standard, updateable OpenGL driver for all devices built on Vulkan. In Android Q we're adding experimental support for ANGLE on top of Vulkan on Android devices. ANGLE is a graphics abstraction layer designed for high-performance OpenGL compatibility across implementations. Through ANGLE, the many apps and games using OpenGL ES can take advantage of the performance and stability of Vulkan and benefit from a consistent, vendor-independent implementation of ES on Android devices. In Android Q, we're planning to support OpenGL ES 2.0, with ES 3.0 next on our roadmap.

    We'll expand the implementation with more OpenGL functionality, bug fixes, and performance optimizations. See the docs for details on the current ANGLE support in Android, how to use it, and our plans moving forward. You can start testing with our initial support by opting-in through developer options in Settings. Give it a try today!

    Vulkan everywhere

    We're continuing to expand the impact of Vulkan on Android, our implementation of the low-overhead, cross-platform API for high-performance 3D graphics. Our goal is to make Vulkan on Android a broadly supported and consistent developer API for graphics. We're working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices. Going forward, this will help provide a uniform high-performance graphics API for apps and games to use.

    Neural Networks API 1.2

    Since introducing the Neural Networks API (NNAPI) in 2017, we've continued to expand the number of operations supported and improve existing functionality. In Android Q, we've added 60 new ops including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimisations. This lays the foundation for accelerating a much greater range of models -- such as those for object detection and image segmentation. We are working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.

    Strengthening Android's Foundations

    ART performance

    Android Q introduces several new improvements to the ART runtime which help apps start faster and consume less memory, without requiring any work from developers.

    Since Android Nougat, ART has offered Profile Guided Optimization (PGO), which speeds app startup over time by identifying and precompiling frequently executed parts of your code. To help with initial app startup, Google Play is now delivering cloud-based profiles along with APKs. These are anonymized, aggregate ART profiles that let ART pre-compile parts of your app even before it's run, giving a significant jump-start to the overall optimization process. Cloud-based profiles benefit all apps and they're already available to devices running Android P and higher.

    We're also continuing to make improvements in ART itself. For example, in Android Q we've optimized the Zygote process by starting your app's process earlier and moving it to a security container, so it's ready to launch immediately. We're storing more information in the app's heap image, such as classes, and using threading to load the image faster. We're also adding Generational Garbage Collection to ART's Concurrent Copying (CC) Garbage Collector. Generational CC is more efficient as it collects young-generation objects separately, incurring much lower cost as compared to full-heap GC, while still reclaiming a good amount of space. This makes garbage collection overall more efficient in terms of time and CPU, reducing jank and helping apps run better on lower-end devices.

    Security for apps

    BiometricPrompt is our unified authentication framework to support biometrics at a system level. In Android Q we're extending support for passive authentication methods such as face, and adding implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm the transaction in the TEE during the authentication. The implicit flow is designed for a lighter-weight alternative for transactions with passive authentication. We've also improved the fallback for device credentials when needed.

    Android Q adds support for TLS 1.3, a major revision to the TLS standard that includes performance benefits and enhanced security. Our benchmarks indicate that secure connections can be established as much as 40% faster with TLS 1.3 compared to TLS 1.2. TLS 1.3 is enabled by default for all TLS connections. See the docs for details.

    Compatibility through public APIs

    Another thing we all care about is ensuring that apps run smoothly as the OS changes and evolves. Apps using non-SDK APIs risk crashes for users and emergency rollouts for developers. In Android Q we're continuing our long-term effort begun in Android P to move apps toward only using public APIs. We know that moving your app away from non-SDK APIs will take time, so we're giving you advance notice.

    In Android Q we're restricting access to more non-SDK interfaces and asking you to use the public equivalents instead. To help you make the transition and prevent your apps from breaking, we're enabling the restrictions only when your app is targeting Android Q. We'll continue adding public alternative APIs based on your requests; in cases where there is no public API that meets your use case, please let us know.

    It's important to test your apps for uses of non-SDK interfaces. We recommend using the StrictMode method detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI. Even if the APIs are exempted (grey-listed) at this time, it's best to plan for the future and eliminate their use to reduce compatibility issues. For more details on the restrictions in Android Q, see the developer guide.

    Modern Android

    We're expanding our efforts to have all apps take full advantage of the security and performance features in the latest version of Android. Later this year, Google Play will require you to set your app's targetSdkVersion to 28 (Android 9 Pie) in new apps and updates. In line with these changes, Android Q will warn users with a dialog when they first run an app that targets a platform earlier than API level 23 (Android Marshmallow). Here's a checklist of resources to help you migrate your app.

    We're also moving the ecosystem toward readiness for 64-bit devices. Later this year, Google Play will require 64-bit support in all apps. If your app uses native SDKs or libraries, keep in mind that you'll need to provide 64-bit compliant versions of those SDKs or libraries. See the developer guide for details on how to get ready.

    Get started with Android Q Beta

    With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you'll want to enable and test with Android Q storage changes, new location permission states, restrictions on background app launch, and restrictions on device identifiers. See the privacy documentation for details.

    To get started, just install your current app from Google Play onto a device or Android Virtual Device running Android Q Beta and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. Take a look at the migration guide for steps and a recommended timeline.

    Next, update your app's targetSdkVersion to 'Q' as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.

    Explore the new features and APIs

    When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Take a look at the API diff report, the Android Q Beta API reference, and developer guides as a starting point. Also, on the Android Q Beta developer site, you'll find release notes and support resources for reporting issues.

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

    How do I get Android Q Beta?

    It's easy - you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we're supporting all three generations of Pixel -- Pixel 3, Pixel 2, and even the original Pixel!). Downloadable system images for those devices are also available. If you don't have a Pixel device, you can use the Android Emulator, and download the latest emulator system images via the SDK Manager in Android Studio.

    We plan to update the preview system images and SDK regularly throughout the preview. We'll have more features to share as the Beta program moves forward.

    As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.

    March 13th 2019, 3:48 pm

    Grow your indie game with Google Play

    Android Developers Blog

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

    Google Play empowers game developers of all sizes to engage and delight people everywhere, and build successful businesses too. We are inspired by the passion and creativity we see from the indie games community, and, over the past few years, we've invested in and nurtured indie games developers around the world, helping them express their unique voice and bring ideas to life.

    This year, we've put together several initiatives to help the indie community.

    Indie Games Showcase

    For indie developers who are constantly pushing the boundaries of storytelling, visual excellence, and creativity in mobile we are announcing today the Indie Games Showcase, an international competition for games studios from Europe*, South Korea and Japan. Those of you who meet the eligibility criteria (as outlined below) can enter your game for a chance to win several prizes, including:

    How to enter the competition

    If you're over 18 years old, based in one of the eligible countries, have 30 or less full time employees, and have published a new game on Google Play after 1 January 2018, you can enter your game. If you're planning on publishing a new game soon, you can also enter by submitting a private beta. Submissions close on May 6 2019. Check out all the details in the terms and conditions for each region. Enter now!

    Indie Games Accelerator

    Last year we launched our first games accelerator for developers in Southeast Asia, India and Pakistan and saw great results. We are happy to announce that we are expanding the format to accept developers from select countries in the Middle East, Africa, and Latin America, with applications for the 2019 cohort opening soon. The Indie Games Accelerator is a 6 month intensive program for top games startups, powered by mentors from the gaming industry as well as Google experts, offering a comprehensive curriculum that covers all aspects of building a great game and company.

    Mobile Developer Day at GDC

    We will be hosting our annual Developer Day at the Game Developers Conference in San Francisco on Monday, March 18th. Join us for a full day of sessions covering tools and best practices to help build a successful mobile games business. We'll focus on game quality, effective monetization and growth strategies, and how to create, connect, and scale with Google. Sign up to stay up to date or join us via livestream.

    Developer Days

    We also want to engage with you in person with a series of events. We will be announcing them shortly, so please make sure to sign up to our newsletter to get notified about events and programs for indie developers.

    Academy for App Success

    Looking for tips on how to use various developer tools in the Play Console? Get free training through our e-learning program, the Academy for App Success. We even have a custom Play Console for game developers course to get a jump start on Google Play.

    We look forward to seeing your amazing work and sharing your creativity with other developers, gamers and industry experts around the world. And don't forget to submit your game for a chance to get featured on Indie Corner on Google Play.

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


    How useful did you find this blog post?

    March 13th 2019, 2:07 am

    Supplement your earnings with Rewarded Products

    Android Developers Blog

    Posted by Patrick Davis, Product Manager, Google Play

    Developers are increasingly using multiple methods to monetize their apps and games. One trend has been to reward users for a monetizable action, like watching a video, with in-game currency or other benefits. This gives users more choice in how they experience the app or game, and has been an effective way to monetize non-paying users.

    To support this monetization method, Google Play is excited to announce rewarded products, a new product type now available in open beta in the Play Console.

    Rewarded products make it easy for Google Play developers to increase their monetized user base. Our first rewarded product offering will be in a video format. Users can elect to watch a video advertisement and upon completion be rewarded with virtual goods or in-game currency. In the example below, the user selects "watch ad", views the video, and then is granted 100 coins.

    Rewarded products can be added to any app using the Google Play Billing Library or AIDL interface with only a few additional API calls. No extra SDK integration is required. This significantly reduces the work required to implement compared to other offerings. Rewarded products are powered by AdMob technology to give access to the broad range of content from advertisers currently working with Google.

    Get started with rewarded products.

    For developers interested in best practices on how to diversify revenue and how rewarded products fit in, please visit us at Google's Mobile Developer day at GDC or watch via the livestream.

    How useful did you find this blog post?

    March 6th 2019, 1:14 pm

    Android Jetpack WorkManager Stable Release

    Android Developers Blog

    Posted by Sumir Kataria, Software Engineering Lead & Jisha Abubaker, Product Manager

    Simplify how you manage background work with WorkManager

    Today, we're happy to announce the release of Android Jetpack WorkManager 1.0 Stable. We want to thank so many of you in our dev community who have given us feedback and logged bugs along the way - we've gotten here thanks to your help!

    When we looked at the top problems faced by developers, we saw that doing background processing reliably and in a battery-friendly manner was a huge challenge. This meant that periodically fetching fresh content or uploading your logs was complex. Different versions of Android provided different tools for the job, each with their own API quirks. For example, listening for network or storage availability and automatically retrying your tasks involved a lot of work.

    Our answer to these challenges was WorkManager. We introduced a preview of the Android Jetpack WorkManager library at Google I/O 2018 and have since iterated on it with additional features and bug fixes thanks to your valuable input.

    The goal of WorkManager is to make background operations easy for you. WorkManager takes into account constraints like battery-optimization, storage, or network availability, and it only runs its tasks when the appropriate conditions are met. It also knows when to retry or reschedule your work--even if your device or app restarts.

    We believe WorkManager is a friendly, approachable API that can take care of one of the most complex parts of Android for you so you can focus on the code that makes your app unique.

    WorkManager Highlights

    Here are some key features of WorkManager:

    Watch and read below to learn when and how to use WorkManager to simplify managing background work in your apps:

    When to use WorkManager

    WorkManager is best suited for tasks that can be deferred, but are still expected to run even if the application or device restarts (for example, syncing data periodically with a backend service and uploading logs or analytics data).

    For tasks like sending an instant message that are required to run immediately or for tasks that are not required to run after the app exits, take a look at our background processing guide to learn which solution meets your needs.

    How to use WorkManager

    To get started with the WorkManager API, add the WorkManager dependency available on Google's Maven repository in Java or Kotlin to your application's build.gradle file:

    dependencies {
        def work_version = 1.0.0
    
        // Java
        implementation "android.arch.work:work-runtime:$work_version"
    
        // Kotlin KTX + coroutines
        implementation "android.arch.work:work-runtime-ktx:$work_version"
      }

    Now, simply subclass a Worker and implement your background work with doWork() and enqueue it with WorkManager.

    class MyWorker(ctx: Context, params: WorkerParameters)
      : Worker(ctx, params) {
      override fun WorkerResult doWork() {
        //do the work you want done in the background here
        return Result.success()
      }
    }
    
    // optionally, add constraints like power, network availability
    val constraints: Constraints = Constraints.Builder()
         .setRequiresCharging(true)
                    .setRequiredNetworkType(NetworkType.CONNECTED)
                    .build()
    
    val myWork = OneTimeWorkRequestBuilder<MyWorker>()
                    .setConstraints(constraints).build()
    
    // Now, enqueue your work
    WorkManager.getInstance().enqueue(myWork)

    WorkManager will now take care of running your task when it detects that your device is charging and the network is available.

    Why use WorkManager

    Backward compatibility

    WorkManager will leverage the right scheduling API under the hood: it uses JobScheduler API on Android 6.0+ (API 23+) and a combination of AlarmManager and BroadcastReceiver on previous versions.

    It also seeks to ensure the best possible behavior so that it complies with system optimizations introduced in newer Android API versions to maximize battery and enforce good app behavior.

    For example, WorkManager will schedule background work during the maintenance window for Android 6.0+ (API 23+) devices when the system is in Doze mode.

    Reliable scheduling

    With WorkManager, you can easily add constraints like network availability or charging status. Your work will run when the constraints are met and automatically retried if they fail while running. For example, if your task requires network to be available, the task will be stopped when network is no longer available and retried later.

    You can also monitor work status and retrieve work result using LiveData. This allows your UI to be notified when your task is completed.

    In the event that your work fails, you can control how your work is retried by configuring how backoff is handled.

    WorkManager is also able to reschedule your work, using a record of your work in its local database, if an application or device restart occurs.

    Control over how your work is run

    We understand that each app has unique needs, and so do your tasks--even within the same app. WorkManager provides a simple yet highly flexible API surface to help configure your work and how it is run.

    Take advantage of one-off scheduling with OneTimeWorkRequest or recurrent scheduling with PeriodicWorkRequest.

    You can also chain your one time work requests to run in order or in parallel. If any work in the chain fails, WorkManager seeks to ensure that the remaining chain of work will not run. Read more about chaining work requests here.

    If you require more flexibility over how WorkManager parallelizes and manages work, check out our advanced threading guide.

    What developers have to say

    redBus, the largest online bus ticketing platform, shares their experience using WorkManager to simplify how they collect user feedback in their Android app:

    "Feedback is critical to redBus as we expand into other countries. It often happens that a user gives critical feedback about a functionality within the redBus app but when the app tries to upload the feedback to backend servers, there might not be enough network coverage or battery.
    WorkManager has simplified the way redBus app delivers information to it's backend servers. WorkManager library's capability to handle parameters like network connectivity, battery and use appropriate handlers like AlarmManager or JobScheduler has enabled us to concentrate on building business logics and offloading execution complexity to WorkManager."

    - Dinesh Shanmugam

    Android Lead, redBus.in

    Get started with WorkManager

    Check out our getting started guide and hands-on codelab to start using the WorkManager library for your background task needs.

    We appreciate your feedback, including features you like and features you would like to see.

    If you find a bug or issue, feel free to file an issue.

    March 5th 2019, 1:09 pm

    Android Security Improvement update: Helping developers harden their apps, one thwarted vulnerabilit

    Android Developers Blog

    Posted by Patrick Mutchler and Meghan Kelly, Android Security & Privacy Team

    Helping Android app developers build secure apps, free of known vulnerabilities, means helping the overall ecosystem thrive. This is why we launched the Application Security Improvement Program five years ago, and why we're still so invested in its success today.

    What the Android Security Improvement Program does

    When an app is submitted to the Google Play store, we scan it to determine if a variety of vulnerabilities are present. If we find something concerning, we flag it to the developer and then help them to remedy the situation.

    Think of it like a routine physical. If there are no problems, the app runs through our normal tests and continues on the process to being published in the Play Store. If there is a problem, however, we provide a diagnosis and next steps to get back to healthy form.

    Over its lifetime, the program has helped more than 300,000 developers to fix more than 1,000,000 apps on Google Play. In 2018 alone, the program helped over 30,000 developers fix over 75,000 apps. The downstream effect means that those 75,000 vulnerable apps are not distributed to users with the same security issues present, which we consider a win.

    What vulnerabilities are covered

    The App Security Improvement program covers a broad range of security issues in Android apps. These can be as specific as security issues in certain versions of popular libraries (ex: CVE-2015-5256) and as broad as unsafe TLS/SSL certificate validation.

    We are continuously improving this program's capabilities by improving the existing checks and launching checks for more classes of security vulnerability. In 2018, we deployed warnings for six additional security vulnerability classes including:

    1. SQL Injection
    2. File-based Cross-Site Scripting
    3. Cross-App Scripting
    4. Leaked Third-Party Credentials
    5. Scheme Hijacking
    6. JavaScript Interface Injection

    Ensuring that we're continuing to evolve the program as new exploits emerge is a top priority for us. We are continuing to work on this throughout 2019.

    Keeping Android users safe is important to Google. We know that app security is often tricky and that developers can make mistakes. We hope to see this program grow in the years to come, helping developers worldwide build apps users can truly trust.

    February 28th 2019, 1:19 pm

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

    Android Developers Blog

    Posted by Rahul Mishra and Tom Watkins, Android Security & Privacy Team

    In 2018, Google Play Protect made Android devices running Google Play some of the most secure smartphones available, scanning over 50 billion apps everyday for harmful behaviour.

    Android devices can genuinely improve people's lives through our accessibility features, Google Assistant, digital wellbeing, Family Link, and more — but we can only do this if they are safe and secure enough to earn users' long term trust. This is Google Play Protect's charter and we're encouraged by this past year's advancements.

    Google Play Protect, a refresher

    Google Play Protect is the technology we use to ensure that any device shipping with the Google Play Store is secured against potentially harmful applications (PHA). It is made up of a giant backend scanning engine to aid our analysts in sourcing and vetting applications made available on the Play Store, and built-in protection that scans apps on users' devices, immobilizing PHA and warning users.

    This technology protects over 2 billion devices in the Android ecosystem every day.

    What's new

    On by default

    We strongly believe that security should be a built-in feature of every device, not something a user needs to find and enable. When security features function at their best, most users do not need to be aware of them. To this end, we are pleased to announce that Google Play Protect is now enabled by default to secure all new devices, right out of the box. The user is notified that Google Play Protect is running, and has the option to turn it off whenever desired.

    New and rare apps

    Android is deployed in many diverse ways across many different users. We know that the ecosystem would not be as powerful and vibrant as it is today without an equally diverse array of apps to choose from. But installing new apps, especially from unknown sources, can carry risk.

    Last year we launched a new feature that notifies users when they are installing new or rare apps that are rarely installed in the ecosystem. In these scenarios, the feature shows a warning, giving users pause to consider whether they want to trust this app, and advising them to take additional care and check the source of installation. Once Google has fully analyzed the app and determined that it is not harmful, the notification will no longer display. In 2018, this warning showed around 100,000 times per day

    Context is everything: warning users on launch

    It's easy to misunderstand alerts when presented out of context. We're trained to click through notifications without reading them and get back to what we were doing as quickly as possible. We know that providing timely and context-sensitive alerts to users is critical for them to be of value. We recently enabled a security feature first introduced in Android Oreo which warns users when they are about to launch a potentially harmful app on their device.

    This new warning dialog provides in-context information about which app the user is about to launch, why we think it may be harmful and what might happen if they open the app. We also provide clear guidance on what to do next. These in-context dialogs ensure users are protected even if they accidentally missed an alert.

    Auto-disabling apps

    Google Play Protect has long been able to disable the most harmful categories of apps on users devices automatically, providing robust protection where we believe harm will be done.

    In 2018, we extended this coverage to apps installed from Play that were later found to have violated Google Play's policies, e.g. on privacy, deceptive behavior or content. These apps have been suspended and removed from the Google Play Store.

    This does not remove the app from user device, but it does notify the user and prevents them from opening the app accidentally. The notification gives the option to remove the app entirely.

    Keeping the Android ecosystem secure is no easy task, but we firmly believe that Google Play Protect is an important security layer that's used to protect users devices and their data while maintaining the freedom, diversity and openness that makes Android, well, Android.

    Acknowledgements: This post leveraged contributions from Meghan Kelly and William Luh.

    February 26th 2019, 1:26 pm

    Expanding target API level requirements in 2019

    Android Developers Blog

    Posted by Edward Cunningham, Android Security & Privacy Team

    In a previous blog we described how API behavior changes advance the security and privacy protections of Android, and include user experience improvements that prevent apps from accidentally overusing resources like battery and memory.

    Since November 2018, all app updates on Google Play have been required to target API level 26 (Android 8.0) or higher. Thanks to the efforts of thousands of app developers, Android users now enjoy more apps using modern APIs than ever before, bringing significant security and privacy benefits. For example, during 2018 over 150,000 apps added support for runtime permissions, giving users granular control over the data they share.

    Today we're providing more information about the Google Play requirements for 2019, and announcing some changes that affect apps distributed via other stores.

    Google Play requirements for 2019

    In order to provide users with the best Android experience possible, the Google Play Console will continue to require that apps target a recent API level:

    Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Apps can still use any minSdkVersion, so there is no change to your ability to build apps for older Android versions.

    For a list of changes introduced in Android 9 Pie, check out our page on behavior changes for apps targeting API level 28+.

    Apps distributed via other stores

    Targeting a recent API level is valuable regardless of how an app is distributed. In China, major app stores from Huawei, OPPO, Vivo, Xiaomi, Baidu, Alibaba, and Tencent will be requiring that apps target API level 26 (Android 8.0) or higher in 2019. We expect many others to introduce similar requirements – an important step to improve the security of the app ecosystem.

    Over 95% of spyware we detect outside of the Play Store intentionally targets API level 22 or lower, avoiding runtime permissions even when installed on recent Android versions. To protect users from malware, and support this ecosystem initiative, Google Play Protect will warn users when they attempt to install APKs from any source that do not target a recent API level:

    These Play Protect warnings will show only if the app's targetSdkVersion is lower than the device API level. For example, a user with a device running Android 6.0 (Marshmallow) will be warned when installing any new APK that targets API level 22 or lower. Users with devices running Android 8.0 (Oreo) or higher will be warned when installing any new APK that targets API level 25 or lower.

    Prior to August, Play Protect will start showing these warnings on devices with Developer options enabled to give advance notice to developers of apps outside of the Play Store. To ensure compatibility across all Android versions, developers should make sure that new versions of any apps target API level 26+.

    Existing apps that have been released (via any distribution channel) and are not receiving updates will be unaffected – users will not be warned when installing them.

    Getting started

    For advice on how to change your app’s target API level, take a look at the migration guide and this talk from I/O 2018: Migrate your existing app to target Android Oreo and above.

    We're extremely grateful to the Android developers worldwide who have already updated their apps to deliver security improvements for their users. We look forward to making great progress together in 2019.

    February 21st 2019, 2:36 pm

    How we fought bad apps and malicious developers in 2018

    Android Developers Blog

    Posted by Andrew Ahn, Product Manager, Google Play

    Google Play is committed to providing a secure and safe platform for billions of Android users on their journey discovering and experiencing the apps they love and enjoy. To deliver against this commitment, we worked last year to improve our abuse detection technologies and systems, and significantly increased our team of product managers, engineers, policy experts, and operations leaders to fight against bad actors.

    In 2018, we introduced a series of new policies to protect users from new abuse trends, detected and removed malicious developers faster, and stopped more malicious apps from entering the Google Play Store than ever before. The number of rejected app submissions increased by more than 55 percent, and we increased app suspensions by more than 66 percent. These increases can be attributed to our continued efforts to tighten policies to reduce the number of harmful apps on the Play Store, as well as our investments in automated protections and human review processes that play critical roles in identifying and enforcing on bad apps.

    In addition to identifying and stopping bad apps from entering the Play Store, our Google Play Protect system now scans over 50 billion apps on users' devices each day to make sure apps installed on the device aren't behaving in harmful ways. With such protection, apps from Google Play are eight times less likely to harm a user's device than Android apps from other sources.

    Here are some areas we've been focusing on in the last year and that will continue to be a priority for us in 2019:

    Protecting User Privacy

    Protecting users' data and privacy is a critical factor in building user trust. We've long required developers to limit their device permission requests to what's necessary to provide the features of an app. Also, to help users understand how their data is being used, we've required developers to provide prominent disclosures about the collection and use of sensitive user data. Last year, we rejected or removed tens of thousands of apps that weren't in compliance with Play's policies related to user data and privacy.

    In October 2018, we announced a new policy restricting the use of the SMS and Call Log permissions to a limited number of cases, such as where an app has been selected as the user's default app for making calls or sending text messages. We've recently started to remove apps from Google Play that violate this policy. We plan to introduce additional policies for device permissions and user data throughout 2019.

    Developer integrity

    We find that over 80% of severe policy violations are conducted by repeat offenders and abusive developer networks. When malicious developers are banned, they often create new accounts or buy developer accounts on the black market in order to come back to Google Play. We've further enhanced our clustering and account matching technologies, and by combining these technologies with the expertise of our human reviewers, we've made it more difficult for spammy developer networks to gain installs by blocking their apps from being published in the first place.

    Harmful app contents and behaviors

    As mentioned in last year's blog post, we fought against hundreds of thousands of impersonators, apps with inappropriate content, and Potentially Harmful Applications (PHAs). In a continued fight against these types of apps, not only do we apply advanced machine learning models to spot suspicious apps, we also conduct static and dynamic analyses, intelligently use user engagement and feedback data, and leverage skilled human reviews, which have helped in finding more bad apps with higher accuracy and efficiency.

    Despite our enhanced and added layers of defense against bad apps, we know bad actors will continue to try to evade our systems by changing their tactics and cloaking bad behaviors. We will continue to enhance our capabilities to counter such adversarial behavior, and work relentlessly to provide our users with a secure and safe app store.

    How useful did you find this blog post?

    February 13th 2019, 1:18 pm

    An Update on Android Things

    Android Developers Blog

    Posted by Dave Smith, Developer Advocate for IoT

    Over the past year, Google has worked closely with partners to create consumer products powered by Android Things with the Google Assistant built-in. Given the successes we have seen with our partners in smart speakers and smart displays, we are refocusing Android Things as a platform for OEM partners to build devices in those categories moving forward. Therefore, support for production System on Modules (SoMs) based on NXP, Qualcomm, and MediaTek hardware will not be made available through the public developer platform at this time.

    Android Things continues to be a platform for experimenting with and building smart, connected devices using the Android Things SDK on top of popular hardware like the NXP i.MX7D and Raspberry Pi 3B. System images for these boards will remain available through the Android Things console where developers can create new builds and push app updates for up to 100 devices for non-commercial use.

    We remain dedicated to providing a managed platform for IoT devices, including turnkey hardware solutions. For developers looking to commercialize IoT products in 2019, check out Cloud IoT Core for secure device connectivity at scale and the upcoming Cloud IoT Edge runtime for a suite of managed edge computing services. For on-device machine learning applications, stay tuned for more details about our Edge TPU development boards.

    February 12th 2019, 2:00 pm

    Google releases source code of Santa Tracker for Android 2018

    Android Developers Blog

    Posted by Chris Banes, Chief Elf of Android Engineering

    Today, we pushed the source code for Google's Santa Tracker 2018 Android app at google/santa-tracker-android, including its 17 mini-games, Santa tracking feature, Wear app and more!

    Visually the app looks much the same this year, but underneath the hood the app has gone on a massive size reduction exercise to make the download from Google Play as small as possible. When a user downloads the app the initial download is now just 9.2MB, compared to last year's app which was 60MB. That's a 85% reduction! 🗜️

    Android App Bundle

    We achieved that reduction by migrating the app over to using an Android App Bundle. The main benefit is that Google Play can now serve dynamically optimized APKs to users' devices. Moreover, we were also able to separate out all of the games into their own dynamic feature modules, downloaded on demand. This is why you might have seen a progress bar when you first opened a game, we are actually downloading the game from Google Play before starting the game:

    The progress bar shown while a game is fetched from Google Play

    You can read more about our journey migrating over to App Bundle in a small blog series, starting with our 'Moving to Android App Bundle' post.

    Gboard stickers

    One of the new features we added this year was a Gboard sticker pack, allowing users to share stickers to their friends. You might even notice some of the characters from the games in the stickers!

    'Santa Dunk' is one of the 20 available stickers

    We use Firebase App Indexing to publish our stickers to the local index on the device, where the Gboard keyboard app picks them up, allowing the user to share them in apps. You can see the source code here.

    The sticker pack being used in a very important conversation

    Lots of code improvements

    Aside from the things mentioned above, we've also completed a number of code health improvements. We have increased the minimum SDK version to Lollipop (21), migrated from the Support Library to AndroidX, reduced the file size of our game assets by switching to modern formats, and lots of other small improvements! Phew 😅.

    Go explore the code

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

    January 29th 2019, 1:04 pm

    Google Mobile Developer Day is coming to GDC 2019

    Android Developers Blog

    Posted by Kacey Fahey, Developer Marketing, Google Play

    We're excited to be part of the Game Developers Conference (GDC) 2019 in San Francisco. Join us on Monday, March 18th at the Google Mobile Developer Day, either in person or over live stream, for a full day of sessions covering tools and best practices to help build a successful mobile games business on Google Play. We'll focus on game quality, effective monetization and growth strategies, and how to create, connect, and scale with Google.

    This year's sessions are focused on tips and tools to help your mobile game business succeed. Come hear our latest announcements and industry trends, as well as learnings from industry peers. We will hold a more technical session in the second half of the day, where we'll share ways to optimize your mobile game's performance for the best possible player experience.

    Also, make sure to visit the Google booth from Wednesday March 20th until Friday March 22nd. Here, you will be able to interact with hands-on demos, attend talks in the theater, and get your questions answered by Google experts. We're bringing a big team and hope to see you there.

    Learn more about Google's activities throughout the week of GDC and sign up to stay informed. For those who can't make it in person, join the live stream starting at 10am PST on Monday, March 18th. These events are part of the official Game Developers Conference and require a pass to attend.

    How useful did you find this blog post?

    January 23rd 2019, 12:49 pm

    Grow your app business internationally through localization on Google Play

    Android Developers Blog

    Posted by Chris Yang, Program Manager, Translation Service

    It is not uncommon for developers to have the following concerns and thoughts when considering whether to localize their apps: "I just don't have the time!" "Translation is too expensive." "High-quality translation is just hard to find.'' Does this sound familiar?

    At Google, we consider translation a key component of making the world's information universally accessible and useful. This commitment extends not only to localizing our own products, but also to providing tools to help developers and translators more easily localize their apps.

    Introducing the Google Play App Translation Service

    Available in the Google Play Console, the Google Play App Translation Service simplifies localization of your app user interface strings, store listing, in-app product names, and universal apps campaign ads. Thousands of developers have already used this service to reach hundreds of millions of users worldwide.

    Here is an overview of some of the ways it can help:

    1. Quick and easy - Order in minutes and receive your translation in as little as two days.

    2. Professional and human - Get high-quality translations by real human translators.

    3. Value for money - Translate your app for as little as $0.07 per word.

    Ordering a Translation

    Find the Translation Service in the Google Play Console:

    When you're ready to translate, just select the languages to use for translation, choose a vendor, and place your order.

    Select languages to translate into.

    Choose what type of content you want to translate.

    Easily complete purchase of the service.

    Language recommendations

    You can also expand your global footprint with translation recommendations that can help increase installs. The recommendations can be found in the Google Play Console.

    The language recommendation feature is developed using machine learning and is based on your app's install history and market data.

    Did you know that you can reach almost 80% of internet users worldwide with only 10 languages. In particular, the Google Play opportunity in Russia and the Middle East continues to grow. Let us know once you have localized for these markets so we can consider featuring your app or game in the Now in Russian and Now in Arabic collections on the Play Store.

    Launching the translation

    Once you download the translation, you'll be ready to publish your newly translated app update on Google Play.

    Get started with the App Translation Service today and let us know what you think!

    How useful did you find this blog post?

    January 16th 2019, 4:27 pm

    Get your apps ready for the 64-bit requirement

    Android Developers Blog

    Posted by Vlad Radu, Product Manager, Play and Diana Wong, Product Manager, Android

    64-bit CPUs deliver faster, richer experiences for your users. Adding a 64-bit version of your app provides performance improvements, makes way for future innovation, and sets you up for devices with 64-bit only hardware.

    We want to help you get ready and know you need time to plan. We’ve supported 64-bit CPUs since Android 5.0 Lollipop and in 2017 we first announced that apps using native code must provide a 64-bit version (in addition to the 32-bit version). Today we’re providing more detailed information and timelines to make it as easy as possible to transition in 2019.

    The 64-bit requirement: what it means for developers

    Starting August 1, 2019:

    Starting August 1, 2021:

    The requirement does not apply to:

    We are not making changes to our policy on 32-bit support. Play will continue to deliver apps to 32-bit devices. This requirement means that apps with 32-bit native code will need to have an additional 64-bit version as well.

    Preparing for the 64-bit requirement

    We anticipate that for most developers, the move to 64-bit should be straightforward. Many apps are written entirely in non-native code (e.g. the Java programming language or Kotlin) and do not need code changes.

    All developers: Here is an overview of the steps you will need to take in order to become 64-bit compliant. For a more detailed outline of this process refer to our in-depth documentation.

    Inspect your APK or app bundle for native code. You can check for .so files using APK Analyzer. Identify whether they are built from your own code or are imported by an SDK or library that you are using. If you do not have any .so files in your APK, you are already 64-bit compliant.

    Enable 64-bit architectures and rebuild native code (.so files) imported by your own code. See the documentation for more details.

    Game developers: The three most used engines all currently support 64-bit (Unreal & Cocos2d since 2015, Unity since 2018). We understand that migrating a 3rd party game engine is an intensive process with long lead times.

    Since Unity only recently began providing 64-bit support in versions 2017.4 and 2018.2, we are granting an automatic extension to existing games using versions 5.6 or older until August 2021. Unity provides guides that can help you through the process of upgrading to a 64-bit compliant version.

    SDK and library owners: Update for 64-bit compliance as soon as possible to give app developers time to adapt, and let your developers know. Sign up and register your SDK to receive updates about the latest tools and information that can help you serve your customers.

    Going forward

    For those that already support 64-bit - thank you and great work! If you haven’t yet, we encourage you to begin any work for the 64-bit requirement as soon as possible. As we move closer to the deadline, we’ll be updating our developer documentation with more information on how to check if your app is compliant.

    We’re excited about the future that 64-bit CPUs bring in areas such as artificial intelligence, machine learning, and immersive mobile. Supporting 64-bit prepares the ecosystem for the innovation enabled by the advanced compute capabilities of 64-bit devices, and for future Android devices that only support 64-bit code.

    How useful did you find this blog post?

    January 15th 2019, 5:21 pm

    Reminder SMS/Call Log Policy Changes

    Android Developers Blog

    Posted by Paul Bankhead, Director, Product Management, Google Play

    TLDR; As previously announced and directly communicated to developers via email, we'll be removing apps from the Google Play Store that ask for SMS or Call Log permission. If you have not submitted a permissions declaration form and you're app is removed, see below for next steps.

    We take access to sensitive data and permissions very seriously. This is especially true with SMS and Call Log permissions, which were designed to allow users to pick their favorite dialer or messaging app, but have also been used to enable many other experiences that might not require that same level of access. In an effort to improve users' control over their data, last October we announced we would be restricting developer access to SMS and Call Log permissions.

    Our new policy is designed to ensure that apps asking for these permissions need full and ongoing access to the sensitive data in order to accomplish the app's primary use case, and that users will understand why this data would be required for the app to function.

    Developers whose apps used these permissions prior to our announcement were notified by email and given 90 days to either remove the permissions, or submit a permissions declaration form to enable further review.

    More about app reviews

    We take this review process seriously and understand it's a change for many developers. We apply the same criteria to all developers, including dozens of Google apps. We added to the list of approved use cases over the last few months as we evaluated feedback from developers.

    Our global teams carefully review each submission. During the review process, we consider the following:

    With this change, some uses cases will no longer be allowed. However, many of the apps we reviewed with one of these permissions can rely on narrower APIs, reducing the scope of access while accomplishing similar functionality. For example, developers using SMS for account verification can alternatively use the SMS Retriever API, and apps that want to share content using SMS can prepopulate a message and trigger the default SMS app to show via intents.

    Tens of thousands of developers have already resubmitted their apps to support the new policy or have submitted a form. Thank you! Developers who submitted a form received a compliance extension until March 9th.

    Next steps

    Over the next few weeks, we will be removing apps from the Play Store that ask for SMS or Call Log permission and have not submitted a permission declaration form. If your app is removed and you would like to have it republished, you can do one of the following in the Play Console:

    Keeping our overall Android ecosystem healthy is very important, and protection of user data is vital to the long term health of all developers. We know these changes have required significant work from you and we appreciate your efforts to create innovative experiences while protecting user's privacy.

    January 14th 2019, 7:23 pm

    Android Studio 3.3

    Android Developers Blog

    Posted by Jamal Eason, Product Manager

    We are excited to kick off the new year with a stable release of Android Studio 3.3 focused on refinement and quality. You can download it today from developer.android.com/studio. Based on the feedback from many of you, we have taken a step back from large features to focus on our quality fundamentals. The goal is to ensure Android Studio continues to help you stay productive in making great apps for Android. Since the last stable release, Android Studio 3.3 addresses over 200 user- reported bugs. This release also includes official support for Navigation Editor, improved incremental Java compilation when using annotation processors, C++ code lint inspections, an updated new project wizard, and usability fixes for each of the performance profilers. In addition, saving snapshots on exit for the Android emulator is 8x faster.

    Android Studio 3.3 kicks off the broader quality focus area for the year, which we call Project Marble. Announced at the Android Developer Summit in November 2018, Project Marble is the Android Studio team's focus on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid, along with refining and polishing the user-facing features that matter to you in your day-to-day app development workflows. In Project Marble, we are specifically looking at reducing the number of crashes, hangs, memory leaks, and user-impacting bugs. We are also investing in our measurement infrastructure to prevent these issues from occurring. Stay tuned for more updates and details as we progress on this initiative.

    This release of Android Studio is a solid milestone for the product. If you want the latest in feature refinement and quality, then download Android Studio 3.3 today on the stable release channel. Watch and read below for some of the notable changes and enhancements that you will find in Android Studio 3.3.

    Develop

    Navigation Editor

    Clang-Tidy Code Inspection Settings

    New Project Wizard

    Delete Unused Directories Dialogue

    IDE User Feedback

    Build

    Single-Variant Project Sync

    Test

    Android Pie à la mode: Security & Privacy

    Android Developers Blog

    Posted by Vikrant Nanda and René Mayrhofer, Android Security & Privacy Team

    There is no better time to talk about Android dessert releases than the holidays because who doesn't love dessert? And what is one of our favorite desserts during the holiday season? Well, pie of course.

    In all seriousness, pie is a great analogy because of how the various ingredients turn into multiple layers of goodness: right from the software crust on top to the hardware layer at the bottom. Read on for a summary of security and privacy features introduced in Android Pie this year.

    Strengthening Android

    Making Android more secure requires a combination of hardening the platform and advancing anti-exploitation techniques.

    Platform hardening

    With Android Pie, we updated File-Based Encryption to support external storage media (such as, expandable storage cards). We also introduced support for metadata encryption where hardware support is present. With filesystem metadata encryption, a single key present at boot time encrypts whatever content is not encrypted by file-based encryption (such as, directory layouts, file sizes, permissions, and creation/modification times).

    Android Pie also introduced a BiometricPrompt API that apps can use to provide biometric authentication dialogs (such as, fingerprint prompt) on a device in a modality-agnostic fashion. This functionality creates a standardized look, feel, and placement for the dialog. This kind of standardization gives users more confidence that they're authenticating against a trusted biometric credential checker.

    New protections and test cases for the Application Sandbox help ensure all non-privileged apps targeting Android Pie (and all future releases of Android) run in stronger SELinux sandboxes. By providing per-app cryptographic authentication to the sandbox, this protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data widely accessible.

    Anti-exploitation improvements

    With Android Pie, we expanded our compiler-based security mitigations, which instrument runtime operations to fail safely when undefined behavior occurs.

    Control Flow Integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of compiled code. In Android Pie, it has been enabled by default within the media frameworks and other security-critical components, such as for Near Field Communication (NFC) and Bluetooth protocols. We also implemented support for CFI in the Android common kernel, continuing our efforts to harden the kernel in previous Android releases.

    Integer Overflow Sanitization is a security technique used to mitigate memory corruption and information disclosure vulnerabilities caused by integer operations. We've expanded our use of Integer Overflow sanitizers by enabling their use in libraries where complex untrusted input is processed or where security vulnerabilities have been reported.

    Continued investment in hardware-backed security

    One of the highlights of Android Pie is Android Protected Confirmation, the first major mobile OS API that leverages a hardware-protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. Developers can use this API to display a trusted UI prompt to the user, requesting approval via a physical protected input (such as, a button on the device). The resulting cryptographically signed statement allows the relying party to reaffirm that the user would like to complete a sensitive transaction through their app.

    We also introduced support for a new Keystore type that provides stronger protection for private keys by leveraging tamper-resistant hardware with dedicated CPU, RAM, and flash memory. StrongBox Keymaster is an implementation of the Keymaster hardware abstraction layer (HAL) that resides in a hardware security module. This module is designed and required to have its own processor, secure storage, True Random Number Generator (TRNG), side-channel resistance, and tamper-resistant packaging.

    Other Keystore features (as part of Keymaster 4) include Keyguard-bound keys, Secure Key Import, 3DES support, and version binding. Keyguard-bound keys enable use restriction so as to protect sensitive information. Secure Key Import facilitates secure key use while protecting key material from the application or operating system. You can read more about these features in our recent blog post as well as the accompanying release notes.

    Enhancing user privacy

    User privacy has been boosted with several behavior changes, such as limiting the access background apps have to the camera, microphone, and device sensors. New permission rules and permission groups have been created for phone calls, phone state, and Wi-Fi scans, as well as restrictions around information retrieved from Wi-Fi scans. We have also added associated MAC address randomization, so that a device can use a different network address when connecting to a Wi-Fi network.

    On top of that, Android Pie added support for encrypting Android backups with the user's screen lock secret (that is, PIN, pattern, or password). By design, this means that an attacker would not be able to access a user's backed-up application data without specifically knowing their passcode. Auto backup for apps has been enhanced by providing developers a way to specify conditions under which their app's data is excluded from auto backup. For example, Android Pie introduces a new flag to determine whether a user's backup is client-side encrypted.

    As part of a larger effort to move all web traffic away from cleartext (unencrypted HTTP) and towards being secured with TLS (HTTPS), we changed the defaults for Network Security Configuration to block all cleartext traffic. We're protecting users with TLS by default, unless you explicitly opt-in to cleartext for specific domains. Android Pie also adds built-in support for DNS over TLS, automatically upgrading DNS queries to TLS if a network's DNS server supports it. This protects information about IP addresses visited from being sniffed or intercepted on the network level.

    We believe that the features described in this post advance the security and privacy posture of Android, but you don't have to take our word for it. Year after year our continued efforts are demonstrably resulting in better protection as evidenced by increasing exploit difficulty and independent mobile security ratings. Now go and enjoy some actual pie while we get back to preparing the next Android dessert release!

    Acknowledgements: This post leveraged contributions from Chad Brubaker, Janis Danisevskis, Giles Hogben, Troy Kensinger, Ivan Lozano, Vishwath Mohan, Frank Salim, Sami Tolvanen, Lilian Young, and Shawn Willden.

    December 20th 2018, 1:54 pm

    Wrapping up for 2018 with Google Play and Android

    Android Developers Blog

    Posted by Patricia Correa, Platforms & Ecosystems

    Earlier this year we highlighted some of Google Play's milestones and commitments in supporting the 1M+ developers on the Play Store, as well as those of you working on Android apps and games and looking to launch and grow your business on our platforms. We have been inspired and humbled by the achievements of app and game developers, building experiences that delight and help people everywhere, as some stories highlighted in #IMakeApps.

    We continue to focus on helping you grow thriving businesses and building tools and resources to help you reach and engage more users in more places, whilst ensuring a safe and secure ecosystem. Looking to 2019, we are excited about all the things to come and seeing more developers adopt new features and update to Android P.

    In the meantime let's share some of the 2018 highlights on Google Play and Android:

    Building for the future

    Along with Android P we have continued to help the Android developer ecosystem, launching Android Jetpack, the latest Android Studio, and Kotlin support. Developers are also now able to add rich and dynamic UI templates with Slices in places such as Google Search and Assistant, APIs for new screens support, and much more. Discover the latest from Android 9, API Level 28.

    Smaller apps have higher conversion rates and our research shows that a large app size is a key driver of uninstalls. At I/O we launched a new publishing format, the Android App Bundle, helping developers to deliver smaller and more efficient apps with a simplified release process, and with features on demand - saving on average 35% in download size! On devices using Android M and above, app bundles can reduce app size even further, by automatically supporting uncompressed native libraries, thereby eliminating duplication on devices.

    You can build app bundles in the Android Studio 3.2 stable release and in Unity 2018.3 beta, and upload larger bundles with installed APK sizes of up to 500MB without using expansion files, through an early access feature soon to be available to all developers.

    Richer experiences and discovery

    Discovery of your apps and games is important, so we launched Google Play Instant and increased the size limit to 10MB to enable TRY NOW on the Play Store, and removed the URL requirement for Instant apps. Android Studio 3.3 beta release, lets you publish a single app bundle and classify it or a particular module to be instant enabled (without maintaining separate code).

    For game developers, Unity introduced the Google Play Instant plug-in and instant app support is built into the new Cocos Creator. Our app pre-registration program, has seen nearly 250 million app pre-registrations, helping drive app downloads through richer discovery.

    Optimizing for quality and performance

    Android vitals are now more actionable, with a dashboard highlighting core vitals, peer benchmarks, start-up time and permission denials vitals, anomaly detection and alerts, and linking pre-launch reports - all so that you can better optimize and prioritize issues for improved quality and performance.

    There are more opportunities to get feedback and fix issues before launch. The Google Play Console expanded the functionality of automated device testing with a pre-launch report for games, and the launch of the internal and closed test tracks lets you push your app to up to 100 internal testers, before releasing them to production.

    Insights for your business, now and in the long term

    Metrics are critical to optimize your business and we've added new customizable tools in the Play Console, with downloadable reports to help you evaluate core metrics. Including cumulative data, 30-day rolling averages, and roll-ups for different time periods to better match the cadence of your business.

    You can now configure the statistics report to show how your instant apps are performing, analyze different dimensions and identify how many install the final app on their device. The acquisition report shows users discovery journey through to conversion - with average revenue per user and retention benchmarks against similar apps. You can also find the best performing search terms for your store listing with organic breakdown - helping to optimize efforts to grow and retain a valuable audience.

    Increasingly developers are adopting subscriptions as their core monetization model. The dedicated new subscriptions center means you can easily change subscription prices, offer partial refunds for in-app products and subscriptions, and also make plan changes in Play Billing Library version 1.2. Learn how to keep subscribers engaged; users can pause plans, giving you more control with order management and the cancellation survey.

    Discover how to use all the new features and best practices on the Academy for App Success, our interactive free e-learning platform, offering bite-sized courses that help you make the most of Play Console and improve your app quality.

    Make sure you follow @googleplaydev and sign up to our newsletter to stay ahead of all our updates in 2019! We hope these features and tools will enable us to continue a successful partnership with you in the New Year - follow our countdown for a daily highlight. From all of us at Google Play - happy holidays.

    How useful did you find this blog post?

    December 18th 2018, 1:46 pm

    In reviews we trust — Making Google Play ratings and reviews more trustworthy

    Android Developers Blog

    Posted by Fei Ye, Software Engineer and Kazushi Nagayama, Ninja Spamologist

    Google Play ratings and reviews are extremely important in helping users decide which apps to install. Unfortunately, fake and misleading reviews can undermine users' trust in those ratings. User trust is a top priority for us at Google Play, and we are continuously working to make sure that the ratings and reviews shown in our store are not being manipulated.

    There are various ways in which ratings and reviews may violate our developer guidelines:

    When we see these, we take action on the app itself, as well as the review or rating in question.

    In 2018, the Google Play Trust & Safety teams deployed a system that combines human intelligence with machine learning to detect and enforce policy violations in ratings and reviews. A team of engineers and analysts closely monitor and study suspicious activities in Play's ratings and reviews, and improve the model's precision and recall on a regular basis. We also regularly ask skilled reviewers to check the decisions made by our models for quality assurance.

    It's a big job. To give you a sense of the volume we manage, here are some numbers from a recent week:

    Our team can do a lot, but we need your help to keep Google Play a safe and trusted place for apps and games.

    If you're a developer, you can help us by doing the following:

    Example of a violation: incentivized ratings is not allowed

    If you're a user, you can follow these simple guidelines as well:

    Finally, if you find bad ratings and reviews on Google Play, help us improve by sending your feedback! Users can mark the review as "Spam" and developers can submit feedback through the Play Console.

    Tooltip to flag the review as Spam.

    Thanks for helping us keep Google Play a safe and trusted place to discover some of the world's best apps and games.

    How useful did you find this blog post?

    December 17th 2018, 3:44 pm

    More visibility into the Android Open Source Project

    Android Developers Blog

    Posted by Jeff Bailey, AOSP Team

    AOSP has been around for more than 10 years and visibility into the project has often been restricted to the Android Team and Partners. A lot of that has been rooted in business needs: we want to have fun things to show off at launches and the code wasn't factored in a way that let us do more in the open.

    At the Android Developer Summit last month, we demoed GSI running on a number of partner devices, enabled through Project Treble. The work done to make that happen has provided the separation needed, and has also made it easier to work with our partners to upstream fixes for Android into AOSP. As a result of this, more than 40% of the commits to our git repository came in through our open source tree in Q3 of this year.

    Publishing Android's Continuous Integration Dashboard

    In order to support the developers working directly in AOSP and our partners upstreaming changes, we have enabled more than 8000 tests in presubmit -- tests that are run before the code is checked in -- and are working to add other continuous testing like the Compatibility Test Suite which ensures that our AOSP trees are in a continuously releasable state. Today we are excited to open this up for you through https://ci.android.com/.

    On this dashboard, across the top are the targets that we are building, down the left are the revisions. As we add more targets (such as GSI), they will appear here. Each square in the table provides access to the build artifacts. An anchor on the left provides a permanent URL for that revision. Find out more at https://source.android.com/setup/build/dashboard.

    Our DroidCop team (similar to Chromium's Tree Sherrifs) watches this dashboard and works with developers to ensure the health of the tree. This is just the start for us and we are building on this tool to add more in the coming months.

    I'd like to thank the Android Engineering Productivity Team for embracing this and I'm excited for us to take this step! I'd love to hear how you use this. Contact me at @jeffbailey-aosp on Twitter, jeffbailey+aosp@google.com, or tag /u/jeffbailey in a post to reddit.com/r/androiddev.

    December 14th 2018, 1:08 pm

    Notifications from the Twitter app are easier on your battery

    Android Developers Blog

    This blogpost is a collaboration between Google and Twitter. Authored by Jingwei Hao with support from César Puerta, Fred Lohner from Twitter, and developed with Jingyu Shi from Google. Push notifications are an important way to keep Twitter users informed about what's happening. However, they can be a significant and often overlooked source of battery drain. For example: high priority notifications can wake a phone from Doze, and fetching data upon push notification delivery via the network can drain the battery quickly.
    As app developers at Twitter, we know that battery life is an important aspect of the mobile experience for our users. Over time we've taken several steps to optimize our app to work with the power saving features, particularly around push notifications. In this article, we'll share what we did to save battery life on our users' devices in the hope this will help other developers optimize their apps as well.

    Firebase Cloud Messaging migration

    Earlier this year, we upgraded our notifications messaging library to the next evolution of GCM: Firebase Cloud Messaging (FCM). This gave us the ability to use the latest APIs and get access to the additional features Firebase has to offer.
    This was a very unique migration for us for multiple reasons:
    • Push notifications are an important part of Twitter's mobile engagement strategy. Notifications help our users stay informed and connected with the world, and helped a man get his nuggs. Therefore, we couldn't afford having unreliable delivery of notifications during and after the migration, which would negatively impact the platform.
    • Since it's not possible to support both GCM and FCM in the application, we were not able to use typical A/B testing techniques during the migration.
    We mitigated the risks by thoroughly testing across dogfood, alpha, and beta users for both migration and rollback paths, with real time metrics monitoring, and a staged app roll out. During the migration, we were pleased to find that replacing GCM with FCM worked smoothly in all our use cases.
    Migrating to FCM proved valuable to us when testing against the power saving features on Android. With APIs like: getPriority() and getOriginalPriority(), FCM gave us insight into if the priority of FCM messages are downgraded.

    Set the right FCM message priority

    On the backend at Twitter, we always try to make sure that notifications are assigned with the appropriate priority, making sure that high priority FCM messages are only used to generate a user visible notification. In fact, a very small fraction of notifications we send are classified as high priority.
    App Standby Buckets was introduced in Android 9 Pie, this feature impose restrictions on the number of high priority messages the app will receive based on which bucket the app belongs to. As a result, high priority messages should be reserved for the notifications users are more likely to interact with. Using high priority FCM messages for actions which do not involve user interactions can lead to negative consequences, for example: once an app exhausts its app standby bucket quota, the following genuinely urgent FCM messages will be downgraded to normal priority and delayed when device is in Doze.
    To understand how our app performs with App Standby Buckets, we gathered statistics on the notification priorities at both send and delivery time for the Twitter App:
    • During our test, we observed that none of the high priority FCM messages were downgraded, especially for the 2% of devices which are bucketed in the frequent or lower bucket when the notifications are delivered. This is particularly worth noting since the system could potentially impose restrictions on high priority FCM messages for devices in low active buckets.
    • 86% of the devices were bucketed in the active bucket when high priority FCM messages are delivered. This is another positive signal that our priority assignment of the messages is consistent with the use pattern from the users.
    This was very encouraging to see, as it means all users would receive the important notifications without any delay, and this is true no matter the app is considered active or not by the Android system. This also confirms that we are correctly categorizing high priority FCM messages based on our users usage engagement patterns.

    Avoid follow-up data prefetch for notifications

    Prefetching data is a popular practice to enrich the user experience around notifications. This entails including a piece of metadata within the payload of a notification. When the notification is delivered, the app leverages the payload data to start one or multiple network calls to download more data before the rendering of the notification. FCM payload has a 4KB max limit, and when more data is needed to create rich notifications, this prefetch practice is used. But doing this has a trade-off, and will increase both device power consumption and notification latency. At Twitter, among all the types of notifications we push to our users, there's only one type which does prefetching which makes up to less than 1% of the volume. In addition, in the cases where data prefetching for notification is unavoidable, it should be scheduled with JobScheduler or WorkManager tasks in order to avoid issues with the background execution limits in Oreo+.

    Create notification channels

    In addition, Notification Channels were introduced in the Android 8 Oreo release. We designed the importance level of the channels with multiple factors in mind, user experience being the most important and power-saving being another. Currently, Twitter for Android has nine notification channels, among which only direct messaging, emergency, and security are designed as high importance, leaving most of the channels with a lower importance level, making it less intrusive.

    Summary

    We set out to improve our user experience by migrating to FCM, prioritizing notifications cautiously, limiting prefetching, and carefully designing notification channels. We were glad to find that these changes had a positive impact on battery performance and enabled our app to take advantage of the power-saving features introduced in recent versions of Android.
    Designing for power optimization in a large evolving application is a complex and ongoing process, particularly as the Android platform grows and provides more granular controls. At Twitter we strongly believe in continuous refinement to improve application performance and resource consumption. We hope this discussion is useful in your own quest to optimize your app's performance and use of resources 💙

    December 13th 2018, 8:12 pm

    New Keystore features keep your slice of Android Pie a little safer

    Android Developers Blog

    Posted by Brian Claire Young and Shawn Willden, Android Security; and Frank Salim, Google Pay

    New Android Pie Keystore Features

    The Android Keystore provides application developers with a set of cryptographic tools that are designed to secure their users' data. Keystore moves the cryptographic primitives available in software libraries out of the Android OS and into secure hardware. Keys are protected and used only within the secure hardware to protect application secrets from various forms of attacks. Keystore gives applications the ability to specify restrictions on how and when the keys can be used.

    Android Pie introduces new capabilities to Keystore. We will be discussing two of these new capabilities in this post. The first enables restrictions on key use so as to protect sensitive information. The second facilitates secure key use while protecting key material from the application or operating system.

    Keyguard-bound keys

    There are times when a mobile application receives data but doesn't need to immediately access it if the user is not currently using the device. Sensitive information sent to an application while the device screen is locked must remain secure until the user wants access to it. Android Pie addresses this by introducing keyguard-bound cryptographic keys. When the screen is locked, these keys can be used in encryption or verification operations, but are unavailable for decryption or signing. If the device is currently locked with a PIN, pattern, or password, any attempt to use these keys will result in an invalid operation. Keyguard-bound keys protect the user's data while the device is locked, and only available when the user needs it.

    Keyguard binding and authentication binding both function in similar ways, except with one important difference. Keyguard binding ties the availability of keys directly to the screen lock state while authentication binding uses a constant timeout. With keyguard binding, the keys become unavailable as soon as the device is locked and are only made available again when the user unlocks the device.

    It is worth noting that keyguard binding is enforced by the operating system, not the secure hardware. This is because the secure hardware has no way to know when the screen is locked. Hardware-enforced Android Keystore protection features like authentication binding, can be combined with keyguard binding for a higher level of security. Furthermore, since keyguard binding is an operating system feature, it's available to any device running Android Pie.

    Keys for any algorithm supported by the device can be keyguard-bound. To generate or import a key as keyguard-bound, call setUnlockedDeviceRequired(true) on the KeyGenParameterSpec or KeyProtection builder object at key generation or import.

    Secure Key Import

    Secure Key Import is a new feature in Android Pie that allows applications to provision existing keys into Keystore in a more secure manner. The origin of the key, a remote server that could be sitting in an on-premise data center or in the cloud, encrypts the secure key using a public wrapping key from the user's device. The encrypted key in the SecureKeyWrapper format, which also contains a description of the ways the imported key is allowed to be used, can only be decrypted in the Keystore hardware belonging to the specific device that generated the wrapping key. Keys are encrypted in transit and remain opaque to the application and operating system, meaning they're only available inside the secure hardware into which they are imported.

    Secure Key Import is useful in scenarios where an application intends to share a secret key with an Android device, but wants to prevent the key from being intercepted or from leaving the device. Google Pay uses Secure Key Import to provision some keys on Pixel 3 phones, to prevent the keys from being intercepted or extracted from memory. There are also a variety of enterprise use cases such as S/MIME encryption keys being recovered from a Certificate Authorities escrow so that the same key can be used to decrypt emails on multiple devices.

    To take advantage of this feature, please review this training article. Please note that Secure Key Import is a secure hardware feature, and is therefore only available on select Android Pie devices. To find out if the device supports it, applications can generate a KeyPair with PURPOSE_WRAP_KEY.

    December 12th 2018, 1:46 pm

    Effective foreground services on Android

    Android Developers Blog

    Posted by Keith Smyth

    This is the fourth in a series of blog posts in which outline strategies and guidance in Android with regard to power.

    A process is not forever

    Android is a mobile operating system designed to work with constrained memory and battery. For this reason, a typical Android application can have its process killed by the system to recover memory. The process being killed is chosen based on a ranking system of how important that process is to the user at the time. Here, in descending order, is the ranking of each class of process. The higher the rank, the less likely that process is to be killed.

    Native Native Linux daemon processes are responsible for running everything (including the process killer itself).
    System The system_server process, which is responsible for maintaining this list.
    Persistent apps Persistent apps like Phone, Wi-Fi, and Bluetooth are crucial to keeping your device connected and able to provide its most basic features.
    Foreground app A foregrounded / top (user visible) app is the app a user is currently using.
    Perceptible apps These are apps that the user can perceive are running. For example an app with a foreground service playing audio, or an app set as the preferred voice interaction service will be bound to the system_server, effectively promoting it to Perceptible level.
    Service Background services like download manager and sync manager.
    Home The Launcher app containing desktop wallpaper
    Previous app The previous foreground app the user was using. The previous app lives above the cached apps as it's the most likely app the user will switch to next.
    Cached apps These are the remaining apps that have been opened by the user, and then backgrounded. They will be killed first to recover memory, and have the most restrictions applied to them on modern releases. You can read about them on the Behavior Changes pages for Nougat, Oreo and Pie.


    The foreground service

    There is nothing wrong with becoming a cached app: Sharing the user's device is part of the lifecycle that every app developer must accept to keep a happy ecosystem. On a device with a dead battery, 100% of the apps go unused. And an app blamed for killing the battery could even be uninstalled.

    However, there are valid scenarios to promote your app to the foreground: The prerequisites for using a foreground service are that your app is executing a task that is immediate, important (must complete), is perceptible to the user (most often because it was started by the user), and must have a well defined start and finish. If a task in your app meets these criteria, then it can be promoted to the foreground until the task is complete.

    There are some guidelines around creating and managing foreground services. For all API levels, a persistent notification with at least PRIORITY_LOW must be shown while the service is created. When targeting API 26+ you will also need to set the notification channel to at least IMPORTANCE_LOW. The notification must have a way for the user to cancel the work, this cancellation can be tied to the action itself: for example, stopping a music track can also stop the music-playback service. Last, the title and description of the foreground service notification must show an accurate description of what the foreground service is doing.

    To read more about foreground services, including several important updates in recent releases, see Running a service in the foreground

    Foreground service use cases

    Some good example usages of foreground services are playing music, completing a purchase transaction, high-accuracy location tracking for exercise, and logging sensor data for sleep. The user will initiate all of these activities, they must happen immediately, have an explicit beginning and end, and all can be cancelled by the user at any time.

    Another good use case for a foreground service is to ensure that critical, immediate tasks (e.g. saving a photo, sending a message, processing a purchase) are completed if the user switches away from the application and starts a new one. If the device is under high memory pressure it could kill the previous app while it is still processing causing data loss or unexpected behavior. An elegantly written app will detect being backgrounded and respond by promoting its short, critical task to the foreground to complete.

    If you feel you need your foreground service to stay alive permanently, then this is an indicator that a foreground service is not the right answer. Many alternatives exist to both meet the requirements of your use case, and be the most efficient with power.

    Alternatives

    Passive location tracking is a bad use case for foreground services. If the user has consented to being tracked, use the FusedLocationProvider API to receive bundled location updates at longer intervals, or use the geofencing API to be efficiently notified when a user enters or leaves a specified area. Read more about how to optimize location for battery.

    If you wish to pair with a Bluetooth companion device, use CompanionDeviceManager. For reconnecting to the device, BluetoothLeScanner has a startScan method that takes a PendingIntent that will fire when a narrow filter is met.

    If your app has work that must be done, but does not have to happen immediately: WorkManager or JobScheduler will schedule the work for the best time for the entire system. If the work must be started immediately, but then can stop if the user stops using the app, we recommend ThreadPools or Kotlin Coroutines.

    DownloadManager facilitates handling long running downloads in the background. It will even handle retries over poor connections and system reboots for you.

    If you believe you have a use case that isn't handled let us know!

    Conclusion

    Used correctly, the foreground service is a great way to tell Android that your app is doing something important to the user. Making the right decision on which tool to use remains the best way to provide a premium experience on Android for all users. Use the community and Google to help with these important decisions, and always respect the user first.

    December 11th 2018, 5:52 pm

    Google Play services discontinuing updates for API levels 14 and 15

    Android Developers Blog

    Posted by Sam Spencer, Technical Program Manager, Google Play

    The Android Ice Cream Sandwich (ICS) platform is seven years old and the active device count has been below 1% for some time. Consequently, we are deprecating support for ICS in future releases of Google Play services. For devices running ICS, the Google Play Store will no longer update Play Services APK beyond version 14.7.99.

    What does this mean as an Application developer:

    The Google Play services SDK contains the interfaces to the functionality provided by the Google Play services APK, running as background services. The functionality required by the current, released SDK versions is already present on ICS devices with Google Play services and will continue to work without change.

    With the SDK version changes earlier this year, each library can be independently released and may update its own minSdkVersion. Individual libraries are not required to change based on this deprecation. Newer SDK components may continue to support API levels 14 and 15 but many will update to require the higher API level. For applications that support API level 16 or greater, you will not need to make any changes to your build. For applications that support API levels 14 or 15, you may continue to build and publish your app to devices running ICS, but you will encounter build errors when updating to newer SDK versions. The error will look like this:

    Error:Execution failed for task ':app:processDebugManifest'.
    > Manifest merger failed : uses-sdk:minSdkVersion 14 cannot be smaller than version 16 declared in library [com.google.android.gms:play-services-FOO:16.X.YY]
            Suggestion: use tools:overrideLibrary="com.google.android.gms:play_services" to force usage
    

    Unfortunately, the stated suggestion will not help you successfully run your app on older devices. In order to use the newer SDK, you will need to use one of the following options:

    1. Target API level 16 as the minimum supported API level.

    This is the recommended course of action. To discontinue support for API levels that will no longer receive Google Play services updates, simply increase the minSdkVersion value in your app's build.gradle to at least 16. If you update your app in this way and publish it to the Play Store, users of devices with less than that level of support will not be able to see or download the update. However, they will still be able to download and use the most recently published version of the app that does target their device.

    A very small percentage of all Android devices are using API levels less than 16. You can read more about the current distribution of Android devices. We believe that many of these old devices are not actively being used.

    If your app still has a significant number of users on older devices, you can use multiple APK support in Google Play to deliver an APK that uses Google Play services 14.7.99. This is described below.

    2. Build multiple APKs to support devices with an API level less than 16.

    Along with some configuration and code management, you can build multiple APKs that support different minimum API levels, with different versions of Google Play services. You can accomplish this with build variants in Gradle. First, define build flavors for legacy and newer versions of your app. For example, in your build.gradle, define two different product flavors, with two different compile dependencies for the stand-in example play-services-FOO component:

    productFlavors {
        legacy {
            minSdkVersion 14
            versionCode 1401  // Min API level 14, v01
        }
        current {
            minSdkVersion 16
            versionCode 1601  // Min API level 16, v01
        }
    }
    
    dependencies {
        legacyCompile 'com.google.android.gms:play-services-FOO:16.0.0'
        currentCompile 'com.google.android.gms:play-services-FOO:17.0.0'
    }
    

    In the above situation, there are two product flavors being built against two different versions of play-services-FOO. This will work fine if only APIs are called that are available in the 16.0.0 library. If you need to call newer APIs made available with 17.0.0, you will have to create your own compatibility library for the newer API calls so that they are only built into the version of the application that can use them:

    1. Declare a Java interface that exposes the higher-level functionality you want to perform that is only available in current versions of Play services.
    2. Build two Android libraries that implement that interface. The "current" implementation should call the newer APIs as desired. The "legacy" implementation should no-op or otherwise act as desired with older versions of Play services. The interface should be added to both libraries.
    3. Conditionally compile each library into the app using "legacyCompile" and "currentCompile" dependencies as illustrated for play-services-FOO above.
    4. In the app's code, call through to the compatibility library whenever newer Play APIs are required.

    After building a release APK for each flavor, you then publish them both to the Play Store, and the device will update with the most appropriate version for that device. Read more about multiple APK support in the Play Store.

    December 6th 2018, 6:22 pm

    Improve media and messaging app integrations with Android Auto

    Android Developers Blog

    Posted by John Posavatz, Product Manager, Android Auto

    At Google I/O this past May, we provided a sneak preview of several new media and messaging features for Android Auto. We are happy to announce that these features are now ready in our latest version of Android Auto, and we encourage you to update your Android Auto implementations to take advantage of them!

    New Media Features

    Several new features make it easier for users to find the media content that they're looking for. Check out the full documentation for them on our Android developer site.

    Search results

    After performing an Assistant-based search (e.g. "OK Google, play [artist / album / playlist / book / song / genre]"), music auto-plays as before, and in addition you can now provide your own list of categorized results. First, you'll need to declare support for onSearch() in your MediaBrowserServiceCompat implementation, and then override it. Android Auto forwards a user's search terms to this method whenever a user invokes the "Show more results" affordance.

    Android Auto calls onSearch with the same Bundle of extras as the one defined for Android Auto's playFromSearch() calls. Unlike playFromSearch(), onSearch() includes a Result> that can be used to return multiple MediaItems back to Android Auto for display.

    You can then categorize search results using title items. For example, music apps may include categories such as "Artists", "Albums" and "Songs".

    Improved browse

    Content has been "brought forward" out of the drawer, and now resides within the main view of the media screen. Within this new layout, you now have an option of either displaying your browse trees as a simple list, or you can optionally display large grids of album art / icons. We recommend using lists wherever the text description is most useful in describing content (e.g. a list of track names or podcast episodes), whereas the larger grid view is most appropriate where the album / icon aids in quick identification and selection.

    To start applying content styles, you should set a global default for how your media items are displayed by applying specific constants in the BrowserRoot extras bundle returned by the onGetRoot() function. Android Auto reads the extras associated with each item in the browse tree and looks for specific constants (detailed in our documentation), and then use the presence/value of each key to add the appropriate indicator.

    In order to change the default behavior for a specific node, the Content Style API supports overriding the default global hint for any browsable node's children. The same extras as above can be supplied as extras in the MediaDescription. If these extras are present, then the children of that browsable node will have the new Content Style hint.

    Finally, you can organize content using title items to group media in a list. To do this, every media item in the group needs to declare an extra in their media description with the same string value, which you can localize. This value is used as the group title. You also need to pass the media items together and in the order you want them displayed.

    Additional metadata icons

    In both browsing and playback views, you are now able to show icons next to media items which have explicit language, have been downloaded to the user's device, and which are unplayed / partially played / completed (e.g. for audiobooks and podcasts).

    Android Auto inspects extras for each item in the browse tree and looks for the specific keys for the indicators, and then uses the presence/value of each key to add the appropriate indicator.

    You should add these extras to content returned by your MediaBrowse Service. "Explicit" and "Downloaded" are boolean extras (set to true to show the indicator), while "Completion State" is an integer extra set to the appropriate value. Apps should create an extras bundle that includes one or more of these keys and pass that to MediaDescription.Builder.setExtras().

    Updates to Messaging

    We are deprecating CarExtender, in favor of the more robust and broadly beneficial MessagingStyle API. Migrating to MessagingStyle is very straightforward, and not only extends messaging support beyond Android Auto (for example, to Google Assistant), but it also brings the following immediate benefits for Android Auto:

    Group messaging

    Formerly, Android Auto's support for group messages was lacking - in most cases, notifications were never shown. MessagingStyle addresses that, so that your users never miss a message.

    MMS / RCS support

    Android Auto only supports SMS natively through the system SMS broadcast. MessagingStyle allows support for SMS apps that themselves support RCS and MMS.

    To enable your app to provide messaging service for Auto devices, your app must do the following:

    1. Build and send NotificationCompat.MessagingStyle objects that contain reply and mark-as-read Action objects.
    2. Handle replying and marking a conversation as read with a Service.
    3. Configure your manifest to indicate the app supports Android Auto.

    By moving to MessagingStyle, your app will not only gain automotive support, but also gain a richer mobile notification experience including inline replying, image preview, and conversation history; all within the notification shade.

    An in-depth guide to implementing (or updating to) MessagingStyle can be found in our online developer documentation.

    Thanks for continuing to support Android Auto!

    December 5th 2018, 6:34 pm

    Android codelab courses are here!

    Android Developers Blog

    Jocelyn Becker, Senior Program Manager, Google Developer Training

    The Google Developers Training team recently published an updated version of our Android Developer Fundamentals course as a series of Google codelabs.

    Codelabs made their debut as onsite tutorials at Google I/O in 2015, and have skyrocketed in popularity as a way for developers to learn how to use Google technologies, APIs, and SDKs. A codelab is a short, self-contained tutorial that walks you through how to do a specific task. More than 2 million users have worked through Google codelabs this year.

    Our Android courses were originally intended as classroom-based courses. However, we found that many people work through the courses on their own, outside of formal teaching programs. So, when we updated the Android Developer Fundamentals course, in addition to supporting classroom-based learning, we made the material available as a sequential series of codelabs.

    Android Developer Fundamentals course

    The updated Android Developer Fundamentals (V2) course includes lessons on using the Room database and other Architecture Components. All the apps have been updated to reflect that the Empty Activity template in Android Studio uses ConstraintLayout, and we've updated all apps to a later version of Android Studio. For more details on the differences, see the release notes.

    Advanced Android course

    We've also re-published the Advanced Android Developer course as a series of codelabs. This course provides step-by-step instructions for learning about more advanced topics, and adding features to your app to improve user engagement and delight. Learn how to add maps to your apps, create custom views, use SurfaceView to draw directly to the screen, and much more.

    Teaching materials for both courses

    If you want to teach either course in the classroom, or use it as the basis of a study jam, the complete package is still available, including slide decks, source code in GitHub, and concept guides, in addition to the step-by-step codelabs.

    December 4th 2018, 2:09 pm

    Celebrating the developers behind the best apps and games of 2018

    Android Developers Blog

    Posted by Purnima Kochikar, Director, Business Development, Games & Applications

    Today, we announced our annual Best of 2018 list, highlighting the best content on Google Play. But ever wonder about the makers behind your favorite apps and games like PUBG MOBILE or Tasty? Well, we wanted to take a moment to celebrate the developers that brought to life the best U.S. apps and games of 2018. And this year was jam packed with entertainment — all thanks to the developers who pushed the envelope and sparked our imaginations.

    Check out the full rundown of the developers behind the best apps and games of 2018 on Google Play:

    Best App of 2018

    Most Entertaining Apps

    Best Self Improvement Apps

    Best Daily Helper Apps

    Best Hidden Gem Apps

    Best Game of 2018

    Most Competitive Games

    Most Innovative Games

    Best Indie Games

    Most Casual Games

    December 3rd 2018, 1:06 pm

    SDK Developers: sign up to stay up to date with latest tips, news and updates

    Android Developers Blog

    Posted by Parul Soi, Strategic Partner Development Manager, Google Play

    Android is fortunate to have an incredibly rich ecosystem of SDKs and libraries to help developers build great apps more efficiently. These SDKs can range from developer tools that simplify complicated feature development to end-to-end services such as analytics, attribution, engagement, etc. All of these tools can help Android developers reduce cost and ship products faster.

    For the past few months, various teams at Google have been working together on new initiatives to expand the resources and support we offer for the developers of these tools. Today, SDK developers can sign up and register their SDK with us to receive updates that will keep you informed about Google Play policy changes, updates to the platform, and other useful information.

    Our goal is to provide you with whatever you need to better serve your technical and business goals in helping your partners create better apps or games. Going forward we will be sharing further resources to help SDK developers, so stay tuned for more updates.

    If you develop an SDK or library for Android, make sure you sign up and register your SDK to receive updates about the latest tools and information to help serve customers better. And, if you're an app developer, share this blogpost with the developers of the SDKs that you use!

    How useful did you find this blog post?

    November 30th 2018, 1:52 pm

    Fast Pair Update

    Android Developers Blog

    Posted by Seang Chau (VP Engineering)

    Last year we announced Fast Pair, a set of specs that make it easier to connect Bluetooth headsets and speakers to Android devices.

    Today, we're making it easier for people to connect Fast Pair compatible accessories to devices associated with the same Google Account. Fast Pair will connect accessories to a user's current and future Android phones (6.0+), and we're adding support for Chromebooks in 2019.

    Fast Pair provides stress-free Bluetooth pairing for your Android phone.

    We have been working closely with dozens of manufacturers, many of which are bringing new Fast Pair compatible devices to market over the coming months. This includes Jaybird, who is already selling the Tarah Wireless Sport Headphones, as well as upcoming products from prominent brands such as Anker SoundCore, Bose, and many more.

    The Jaybird Tarah, Fast Pair compatible sport headphones already available in the market.

    We also want to make it easy for manufacturers to ship compatible products with minimal additional engineering effort. We collaborated with industry leading Bluetooth audio companies such as Airoha Technology Corp., BES and Qualcomm Technologies International, Ltd. (QTIL) to add native Fast Pair support to their software development kits.

    If you are a manufacturer interested in creating Fast Pair compatible Bluetooth devices, just head to our Nearby Devices console to register your product and validate that it has correctly implemented the Fast Pair specs.

    November 27th 2018, 1:01 pm

    Wear OS by Google: final API 28 emulator with new redesigned UI

    Android Developers Blog

    Posted by Hoi Lam, Lead Developer Advocate

    Today, we are launching the final API 28 emulator image for developers. This image will also contain the UI redesign we announced in August. You should verify that your app's notification works well with the new notification steam, and that your apps work well against changes previously announced for API 28.

    What's new in API 28?

    Here are the highlights of the API 28 emulator:

    Please note that changes related to the new notification stream are being rolled out to devices supporting API 25 and up. You can test how your notification will behave now, before roll-out is complete, by using the API 28 emulator image.

    Keep your feedback coming

    Just because we are now in release build does not mean that our work stops here. Please continue to submit all bug / enhancement requests via the Wear OS by Google issue tracker.

    Finally, we are grateful for all of your valuable feedback during the developer preview. It played an important role in our decision making process - especially concerning App Standby Buckets. Thank you!

    November 20th 2018, 1:00 pm

    Getting screen brightness right for every user

    Android Developers Blog

    Posted by Ben Murdoch, Software Engineer and Michael Wright, Android Framework Engineer

    The screen on a mobile device is critical to the user experience. The improved Adaptive Brightness feature in Android P automatically manages the display to match your preferences for brightness level so you get the best experience, whatever the current lighting environment.

    Screen brightness in Android is managed via Quick Settings or via the settings app

    (Settings → Display → Brightness Level).

    In Android Pie, Adaptive Brightness is enabled by default (Settings → Display → Adaptive Brightness).

    While enabled, Android automatically selects a screen brightness that's suitable for the user's current ambient light conditions. Prior to Android Pie, the brightness slider didn't represent an absolute screen brightness level, but a global adjustment factor for boosting or reducing the device manufacturer's preset screen brightness curve across all ambient light levels:

    * Setting the slider to center resulted in the device using the preset.

    * Setting the slider to the left of center applied a negative scale factor, making the screen dimmer than the preset.

    * Setting the slider to the right of center applied a positive scale factor, making the screen brighter than the preset.

    So, under low ambient light conditions, you might prefer a brighter screen than the preset level and move the brightness slider up accordingly. But, because that adjustment would boost the brightness at all ambient light levels, you might find yourself needing to move the brightness slider back down in brighter ambient light. And so on, back and forth.

    To improve this experience, we've introduced two important changes to screen brightness in Android Pie:

    1. Better slider control
    2. Personalization of the brightness level

    Better slider control

    The slider control now represents absolute screen brightness rather than the global adjustment factor. That means that you may see it move on its own while Adaptive Brightness is on. This is expected behavior!

    Humans perceive brightness on a logarithmic rather than linear scale1. That means changes in screen brightness are much more noticeable when the screen is dark versus bright. To match this difference in perception, we updated the brightness slider UI in the notification shade and System Settings app to work on a more human-like scale. This means you may need to move the slider farther to the right than you did on previous versions of Android for the same absolute screen brightness, and that when setting a dark screen brightness you have more precise control over exactly which brightness to set.

    Personalization of screen brightness

    Prior to Android P, when developing a new Android device the device manufacturer would determine a baseline mapping from ambient brightness to screen brightness based on the display manufacturer's recommendation and a bit of experimentation. All users of that device would receive the same baseline mapping and, while using the device, move the brightness slider around to set their global adjustment factor. To determine the final screen brightness, the system would first look at the room brightness and the baseline mapping to find the default screen brightness for that situation, and then apply the global adjustment factor.

    What we found is that in many cases this global adjustment factor didn't adequately capture personal preferences - that is, users tended to change the slider often for new lighting environments.

    For Android Pie we worked with researchers from DeepMind to build a machine learning model that will observe the interactions that a user makes with the screen brightness slider, and train on-device to personalise the mapping of ambient light level to screen brightness.

    This means that Android will learn what screen brightness is comfortable for a user in a given lighting environment. The user teaches it by manually adjusting the slider, and, as the software trains over time, the user should need to make fewer manual adjustments. In testing the feature, we've observed that after a week almost half our test users are making fewer manual adjustments while the total number of slider interactions across all internal test users was reduced by over 10%. The model that we've developed is updatable and will be tuned based on real world usage now that Android Pie has been released. This means that the model will continue to get better over time.

    We believe that screen brightness is one of those things that should just work, and these changes in Android Pie are a step towards realizing that. For the best performance no matter where you are models run directly on the device rather than the cloud, and train overnight while the device charges.

    The improved Adaptive Brightness feature is now available on Pixel devices and we are working with our OEM partners now to incorporate Adaptive Brightness into Android Pie builds for their devices.

    Notes

    November 19th 2018, 2:26 pm

    Combating Potentially Harmful Applications with Machine Learning at Google: Datasets and Models

    Android Developers Blog

    Posted by Mo Yu, Android Security & Privacy Team

    In a previous blog post, we talked about using machine learning to combat Potentially Harmful Applications (PHAs). This blog post covers how Google uses machine learning techniques to detect and classify PHAs. We'll discuss the challenges in the PHA detection space, including the scale of data, the correct identification of PHA behaviors, and the evolution of PHA families. Next, we will introduce two of the datasets that make the training and implementation of machine learning models possible, such as app analysis data and Google Play data. Finally, we will present some of the approaches we use, including logistic regression and deep neural networks.

    Using machine learning to scale

    Detecting PHAs is challenging and requires a lot of resources. Our security experts need to understand how apps interact with the system and the user, analyze complex signals to find PHA behavior, and evolve their tactics to stay ahead of PHA authors. Every day, Google Play Protect (GPP) analyzes over half a million apps, which makes a lot of new data for our security experts to process.

    Leveraging machine learning helps us detect PHAs faster and at a larger scale. We can detect more PHAs just by adding additional computing resources. In many cases, machine learning can find PHA signals in the training data without human intervention. Sometimes, those signals are different than signals found by security experts. Machine learning can take better advantage of this data, and discover hidden relationships between signals more effectively.

    There are two major parts of Google Play Protect's machine learning protections: the data and the machine learning models.

    Data sources

    The quality and quantity of the data used to create a model are crucial to the success of the system. For the purpose of PHA detection and classification, our system mainly uses two anonymous data sources: data from analyzing apps and data from how users experience apps.

    App data

    Google Play Protect analyzes every app that it can find on the internet. We created a dataset by decomposing each app's APK and extracting PHA signals with deep analysis. We execute various processes on each app to find particular features and behaviors that are relevant to the PHA categories in scope (for example, SMS fraud, phishing, privilege escalation). Static analysis examines the different resources inside an APK file while dynamic analysis checks the behavior of the app when it's actually running. These two approaches complement each other. For example, dynamic analysis requires the execution of the app regardless of how obfuscated its code is (obfuscation hinders static analysis), and static analysis can help detect cloaking attempts in the code that may in practice bypass dynamic analysis-based detection. In the end, this analysis produces information about the app's characteristics, which serve as a fundamental data source for machine learning algorithms.

    Google Play data

    In addition to analyzing each app, we also try to understand how users perceive that app. User feedback (such as the number of installs, uninstalls, user ratings, and comments) collected from Google Play can help us identify problematic apps. Similarly, information about the developer (such as the certificates they use and their history of published apps) contribute valuable knowledge that can be used to identify PHAs. All these metrics are generated when developers submit a new app (or new version of an app) and by millions of Google Play users every day. This information helps us to understand the quality, behavior, and purpose of an app so that we can identify new PHA behaviors or identify similar apps.

    In general, our data sources yield raw signals, which then need to be transformed into machine learning features for use by our algorithms. Some signals, such as the permissions that an app requests, have a clear semantic meaning and can be directly used. In other cases, we need to engineer our data to make new, more powerful features. For example, we can aggregate the ratings of all apps that a particular developer owns, so we can calculate a rating per developer and use it to validate future apps. We also employ several techniques to focus in on interesting data.To create compact representations for sparse data, we use embedding. To help streamline the data to make it more useful to models, we use feature selection. Depending on the target, feature selection helps us keep the most relevant signals and remove irrelevant ones.

    By combining our different datasets and investing in feature engineering and feature selection, we improve the quality of the data that can be fed to various types of machine learning models.

    Models

    Building a good machine learning model is like building a skyscraper: quality materials are important, but a great design is also essential. Like the materials in a skyscraper, good datasets and features are important to machine learning, but a great algorithm is essential to identify PHA behaviors effectively and efficiently.

    We train models to identify PHAs that belong to a specific category, such as SMS-fraud or phishing. Such categories are quite broad and contain a large number of samples given the number of PHA families that fit the definition. Alternatively, we also have models focusing on a much smaller scale, such as a family, which is composed of a group of apps that are part of the same PHA campaign and that share similar source code and behaviors. On the one hand, having a single model to tackle an entire PHA category may be attractive in terms of simplicity but precision may be an issue as the model will have to generalize the behaviors of a large number of PHAs believed to have something in common. On the other hand, developing multiple PHA models may require additional engineering efforts, but may result in better precision at the cost of reduced scope.

    We use a variety of modeling techniques to modify our machine learning approach, including supervised and unsupervised ones.

    One supervised technique we use is logistic regression, which has been widely adopted in the industry. These models have a simple structure and can be trained quickly. Logistic regression models can be analyzed to understand the importance of the different PHA and app features they are built with, allowing us to improve our feature engineering process. After a few cycles of training, evaluation, and improvement, we can launch the best models in production and monitor their performance.

    For more complex cases, we employ deep learning. Compared to logistic regression, deep learning is good at capturing complicated interactions between different features and extracting hidden patterns. The millions of apps in Google Play provide a rich dataset, which is advantageous to deep learning.

    In addition to our targeted feature engineering efforts, we experiment with many aspects of deep neural networks. For example, a deep neural network can have multiple layers and each layer has several neurons to process signals. We can experiment with the number of layers and neurons per layer to change model behaviors.

    We also adopt unsupervised machine learning methods. Many PHAs use similar abuse techniques and tricks, so they look almost identical to each other. An unsupervised approach helps define clusters of apps that look or behave similarly, which allows us to mitigate and identify PHAs more effectively. We can automate the process of categorizing that type of app if we are confident in the model or can request help from a human expert to validate what the model found.

    PHAs are constantly evolving, so our models need constant updating and monitoring. In production, models are fed with data from recent apps, which help them stay relevant. However, new abuse techniques and behaviors need to be continuously detected and fed into our machine learning models to be able to catch new PHAs and stay on top of recent trends. This is a continuous cycle of model creation and updating that also requires tuning to ensure that the precision and coverage of the system as a whole matches our detection goals.

    Looking forward

    As part of Google's AI-first strategy, our work leverages many machine learning resources across the company, such as tools and infrastructures developed by Google Brain and Google Research. In 2017, our machine learning models successfully detected 60.3% of PHAs identified by Google Play Protect, covering over 2 billion Android devices. We continue to research and invest in machine learning to scale and simplify the detection of PHAs in the Android ecosystem.

    Acknowledgements

    This work was developed in joint collaboration with Google Play Protect, Safe Browsing and Play Abuse teams with contributions from Andrew Ahn, Hrishikesh Aradhye, Daniel Bali, Hongji Bao, Yajie Hu, Arthur Kaiser, Elena Kovakina, Salvador Mandujano, Melinda Miller, Rahul Mishra, Damien Octeau, Sebastian Porst, Chuangang Ren, Monirul Sharif, Sri Somanchi, Sai Deep Tetali, Zhikun Wang, and Mo Yu.

    November 15th 2018, 2:26 pm

    An Update on Project Treble

    Android Developers Blog

    Posted by Iliyan Malchev, Project Treble Architect

    Last week at the 2018 Android Dev Summit, we demonstrated the benefits of Project Treble by showing the same Generic System Image (GSI) running on devices from different OEMs. We highlighted the availability of GSI for Android 9 Pie that app developers can use to develop and test their apps with Android 9 on any Treble-compliant device.

    Launched with Android Oreo in 2017, Project Treble has enabled OEMs and silicon vendors to develop and deploy Android updates faster than what was previously possible. Since then, we've been working with device manufacturers to define Vendor Interfaces (VINTF) and draw a clear separation between vendor and framework code on Android devices.

    Going forward, all devices launching with Android 9 Pie or later will be Treble-compliant and take full advantage of the Treble architecture to deliver faster upgrades. Thanks to Treble, we expect to see more devices from OEMs running Android 9 Pie at the end of 2018 as compared to the number of devices that were running Android Oreo at the end of 2017.

    The GSI is built from the latest available AOSP source code, including the latest bug fixes contributed by OEMs. Device manufacturers already use GSI to validate the implementation of the vendor interface on their devices, and Android app developers can now harness the power of the GSI to test their apps across different devices. With GSI, you can test your apps on a pure AOSP version of the latest Android dessert, including the latest features and behavior changes, on any Treble-compliant device that's unlocked for flashing.

    We're continuing to work on making GSI even more accessible and useful for app developers. For example, the GSI could enable early access to future Android platform builds that you can run on a Treble-compliant Android 9 device, so you could start app development and validation before the AOSP release.

    If you are interested in trying GSI today, check out the documentation for full instructions on how to build GSI yourself and flash it to your Treble-compliant device.

    November 14th 2018, 8:11 pm

    Get your app ready for foldable phones

    Android Developers Blog

    Posted by Leo Sei, Product Manager on Android

    As you may have heard from the Android Dev Summit, we announced that we're expanding support in Android to include Foldables, in preparation for upcoming devices from hardware partners like Samsung.

    Here are a set of recommendations and information to make sure your application provides a great user experience on this new form factor (you can also check out the Android Dev Summit dedicated session here)

    1. Screen continuity

    On this new form factor, your application could be transitioned from one screen to another automatically (eg. when folding / unfolding a foldable phone).

    During this transition, your app will receive a configuration change for the new layout (and possibly density in some cases).

    To provide a great user experience when changing from one screen to the other, you want to make sure your app properly support runtime configuration change.

    How to test: Emulators for various devices should become available soon (eg., Samsung will publish a folding / unfolding emulator apk later in Q4 which should work on Samsung Galaxy S4 tablets as well as the AOSP emulator in Android studio).

    2. Multi-resume

    Today, when an app is in multi-window but not focused, it is on the OnPause state.

    While we provide recommendations on how to support multi-window, we noticed a significant number of apps are not handling the onPause state according to those recommendations (video paused or stopped, instant messages not displayed etc).

    To help developers provide the best user experience on multi-window with minimal effort, we're allowing device manufacturers to keep all apps resumed when in multi-windows in P.

    To opt-in to this behavior in Android P, add the following meta-data in your app manifest:

    <meta-data android:name="android.allow_multiple_resumed_activities" android:value="true" />

    Note: With the next Android version we're looking into how to optimize compatibility for this behavior.

    How to test: There are no device at the moment with this behavior but device manufacturers are working to update existing devices to allow developers to test. Stay tuned for more details from device manufacturers.

    3. Multi-display

    Beginning with Android 8.0 (API level 26), the platform offers enhanced support for multiple displays. If an activity supports multi-window mode and is running on a device with multiple displays, users can move the activity from one display to another. When an app launches an activity, the app can specify which display the activity should run on. See here for the full documentation

    How to test: You can try it out by using the "Developer options > Simulate secondary displays" option. Keep in mind that those simulated display do not process inputs.

    November 9th 2018, 1:59 pm

    Unfolding right now at #AndroidDevSummit!

    Android Developers Blog

    Posted by Stephanie Cuthbertson, Director of Product Management

    Today, at the Computer History Museum in Mountain View, CA, we kicked off the Android Dev Summit, taking a look back at the last 10 years of Android and then jumping into some important new features for Android developers. Here's a look at some of the things we shared!

    Unfolding Android into new experiences

    As early as Android 1.6, Android and our partners have contemplated different screen sizes and densities, enabling the platform to power a broad category of form factors and new experiences like Android TV, Android Auto, Wear OS and even Android apps on Chromebooks. Phone screens are an area where Android partners set the bar, introducing "phablets" when phone screens were small. Fast forward to today, when a phablet is... just a phone, a standard size users have come to love.

    Now we see a Android device makers creating a new category: Foldables. Taking advantage of new flexible display technology, the screen can literally bend and fold.

    There are two variants broadly speaking: two-screen devices and one-screen devices. When folded, foldables look like phones, fitting in your pocket or purse. When unfolded, their defining feature is what we call screen continuity. For example, start a video with the folded smaller screen - and later you can sit down and unfold the device to get a larger tablet-sized screen for a beautiful, immersive experience. As you unfold, the app seamlessly transfers to the bigger screen without missing a beat. We're optimizing Android for this new form factor. And, making changes to help developers everywhere take advantage of the possibilities this creates for amazing new experiences, new ways to engage and delight your users. Tune in to the Foldables session at Dev Summit this week to learn more. Expect to see Foldables coming from several Android manufacturers, including one Samsung previewed today and plans to offer next year.

    Kotlin: updates to the fastest growing language

    We made Kotlin a first class language on Android in 2017. This month we had over 118,000 new projects using Kotlin started in Android Studio - from those users who opt in to share metrics. That's a 10X increase from last year. It's become the fastest growing language in terms of growth of number of contributors on GitHub, and voted the #2 most loved language on Stack Overflow. In our surveys, the more developers use Kotlin, the higher their satisfaction.

    Last week, JetBrains released the latest version of Kotlin, 1.3, which brings new language features, APIs, bug fixes, and performance improvements:

    All of these new features of Kotlin 1.3 will be integrated into the Kotlin-specific APIs that we provide–a majority of which are through KTX extensions as part of Jetpack.

    Android Jetpack: Navigation, Work Manager, and Slices

    At Google I/O we announced Jetpack, the next generation of tools and Android APIs to accelerate Android application development. Jetpack builds on the foundations laid out by Support Library and Architecture. Already, 80% of top 1,000 apps and games are using one of the new Jetpack libraries in production.

    This summer we moved AndroidX - Jetpack's evolution of the original Android Support Library - to public AOSP. This means you can see features and bug fixes implemented in real-time, and contribute to any of the AndroidX libraries. You can learn more about contributing here.

    We've been working to get as much feedback and refinement as possible on two new Architecture Component libraries: Navigation and Work Manager, and we plan to move both to Beta this month. The Navigation Architecture Component offers a simplified way to implement Android's navigation principles in your application, using a single Activity. Plus, the new Navigation Editor in Android Studio creates and edits your navigation architecture. This eliminates navigation boilerplate, gives you atomic navigation operations, easier animated transitions and more. WorkManager makes it easy to perform background tasks in the most efficient manner, choosing the most appropriate solution based on the application state and device API level.

    Navigation Editor

    We're also excited to see Android Slices move to public Search experiments! At I/O this year we introduced Slices, a new way to bring users to your app. Slices are like a mini snippet of your app, where you can surface content and actions. You can book a flight, play a video, or call a ride. Slices is another example where we want to be open very early, but we want to take the time to get it right. We're moving into public EAP this month with Doist, Kayak and others. We'll run experiments surfacing Slices in Google search results. To learn more, there's also a session today at Dev Summit with more info and best practices.

    Android Studio: focusing on productivity, build speed, quality and fundamentals

    Android Studio is our official IDE for Android development. We asked where do you spend the most time? When we gather data from Android Studio's opted-in users we see that build time are getting faster with every release, sometimes as fast as 20%, but we also see build time getting slower and slower over time. So, how can both things be true? We've been digging in hard to understand.

    It turns out build is a pretty complicated ecosystem. Developer choices makes a huge difference. Our developers are using a very broad (and growing) combination of OSes, custom plug-ins, annotation processors, languages. All of these can significantly affect times. In one case, a plugin some users like to add was silently slowing build speeds by up to 45%. Learning this, we realized we need build profiling and analysis tools so you can easily understand what's slowing your build down. We're also investing more in our own plugins to accelerate performance to make sure we continue to improve the performance of core build.

    Android Studio 3.3 launches beta 3 today. In coming releases expect to see a strong focus on quality and fundamentals: reducing the number of crashes and hangs, optimizing memory usage, and fixing user-impacting bugs. We also announced today that we're making Android Studio an officially supported IDE on Chrome OS early next year; learn more here.

    Android App Bundles and dynamic features

    App sizes have grown dramatically, up 5x since 2012. But larger apps have downsides: lower install conversion rates, lower update rates, and higher uninstalls. This is why we built the Android App Bundle, the new publishing format that serves only the code and resources a user needs to run your app on their specific device; on average apps see 35% size savings compared to a universal APK. The app bundle also saves you time and effort with each release since you don't need to use incomplete solutions like multi-APK. Android Studio 3.2 brought full IDE support of app bundles, and there are now thousands of app bundles in production totaling billions of installs, including Google's apps like YouTube, Google Maps, Google Photos, and Google News.

    The app bundle now supports uncompressed native libraries; with no additional developer work needed, the app bundle now makes apps using native libraries an average of 8% smaller to download and 16% smaller on disk on M+ devices.

    Once you switch to the app bundle you can also start modularizing your app. With dynamic feature modules, you can load any app functionality on demand instead of at install time. You don't need to keep big features that are only used once, on every single device forever; dynamic features can be installed and uninstalled dynamically when your app requests them.

    In-app Updates API

    We've heard that you'd like more controls to ensure that users are running the latest and greatest version of your app. To address this, we're launching an In-app Updates API. We're testing the API with early access partners and will be launching it to all developers soon.

    You'll have two options with this API; the first is a full-screen experience for critical updates when you expect the user to wait for the update to be applied immediately. The second option is a flexible update, which means the user can keep using the app while the update is downloaded. You can completely customize the update flow so it feels like part of your app.

    Instant discovery

    We're also making instant apps easier than ever to adopt. We recently made using web URLs optional, enabling you to take your existing play store deep link traffic and send users to your instant experience if it's available. Additionally, we've raised the instant app size limit to 10MB for the Try Now button on the Play Store and web banners to make it even easier to adopt.

    In the Android Studio 3.3 beta, you can now build an instant-enabled app bundle. This means that you can now build and deploy both your Instant and installed experiences from a single Android Studio project, and include them in a single Android App Bundle. You only have to upload just ONE artifact for both instant and installed app.

    As developers, your feedback has been critical in shaping these investment areas; you are part of how we work, from early ideas, to EAPs and canaries, Beta, and iterating after launch. We hope you join us for the next two days whether you're watching the 30+ sessions on the livestream, joining social, or with us in-person in Mountain View. From the team, a sincere thank you for all your thoughtful feedback and contributions. We hope you enjoy Android Dev Summit.

    November 7th 2018, 2:14 pm

    R8, the new code shrinker from Google, is available in Android studio 3.3 beta

    Android Developers Blog

    Posted by Leo Sei, Product Manager on Android Studio and R8

    Android developers know that APK size is an important factor in user engagement. Code shrinking helps reduce the size of your APK by getting rid of unused code and resources as well as making your actual code take less space (also known as minification or obfuscation).

    That's why we're investing in improving code shrinking to make it faster and more efficient. We're excited to announce that the next generation code shrinker, R8, is available for preview as part of Android Studio 3.3 beta.

    R8 does all of shrinking, desugaring and dexing in one step. When comparing to the current code shrinking solution, Proguard, R8 shrinks the code faster while improving the output size.

    The following data comes from benchmark on the Santa Tracker app, you can find the project with benchmark details on this GitHub repository.

    How to try it

    R8 is available with Android Studio 3.3 beta and works with Proguard rules. To try it, set the following in your project's gradle.properties file:

    android.enableR8=true

    For the more adventurous, R8 also has full mode that is not directly compatible with Proguard. In order to try that out you can additionally set the following in your gradle.properties file:

    android.enableR8.fullMode=true

    This turns on more optimizations, that can further reduce app size. However, you might need a few extra keep rules to make it work.

    We have tested R8 correctness and performances on a number of apps and the results are promising so we plan to switch R8 as the default shrinker in Android studio soon.

    Please give R8 a try and we would love to hear your feedback. You can file a bug report using this link.

    November 5th 2018, 2:08 pm

    The Android Dev Summit app is live! Get ready for November 7-8

    Android Developers Blog

    Posted by Matt Pearring, Associate Product Marketing Manager, Developer Marketing

    In just a week, we'll be kicking off Android Dev Summit 2018, broadcasting live from the Computer History Museum in Mountain View, CA on November 7 and 8. We'll have two days of deep technical sessions from the Android engineering team, with over 30 sessions livestreamed. The app just went live; download it on Google Play and start planning.

    With the app you can explore the conference schedule with details on keynotes, sessions, and lightning talks. You can also plan your summit experience by saving events to your personalized schedule. This year's app is also an Instant app, so you can try it out first before installing it!

    [Android Dev Summit app screenshots]

    If you can't join in person, you can always join us online — we'll be livestreaming all of the sessions on the Android Dev Summit website or app and making them available on YouTube throughout the conference so you can watch at your own pace. Plus, we will share updates directly from the Computer History Museum to our social channels, so be sure to follow along!

    October 31st 2018, 5:44 pm

    Discontinuing support for Android Nearby Notifications

    Android Developers Blog

    Posted by Ritesh Nayak M, Product Manager

    Three years ago, we created Nearby Notifications as a way for Android users to discover apps and content based on what is nearby. Our goal was to bring relevant and engaging content to users - to provide useful information proactively. Developers have leveraged this technology to let users know about free wifi nearby, provide guides while in a museum, and list transit schedules at bus stops.

    We've learned a lot building and launching Nearby Notifications. However, earlier this year, we noticed a significant increase in locally irrelevant and spammy notifications that were leading to a poor user experience. While filtering and tuning can help, in the end, we have a very high bar for the quality of content that we deliver to users, especially content that is delivered through notifications. Ultimately, we have determined these notifications did not meet that bar. As a result, we have decided to discontinue support for Nearby Notifications. We will stop serving Nearby Notifications on December 6th, 2018.

    What does it mean for Android users

    Android users will stop receiving Nearby Notifications.

    What does it mean for developers

    On December 6th we will stop delivering both Eddystone and Physical Web beacon notifications. You will still continue to have access to the beacon dashboard and can deliver proximity based experiences similar to Nearby Notifications via your own apps using our Proximity Beacons API.

    We have two related APIs, Nearby Messages and Connections, that are available for developers to build device-to-device connectivity experiences, and also have Fast Pair, for device discovery and pairing. We will continue to invest in these APIs and support products using these technologies.

    We sincerely appreciate the efforts of the Android developer community in supporting and evolving Nearby technology and the feedback that has helped us improve. We look forward to continuing to deliver engaging proximity experiences to users and seeing what developers create within their apps with our APIs.

    October 25th 2018, 12:37 pm

    Free training for Android developers - learn how to succeed on Google Play

    Android Developers Blog

    Dan Lavelle, Head of Learning Operations, Google Play

    Having a great idea for an app or game is just the beginning. At Google Play, it's our goal to provide you with the tools and skills to build successful mobile app and games businesses. Training continues to be among the top requested features from Android developers, and we've heard your feedback.

    That's why we're launching a brand new, free e-learning platform to help you realize the full potential of your business on Google Play.

    Introducing Google Play's Academy for App Success

    Whether you're looking to grow your audience, understand performance metrics, or increase revenue, Play Academy is here to help you understand the best practices and Play Console features to succeed on Google Play. We built Play Academy to fit into your busy schedule. Learn from your home or office computer, or take courses on-the-go with your mobile device.

    Key features of Play Academy

    Learning paths

    Choose from 10 collections of bite-sized courses organized around features and best practices, including; Test your app before release, Evaluate your app's technical performance, and Monetize your app.

    Interactive lessons

    Learn through a rich multimedia and interactive e-learning experience.

    Assessments

    Test your new knowledge of key Play Console features and mobile app best practices.

    Achievements

    Get recognition for your new skills. Wear your achievement badges with pride on your Play Academy profile.

    Start learning today

    It's easy to get started with free e-learning content from Google Play. Head over to g.co/play/academy to sign up and start your developer journey. Also, make sure you keep an eye on upcoming Play Academy news - we'll regularly update our courses to keep pace with the newest features and programs so that you can stay up-to-date with the latest insights you'll need to grow your app or game business.

    How useful did you find this blog post?

    October 24th 2018, 1:11 pm

    Google Play offline peer to peer installs beta

    Android Developers Blog

    Posted by James Bender, Product Manager, Google Play

    In June we started adding security metadata to all apps and app updates to help verify product authenticity from Google Play. We're doing this is to help developers reach a wider audience, particularly in countries where peer-to-peer app sharing is common because of costly data plans and limited connectivity.

    Now, when a user shares an app via Play-approved partner peer-to-peer apps, Play will be able to determine shared app authenticity while a device is offline, add those shared apps to a user's Play Library, and manage app updates when the device comes back online. This will give users more confidence when using Play-approved peer-to-peer app beta partners, starting today with SHAREIt. Additional integrations from Files Go by Google and Xender are planned in the coming weeks. Please visit the Play Store to make sure you have the latest versions of these apps.

    This also benefits you as a developer as it provides a Play-authorized offline distribution channel and, since the peer-to-peer shared app is added to your user's Play library, your app will now be eligible for app updates from Play.

    No action is needed by developers or your users. This is an important step that improves the integrity of Google Play's mobile app ecosystem. Offline Play peer-to-peer sharing presents a new distribution opportunity for developers while helping more people keep their apps up to date.

    How useful did you find this blog post?

    October 19th 2018, 4:04 pm

    Android Protected Confirmation: Taking transaction security to the next level

    Android Developers Blog

    Posted by Janis Danisevskis, Information Security Engineer, Android Security

    In Android Pie, we introduced Android Protected Confirmation, the first major mobile OS API that leverages a hardware protected user interface (Trusted UI) to perform critical transactions completely outside the main mobile operating system. This Trusted UI protects the choices you make from fraudulent apps or a compromised operating system. When an app invokes Protected Confirmation, control is passed to the Trusted UI, where transaction data is displayed and user confirmation of that data's correctness is obtained.

    Once confirmed, your intention is cryptographically authenticated and unforgeable when conveyed to the relying party, for example, your bank. Protected Confirmation increases the bank's confidence that it acts on your behalf, providing a higher level of protection for the transaction.

    Protected Confirmation also adds additional security relative to other forms of secondary authentication, such as a One Time Password or Transaction Authentication Number. These mechanisms can be frustrating for mobile users and also fail to protect against a compromised device that can corrupt transaction data or intercept one-time confirmation text messages.

    Once the user approves a transaction, Protected Confirmation digitally signs the confirmation message. Because the signing key never leaves the Trusted UI's hardware sandbox, neither app malware nor a compromised operating system can fool the user into authorizing anything. Protected Confirmation signing keys are created using Android's standard AndroidKeyStore API. Before it can start using Android Protected Confirmation for end-to-end secure transactions, the app must enroll the public KeyStore key and its Keystore Attestation certificate with the remote relying party. The attestation certificate certifies that the key can only be used to sign Protected Confirmations.

    There are many possible use cases for Android Protected Confirmation. At Google I/O 2018, the What's new in Android security session showcased partners planning to leverage Android Protected Confirmation in a variety of ways, including Royal Bank of Canada person to person money transfers; Duo Security, Nok Nok Labs, and ProxToMe for user authentication; and Insulet Corporation and Bigfoot Biomedical, for medical device control.

    Insulet, a global leading manufacturer of tubeless patch insulin pumps, has demonstrated how they can modify their FDA cleared Omnipod DASH TM Insulin management system in a test environment to leverage Protected Confirmation to confirm the amount of insulin to be injected. This technology holds the promise for improved quality of life and reduced cost by enabling a person with diabetes to leverage their convenient, familiar, and secure smartphone for control rather than having to rely on a secondary, obtrusive, and expensive remote control device. (Note: The Omnipod DASH™ System is not cleared for use with Pixel 3 mobile device or Protected Confirmation).

    This work is fulfilling an important need in the industry. Since smartphones do not fit the mold of an FDA approved medical device, we've been working with FDA as part of DTMoSt, an industry-wide consortium, to define a standard for phones to safely control medical devices, such as insulin pumps. A technology like Protected Confirmation plays an important role in gaining higher assurance of user intent and medical safety.

    To integrate Protected Confirmation into your app, check out the Android Protected Confirmation training article. Android Protected Confirmation is an optional feature in Android Pie. Because it has low-level hardware dependencies, Protected Confirmation may not be supported by all devices running Android Pie. Google Pixel 3 and 3XL devices are the first to support Protected Confirmation, and we are working closely with other manufacturers to adopt this market-leading security innovation on more devices.

    October 19th 2018, 12:18 pm

    Playtime 2018: Helping you build better apps in a smaller bundle

    Android Developers Blog

    Posted by Matt Henderson, Product Manager, Google Play

    Today we are kicking off Playtime, our annual global event series, hosting over 800 attendees in Berlin and San Francisco to share insights from experts around the world and the latest updates on our products. This will be followed by events in Sao Paulo, Singapore, Taipei, Seoul, and Tokyo.

    At Google Play, we continue to invest in tools that make it easier for you to develop and distribute your apps to a global audience. Below are some of the exciting updates we are announcing today:

    Building smaller apps

    The Android App Bundle is Android's new publishing format, with which you can more easily deliver a great experience in a smaller app size. Smaller apps have higher conversion rates and our user research shows that app size is a leading motivator in driving uninstalls. With the Android App Bundle's modularization, you can also deliver features on demand, instead of at install time, further reducing the size of your app.

    Thousands of app bundles are already in production, with an average size reduction of 35%. Today, we are announcing updates that offer additional reasons for you to switch to the bundle.

    To learn more about the Android App Bundle, dynamic features, and all the benefits you receive from building a smaller, modular app, read our Medium post.

    Building a unified instant experience

    We've been listening to your feedback to make it easier to build instant apps, and we recently increased the size limit to 10MB to enable TRY NOW on the Play Store and removed the URL requirement. For game developers, we've partnered with Unity on a Google Play Instant plug-in and have built instant directly into the new Cocos Creator.

    We’re now using the Android App Bundle to solve one of the primary pain points of building instant apps. Previously, you needed to publish both an instant app and an installable app. With Android Studio 3.2, you could publish instant-enabled bundles but you were still required to publish a primary app bundle.

    Now, you don't have to maintain separate code. With the Android Studio 3.3 beta release, a developer can publish a single app bundle and classify it or a particular module to be instant enabled. The unified app bundle is the future of instant app experiences and we hope you will try it out.

    Extending instant trials

    Google Play Instant is now available for premium titles and pre-registration campaigns, so people can try your game before it launches and generate additional buzz. New apps and games join Google Play Instant every day, and we're excited to welcome Umiro, by Devolver Digital, and Looney Tunes World of Mayhem, by Scopely, as some of the first to take advantage of these new features.

    Reducing crash rates and improving quality

    The Play Console offers two tools to help you monitor performance and improve the quality of your apps. The pre-launch report runs your apps on real devices situated in the Firebase Test Lab and generates useful metadata to help you identify and fix issues before pushing your apps to production. Android vitals helps you track the performance and quality of your app on users' devices in the real world.

    Now, we're linking them together to provide more actionable insights. Whenever a real-world crash in Android vitals is also seen during a pre-launch report execution, you'll get all the extra metadata from the pre-launch report available to you in the Android vitals dashboard so you can debug more effectively. This is also linked in both directions, so that if a crash occurs in pre-launch reports that is already happening in the real world, you'll be able to see the current impact in Android vitals which will help you better prioritize the issues highlighted by pre-launch reports.

    Optimizing your app and business

    We've made several updates to make it easier to manage your app and business with Play.

    A new way to learn about Play

    We're equally excited to launch the Academy for App Success with new interactive courses to help developers get the most out of the Play Console, understand Play policies, and utilize best practices to improve quality and increase business performance. This free new program allows you to track your learning progress with quizzes and achievements to demonstrate your expertise. Available in English today, new content and translated courses will be added soon.

    We continue to be inspired by what you build and the impact you have on people around the world. Check our #IMakeApps collection which celebrate some amazing people who create apps and games and share your #IMakeApps story.

    How useful did you find this blog post?

    October 18th 2018, 1:20 pm
    Get it on Google Play تحميل تطبيق نبأ للآندرويد مجانا