Meet Google Play's target API level requirement

Google Play will require that new apps target at least Android 8.0 (API level 26) from August 1, 2018, and that app updates target Android 8.0 from November 1, 2018.

Every new Android version introduces changes that bring significant security and performance improvements – and enhance the user experience of Android overall. Some of these changes only apply to apps that explicitly declare support through their targetSdkVersion manifest attribute (also known as the target API level).

Configuring your app to target a recent API level ensures that users can benefit from these improvements, while still allowing it to run on older Android versions. Targeting a recent API level also allows your app to take advantage of the platform's latest features to delight your users.

This document highlights important points you should know in updating your target API level to meet the Google Play requirement. To proceed, click on on your app's current API level:

• Earlier than Android 5.0 (API level 21).
• Earlier than Android 6.0 (API level 23).
• Earlier than Android 7.0 (API level 24).
• Earlier than Android 8.0 (API level 26).

Note: If your gradle file contains manifest entries, you can confirm or change the current value of targetSdkVersion in your app's gradle file, as described in Configure Your Build. Alternatively, you can use the android:targetSdkVersion attribute in the manifest file, as described in the documentation for the <uses-sdk> manifest element.

Earlier than Android 5.0 (API level 21)

See the respective Behavior Changes page for each of the following releases to ensure your that your app has accounted for changes introduced in these releases:

• Android 5.0 (API level 21).
• Android 4.4 (API level 19).
• Android 4.1.x (API level 16).

Continue by following the instructions in the next section.

Earlier than Android 6.0 (API level 23)

The following considerations apply to apps targeting Android 6.0 and higher versions of the platform:

• Runtime Permissions
  • Dangerous permissions are only granted at runtime. Your UI flows must provide affordances for granting these permissions.
  • Wherever possible, your app should be prepared to handle rejection of permission requests. For example, if a user declines a request to access the device's GPS, your app should have another way to proceed.

For an exhaustive list of changes introduced in Android 6.0 (API level 23), see the Behavior Changes page for that version of the platform.

Continue by following the instructions in the next section.

Earlier than Android 7.0 (API level 24)

The following considerations apply to apps targeting Android 7.0 and higher versions of the platform:

• Doze and App Standby

  You should design for behaviors described in Optimizing for Doze and App Standby, which encompasses incremental changes introduced across several platform releases.

  When a device is in Doze and App Standby Mode, the system behaves as follows:

  • Restricts network access.
  • Defers alarms, syncs, and jobs.
  • Restricts GPS and Wi-Fi scans.
  • Restricts normal-priority Firebase Cloud Messaging messages.
• Permission Changes
  • The system restricts access to app private directories.
  • Exposing a file:// URI outside of your app triggers a FileUriExposedException. Developers who need to share files outside of their apps should implement FileProvider.
• The system forbids linking to non-NDK libraries.

For an exhaustive list of changes introduced in Android 7.0 (API level 24), see the Behavior Changes page for that version of the platform.

Continue by following the instructions in the next section.

Earlier than Android 8.0 (API level 26)

The following considerations apply to apps targeting Android 8.0 and higher versions of the platform:

• Background Execution Limits
  • The system restricts services for apps not running in the foreground.
    • startService() now throws an exception when an app tries to invoke it while startService is prohibited.
    • To start foreground services, an app must use startForeground() and startForegroundService().
    • Carefully review the changes made to the JobScheduler API, as documented on the Android 8.0 (API level 26) Behavior Changes page.
    • Firebase Cloud Messaging requires version 10.2.1 of the Google Play services SDK, or higher.
    • When using Firebase Cloud Messaging, message delivery is subject to background execution limits. When background work is necessary upon message receipt, such as to perform background data sync, your app should schedule jobs via Firebase Job Dispatcher or JobIntentService instead. For more information, see the Firebase Cloud Messaging documentation.
  • Implicit broadcasts
    • Implicit broadcasts are restricted. For information about handling background events, see the documentation for the JobScheduler API.
  • Background Location Limits
    • Apps running in the background have limited access to location data.
      • On devices with Google Play services, use the fused location provider to get periodic location updates.

