Update your app's target SDK version for Wear OS 4

After you update your app to prepare it for Wear OS 4, you can further improve your app's compatibility with this version of Wear OS by targeting Android 13 (API level 33).

If you update your target SDK version, handle the system behavior changes that take effect for apps that target Android 12 or higher, as well as for apps that target Android 13 or higher. In particular, consider the changes to permissions and to app components and navigation behavior that are described later in this guide.

Update your build file

To update your target SDK version, open your module-level build.gradle or build.gradle.kts file, and update them with values for Android 13.

How you format the values in your build file depends on the version of the Android Gradle plugin (AGP) that you are using.

AGP 7.0.0 or higher

If you are using AGP 7.0.0 or higher, update your app's build.gradle or build.gradle.kts file with the following values for Android 13:

Groovy

android {
    compileSdk 33
    ...
    defaultConfig {
        targetSdk 33
    }
}

Kotlin

android {
    compileSdk = 33
    ...
    defaultConfig {
        targetSdk = 33
    }
}

AGP 4.2.0 or lower

If you are using AGP 4.2.0 or lower, update your app's build.gradle or build.gradle.kts file with the following values for Android 13:

Groovy

android {
    compileSdkVersion "33"
    ...
    defaultConfig {
        targetSdkVersion "33"
    }
}

Kotlin

android {
    compileSdkVersion = "33"
    ...
    defaultConfig {
        targetSdkVersion = "33"
    }
}

Changes to permissions

This section lists several changes to permissions that affect apps after they target Android 13.

Background body sensors permission

To get information from common body sensors, such as heart rate, in the background, request the BODY_SENSORS_BACKGROUND permission.

Learn more in the guide to requesting background access to body sensor data.

Exact alarm permission

To use precisely-timed alarms—also known as exact alarms—you must declare either the USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM permission.

Unless your app's core capabilities depend on exact alarms—such as for an alarm clock app or a calendar app—use inexact alarms instead. Most apps can schedule tasks and events using inexact alarms.

Learn more about how to set an exact alarm.

Granular media permissions

If your app needs to access media files that other apps have created, you must request granular media permissions, which start with READ_MEDIA_*, instead of the READ_EXTERNAL_STORAGE permission. If your app was previously granted the READ_EXTERNAL_STORAGE permission, then the system grants the required granular media permissions automatically.

Learn more about granular media permissions.

Changes to app components and navigation

This section lists several changes to app component and navigation behavior that affect apps after they target Android 13.

App component exporting requirements

If your app contains activities, services, or broadcast receivers that use intent filters, you must explicitly declare the android:exported attribute for these app components.

Learn more about safer component exporting.

Specify the mutability of pending intents

You must specify whether each PendingIntent object in your app is mutable or immutable. In most cases, use immutable PendingIntent objects to protect the integrity of the data inside the intent.

Learn more about how to specify the mutability of pending intents.

Foreground service launch restrictions

In most cases, your app can't start foreground services while running in the background.

Learn more about the restrictions on starting a foreground service from the background.

Notification trampoline restrictions

After the user interacts with a notification, you can't call startActivity() inside of a service or broadcast receiver. Such an interstitial app component, whose only capability is launching an activity, is known as a notification trampoline.

Learn more about notification trampoline restrictions.