Android Q Adaptation Guide

In the initial version of Android 10, the official changes are large, and the corresponding developer adaptation costs are still very high. Hereby the 2019.11.11 google android q workshop process, probably explain what Android Q needs to pay attention to.

  • Non-SD interface
  • Device ID
  • External storage
  • Permissions
  • New features – night mode

1. The Non-SDK interface

Official documentation: Limitations for non-SDK interfaces

Officially starting with Android 9 (API level 28), there are restrictions on the non-SDK interfaces used by apps. These restrictions work if your app gets a handle by referencing a non-SDK interface or trying to use reflection or JNI. The official explanation is to improve user experience and reduce the risk of application crashes.

1.1 Non-SDK interface detection tool

The official gave a detection tool, download address: veridex

How to use veridex: Appcompat.sh –dex-file=apk.apk

1.2 Blacklist, greylist, greylist-max-o, greylist-max-p meaning

blacklist, greylist, greylist-max-o, greylist-max-p have the following meanings:

Blacklist: non-SDK interface forbidden, Crash directly at runtime (just it must be resolved)

Greylist: A non-SDK interface that can still be used by the current version, but may become a restricted non-SDK interface in the next version.

Greylist-max-o: Non-SDK interface that can be used in targetSDK<=O but is disabled in targetSDK>=P

Greylist-max-p: Non-SDK interface that can be used in targetSDK<=P but is disabled in targetSDK>=Q

1.3 Android Q hardening and hotfix

Regarding reinforcement and heat repair, the official API is also provided.

Note: Applications that do not adapt to Android Q, if you use the blacklist related interface, when you open it on the Android Q system, it will directly Crash!

2 The Device ID

Starting from Android 10, it is impossible to completely identify a device. The method of identifying devices using device information such as mac address and IMEI has failed from Android 10. And whether or not your app is equipped with Android 10.

2.1 IMEI and other device information

Starting from Android10, the normal application no longer allows the request permission android.permission.READ_PHONE_STATE.

Moreover, no matter whether your app has been adapted to Android Q (whether targetSdkVersion is greater than or equal to 29), device information such as device IMEI cannot be obtained.

The affected APIs are as follows:

Build.getSerial();

TelephonyManager.getImei();

TelephonyManager.getMeid()

TelephonyManager.getDeviceId();

TelephonyManager.getSubscriberId();

TelephonyManager.getSimSerialNumber();

The application of targetSdkVersion<29 will return null directly when getting the device ID.

The application of targetSdkVersion>=29 will directly run out of the exception SecurityException when getting the device ID.

If your app still wants to get information such as device IMEI on devices below Android 10, you can adapt it as follows:

<uses-permission android:name="android.permission.READ_PHONE_STATE"
​
                 android:maxSdkVersion="28"/>

2.2 Mac address random allocation

Starting with Android 10, by default, randomly assigned MAC addresses are transmitted on devices with Android 10 or higher. (Starting with Android 10, the normal app can’t get the real mac address of the device, and the device is no longer able to use the mac address)

2.3 How to identify the uniqueness of the device?

The solution Google gives is: If your app needs to track the reloading of non-logged-in users, the ANDROID_ID can be used to identify the device.

The generation rule of ANDROID_ID is: signature + device information + device user

ANDROID_ID reset rule: ANDROID_ID will be reset when the device is restored to factory settings

String androidId = Settings.Secure.getString(this.getContentResolver(), Settings.Secure.ANDROID_ID);

That is to say, from Android 10, it is impossible to completely identify a device. The method of identifying devices using device information such as mac address and IMEI has failed from Android 10. And whether or not your app is equipped with Android 10.

3. External Storage

External storage access is limited to application files and media

Manage scoped external storage access

To solve the problem in the screenshot, starting from Android Q, the official has imposed certain restrictions on external storage.

To give users more control over their files and to limit file clutter, apps targeting Android 10 (API level 29) and higher are given scoped access into an external storage device, or scoped storage, by default. Such apps can see only their app- Specific directory—accessed using Context.getExternalFilesDir()—and specific types of media. It’s a best practice to use scoped storage unless your app needs access to a file that doesn’t reside in either the app-specific directory or the MediaStore.

To enable users to change the files in the management Sdcard, solve the problem of file confusion. Starting with Android 10 (API level 29), Android will impose certain restrictions on external storage.

By default, for external storage, the App can only access its own specific file directory via Context.getExternalFilesDir();

And system-specific file type directories (eg photos, screenshots, videos, etc.).

3.1 APP-Exclusive Path

For access to App-specific internal storage paths and external storage paths, READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions are no longer required:

Internal storage path /data/data/<package_name>/

External storage path /storage/Android/data/<package_name>/

3.2 Mobile Phone Sharing Path

To read shared files created by other APPs, such as albums, screenshots, etc., you need to apply for READ_EXTERNAL_STORAGE permission:

Image: Photos, Screenshots Access using the MediaStore.Images API

Video: Access using the MediaStore.Video API

Audio: Access using the MediaStore.Audio API

3.3 Downloads Folder

Read the Downloads folder of the phone, do not need any permissions, you need to use the API Storage Access Framework

4. The Authority Is Related

mainly includes:

  • Access device location information while running in the background
  • Restrictions on starting an activity from the background
  • Screen recording
  • Camera and microphone

4.1 Access device location information when running in the background

Android 10 introduced ACCESS_BACKGROUND_LOCATION permission.

If the app is running in the background and accessing the phone location, you need to apply for the permission dynamically, and the user can choose to reject it.

Most of the data given by the official is sensitive to location information. And most users are not allowed to use location information in the background.

4.2 The limit of starting the activity from the background

Please check the official documentation for details.

4.3 Screen recording

There is no need to manually apply for permission, but the official API will request permission from the user to pop up the window.

4.4 camera and microphone

Android 9 camera and microphone background permissions have been removed

5. New features – night mode

For the night mode, interested students can check out my other document:

Android Q dark theme

6. reference article

[Android 10 for Developers]

Leave a Reply

Your email address will not be published. Required fields are marked *