Preparing the application for Android Q. Part 1

The translation of the article was prepared specifically for students of the course “Android-developer. Basic course . " We also remind you that we are continuing to enroll in the advanced course "Specialization Android-developer"

We are in the 10th year of Android development (Android Q must be version 10.0). According to Beta 4, Android Q officially has a 29th level API . Although Beta 5 already exists and Beta 6 is expected, the API has been marked as final, and now is the time to see how Android Q will affect applications and what changes need to be made to fully support Android Q.

Important changes (not all) presented in Android Q can be divided into two categories: a) Confidentiality and security , b) User Experience .

From the translator: “We divided the translation into two parts corresponding to these categories. Accordingly, in the first part we will talk about privacy and security. "

1) Confidentiality and security

a) Starting background Activities

You can no longer start an Activity when your application is in the background.

 val fullScreenIntent = Intent(this, val fullScreenPendingIntent = PendingIntent.getActivity(this, 0, fullScreenIntent, PendingIntent.FLAG_UPDATE_CURRENT) val notificationBuilder = NotificationCompat.Builder(this, CHANNEL_ID) .... .setPriority(NotificationCompat.PRIORITY_HIGH) .setCategory(NotificationCompat.CATEGORY_CALL) .setFullScreenIntent(fullScreenPendingIntent, true) 

Add Fullscreen PendingIntent to the notification. Now that the notification has worked, the system will launch a full-screen Intent.

Therefore, if we want to start Activity from the background, first create a notification that will be displayed to the user. In this notification, add Fullscreen PendingIntent . Also, add the USE_FULL_SCREEN_INTENT permission to your manifest. Now that the notification has worked, the system will launch a full-screen Intent.

b) Hardware identifiers

Access to non-resettable device identifiers has been revoked in Android Q.

c) Background definition of location

Starting with Android Q, the system will distinguish between location requests made in the foreground and in the background.

The request for permission to access the location will now have 3 options: Allow all the time, Allow only when using the application (access only in the foreground) and Deny (no access).

Image taken from Android Developer Documentation

 <service android:name="MyNavigationService" android:foregroundServiceType="location" ... /> 

If the application needs constant access to the location of the device, for example, for geofence, it can configure a request to allow access to the location in the background. Other aspects of the application (such as how the location is extracted and used) do not need to be changed. To request access to a location in the background, add the ACCESS_BACKGROUND_LOCATION permission to the manifest:

 <manifest> <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" /> <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" /> </manifest> //Request for the permission like any other permission request: ActivityCompat.requestPermissions(this, arrayOf(Manifest.permission.ACCESS_COARSE_LOCATION, Manifest.permission.ACCESS_BACKGROUND_LOCATION), your-permission-request-code) 

Request location access in background

Reminder displayed by the system about access to a location in the background

A few important things to keep in mind: the user can be reminded after giving the application access to the location of the device in the background, and, like any other permission, the user can revoke the permission for it. This is especially important for applications in which Q is not a target SDK, but running on devices with Android Q, because it would get the default background resolution if it had permission to determine the location. Make sure your application handles such scripts gracefully. For this reason, whenever an application starts a service or requests a location, check to see if the user still allows the application to access location information.

On this, the first part of the article came to an end. And as promised, we will talk about User Experiences in the second part .


All Articles