Tag Archives: Develop

Automatic Update Prompts for Crashing Apps

Posted by Kurt Williams, Product Manager, Google Play

We are excited to announce a new feature that will help you to increase the rollout velocity of app updates and meet Play’s quality bar. On phones and tablets running Android 7.0 (SDK level 24) and above, the Play Store will prompt users to update your app if it crashes in the foreground and a more stable version is available. This will reduce your user-perceived crash rate.

Update the app to fix crashes dialog
The Play Store can now automatically prompt users to update your app after a user visible crash.


What you need to do: nothing!

These new prompts don’t require any integration by you and are enabled automatically when Play determines that a newer version of your app has a statistically relevant, lower crash rate. Furthermore, since the dialog is shown by the Play Store and not your app, the update prompt can be shown even if your app crashes on startup.

Data driven improvement over time

There are a few thresholds we take into account, which we will tune over time to achieve the best outcome. These include:

  1. User activity level of an app version according to Vitals to ensure we have statistical relevance
  2. Foreground crash rate of an app version and of its newer version
  3. Number of times a prompt can be shown for each version of your app on a device, if the user doesn’t choose to update

We believe that this new feature will help your users update to the best available version of your app, and help you deliver the best experience to your users.



Google Play Logo

Improving user privacy by requiring opt-in to send X-Requested-With header from WebView

Posted by Peter Birk Pakkenberg, Software Engineer

X-Requested-With (XRW) is a nonstandard header.

When a user installs and runs an application that uses a WebView to embed web content, the WebView will add the X-Requested-With header on every request sent to servers, with a value of the application APK name. It is then left to the receiving web server to determine if and how to use this information.

We want to protect the user's privacy by only sending this header on requests if the app developer explicitly opts-in to share with services embedded within the WebView. We are introducing new and purpose-built methods of client attestation that solve important safety use cases in a privacy-sensitive manner.

To let current online services that depend on this header migrate away from using it, we will run a Deprecation Origin Trial, while removing the header for general traffic.

Why are we making this change?

In early use cases, the X-Requested-With header was used to detect click fraud from malicious apps. It was also used to let a server know it's interacting with AJAX requests and needn't reply with HTML. The header was quickly adopted by common frameworks (jQuery, Dojo, Django) as a defense against CSRF attacks. However, several vulnerabilities (such as browser extensions impersonating websites) appeared around its use.

Android WebView adopted the X-Requested-Header with the application name as the value, as a way to allow online services to detect deceptive apps that were using hidden webviews to generate fake traffic. While this problem still exists today, the header as it is currently implemented does not fully solve the problem, as apps can easily change the value being sent on some requests in later Android versions.

The header, as currently implemented by default in Android WebView, does not follow the principle of meaningful consent of all parties exchanging the information and the Android Platform Security Model’s definition of multi-party consent.

APK name also contains specific information about the context in which the user is consuming the web content, and can leak the identity of the app to the online service.

How does this proposal affect the header?

It's important to note that the non-WebView use cases will not change because of this proposal, as clients and servers still can and will set the header in normal JavaScript environments.

Even today, WebView will not overwrite the header if the header has already been set on an AJAX request by a JavaScript framework.

This removal only targets the WebView use case, which adds the header to every HTTP request made by the browser (that is, not the XMLHttpRequest use case).

What is the impact of removing this feature?

Today content owners may decide to rely on X-Requested-With to attribute traffic and control access without employing their own authentication. Other services use it for reporting of aggregate patterns about their user base.

All of these use cases will be affected by the removal of the header on requests, and in the majority of cases where the header is not modified by dishonest apps, it provides useful information to online services.

Given this, we plan to limit disruption during the deprecation and transition to purpose-built replacement signals by offering a Deprecation Origin Trial to maintain the existing behavior.

We ask for feedback on existing use cases that currently rely on and may be impacted by these changes.

Next steps and the future of XRW

As we gradually roll out the removal, origins participating in the trial will be exempted (that is, WebView will continue to send the header to these origins for as long as the trial lasts). The deprecation trial is expected to remain active for at least a year to give partners time to adjust for the change.

