Yes, you read that right, it’s going to take you to adapt Android 13 right now.

Google I/O 2022 released Android 13 beta 2 and Android 13 Beta 1 device support list of domestic manufacturers, although in accordance with the usual practice, Android 13 should be the end of the year before the release of the official version, but I believe that some developers have already received the platform of Android 13 adaptation requirements, so this is also combined with Oppo’s Android 13 application compatibility adaptation guide and some official documentation to do a finishing test. So this article is also combined with Oppo’s Android 13 application compatibility adaptation guide and the official content of some documents to do a finishing test.

The main compatibility issue with Android 13 is still the privacy permissions, so this adaptation guide focuses on this part of the content, which involves a wide range of albums and notification permissions.

 Album Permissions

As you may have seen, this is the system image selector available on Android 13, which can be opened via Intent(MediaStore.ACTION_PICK_IMAGES); , and supports video, audio, and image categorization, with multi-select and single-select support. It’s also official that this feature won’t just be in Android 13, but that Google will be placing it in the Play store and pushing it out to Android 11 and Android 12 devices. This feature will not only be available in Android 13, Google will also place it in the Play Store and push it to Android 11 and Android 12 devices.

We tested this by adjusting the TargetSDK setting to PreView and then running it on Tiramisu’s emulator, mainly testing the difference between TargetSDK at less than “Tiramisu” and equal to “Tiramisu”.

 As shown in the figure below:

• 
  Figure 1 shows the TargetSDK running on the Andorid 13 emulator when it is below 13, where information about the local gallery can be accessed normally;

• 
  Fig. 2 shows the system album selection component under “Tiramisu”, which is opened by the official Intent(MediaStore.ACTION_PICK_IMAGES); , and it is fine.

• 
  Fig. 3 and Fig. 4 show the reading of albums after running with “Tiramisu”, using the previous code, without processing, and you can see that the relevant information cannot be read at this point;

• 
  Figure 5 shows that by applying the new android.permission.READ_MEDIA_IMAGES permission, you can continue to access the previous album information with the previous code, because for the target version of Android 13, the READ_EXTERNAL_STORAGE permission is now refined, and the developer needs to use READ_MEDIA_IMAGE , READ_MEDIA_VIDEO , and READ_MEDIA_AUDIO instead of adapting;

• 
  Fig. 6 After applying permissions, you can read the albums and other information normally;

To summarize: So if the TargetSDK is under Android 13, it doesn’t need to be processed, if it is on Android 13 and above, it needs to be added to the application permissions.

    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
    <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
    <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />

On Android R, the notification permissions of apps can be managed in Settings, but apps cannot modify app-level notification permissions, so apps can’t know whether they have the permission to send notifications or not.

That’s why runtime permissions for notifications have been added in Android 13, where Android 13 (33) notifications are handled differently depending on the target API level of the running app, though Android 13 prompts the user to grant the app permission to send notifications regardless of the app’s target API level.

The image below, for example, is targetSdk 30 running on an Android 13 emulator, and still pops up to let the user know whether to allow the push or not.

• 
  By selecting Allow, the application can send notifications through any channel and publish notifications related to frontend services;
• 
  By selecting the disallow option, the app will not be able to send notifications and all notification channels will be blocked except for a few specific rules, which is similar to the behavior that occurs after a user manually turns off all notifications for an app in the system settings.
• 
  If the user doesn’t choose to, for example, scratch the dialog box, or just go back, the app can only send notifications if the system has temporary authorization to do so (the app must already have a notification channel and the user hasn’t explicitly deactivated the app’s notifications on devices powered by 12L or lower)

Of course, the system also handles notification access based on the application’s target API level: the

•  For newly installed applications, the program’s target APIs behave differently:
  • 
    Taking Android 13 as the TargetSDK (33), the app needs to declare the permission android.permission.POST_NOTIFICATION in Manifest, and the level of this permission is “dangerous”, so the App POST_NOTIFICATION permission in Manifest, the level of this permission is “dangerous”, so the app needs to show the runtime notification to the user in order to be granted the permission (i.e., calling the permission request in the code, but turning it on in the settings does not work), and the notification of the app that is not granted the permission will be deleted by the system;
  • 
    If the application is targeting platform 12L (API level 32) or lower; when the application creates its first notification channel, the system displays the Permissions dialog box;

In the case of an existing application update, the target API level for the program is:

• 
  With Android 13 (33) as the target platform, the system temporarily grants apps permission to send notifications until activity in the app is launched for the first time (i.e., the first time the app is launched after the update), which requires that the app must have an existing notification channel and that its notifications must not be explicitly disabled by the user;
