Behaviour changes in android 13 can be classified into two types:

• Changes that may only effect apps targeting android 13

• Changes that may affect all apps regardless of their target android version

Changes effecting all apps:

• Performance and battery
o Foreground Services (FGS) Task Manager
▪ Starting in Android 13 (API level 33), users can complete a
workflow from the notification drawer to stop apps that have
ongoing foreground services.
▪ This affordance is known as the Foreground Services (FGS)
Task Manager. Apps must be able to handle this user-
initiated stopping.
o Improve prefetch job handling using JobScheduler
▪ JobScheduler provides a way for apps to mark specific jobs
as "prefetch" jobs (using JobInfo.Builder.setPrefetch()),
meaning that they should ideally run close to, and before, the
next app launch to improve user experience.
▪ In Android 13 (API level 33) and higher, the system tries to
determine the next time an app will be launched, and uses
that estimation to run prefetch jobs. Apps should try to use
prefetch jobs for any work that they want to be done prior to
the next app launch.
o Battery Resource Utilization
▪ On Android 13 (API level 33) and higher, unless your app
qualifies for an exemption, the system places your app in the
restricted bucket in the following situations:
• The user doesn't interact with your app for a specific
number of days. Android 13 reduces this number
FROM 45 to 8.
• app invokes an excessive number of broadcasts or
bindings during a 24-hour period.
▪ Do not try to manipulate the system into putting your app
into one bucket or another. The system's bucketing methods
can change, and every device manufacturer could choose to
write their own bucketing app with its own algorithm.
 Instead, make sure your app behaves appropriately no matter
which bucket it's in.
▪ If the app's notifications aren't actionable, users won't be
able to trigger the app's promotion to the active bucket by
interacting with the notifications
▪ If apps are split across multiple packages, those packages
might be in different buckets and, thus, have different access
levels. You should be sure to test such apps with the
packages assigned to various buckets to make sure the app
behaves properly.
o High Priority Firebase Cloud Message (FCM) Quotas
▪ App Standby Buckets no longer determine how many high
priority FCMs an app can use.
▪ High priority FCM quotas scale in proportion to the number
of notifications shown to the user in response to High
Priority FCMs.
▪ If your application doesn't always post notifications in
response to High Priority FCMs, we recommend that you
change the priority of these FCMs to normal so that the
messages that result in a notification don't get downgraded.
• Privacy
o Runtime permission for notifications
▪ Android 13 (API level 33) introduces a runtime notification
permission: POST_NOTIFICATIONS. This change helps
users focus on the notifications that are most important to
them.
▪ Notifications related to media sessions and apps that self-
manage phone calls are exempt from this behavior change.
o Hide sensitive content from clipboard
▪ If your app allows users to copy sensitive content, such as
passwords or credit card information, to the clipboard, you
must add a flag to ClipData’s ClipDescription before calling
ClipboardManager#setPrimaryClip(). Adding this flag
prevents sensitive content from appearing in the content
preview.
• Security
o Intent filters block non-matching intents
▪ When your app sends an intent to an exported component of
another app that targets Android 13 or higher, that intent is
 delivered if and only if it matches an <intent-filter> element