Further, during the deprecation origin trial, we will be developing new privacy-preserving APIs to match the use cases where the XRW header is being used today, such as client attestation APIs.

Separately from the deprecation trial, we will provide an opt-in API for application developers. This API will allow individual apps to selectively send the header to chosen origins, which can be used to maintain functionality of legacy sites that are not migrating, and the API will remain after the deprecation trial has finished.

Helpful resources

Key areas where we are seeking feedback

  • Key use cases for the XRW header today (e.g., payment authentication, account takeover fraud)
  • How important the XRW header is for each of these use cases
  • Desired capabilities that any new privacy-preserving alternatives would ideally have

Announcing Cross device SDK Developer Preview for building rich multi-device experiences on Android

Posted by Alex Rocha - Developer Relations Engineer Manager, Ryan Ausanka-Crues - Eng Manager, Multi-device development, Stella Loh - Product Manager, Multi-device development

Today we’re launching our Developer Preview of the new Cross device SDK for Android. First announced during the Google I/O ‘22 Multi-device development session, our Cross device SDK allows developers to build rich multi-device experiences with a simple and intuitive set of APIs. This SDK abstracts away the intricacies involved with working with device discovery, authentication, and connection protocols, allowing you to focus on what matters most—building delightful user experiences and connecting these experiences across a variety of form factors and platforms.

What’s in Developer Preview

This initial release contains a set of rich APIs centered around the core functionality of Device discovery, Secure connections, and Multi-device Sessions.

  1. Device discovery: Easily find nearby devices, authorize peer-to-peer communication, and start the target application on receiving devices.
  2. Secure connections: Enable encrypted, low-latency bi-directional data sharing between authorized devices.
  3. Multi-device Sessions: Enable transferring or extending an application’s user experience across multiple devices.

In turn, this will allow you to build compelling cross-device experiences by enabling and simplifying the following use cases:

  • Discovering and authorizing communication with nearby devices.
  • Sharing an app’s current state with the same app on another device.
  • Starting the app on a secondary device without having to keep the app running in background.
  • Establishing secure connections for devices to communicate with each other.
  • Enabling task handoff where the user starts a task on one device, and can easily continue on another device.

Starting today with a Developer Preview for Android phones and tablets, the Cross device SDK will be available later for other Android surfaces and non-Android OSs.

Under The Hood

The Cross device SDK provides a software abstraction layer that handles all aspects of cross-device connectivity, leveraging wireless technologies such as Bluetooth, Wi-Fi, and Ultra-wide band; our SDK does all the heavy-lifting under the hood, offering you a modular,connectivity-agnostic API that supports bi-directional communication between devices and is backward compatible to Android 8. In addition, apps will not have to declare or request Runtime Permissions for any of the underlying connectivity protocols used (such as BLUETOOTH_CONNECT, BLUETOOTH_SCAN, ACCESS_FINE_LOCATION, etc.), and the user can allow apps to connect to only the device(s) they selected.

Getting started with Developer Preview

Head over to our developer guide to get started and try out the Developer Preview of the Cross device SDK for Android. Make sure to check out our Rock Paper Scissor sample app (Kotlin and Java) on GitHub for a demonstration on how to work with the various APIs and our Google I/O ‘22 Multi-device development session for a general overview of the SDK.

Feedback

We’d love to hear from you during this initial Developer Preview launch to help us shape the SDK and influence future roadmapping, so please share your feedback and let us know your experience with the SDK!

Now in Android – a new, open source, real-world sample app

Posted by Paris Hsu, Product & Design, Android and Don Turner, Developer Relations Engineer, Android

Now in Android Splash logo

The Now in Android app is now on GitHub!

For two years, 'Now in Android' has been a popular blog and YouTube series, providing you with the latest and greatest developer news from the Android team. Starting today, you can check out the alpha version of the Now in Android app on GitHub! ?

The app has two goals:

Firstly, it showcases best practices, opinionated designs, and solutions to complex real-world problems which other sample apps don’t handle. It does so with an open source implementation of a real world app.