• Notification Channels
  • You should define notification interruption properties on a per-channel basis.
  • You must assign notifications to a channel for the notifications to appear.
  • This version of the platform supports NotificationCompat.Builder.
• Privacy
  • ANDROID_ID is scoped per app signing key.

For an exhaustive list of changes introduced in Android 8.0 (API level 26), see the Behavior Changes page for that version of the platform.

Continue by following the instructions in the next section.

Modernizing your apps

As you update the target API level for your apps, consider adopting recent platform features to modernize your apps and delight your users.

• Migrate your app from Google Cloud Messaging (GCM) to the latest version of Firebase Cloud Messaging.
• Take advantage of advanced window management.
  • Support larger aspect ratios (more than 16:9) to take advantage of recent advances in hardware. Ensure that your app resizes to fill the available screen space. Only declare a maximum aspect ratio as a last resort. For more information about maximum aspect ratios, see Declare Restricted Screen Support.
  • Add multi-window support to help your app increase productivity, and to manage multiple displays.
  • If a great minimized app experience would improve the user experience, add support for Picture-in-Picture functionality.
  • Optimize for devices with display cutout.
    • Do not assume status bar height. Instead, use WindowInsets and View.OnApplyWindowInsetsListener (watch this video for an explanation).
    • Do not assume that the app has the entire window. Instead, confirm its location by using View.getLocationInWindow(), not View.getLocationOnScreen().
    • When handling MotionEvent, use MotionEvent.getX() and MotionEvent.getY(), not MotionEvent.getRawX(), MotionEvent.getRawY().
• Use modern camera support.
  • Use the Camera2 API to make the most of using the camera.
  • Enable Pixel Visual Core to accelerate HDR+ processing on Pixel 2 devices.

Check and update your SDKs and libraries

Make sure that your third-party SDK dependencies support API 26: Some SDK providers publish it in their manifest; others will require additional investigation. If you use an SDK that doesn't support API 26, please make it a priority to work with the SDK provider to resolve the issue.

Additionally, note that your app or game's targetSdkVersion may restrict access to private Android platform libraries; see NDK Apps Linking to Platform Libraries for details.

You should also verify any restrictions that may exist in the verson of the Android Support Library that you're using. As always, you must ensure compatibility between the major version of Android Support Library and your app’s compileSdkVersion.

We recommend that you choose a targetSdkVersion smaller than or equal to the Support Library’s major version. We encourage you to update to a recent compatible Support Library in order to take advantage of the latest compatibility features and bug fixes.

Test your app

After you update your app's API level and features as appropriate, you should test some core use cases. The following suggestions are not exhaustive, but aim to guide your testing process. We suggest testing:

• That your app compiles to API 26 without errors or warnings.
• That your app has a strategy for cases where the user rejects permission requests, and prompts the user for permissions. To do so:
  • Go to your app's App Info screen, and disable each permission.
  • Open the app and ensure no crashes.
  • Perform core use case tests and ensure required permissions are re-prompted.

• Handles Doze with expected results and no errors.
  • Using adb, place your test device into Doze while your app is running.
    • Test any use cases that trigger Firebase Cloud Messaging messages.
    • Test any use cases that use Alarms or Jobs.
    • Eliminate any dependencies on background services.
  • Set your app into App Standby
    • Test any use cases that trigger Firebase Cloud Messaging messages.
    • Test any use cases that use Alarms.

• Handles new photos / video being taken
  • Check that your app handles the restricted ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcasts correctly (i.e. moved to JobScheduler jobs).
  • Ensure that any critical use cases that depend on these events still work.
• Handles sharing files to other apps
  • Test any use case that shares file data with any other app (even another app by the same developer)
  • Test the content is visible in the other app and doesn’t trigger crashes.

Further information

Opt in to emails in the Google Play Console so that we can send you important updates and announcements from Android and Google Play, including our monthly partner newsletter.