in the receiving app. Non-matching intents are blocked.
▪ Similarly, if your app upgrades to Android 13 or higher, any
intent sent from another app is delivered to an exported
component of your app if and only if that intent matches a
declared <intent-filter> element in your app.
o Migrate away from shared user ID
▪ If your app uses the deprecated android:sharedUserId
attribute and no longer depends on the attribute's
functionality, you can set the
android:sharedUserMaxSdkVersion attribute to 32
▪ This attribute tells the system that your app no longer relies
on a shared user ID.
▪ If your app declares android:sharedUserMaxSdkVersion and
is newly installed on devices running Android 13 or higher,
your app behaves as if you never
defined android:sharedUserId.
▪ Updated apps still use the existing shared user ID.
▪ If you already define the android:sharedUserId attribute in
your manifest, don't remove it. Doing so causes app updates
to fail.
• User Experience
o Dismissible foreground service notifications
▪ On devices that run Android 13 or higher, users can dismiss
notifications associated with foreground services by default.
• Core functionality
o Legacy copy of speech service implementation removed
▪ Android 13 removes the SpeechService implementation—
including Voice IME, RecognitionService and an intent-
based API—from the Google app.
▪ To help maintain app compatibility on Android 12, the
Google app uses a trampoline to divert traffic to the Speech
Services by Google app. In Android 13, this trampoline is
removed.
▪ Apps should use the device's default provider for
SpeechService, rather than hard-coding a specific app.
Changes effecting apps that target android 13:
• Performance and Battery
o Battery Resource Utilization
▪ If the user places your app in the "restricted" state for
background battery usage while your app targets Android 13,
the system doesn't deliver the BOOT_COMPLETED
broadcast or the LOCKED_BOOT_COMPLETED broadcast
until the app is started for other reasons.
• Privacy
o Notification permission affects foreground service appearance
▪ If the user denies the notification permission, they don't see
notices related to foreground services in the notification
drawer.
▪ However, users still see notices related to foreground
services in the Foreground Services (FGS) Task Manager,
regardless of whether the notification permission is granted.
o New runtime permission for nearby Wi-Fi devices
▪ Android 13 (API level 33) introduces a runtime permission
in the NEARBY_DEVICES permission group for apps that
manage a device's connections to nearby access points over
Wi-Fi. This permission, NEARBY_WIFI_DEVICES, fulfills
Wi-Fi use cases.
▪ As long as your app doesn't derive physical location
information from the Wi-Fi APIs, request
NEARBY_WIFI_DEVICES instead of
ACCESS_FINE_LOCATION
▪ When you declare the NEARBY_WIFI_DEVICES
permission, strongly assert that your app never derives
physical location information from Wi-Fi APIs. To do so, set
the android:usesPermissionFlags attribute to
neverForLocation
▪ This change affects your app only if you call a Wi-Fi API IN
THE list of affected APIs.
o Granular media permissions
▪ If your app targets Android 13 or higher and needs to access
media files that other apps have created, you must request
one or more of the granular media permissions instead of the
READ_EXTERNAL_STORAGE permission
▪ Images and photos: READ_MEDIA_IMAGES
 ▪ Videos: READ_MEDIA_VIDEO
▪ Audio files: READ_MEDIA_AUDIO
▪ If the user previously granted your app the
READ_EXTERNAL_STORAGE permission, the system
automatically grants the granular media permissions to your
app.
▪ Otherwise, the system shows a user-facing dialog when your
app requests any of the permissions
▪ If your app only needs to access images, photos, and videos,
consider using the photo picker instead of declaring the
READ_MEDIA_IMAGES and READ_MEDIA_VIDEO
permissions.
o Use of body sensors in the background requires new permission
▪ If your app targets Android 13 and requires access to body
sensor information while running in the background, you
must declare the new BODY_SENSORS_BACKGROUND
permission in addition to the existing BODY_SENSORS
permission.
▪ This is a "hard-restricted" permission
• User Experience
o Media controls derived from PlaybackState
▪ For apps targeting Android 13 (API level 33) and higher, the
system derives media controls from PlaybackState actions.
▪ This allows the system to show a richer set of controls that
are technically consistent between phones and tablet devices,
and also align with how media controls are rendered on other
Android platforms such as Android Auto and Android TV.
▪ Starting with Android 13, the system displays up to five
action buttons based on the PlaybackState
o App colour theme applied automatically to WebView content
▪ For apps targeting Android 13 (API level 33) or higher, the
setForceDark() method is deprecated, resulting in a no-op if
the method is called.
▪ If you still need to customize your app's color theme
behavior, use the setAlgorithmicDarkeningAllowed()
method instead. For backward compatibility with previous
Android versions, the equivalent
setAlgorithmicDarkeningAllowed() method in AndroidX is
recommended.
• Google Play Services
 o Permission required for advertising ID
▪ Apps that use Google Play services advertising ID and target
Android 13 (API level 33) and higher must declare the
AD_ID normal permission in their app's manifest file
▪ If your app does not declare this permission when targeting
Android 13 or higher, the advertising ID is automatically
removed and replaced with a string of zeroes.
• Updated non-SDK restrictions
o Android 13 includes updated lists of restricted non-SDK interfaces
based on collaboration with Android developers and the latest
internal testing. Whenever possible, we make sure that public
alternatives are available before we restrict non-SDK interfaces.
o If your app does not target Android 13, some of these changes
might not immediately affect you. However, while you can
currently use some non-SDK interfaces (depending on your app's
target API level), using any non-SDK method or field always
carries a high risk of breaking your app.