Secondly, it helps you (the developer) keep up to date with the areas of Android development which interest you most. It is a working app planned for publication on the Play Store.

image of Now in Android app screen designs on three phones

Now in Android app screen designs

For this first alpha release, the Now in Android app includes:

As well as these features, we are also documenting the learning journeys we took to certain decisions with the app's design and implementation. Check out our first journey on the app's Architecture here.

image showing how the Now in Android app adapts based on device screen size

The Now in Android screens adapt based on device screen size

Since this is an alpha release, we expect that there will be bugs and missing features, and we would greatly appreciate your feedback. We have some exciting features planned, such as user authentication and loading data from a real backend. We can’t wait for you to check out the app and let us know what you think!

Finally, if you want to learn about the tools we used to build the app and how we target multiple screen sizes, check out these talks from this year's Google I/O:

Improving App Performance with Baseline Profiles

Or how to improve startup time by up to 40%

Posted by Kateryna Semenova, DevRel Engineer; Rahul Ravikumar, Software Engineer; Chris Craik, Software Engineer

ALT TEXT GOES HERE


Why is startup time important?

A lot of apps find correlation between app performance and user engagement. People expect apps to be responsive and fast to load. Startup time is one of the major metrics for app performance and quality.

Some of our partners have already invested a lot of time and resources for app startup optimizations. For example, check out the Facebook story.

In this blog post we’ll discuss Baseline Profiles and how they improve app and library performance, including startup time by up to 40%. While this blogpost focuses on startup, baseline profiles also significantly improve jank as well.


History

Android 9 (API level 28) introduced ART optimizing profiles in Play Cloud to improve app startup time. On average, we’ve seen that apps' cold starts are at least 15% faster across a variety of devices when Cloud Profiles are available.


How do Profiles work?

When the app is first launched after install or update, its code runs in an interpreted mode until it is JITted. In an APK, Java and Kotlin code is compiled as dex bytecode, but not fully compiled to machine code (since Android 6), due to the cost of storing and loading fully compiled apps. Classes and methods that are frequently used in the app, as well as those used for app startup, are recorded into a profile file. Once the device enters idle mode, ART compiles the apps based on these profiles. This speeds up subsequent app launches.

Starting with Android 9 (API level 28), Google Play also provides Cloud Profiles. When an app runs on a device, the profiles generated by ART are uploaded by the Play Store app and aggregated in the cloud. Once there are enough profiles uploaded for an application, the Play app uses the aggregated profile for subsequent installs.


Problem

While Cloud Profiles are great when they are available, they aren't always ready to be used when an app is installed. Collecting and aggregating the profiles usually takes several days, which is a problem when many apps update on a weekly basis. Many users will install an update before the Cloud Profile is available. The Google Android team started looking for other ways to improve the latency of profiles.


Solution

Baseline Profiles are a new mechanism to provide profiles which can be used on Android 7 (API level 24) and higher. A baseline profile is an ART profile generated by the Android Gradle plugin using a human readable profile format that can be provided by apps and libraries. An example might look like this:

HSPLandroidx/compose/runtime/ComposerImpl;->updateValue(Ljava/lang/Object;)V
HSPLandroidx/compose/runtime/ComposerImpl;->updatedNodeCount(I)I
HLandroidx/compose/runtime/ComposerImpl;->validateNodeExpected()V
PLandroidx/compose/runtime/CompositionImpl;->applyChanges()V
HLandroidx/compose/runtime/ComposerKt;->findLocation(Ljava/util/List;I)I

Example for Compose library.


The binary profile is stored in a specific location in the APK assets directory (assets/dexopt/baseline.prof).

Baseline Profiles are created during build time, shipped as part of the APK to Play, and then sent from Play to users when an app is downloaded. They fill the gap in the ART Cloud Profile pipeline, when Cloud Profiles are not yet available, and automatically merge with Cloud Profiles when they are.


This diagram displays the baseline profile workflow from creation through end-user delivery.

This diagram displays the baseline profile workflow from creation through end-user delivery.


