Five-minute technical talk | A brief analysis of Android 14 updates and upgrades

Part 01

New Features

1.1 Grammatical gender

Just as the third person in Chinese includes he, she, and it, many languages ​​have grammatical differences in nouns, verbs, and prepositions according to different genders and objects. There are as many as 3 billion people who use gender-sensitive languages. Therefore, if the APP does not make grammatical distinctions based on gender, it may bring a bad user experience.

Therefore, Android 14 introduces a new feature: Grammar Gender. Developers can call a dedicated API: GrammaticalInflectionManager to set the gender preference of a single APP:

setRequestedApplicationGrammaticalGender(int) : Sets the gender preference. The parameter is a constant type. The specific types are as follows:

GRAMMATICAL_GENDER_NOT_SPECIFIED, 0: Gender preference has not been specified, and the default values ​​resource will be used;

GRAMMATICAL_GENDER_NEUTRAL, 1: specifies neutral, objective resource text, such as values-fr resource;

GRAMMATICAL_GENDER_FEMININE, 2: Specifies resource text for women, such as the values-fr-feminine resource;

GRAMMATICAL_GENDER_MASCULINE, 3: Specifies resource text for men, such as the values-fr-masculine resource.

The method getApplicationGrammaticalGender() is used to obtain grammatical gender preference and returns the above four int types.

After completing the gender syntax configuration, you need to declare the configuration changes in the app's manifest file:

<activity android:name=".TestActivity"

android:configChanges="grammaticalGender"

android:exported="true">

</activity>

1.2 Screenshot detection

Based on considerations related to privacy permissions, APP needs to monitor and provide feedback on screenshot operations. In previous Android versions, these operations often required developers to monitor the directory where the screenshot files were stored to implement them, which could easily cross the "privacy red line."

To create a more standardized screenshot detection experience, Android 14 introduces a privacy-preserving screenshot detection API. This API allows applications to register callbacks on a per-activity basis. When the user takes a screenshot while the activity is visible, these callback functions are called and the user is notified.

First, declare the new permission:

<uses-permission android:name="android.permission.DETECT_SCREEN_CAPTURE" />

Then, complete the following steps for each activity in your app where a user might capture a screenshot.

1. Implement a callback by overriding the onScreenCapture() function. In this callback, your app can take action, such as alerting another user that someone has taken a screenshot of a message conversation.

final Activity.ScreenCaptureCallback screenCaptureCallback =

new Activity.ScreenCaptureCallback() {

@Override

public void onScreenCaptured() {

// Add logic to take action in your app.

}

};

2. In the onStart() method of the activity, register the screenshot callback:

@Override

protected void onStart() {

super.onStart();

registerScreenCaptureCallback(executor,

screenCaptureCallback);

}

3. Finally, in the onStop() method, cancel the registration screen callback:

@Override

protected void onStop() {

super.onStop();

unregisterScreenCaptureCallback(screenCaptureCallback);

}

1.3 Brand new system return design

In Android 13, in order to cope with diverse interaction methods, Google unified the handling of return events. In Android 14, the system's return effect was further upgraded. First, a border and background were added to the return arrow to make it more obvious; second, the color of the return arrow will change with the system theme.

Figure 1: The newly designed “return” arrow

The second is to add a return preview, so that users can view the target interface in advance and decide whether to cancel or continue the return operation. This feature is still being improved, and developers need to manually enable it: Developer Options -> Predictive return gesture animation.

Figure 2 Return to preview diagram

1.4 Package installation improvements

In Android 14, PackageInstaller introduced a new method requestUserPreapproval(), which allows the App to request user approval and obtain authorization before downloading. Compared with previous versions, which have to wait until the apk is downloaded and installed before applying for authorization, this method can effectively avoid invalid downloads and save process time.

In the past, since multiple app stores may be installed on Android devices, compatibility issues may occur when using different app stores to update apps. Therefore, in Android 14, a new setRequestUpdateOwnership() method has been added to specify the app store app for subsequent updates of the app. The permission needs to be applied for: android.permission.ENFORCE_UPDATE_OWNERSHIP

After that, if the App wants to change the App Store, it will need to obtain user approval.

Have you ever encountered this situation? You are using an App, but the mobile app store triggers the automatic update condition, which directly interrupts the App process, which can make you depressed or even cause data loss. To avoid this situation, Android 14 introduces a new installation constraint API: InstallConstraints. First, use InstallConstraints.Builder to build and set update conditions, such as requiring the App process not to be in the foreground setAppNotForegroundRequired(), requiring the device not to be in a call state setNotInCallRequired(), etc. Then use commitSessionAfterInstallConstraintsAreMet() to pass in the above InstallConstraints configuration instance.

Part 02

Version adaptation improvement

2.1 Default to denying accurate alarm settings

Precise alarms are useful for user-specified notifications or actions that need to be performed at an exact time. Starting with Android 14, the system no longer pre-grants the SCHEDULE_EXACT_ALARM permission to most newly installed apps targeting Android 13 and higher, and the permission is denied by default.

The SCHEDULE_EXACT_ALARM permission is required to start an exact alarm through the following APIs, otherwise the system will throw a security exception

setExact()

setExactAndAllowWhileIdle()

setAlarmClock()

Calendar or alarm apps need to send calendar reminders, wakeup alarms, or reminders when the app is stopped. These apps can request the USE_EXACT_ALARM general permission. The system will grant the USE_EXACT_ALARM permission at installation time, and apps with this permission will be able to schedule exact alarms just like apps with the SCHEDULE_EXACT_ALARM permission.

2.2 Apps can only terminate their own background processes

Android14 adds restrictions on applications calling the killBackgroundProcesses() method. This method is used to terminate the API process and can only terminate the background process of this application. After the update, if the package name of other applications is passed in, this method will not have any impact on other applications.

2.3 Minimum installable target API level

Starting from Android 14, apps with a targetSdkVersion lower than 23 will not be installed. This is intended to improve user security and privacy. Some malware usually invades devices with lower API levels, thereby bypassing the protection of the latest version of the Android system for users. When trying to install a low-version app on an Android 14 device, the installation fails and the log is thrown: INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23

2.4 Granting limited access to photos and videos

On Android 14, when an app requests READ_MEDIA_IMAGES or READ_MEDIA_VIDEO media permissions, users can grant the app access to some photos and videos, and a new dialog box displays the following permission options:

• “Select photos and videos:” New in Android 14, users select specific photos and videos they want to provide to the app.
• Allow All: The user grants full library access to all photos and videos on the device.
• "Don't Allow": The user denies all access.

Part 03

Summarize

Android14 should launch a stable version in the next two months. This article mainly briefly analyzes the new features and version adaptation of the Beta system. There should be no major changes to the API afterwards. Android14 has made further optimizations in terms of UI interaction and application permissions, bringing users a new user experience while also taking into account security and privacy. I wonder if developers and users who have read this article are looking forward to Android14. Let's wait together for the release of the stable version of Android14~