Meet Google Play's target API level requirement

When you upload an APK, information technology must meet Google Play'southward target API level requirements. New apps and app updates must target Android 11 (API level xxx) or higher; except for Wear Bone apps, which must target API level 28 or higher.

Starting in August 2022, new apps must target API level 31 (Android 12) or above and adjust for behavioral changes. Clothing Os apps must target API level 28 or college.

Starting in Nov 2022, app updates must target API level 31 or above and adjust for behavioral changes in Android 12.

Note: Starting in 2022, some out-of-engagement apps volition be unavailable to new users of devices that run newer versions of Android.

Why target newer SDKs?

Every new Android version introduces changes that bring security and functioning improvements and enhance the Android user experience. Some of these changes only apply to apps that explicitly declare back up through their targetSdkVersion manifest attribute (as well known as the target API level).

Configuring your app to target a recent API level ensures that users tin benefit from these improvements, while your app tin can nevertheless run on older Android versions. Targeting a recent API level also allows your app to accept advantage of the platform's latest features to delight your users. Furthermore, every bit of Android 10 (API level 29), users see a warning when they start an app for the first time if the app targets Android 5.ane (API level 22) or lower.

This document highlights important points y'all need to know in updating your target API level to encounter the Google Play requirement.

When migrating from lower versions, delight encounter the total list of changes below.

Note: If your Gradle file contains manifest entries, you lot 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.

Migrate from Android eleven (API level 30) to Android 12 (API level 31)

Security and Permissions

  • Bluetooth: You must replace declarations for the BLUETOOTH and BLUETOOTH_ADMIN permissions with BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE, or BLUETOOTH_CONNECT permissions. You no longer need to make LOCATION runtime permission requests for Bluetooth operations.
  • Location: Users tin can asking apps to call up only guess location information. You must asking the ACCESS_COARSE_LOCATION permission any time you asking ACCESS_FINE_LOCATION.
  • Intent filters: If your app contains activities, services, or broadcast receivers that use intent filters, you must explicitly declare the android:exported aspect for these components.
  • Hibernation: Apps may be put into hibernation mode if they are non used over a catamenia of time. In hibernation mode your app'southward runtime permissions and cache are reset, and you lot tin can't run jobs or alerts. You tin can check your app's hibernation condition.
  • Pending intent mutability: You lot must specify the mutability of each PendingIntent object that your app creates.

User Feel

  • Custom notifications: Notifications with custom content views volition no longer use the full notification area; instead, the system applies a standard template. This template ensures that custom notifications accept the same decoration equally other notifications in all states. This behavior is virtually identical to the behavior of Notification.DecoratedCustomViewStyle.
  • Android App Links verification changes: When using Android App Link verification, brand sure that your intent filters include the BROWSABLE category and support the HTTPS scheme.

Functioning

  • Foreground service launch restrictions: To target Android 12 or college, your app can't commencement foreground services while it runs in the background, except for a few special cases. If an app attempts to start a foreground service while running in the background, an exception occurs (except for the few special cases).

    Consider using WorkManager to schedule and kickoff expedited piece of work while your app runs in the background. To complete time-sensitive deportment that the user requests, commencement foreground services within an verbal warning.

  • Notification trampoline restrictions: When users tap notifications, some apps respond by launching an app component that starts the activity that the user sees and interacts with. This app component is known as a notification trampoline.

    Apps must not start activities from services or broadcast receivers that are used every bit notification trampolines. Later on a user taps on a notification or action button inside the notification, your app cannot phone call startActivity() inside of a service or broadcast receiver.

View the complete set of changes that affect apps targeting Android 12 (API level 31).

Migrating from lower than Android 11 (API level thirty)

Select the version of Android you volition be migrating from:

Migrate to Android 5 (API level 21)

See the corresponding 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.10 (API level 16).

Continue by following the instructions in the side by side section.

Migrate to Android six (API level 23)

The following considerations utilise to apps targeting Android vi.0 and higher versions of the platform:

  • Runtime Permissions

    • Unsafe permissions are only granted at runtime. Your UI flows must provide affordances for granting these permissions.

    • Wherever possible, ensure your app is prepared to handle rejection of permission requests. For example, if a user declines a asking to access the device'southward GPS, ensure your app has another way to continue.

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