One of the biggest benefits of Baseline Profiles is that they can be developed and evaluated locally so developers can see realistic end-user performance improvements. They are also supported on a lower version of Android(7 and higher) than Cloud Profiles, which are only available starting in Android 9.


Impact


App devs

In early 2021, Google Maps switched from a two-week to a one-week release cycle. More frequent updates meant more frequently discarding local pre-compilation, and more users experiencing slow launches without Play Cloud Profiles. By using Baseline Profiles, Google Maps improved their average startup time by 30% and saw a corresponding increase in searches by 2.4%, an immense gain for such an established app.


Library devs

Code in a library is just like that of an app - it's not fully compiled by default, which can be a problem if it does significant work on the critical path of startup.

Jetpack Compose is a UI library that is not a part of the Android system image and thus not fully compiled when installed, unlike much of the Android View toolkit code. This was causing performance problems, especially for the first few cold launches of the app.

To solve this problem, Compose uses profile installer. It ships baseline profile rules which reduce startup time and jank in Compose apps.

Google PlayStore’s search results page has been re-written with Compose. After incorporating the Baseline Profile rules from Compose, time to render the initial search results page with images improved by ~40%.

The Android team has also added Baseline Profiles to relevant AndroidX libraries. This benefits all Android apps using these libraries. Constraint Layout has found shipping profile rules reduces animation frame times by more than one millisecond.


How to use Baseline Profiles


Create a custom Baseline Profile

All apps and library developers can benefit from including Baseline Profiles. Ideally, developers create profiles for their most critical user journeys to ensure that those journeys have consistently fast performance regardless of whether cloud profiles are available. Check out the detailed guide on how to set up Baseline Profiles for both app and library developers.


Update dependencies

If you are not ready to generate Baseline Profiles for your app right now, you can still benefit from them by updating your dependencies. If you build with Android Gradle Plugin 7.1.0-alpha05 or newer, you'll get Baseline Profiles included in your APK that are already provided by libraries (such as Jetpack). Google Play compiles your app with these profiles at install time. You can supplement these profiles as part of building your application.


Measure Improvements

Don’t forget to measure improvements. Follow the steps on how to measure startup with the generated profile locally.


Provide feedback

Please share your feedback and let us know your experience!

Low-Power Sleep Tracking on Android

Posted by Nick Grayson, Product Manager

Illustration of phone with moon and Android logo on screen

Android works best when it helps developers create apps that people love. That’s why we are dedicated to providing useful APIs like Activity Recognition which, with the user’s permission, can detect user’s activities (such as whether a user is biking or walking) to help apps provide contextually aware experiences.

So much of what we do relies on a good night's rest. Our phones have become great tools for making more informed decisions about our sleep. And by being informed about sleep habits, people can make better decisions throughout the day about sleep, which affects things like concentration and mental health.

In an effort to help our users stay informed about their sleep, we are making our Sleep API publicly available.

What is the Sleep API?

The Sleep API is an Android Activity Recognition API that surfaces information about the user’s sleep. It can be used to power features like the Bedtime mode in Clock.

This sleeping information is reported in two ways:

  1. A ‘sleep confidence’, which is reported at a regular interval (up to 10 minutes)
  2. A daily sleep segment which is reported after a wakeup is detected

The API uses an on-device artificial intelligence model that uses the device’s light and motion sensors as inputs.

As with all of our Activity Recognition APIs, the app must be granted the Physical Activity Recognition runtime permission from the user to detect sleep.

Why is this important for developers?

Developers spend valuable engineering time to combine sensor signals to determine when the user has started or ended activities like sleep. These detection algorithms are inconsistent between apps and when multiple apps independently and continuously check for changes in user activity, battery life suffers.

The Sleep API is a simple API that centralizes sleep detection processing in a battery-efficient manner. For this launch, we are proud to collaborate with Urbandroid, the developer of the popular alarm app, Sleep As Android

Android logo sleeping
Sleep as Android is a swiss army knife for getting a better night’s rest. It tracks sleep duration, regularity, phases, snoring, and more. Sleep Duration is one of the most important parameters to watch for ensuring a good night’s rest. The new Sleep API gives us a fantastic opportunity to track it automatically in the most battery efficient way imaginable.

