A tweet released "Android13 Adaptation Guide", @developer please check it!

Foreword:

On August 16, Google announced that the source code of the new Android 13 system had been uploaded to the Android Open Source Project (AOSP), and Android 13 was officially released. Since the first preview version of Android 13 was launched in February 2022, after 7 months of testing and optimization, the official version of Android 13 is finally here! Android 13 still focuses on personal privacy protection and security, and provides technical development capabilities related to large and small screen adaptation and battery utilization optimization in the era of the Internet of Everything.

Interested developers can log in to the official website to download the source code for testing and learning: https://developer.android.google.cn/about/versions/13

The developers of GeTui service have been paying close attention to and following up the development trend of the industry for many years. After the official version of Android 13 was released, we conducted research and adaptation tests using the emulator. This article will talk about the new features of Android 13 in terms of permission changes, system optimization, and function updates to help developers quickly get started with the new Android system.

permission change

1. Notification authority

Notification bar messages have always been an effective channel for communication between apps and users. Before Android 13, apps only needed to use NotificationManager to push notification bar messages to end users. Android13 introduces a new runtime notification permission: POST_NOTIFICATIONS. App developers need to pay close attention to this.

A push has tested this permission, and the summary is as follows:

1. First look at the case of TargetSdk<33.

As shown in the figure below, when the App uses the notification bar function, the system will automatically pop up the authorization pop-up window:

The user clicks "Allow", and the App can push messages to the user normally:

2. Look at the case where TargetSdk == 33.

Developers need to declare the POST_NOTIFICATIONS permission in AndroidManifest.xml, and also need to apply for runtime permissions in the code when using the notification bar push function:

 <?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    package="com.gt.demo.mubai.push">
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
</manifest>
requestPermissions(new String[]{“android.permission.POST_NOTIFICATIONS”})

The above is the case when the user clicks "Allow" App push. Of course, it is also possible for the user to click "Don't Allow". It is worth noting that once the authorization is refused by the user, the system will not display the pop-up window for permission application next time. If the app still needs to push important messages (such as major version updates) to users, it needs to guide users to go to the settings interface to enable notification permissions.