• 
  If the application is targeting platform 12L (32) or lower, the system temporarily grants the application permission to send notifications until the user explicitly selects an option in the permissions dialog box;.

 A final test and summary:

• 
  In case of TargetSDK below Android 12L (32), notifications can only be sent as long as the user agrees, usually when the app is launched, for example, if the user clicks on disallow, the notification can’t be sent, and you need to wait until the next time the app is launched again before asking again or go to the Settings Notification Center to turn it on;

• 
  If the TargetSDK is on Android 13 (33) or above, you must manually add android.permission.POST_NOTIFICATIONS and the code call application, otherwise the Settings Center may not even open;

 Nearby WIFI device permissions

Since Android could previously infer a device’s location by tracking nearby Wi-Fi APs and Bluetooth devices, this time around Google has decided to disable apps from accessing Bluetooth or Wi-Fi scan results unless such apps need to declare ACCESS_FINE_LOCATION permissions.

In Android 13, Google separated Wi-Fi scanning from location-related content, and Android 13 added the NEARBY_WIFI_DEVICES runtime permission (belonging to the NEARBY_DEVICES permission group) for apps that manage the device’s connection to surrounding Wi-Fi hotspots, allowing apps to access nearby Wi-Fi devices without the need for the ACCESS_FINE _LOCATION permission is not required to give the app access to nearby Wi-Fi devices.

Previously, for apps that only need to connect to a Wi-Fi device, but don’t actually need to know the location of the device, apps targeting Android 13 (33) can now refine the request for the NEARBY_WIFI_DEVICES permission via the ” neverForLocation” attribute. DEVICES permission.

As long as your app doesn’t derive a physical location via the Wi-Fi API, you can request NEARBY_WIFI_DEVICES instead of ACCESS_FINE_LOCATION when you target Android 13 or later and use the Wi-Fi API.

This new permission affects several different Wi-Fi use cases, including the following:

• 
  Finding or connecting to a nearby device, such as a printer or media projection device, for similar scenarios can be used as follows:
  • 
    Receive AP information by out-of-band means (e.g., via BLE);
  • 
    Use a hotspot for local use only to discover and connect to devices through the Wi-Fi sense and connect feature;
  •  Discover and connect to devices via direct Wi-Fi connection;
• 
  Initiate a connection to a known SSID, such as a car or smart home device.
•  Turn on a hotspot for local use only.
•  Connect to a nearby Wi-Fi aware device.

 So development needs to differentiate between the permissions corresponding to different api’s;

• 
  API that requires new permissions (NEARBY_WIFI_DEVICES):

  • 
    WifiManager: startLocalOnlyHotspot()
  • 
    WifiAwareManager: attach()
  • WifiAwareSession：publish()、subscribe()
  • WifiP2pManager：addLocalService()、connect()、createGroup()、discoverPeers()、discoverServices()、requestDeviceInfo()、requestGroupInfo()、requestPeers()
  • WifiRttManager：startRanging()

• 
  APIs that still require location information permissions (ACCESS_FINE_LOCATION ):

  • 
    WifiManager: getScanResults(), startScan()

Since the NEARBY_WIFI_DEVICES permission only applies to Android 13 or later, Apps with Android 12L(32) and below should keep all declarations for ACCESS_FINE_LOCATION:

<manifest ...>
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
                     android:maxSdkVersion="32" />
    <application ...>
        ...
    </application>
</manifest>

When targeting Android 13(33), set the usesPermissionFlags property to neverForLocation in the manifest file if the app does not derive a physical location from the Wi-Fi API.

<manifest ...>
    <uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"
                     android:usesPermissionFlags="neverForLocation" />
    <application ...>
        ...
    </application>
</manifest>

So to summarize: apps targeting Android 13(33) to access nearby WI-FI devices. Except for the special case API, which needs to apply for ACCESS_FINE_LOCATION, it needs to apply for android.permission.NEARBY_WIFI_DEVICES runtime permission;

 Using body sensors in the background requires new permissions

The concept of “in-use” access to body sensors (such as heart rate, temperature, and oxygen saturation) was introduced in Android 13, and this access mode is very similar to the one introduced for location information in Android 10 (API level 29).

If your App targets Android 13(33) 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.

Note: This is a “hard limit” permission and will not be available to your app unless the device’s installer lists it as a permission for your app, see the Restricted Permissions guide for more information.

The Intent filter blocks unmatched intent

When an App sends an intent from an exported component of another app that targets Android 13(33) or later, the system will deliver the intent only if the intent matches the <intent-filter> element in the receiving app, in other words, the system will block all mismatched intents, except for the following cases:

• 
  An intent sent to a component of another application that has not declared any intent filters;
•  An intent to send to other components in your app;
•  An intent sent by the system;
•  intent sent by a user with root-level privileges;

 Safer export of context-registered receivers

To help improve the security of runtime receivers, Android 13 allows you to specify whether specific broadcast receivers in an App should be exported and visible to other apps on the device, a change that is a continuation of the more secure components of Android 12;

Apps targeting Android 13(33) or later must specify RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED for each broadcast receiver, otherwise the system throws the following when the App tries to register a broadcast receiver SecurityException

// This broadcast receiver should be able to receive broadcasts from other apps.
// This option causes the same behavior as setting the broadcast receiver's
// "exported" attribute to true in your app's manifest.
context.registerReceiver(sharedBroadcastReceiver, intentFilter,
    RECEIVER_EXPORTED);
// For app safety reasons, this private broadcast receiver should **NOT**
// be able to receive broadcasts from other apps.
context.registerReceiver(privateBroadcastReceiver, intentFilter,
    RECEIVER_NOT_EXPORTED);

 Apply self-revoking permissions

In Android 13, Google added a new API that allows developers to downgrade permissions.

Applications can trigger the revocation of one or more runtime permissions granted to packages that invoke the API, and applications that do not need access to specific runtime permission-controlled APIs can revoke these permissions themselves so that users can ensure that these applications do not unknowingly use these APIs.

To revoke a specific runtime permission, pass the name of the permission into the revokeOwnPermissionOnKill() method, and to revoke a group of runtime permissions at the same time, pass the name of the group into revokeOwnPermissionsOnKill().

Undo occurs asynchronously and terminates all processes associated with the application’s UID.

The system only triggers the undo operation if it is safe to do so, i.e., the undo does not occur when there is an application component still running in the foreground or another application is accessing a component of your application (e.g., a content provider).

If you want to revoke permissions immediately, you can call exit(). However, making the exit() call may cause other apps that are currently accessing the App to crash.

 Clipboard Erase

Android has previously provided a clipboard service that all Apps can use to place and retrieve text.

While it is technically possible for any app to clear the main contents of the global clipboard (as long as they are a foreground app or the default input method on Android 10+), Android itself does not automatically clear the clipboard.

This means that any clipboard content left in the global clipboard can be read by apps later, although Android’s clipboard access has toast messages that may alert the user.

Android 13 adds the Clipboard Auto Clear feature, this feature is disabled by default and will automatically clear the master clip from the global clipboard after a set amount of time, by default after 3600000 milliseconds (60 minutes) the clipboard will be cleared.

Each time you perform a copy/read (write to clipboard setPrimaryClip , read getPrimaryClip ), a message timeout (60min) will be reset, after which the contents of the clipboard memory will be cleared automatically, i.e., within 60min, if there has been no write to clipboard operation, the contents of the clipboard will be cleared automatically.

 Front Desk Services (FGS) Task Manager

Android 13’s new Foreground Services (FGS) task manager displays a list of apps currently running Foreground Services, called Active Apps, which can be accessed by pulling down the notification drawer and clicking on the revelation, which is accompanied by a “stop” button next to each app. ” button next to each application.

Note: When the user clicks the Stop button next to the application, the system stops the entire application, not just the frontend service that is running.

Note: If the system detects that your app has been running a frontend service for an extended period of time (at least 20 hours in a 24-hour period), a notification will be sent inviting the user to interact with the FGS Task Manager, see: developer.android.google.co.uk/about/versi…

 Improving Prefetching with JobScheduler

With JobScheduler, applications can use JobInfo.Builder.setPrefetch() to mark specific jobs as “pre-fetched”, which means that ideally they should run a little bit earlier before the next application startup to improve the user experience.

In the past, the JobScheduler only used this signal to give pre-extraction jobs a chance to use free or redundant data. In Android 13, the system now tries to determine when the app will next launch and runs a pre-extraction job based on that estimate, and apps should try to use Pre-Extraction to complete any work they want to do before the next app launch. Apps should attempt to use Prefetch to complete any work they want to accomplish before the next app launch.

 Battery resource utilization

The Battery Resource Utilization feature was introduced in Android 13 to provide the system with multiple ways to better manage device battery life:

• 
  Updated the rules for when the system places your apps in the “Restricted” app standby mode storage partition.
• 
  New restrictions on what your app can do if a user puts your app in a Restricted state because its background battery usage is too high.
• 
  System notifications have been added to warn users about high battery usage and long-running frontend services.