- Sleep as Android Team



When can I start using this API?

The Sleep API is available for developers to use now as part of the latest version of Google Play Services.

This API is one step of our efforts to help our users get a better night's rest. We look forward to working more on this API and in this area in the future.

If you are interested in exploring or using this API, check out our API Documentation.

Learn Android and Kotlin with no programming experience

Posted by Kat Kuan, Developer Advocate, Android

Many people today are considering career paths that enable them to work remotely. App development allows for that style of work. For people who want a new opportunity, it’s possible to start learning Android today, even without prior programming experience.

In 2016, we released our Android Basics curriculum, which assumes no programming experience, and the response has been tremendous. Hundreds of thousands of students have been learning Android development and programming concepts simultaneously as they build apps. Since then, there have been big platform changes with four major releases of Android and support added for the Kotlin programming language. We also introduced Jetpack, a suite of libraries that make it easier to build better apps with less code. With all these new updates, it’s time to release the next generation of training content for beginners.

Today we’re announcing the launch of Android Basics in Kotlin, a new online course for people without programming experience to learn how to build Android apps. The course teaches Kotlin, a modern programming language that developers love because of its conciseness and how it increases productivity. Kotlin is quickly gaining momentum in industry. Over a single year from 2018 - 2019, Indeed Hiring Lab found a 76% increase in Kotlin jobs.*

Google announced that Android development is Kotlin-first, and 60% of professional Android developers have already adopted the language. In the Play Store, 70% of the top 1,000 apps use Kotlin. To keep pace and prepare for the future, there has never been a more opportune time to learn Android with Kotlin.

Learning to code for the first time can feel intimidating, but it is possible to learn without a technical background. From a recent Stack Overflow Developer Survey, nearly 40% of the professional developers who studied at university did not receive a formal computer science or software engineering degree.

To build your confidence, the Android Basics in Kotlin course offers step-by-step instructions on how to use Android Studio to build apps, as well as how to run them on an Android device (or virtual device). The goal is to expose you to the tools and resources that professional Android developers use. With hands-on practice, you learn the fundamentals of programming. By the end of the course, you will have completed a collection of Android apps to start building a portfolio.

Object detection & tracking gif Text recognition + Language ID + Translate gif

App screenshots from the course

This course is split up into units, where each unit is made up of a series of pathways. At the end of each pathway, there is a quiz to assess what you’ve learned so far. If you pass the quiz, you earn a badge that can be saved to your Google Developer Profile.
Object detection & tracking gif Text recognition + Language ID + Translate gif

Badges you can earn

The course is free for anyone to take. Basic computer literacy and basic math skills are recommended prerequisites. Unit 1 of the course is available today, with more units being released as they become available. If you’ve never built an app before but want to learn how, check out the Android Basics in Kotlin course.

If you already have programming experience, check out the other free training courses we offer in Kotlin:

We can’t wait to see what you build!

*from US tech job postings on Indeed.com

Advanced in-app billing: handling alternative purchase flows

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.

Get your apps ready for the 64-bit requirement

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:

  • All new apps and app updates that include native code are required to provide 64-bit versions in addition to 32-bit versions when publishing to Google Play.
  • Extension: Google Play will continue to accept 32-bit only updates to existing games that use Unity 5.6 or older until August 2021.

Starting August 1, 2021:

  • Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.
  • This will include games built with Unity 5.6 or older.

The requirement does not apply to:

  • APKs or app bundles explicitly targeting Wear OS or Android TV, which are form factors that do not currently support 64-bit code.
  • APKs or app bundles that are not distributed to devices running Android 9 Pie or later.

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.

  • Upgrade any SDKs and libraries to 64-bit compliant versions, if needed. Reach out to the SDK or library owner if one is not available. We’re working with top library owners on their 64-bit compatibility.
  • Test for issues locally once you’ve rebuilt your app.
  • Rollout to your testers using testing tracks for thorough testing.

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?

Google Play services discontinuing updates for API levels 14 and 15

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.