Continue past post-obit the instructions in the next section.

Migrate to Android 7 (API level 24)

The following considerations utilize to apps targeting Android vii.0 and higher versions of the platform:

  • Doze and App Standby

    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 arrangement restricts admission to app private directories.
    • Exposing a file:// URI outside of your app triggers a FileUriExposedException. If yous need to share files outside of your app, implement FileProvider

  • The organization forbids linking to non-NDK libraries.

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

Go on by post-obit the instructions in the side by side section.

Drift to Android viii (API level 26)

The following considerations apply to apps targeting Android viii.0 and higher versions of the platform:

  • Groundwork 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 utilise startForeground() and startForegroundService().
      • Advisedly review the changes fabricated to the JobScheduler API, as documented on the Android viii.0 (API level 26) Behavior Changes folio.
      • Firebase Cloud Messaging requires version 10.2.one of the Google Play services SDK, or higher.
      • When using Firebase Cloud Messaging, message delivery is subject area to background execution limits. When groundwork work is necessary upon bulletin receipt, such as to perform background information sync, your app should schedule jobs via Firebase Job Dispatcher or JobIntentService instead. For more than data, come across the Firebase Cloud Messaging documentation.
    • Implicit broadcasts
      • Implicit broadcasts are restricted. For information near handling groundwork events, see the documentation for the JobScheduler API.
    • Groundwork Location Limits
      • Apps running in the background accept limited admission to location data.
        • On devices with Google Play services, use the fused location provider to get periodic location updates.
  • Notification Channels
    • Y'all should ascertain notification interruption properties on a per-channel footing.
    • 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 viii.0 (API level 26), see the Behavior Changes page for that version of the platform.

Migrating from Android eight (API 26) to Android 9 (API 28)

  • Power Management
    • App Standby buckets bring new background restrictions based on app engagement, such as deferred jobs, alarms and quotas on high-priority messages
    • Battery saver improvements increment the limitations on app standby apps
  • Foreground service permission
    • Demand to request the normal permission FOREGROUND_SERVICE (not runtime permission)
  • Privacy changes
    • Limited access to groundwork sensors
    • Restricted access to phone call logs, now in CALL_LOG permission group
    • Restricted access to telephone numbers, requiring READ_CALL_LOG permission
    • Restricted access to Wi-Fi information

For an exhaustive list of changes introduced in Android 9.0 (API level 28), run into behavior changes.

Migrating from Android 9 (API level 28) to Android 10 (API level 29)

  • Notifications with a full-screen intent
    • Demand to asking the normal permission USE_FULL_SCREEN_INTENT (non runtime permission).
  • Back up for foldables and large screen devices
    • Multiple activities can now be in the "resumed" state at the same time, but only 1 actually has focus.
      • This change affects onResume() and onPause() behavior.
      • New lifecycle concept of "topmost resumed" which tin can be detected by subscribing to onTopResumedActivityChanged().
        • Only one action can be "topmost resumed."
    • When resizeableActivity is set to faux, apps can additionally specify a minAspectRatio which automatically letterboxes the app on narrower aspect ratios.
  • Privacy changes
    • Scoped storage
      • External storage access is limited but to an app-specific directory and to specific types of media that the app has created.
    • Restricted admission to location while the app is in the background, requiring ACCESS_BACKGROUND_LOCATION permission.
    • Restricted access to non-resettable identifiers such as IMEI and serial number.
    • Restricted admission to physical activity data such as the user's step count, requiring ACTIVITY_RECOGNITION permission.
    • Restricted admission to some telephony, Bluetooth, and Wi-Fi APIs, requiring ACCESS_FINE_LOCATION permission.
    • Restricted access to Wi-Fi settings
      • Apps tin can no longer directly enable or disable Wi-Fi and need to do it using settings panels.
      • Restrictions on initiating a connection to a Wi-Fi network, requiring the use of either WifiNetworkSpecifier or WifiNetworkSuggestion.