code show as below:

 private void jumpNotificationSetting() {
    final ApplicationInfo applicationInfo = getApplicationInfo();
 
    try {
        Intent intent = new Intent();
        intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        intent.setAction("android.settings.APP_NOTIFICATION_SETTINGS");
        intent.putExtra("app_package", applicationInfo.packageName);
        intent.putExtra("android.provider.extra.APP_PACKAGE", applicationInfo.packageName);
        intent.putExtra("app_uid", applicationInfo.uid);
        startActivity(intent);
    } catch (Throwable t) {
        t.printStackTrace();
        Intent intent = new Intent();
        intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        intent.setAction("android.settings.APPLICATION_DETAILS_SETTINGS");
        intent.setData(Uri.fromParts("package", applicationInfo.packageName, null));
        startActivity(intent);
    }

★Warm reminder:
If the App wants to confirm whether the user has enabled notifications, it can call NotificationManager.areNotificationsEnabled() to judge. In addition, in addition to the two options of "allow" and "disallow", the user can also swipes away from the permission application dialog (User swipes away from dialog), that is, the user does not choose to authorize (and does not choose not to authorize). Then the next time the App pushes the notification bar message, the system will pop up the user authorization pop-up window again.

★Tweet said:
The notification permission changes in Android 13 will greatly improve the end-user experience. Users can independently choose whether to accept the notification bar messages pushed by the App, reducing frequent interruptions by invalid information. Getui started as a message push service, and has always advocated green push, emphasizing pushing the right content to the right people at the right time, at the right place, and in the right scene, so as to give end users a better experience.

2. WiFi permission change

Android13's changes to WiFi permissions are also a major focus. At the moment when everything is interconnected, different smart home/smart wearable devices are mostly interconnected through WiFi, so these types of App developers should pay more attention to this part of the content.

Under the previous version of Android system, if the App wants to use WiFi-related functions, it needs to apply for ACCESS_FINE_LOCATION, that is, the location permission, as shown below:

▲The picture comes from the official website of Android13

In order to avoid excessive claims by apps and better protect the privacy of end users, Android 13 separates WiFi permissions from location permissions and introduces a new runtime permission: NEARBY_WIFI_DEVICES.

If the App only needs to use WiFi-related APIs and does not need to use location-related APIs such as getScanResults() and startScan(), it is recommended that App developers switch to the new NEARBY_WIFI_DEVICES permission.

New WiFi permission operation mechanism:

▲The picture comes from the official website of Android13

Permission usage and adaptation:
Developers should note that if your application (targetSdk == 33) has declared that it will not deduce the physical location information of the device based on WiFi information, it is no longer necessary to declare the ACCESS_FINE_LOCATION permission.

In addition, if the application only uses the WiFi API without location information on Android13, the developer can add the NEARBY_WIFI_DEVICES permission in AndroidManifest.xml, set the usesPermissionFlags attribute to neverForLocation, and add the limit of maxSdkVersion="32" to the ACCESS_FINE_LOCATION permission. code show as below:

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

3. More subdivided media rights

In addition to the update of notification permissions and WiFi permissions, Android 13 has further refined local data access permissions. Android13 subdivides the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions into: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO and READ_MEDIA_AUDIO,

As shown below:

▲The picture comes from the official website of Android13

One push uses android.permission.READ.MEDIA_IMAGES to test the new permission:

We found that when requesting READ_MEDIA_IMAGES alone, requesting READ_MEDIA_VIDEO alone, and requesting READ_MEDIA_IMAGES & READ_MEDIA_VIDEO at the same time, the system will only display one authorization popup. In addition, if the App (targetSdk == 33) has applied for the read permission, the App also has the write permission, and there is no need to declare the WRITE_EXTERNAL_STORAGE permission. The code is as follows:

 <manifest ...>
    <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" />
  
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
                       android:maxSdkVersion="32" />
</manifest>

4. Precise alarm clock permissions

In order to save system resources, Android 12 introduces the SCHEDULE_EXACT_ALARM permission for authorization management of the "alarm clock and reminder" function. Android 13 has introduced a new alarm clock permission USE_EXACT_ALARM. Different from the SCHEDULE_EXACT_ALARM permission of Android12, if the App has applied for the new permission of USE_EXACT_ALARM, the user cannot turn off the authorization in the settings page. For apps such as schedule management and time management, the USE_EXACT_ALARM permission introduced by Android 13 can bring certain convenience.

Compared with the SCHEDULE_EXACT_ALARM permission of Android 12, apps using the new permission will no longer need to frequently disturb users for authorization, and can provide users with services such as alarm clocks and schedule reminders more efficiently. However, in order to prevent the abuse of new permissions, Google Play has set up a strict listing review mechanism.

Developers should note that once the USE_EXACT_ALARM permission is used, the app will be strictly reviewed by the platform when it is listed on GooglePlay. Unless the App is an alarm, timer, calendar, etc. type of application or has been whitelisted in the application market, GooglePlay will not allow applications that use this permission to be listed.

★Tweet said: With the continuous increase in the protection of the personal rights and interests of App users in my country, it is believed that domestic mobile phone manufacturers and application markets will follow up to establish corresponding review mechanisms to enhance the protection of user rights and interests. It is recommended that App developers continue to pay attention to relevant developments and do the adaptation work in a timely manner.

5. Sensor permissions in the background

Nowadays, bio-information security is also the focus of public attention. To better protect the personal biometric information of end users, Android 13 adds new background sensor permissions. When the app is running in the background, if it needs to obtain sensor information such as heart rate, body temperature, blood oxygen saturation, etc., it will not only apply to the user for the existing BODY_SENSORS permission, but also declare the new BODY_SENSORS_BACKGROUND permission. In summary, it can be seen that Android 13 attaches great importance to and strengthens the protection of personal privacy. In addition to permission changes, Android 13 has also carried out system optimization and component updates to further improve the security and friendliness of the system.

System Optimization

1. More secure system components

IntentFilter

In previous versions of the Android system, developers only need to set android:exported to true to explicitly start Activity and Service across applications. Even if the action or type in the intent-filter does not match, they can be started. To avoid the above vulnerabilities, Android 13 enhances the matching filtering logic of intent-filter. In the case where the receiver's targetSdk == 33, if the intent-filter match hits, the intent will take effect regardless of the sender's targetSdk version.

★Reminder: The following situations do not need to follow the matching filtering logic of intent-filter: The component does not declare the intent BroadcastReceiver issued by the intent system in the same App or the Root process. Under the previous Android system, the BroadcastReceiver broadcast receiver dynamically registered by the application Broadcasts sent by any application will be received (unless the receiver is protected with an application signing permission), which can create a security risk for dynamically registered broadcast receivers.

Android 13 requires that broadcast receivers dynamically registered by an application must indicate in a prominent way whether other applications are allowed to access, that is, whether other applications can send broadcasts to it. Otherwise, the system will throw a SecurityException during dynamic registration. Currently, this enhancement does not take effect by default. Developers need to enable the DYNAMIC_RECEIVER_EXPLICIT_EXPORT_REQUIRED compatibility framework and specify whether to accept broadcasts from other applications when dynamically registering broadcasts:

 context.registerReceiver(receiver, intentFilter, RECEIVER_EXPORTED)
context.registerReceiver(receiver, intentFilter, RECEIVER_NOT_EXPORTED)

★Reminder: System broadcast is not affected by RECEIVER_NOT_EXPORTED.

Second, the foreground service (FGS) task manager

Android 13 also adds the foreground service (FGS) task manager function.

As shown in the figure below, users can directly close foreground services and applications in the drop-down notification bar:

In addition, if the system detects that the app is running a foreground service for a long time (at least 20 hours in a 24-hour period), it will send a reminder notification to the user with the following content: APP is running in the background for a long time . Tap to review. It is worth noting that the system will not display the notification if any of the following conditions are met: a notification related to the foreground service has been sent, that is, the user has not closed the previous reminder to notify the foreground service is of type FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK or FOREGROUND_SERVICE_TYPE_LOCATION

★Warm reminder:
If this notification has already been shown for an app, it will not be shown again for at least 30 days. In addition, system-level applications, security applications (such as applications with the android.app.role.EMERGENCY role) and other running foreground services will not be displayed in the FGS task manager.

3. Notification authority

Android9 introduces the application standby storage partition function. According to the usage time and frequency of the application, the application is dynamically allocated to five storage partitions with different priorities, and then different levels of application resource restrictions are imposed on applications in different storage partitions.

As follows, the storage partitions are sorted by priority from high to low. The lower the priority, the more restrictions on the apps in the partition:

• Active: The app is currently in use, or has been used recently.
• Working Set: The app is used on a regular basis.
• Frequently used: The app will be used frequently, but not on a daily basis.
• Rarely used: The app is not used very often.
• Restricted: Apps consume a lot of system resources, or exhibit bad behavior (introduced in Android 11).

Applications in the "restricted" status will be subject to the following restrictions:

• Unable to start foreground service.
• Existing foreground services are removed from the foreground.
• The alarm will not be triggered.
• Jobs will not be executed.

On the basis of the Android 9 application standby storage partition function, Android 13 optimizes the battery resource strategy to extend the battery life of the device and improve the experience of the end user.

First of all, Android 13 adds the following rules, and apps that meet the corresponding rules will enter the "restricted" bucket (the time the device is turned off will not count towards the interaction limit):

• The user has not interacted with the app for 8 days.
• The application calls too many broadcast or binding services in one day.
• The app consumes a lot of battery power in 1 day, the threshold depends on the device.

Second, Android 13 also adds restrictions to the application of "restricted" storage partitions:

• Apps will not receive BOOT_COMPLETED, LOCKED_BOOT_COMPLETED broadcasts

Fourth, the update of the non-SDK interface restrictions

Android 13 imposes restrictions on some non-SDK interfaces (and provides alternatives for some restrictions). Developers need to know whether the app uses the restricted non-SDK interface when upgrading. Reference to the restricted non-SDK interface in Android13:

 Landroid/app/Activity;->setDisablePreviewScreenshots(Z)V # Use setRecentsScreenshotEnabled() instead.
Landroid/os/PowerManager;->isLightDeviceIdleMode()Z # Use isDeviceLightIdleMode() instead.
Landroid/os/Process;->setArgV0(Ljava/lang/String;)V # In general, do not try to change the process name. If you must change the process name (for instance, for debugging), you can use pthread_setname_np() instead, though be aware that doing this might confuse the system.
Landroid/view/accessibility/AccessibilityInteractionClient;->clearCache(I)V # Use android.accessibilityservice.AccessibilityService#clearCache() instead.

Feature update

The improvement of user experience has also been the focus of Android system updates. Android 13 has mainly updated functions for clipboard, large and small screen adaptation, UI display, etc.

1. Shearing board

First look at the clipboard. I believe that everyone has used the clipboard, which can quickly copy the content on the page, which is convenient for us to edit and modify the content. However, there has always been a hidden danger in the clipboard function, that is, there may be sensitive information in the content copied by the clipboard. In order to better protect the privacy content in the clipboard (such as mobile phone number, email, account password, etc.) from being leaked, Android 13 has updated the clipboard function.

As shown in the figure below, the use of the Android13 clipboard function is divided into 2 steps: confirm that the content has been successfully copied. Provides a preview of the copied content.

In addition, Android 13 also provides a desensitization function that enables users to hide sensitive information in the clipboard, achieving both convenience and security.

2. Better support for tablets and large screens

The wide application of tablet computers, car-mounted large screens, and smart TV screens has made users' terminal scenarios more and more diverse. How to give users of different terminals a beautiful and smooth experience all the time? Android 13 provides better support for this, and updates the system UI and split-screen display on the large screen.

As shown in the figure below, on the large screen, Android 13 supports the display of different functional modules on the same screen, so that the advantages of the large screen can be fully utilized.

▲Under the Android 13 system, users can place the "Quick Settings" section and the "Notification Bar" section on the same screen.

3. Jetpack WindowManager

In addition, Android 13 also supports users to display multiple activities on the large screen at a time to make full use of the display space of the large screen. Developers can determine the specific way for an App to display multiple activities on the same screen (such as side-by-side or stacking) by creating an XML configuration file or calling the Jetpack WindowManager API.

▲For example, display two Activities on a single screen in the form of a split task window.

Fourth, better compatibility support

For apps that have not yet been adapted to large screens, Android 13 also provides more friendly and stable compatibility support, so that these apps can also have a comfortable and beautiful UI display by default, without affecting the experience of end users.

As shown below:

▲The picture comes from the official website of Android13

Summary: Through the Android system updates in the past two years, we can see that Google no longer makes drastic changes to the Android system, but has made great efforts in user experience, privacy protection, system security, and component optimization. For more Android13 update points, developers can go to the Android13 official website to learn more: https://developer.android.google.cn/about/versions/13 If you want to update the new system adaptation and Android development, etc. For in-depth exchanges, welcome to add @ Getui technical support and contact us.

In the future, Getui will continue to pay attention to the development of the Android system and the industry, exchange mobile development technologies with developers, and jointly build a new mobile Internet ecosystem.