Google’s Android 13 update launched last month and it comes with an array of changes including some important changes to notifications and permissions. While this article specifically addresses how it impacts the PlotProjects SDK, it may also be useful for anyone looking to understand the Android 13 changes, so read on to find out what to do if your apps are affected.
In this article we’ll discuss:
- The biggest Android 13 changes
- Changes to notification permissions
- Changes to the appearance of notifications in the foreground
- New Wi-Fi runtime permission
- New permissions required for advertising ID
The biggest Android 13 changes
With Android 13, Google continues to follow in Apple’s footsteps with changes to user privacy settings and permissions. This includes major changes to notifications permissions and the permissions required for advertising ID. Android 13 also introduces the Foreground Services (FGS) Task Manager and new runtime permissions for Wi-Fi.
So let’s look at it all in a little more detail.
Android 13 changes to notification permissions
Android 13 introduces big changes to how users manage apps that send them notifications. For newly-installed apps, notifications will be off by default, meaning apps have to ask for permission before they are able to send push notifications. The new permissions are similar to iOS in that users can allow or deny permissions for notifications via a system-level toggle. Android 13 also adds a runtime permission to help users control their notification settings.
What was the situation in Android 12?
In Android 12, users were automatically opted in for notifications permissions however they could manually disable notifications via > Settings > Notifications > App settings.
What’s changed in Android 13?
- Apps that target API 33 (Android 13) must now request the new POST_NOTIFICATION runtime permission to send push notifications. This applies to all types of notifications. The permission the user selects will determine what capabilities your app has.
- Apps must include a notification when they start a foreground service. They don’t need to request the POST_NOTIFICATION permission in order to launch the foreground service but they must show a notification to alert users when a foreground service is being launched.
- From the notification drawer, users can stop apps running foreground services. This is called the Foreground Services (FGS) Task Manager which we will discuss in more detail later in this article.
Notification permissions for newly-installed apps
Once you ask for permission, users can:
- Select Allow
- Select Don’t Allow
- Or, make no selection and swipe away from the dialog.
Allow
If a user selects Allow, your app can send notifications across all available notification channels including foreground service notifications which appear in the notification drawer.
It’s important to note that if a user allows your notifications but then repeatedly dismisses them, the system will give them the option to block the notification in the future. To prevent this, we recommend that you keep your messages interesting and relevant for your users.
You can do this by sending geo-triggered notifications based on your users’ current location and behavioural intent. You can also engage your users with enticing local deals and discounts using the PlotRewards API.
Don’t Allow
If they select Don’t Allow, you won’t be able to send any notifications and you won’t be able to ask for permission again unless your app qualifies for an exemption or unless they uninstall and reinstall your app.
When a user denies notifications permissions then almost all notifications channels are blocked. It also means that your app can’t send foreground services notifications. The good news is, you can still launch the foreground service and the user will see a notice posted in the Foreground Services Task Manager.
If a user doesn’t allow notifications then changes their mind, they can grant them by going to Settings and turning on notifications for your app.
Swipe Away
If a user makes no selection and swipes away from the dialog box, you can’t send notifications unless you qualify for a temporary grant which you can get by having existing operational notification channels.
Notification permissions for existing apps
If a user already has your app installed and updates their device to Android 13 it’ll automatically work on the existing permissions. As long as permissions weren’t disabled, your app can still send notifications to users, and users don’t see a runtime permission prompt.
If your app was installed on a device running 12L (API 32) or lower that the user is discarding, the system will still consider your app to be an existing app when they upgrade to a newer device that runs Android 13 and restore your app using the backup and restore feature.
Foreground services notifications changes
On Android 13, users can dismiss a notification associated with a foreground service by default. This is done by swiping on the notification. In previous versions of Android, the notification cannot be dismissed unless the foreground service is stopped or removed from the foreground.
- You can make these notifications non-dismissible by following the recommendations set by Android here.
Foreground Services (FGS) Task Manager
Android 13 includes a new Foreground Services Task Manager. It shows users a list of apps currently running foreground services and lets them stop them.
They can access the list of Active apps by swiping down on the notification drawer and tapping on the new icon that shows the number of apps running services in the foreground. Tapping on the new icon shows a card with the name of each app, the amount of time spent active in the foreground, and a Stop button. All they have to do is tap on the Stop button to stop the foreground service.
Any app that has an ongoing foreground service will be affected, regardless of whether it targets Android 13. That said, a few apps are exempt from appearing in the FGS Task Manager including devices that are in demo mode, system-level apps and safety apps bearing the ROLE_EMERGENCY role.
In addition, users can’t stop device owner apps, profile owner apps, persistent apps and apps that have the ROLE_DIALER role.
What happens when a user presses Stop?
- The system removes the app from memory stopping the entire app, not just the foreground service that’s running.
- Your app’s activity back stack is removed.
- Any media playback is stopped.
- The foreground service notification is removed.
- The system doesn’t send your app any callbacks.
It’s important to note that stopping an app via FGS Task Manager doesn’t have the same effect as closing it from the recents screen or via the Force stop option in Settings.
What’s preserved when a user presses Stop?
- Alarms are preserved
- Your app is not removed from history
- Scheduled jobs are preserved.
Nearby Wi-Fi Devices permissions
One of the new features offered by Android 13 is Nearby Wi-Fi Devices Permission. Before Android 13, if you wanted to use Wi-Fi related features your would have to ask the user for ACCESS_FINE_LOCATION permission. This wasn’t ideal as users could get confused between you accessing their location or their Wi-Fi service. Android 13 clarifies this by introducing the NEARBY_WIFI_DEVICES permission for Wi-Fi related features.
In Android 13 you need to request this permission if your app manages a Wi-Fi connection. What’s more, if your app doesn’t derive physical location from Wi-Fi, you no longer need to request ACCESS_FINE_LOCATION permission. This new distinction is similar to the Bluetooth permissions distinction introduced in Android 12.
This new permission is part of the Nearby Devices Group introduced in Android 12. When you request any combination of permissions from this, the system shows a single runtime dialog and asks the user to approve access to nearby devices.
How do I know if this change applies to my app?
- NEARBY_WIFI_DEVICES permission must be requested by all apps that target Android 13 and manage a Wi-Fi connection. You can check the Android Developer guide for a list of API’s that require this permission.
Does your app use Wi-Fi to derive physical location?
- No. If your app doesn’t derive physical location from Wi-Fi, you should strongly assert that. To make this assertion, set the ‘android:usesPermissionFlags’ attribute to ‘neverForLocation’ in your app’s manifest file.
- Yes. If your app does derive physical location from Wi-Fi, you must continue to request the ACCESS_FINE_LOCATION. It’s important to note that even if your app does not derive physical location from Wi-Fi, Android generally recommends keeping the ACCESS_FINE_LOCATION declaration. One reason being that it provides backward compatibility for your app. Additionally, Several Wi-Fi API’s still require the ACCESS_FINE_LOCATION permission.
Advertising ID permissions
Similar to Apple’s IDFA changes in iOS 14.5, Android 13 introduces a new permission requirement when accessing a user’s advertising ID. This change applies to apps targeting Android 13 and using the Google Play services advertising iD. Even if your app doesn’t target Android 13, we recommend that you review the latest details in this Google Play article.
What to do
- If you app is impacted, you must now declare the AD_ID permission in your app’s manifest file as described in the Android Developer guide. Check out this helpful resource for best practices when working with Android Identifiers.
- If you use the PlotProjects SDK to set the advertising ID then don’t worry, we’ve got you covered. You can follow the steps in our documentation. This applies if your app collects Google Play advertising ID via the Plot plugin.
What if my app is impacted and I don’t declare permissions?
- We highly recommend that you do declare the new permissions. Similar to Apple’s policy, the system will automatically remove the advertising ID. We recommend that you check out all of the information we’ve linked to above to keep abreast of the changes and requirements.
Are you affected by Android 13?
If you have any concerns about how Android 13 will affect your apps, please contact us today.
PlotProjects can help to maximise your app’s value for users who are on-the-go. To find out more about our geofencing SDK contact PlotProjects today. With many years of experience and expertise, our solution is hailed as the best in the industry for both big and small businesses alike.
What’s more, with our PlotRewards API you can build local deals and card-linked rewards into your apps and websites within minutes.