Migrating from Android ten (API level 29) to Android eleven (API level 30)

  • Privacy
    • Scoped storage enforcement : Apps should adopt the scoped storage model where app-specific, media, and other file types are saved and accessed using defended locations.
    • Permissions auto-reset: If users haven't interacted with an app for a few months, the system auto-resets the app's sensitive permissions. This shouldn't bear on most apps. If your app primarily works in the background without user interactions, you may consider requesting users to disable auto reset.
    • Groundwork location access: Apps must request foreground and groundwork location permission separately. Granting admission to background location permission tin can only be done in app settings instead of runtime permission dialogs.
    • Parcel Visibility: When an app queries for the list of installed apps and services on the device, the returned list is filtered.
      • If you use Text-to-speech or Speech Recognition services, you volition need to add together queries elements for services to the manifest file.
  • Security
    • Compressed `resource.arsc` files are no longer supported
    • APK Signature Scheme v2 at present required. For backward compatibility reasons, developers should also proceed to sign with APK Signature Scheme v1.
    • Non-SDK interface restriction. Using non-SDK interfaces is not recommended for apps targeting API level 30, as some of these non-SDK interfaces are now blocked. See Non-SDK interfaces that are at present blocked in Android 11 for a comprehensive list of blocked non-SDK interfaces.

For an exhaustive list of changes introduced in Android xi (API level 30), run into the Behavior Changes page.

Go on to update to API 31 by following the instructions in the previous section.

Modernizing your apps

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

  • Consider using CameraX, which is in Beta, to make the well-nigh of using the camera.
  • Use Jetpack components to help you follow best practices, free you from writing boilerplate lawmaking, and simplify complex tasks and so that you can focus on the lawmaking you lot intendance about.
  • Use Kotlin to write better apps faster, and with less lawmaking.
  • Ensure you are following privacy requirements and best practices.
  • Add dark theme support to your apps.
  • Add gesture navigation support to your apps.
  • Migrate your app from Google Cloud Messaging (GCM) to the latest version of Firebase Cloud Messaging.
  • Accept advantage of advanced window management.
    • Support larger aspect ratios (more than sixteen:9) to take advantage of recent advances in hardware. Ensure that your app resizes to make full the available screen space. But declare a maximum aspect ratio equally a last resort. For more data almost maximum attribute ratios, see Declare Restricted Screen Support.
    • Add multi-window back up to help your app increase productivity, and to manage multiple displays.
    • If a slap-up minimized app experience would improve the user experience, add back up for Picture-in-Picture functionality.
    • Optimize for devices with brandish cutout.
    • Do not presume status bar pinnacle. Instead, use WindowInsets and View.OnApplyWindowInsetsListener. Picket this video for an explanation.
    • Do not assume that the app has the entire window. Instead, ostend its location by using View.getLocationInWindow(), non View.getLocationOnScreen().
    • When treatment MotionEvent, use MotionEvent.getX() and MotionEvent.getY(), not MotionEvent.getRawX(), MotionEvent.getRawY().

Check and update your SDKs and libraries

Make certain that your third-party SDK dependencies support API 29: Some SDK providers publish information technology in their manifest; others will require boosted investigation. If you utilise an SDK that doesn't support API 29, make it a priority to work with the SDK provider to resolve the event.

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

You should too verify any restrictions that may exist in the version of the Android Back up Library that you're using. As always, yous 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'due south major version. We encourage you to update to a recent compatible Back up Library in order to take advantage of the latest compatibility features and bug fixes.

Test your app

Later on you update your app'south API level and features every bit appropriate, you should test some core employ cases. The following suggestions are not exhaustive, but aim to guide your testing process. We suggest testing:

  • That your app compiles to API 29 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 practise and then:
    • Go to your app's App Info screen, and disable each permission.
    • Open the app and ensure no crashes.
    • Perform cadre use example 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.
      • Examination whatsoever use cases that trigger Firebase Cloud Messaging letters.
      • Test any employ cases that utilise 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 apply 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 (that is, moved to JobScheduler jobs).
    • Ensure that any critical apply cases that depend on these events still work.
  • Handles sharing files to other apps
    • Exam any use example that shares file information with any other app (even another app past 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 and so that we can send you important updates and announcements from Android and Google Play, including our monthly partner newsletter.