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.

• What affects: All applications running on Q (regardless of the target SDK). An exception is thrown if Android Q is the target version of the application; and Activity just won’t start if Android Q is not the target SDK for the application, but it works on a device with Android Q.
• Exceptions: Bound services, such as accessibility, autocomplete, etc. If the application receives a PendingIntent
  
  
  
  from the system, we can use it to start the Activity. If the application has SYSTEM_ALERT_WINDOW
  
  
  
  permission (removed in Android GO) or the application recently called finish()
  
  
  
  for Activity (it is not recommended to rely on it. “Recently” can be very ambiguous), then your application is free from this restriction.
• Recommended approach: Notification triggering Activity

 val fullScreenIntent = Intent(this, CallActivity::class.java) 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.

• Waterstones: The system decides when to display a notification and when to show an Activity. If the user is actively using the device, a pop-up notification is displayed. If the device is at rest or when the user interacts with the notification, the full-screen Activity starts. For example, as when receiving a phone call (pop-up notifications while using the phone, otherwise full-screen Activity).

b) Hardware identifiers

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

• What affects: All applications running on Q (regardless of the target SDK). An exception is thrown if Q is the target SDK; and returns null
  
  
  
  if the target SDK is less than Q
• Avoid: The Mac address is now randomized, and the IMEI ( TelephonyManager.getDeviceId()
  
  
  
  ) and serial number are no longer available. Now they are “privileged permissions” and are available only for operator applications.
• Recommended approach: Use resettable identifiers such as Advertising ID, Instance ID, or Globally-unique ID (GUID). See Best practices for unique identifiers for more information on which identifier to use in which case.

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).

• What it affects: It depends on the target SDK. If Q is the target SDK for the application, then you need to request a new location permission in the background. If the application has a different target SDK, it will automatically receive this permission if it already had access rights to the location.

Image taken from Android Developer Documentation

• Recommended approach: if the application requires one-time access to the user's location to perform some tasks, use the foreground service with the foregroundServiceType parameter specified as location
  
  
  
  in the application manifest file.

 <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

• Underwater rocks:

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 .