Google has launched Beta version of Android Q with new features and behaviors giving emphasized focus on privacy and security enhancements. Android Q which would be released in August, supports foldable devices, new APIs for Wi-Fi connectivity, Telephony, Camera, etc.

Among all the new features, considering the importance of data privacy in the coming years, Google has specifically addressed them in this release. With this blog, I am going to take you through those privacy features and demonstrate how to migrate them. Let’s start with privacy & security capabilities first.

Top 6 Privacy Feature Changes in Android Q

Android Q provides more transparency and control for the users over their data. Here are the top privacy enhancements we will touch base.

1. Scoped Storage

Use Case:

Till Android P or below, any application can read or write files to the users’ mobile external storage with the read/write permissions provided. This is a security or privacy concern for the user because the external storage will be available even if the application is deleted.

Work Around in Q:

Android Q comes with a feature where the App is given its own folder to store user-facing data. The app will have a private sandbox folder for storage of the required files and this folder is not available to any other app. This helps in keeping the files privately organized. App specific files can be stored in the directory using context.getExternalFilesDir().

Migration Impact:

Apps that follow best practices in terms of accessing external storage should work with scoped storage with minimal development effort. A new manifest attribute “requestLegacyExternalStorage” is introduced in Android Q. If the targetSDK is Android Q, then set the flag to true for backward compatibility.

<manifest ... >
  <!-- This attribute is "false" by default on apps targeting Android Q. -->
  <application android:requestLegacyExternalStorage="true" ... >
    ...
  </application>
</manifest>

2. Restriction to App Interruptions

Use Case:

Assume a user has opened an application and is in the middle of some activity which is very important. Suddenly, a screen/activity pops up on top of his current screen interruptingly. These interruptions without any notice lead to poor experience and in some cases loss of data.

Work Around in Q:

Android Q comes up with a workaround which keeps restrictions on when an application can start activities. This behavior change will minimize interruptions for the user and give more control over the screen.

Migration Impact:

This behavioral change will impact all the apps running on Android Q irrespective of target SDK. To make this work in Android Q, create a notification with information about why the activity or screen should be launched instead of directly starting the activity. High priority notifications can be created with full-screen intent to grab user attention. This behavior change can be enabled or disabled from Device Settings → Developer Options → Allow background activity starts. By default, this is enabled.

3. Control the Device Location Service

Use Case:

Location is one of the most sensitive information of a user who needs privacy. An application will track the location only if the user has provided the permission to do so. Once accepted, the permission remains valid even if the application is closed by the user, hence location is tracked even if the user is actively using the app or not.

Work Around in Q:

Android Q gives the user more control over location. In older versions (till Android 9), runtime permission for the location will be received once the app prompts for access. This allowed the app to keep track of user’s location even the app is in the background which might not be required.

Android Q allows the user to grant permission to deny access to location services, allow only while the app is actively in use and allow all the time irrespective of the app’s state.

Migration Impact:

If the app targets Android Q and it needs user location all the time, ACCESS_BACKGROUND_LOCATION permission must be explicitly declared in the manifest file.

4. Camera Permissions

Use Case:

To get a camera sensor or hardware lens information, the app has to get explicit camera permission. An app cannot get parameters like the orientation of the camera relative to the sensor coordinate system without a user’s consent. Till Android 9 or below, it does not require any permission to access these fields.

Work Around in Q:

Android Q now keeps restriction on accessing camera information. In order to access camera parameters, consent to camera permission is mandatory.

Migration Impact:

Access to the parameters returned by the method getCameraCharacteristics() requires camera permission. Parameters are ANDROID_LENS_POSE_ROTATION, LENS_POSE_TRANSLATION, SENSOR_CALIBRATION_TRANSFORM1, etc.

5. Wi-Fi Manipulation Access

Use Case:

Until Android 9 or below, Wi-Fi could be enabled or disabled from the application using functions like WifiManager.setWifiEnabled(). Wi-Fi is a global level setting of mobile and it should not be controlled from one application.

Work Around in Q:

Android Q keeps restriction on Wi-Fi state which cannot be enabled or disabled using WifiMananger. WifiManager.setWifiEnabled() always returns false.

Migration Impact:

If it is required to switch between Wi-Fi states, use the Settings Panel, which is introduced as one of the features in Android Q. Use a prompt for the user to enable or disable Wi-Fi.

6. Permissions

Use Case:

In order to get user physical activity such as walking, running or biking, apps have built-in functionalities like Motion Sensors, Position Sensors, Environment Sensors and so on. Each sensor has its own access rules.

Work Around in Q:

Android Q adds new runtime permission ACTIVITY_RECOGNITION for the apps that capture users’ step count. A simple permission grant can enable access for multiple sensors.

Migration Impact:

For the apps targeting Android 9 or below, if ACTIVITY_RECOGNITION is specified in the manifest file, the system grants the permission automatically. Individual sensor permissions are not required.

Top 6 New Features in Android Q

Security got a heavy boost in Android Q which makes it invincible. Enterprise device admins can have more control to block app installations from unknown sources across their entire fleet of devices with additional protections against malware.

On-device machine learning, features like the live caption of videos have taken the fancy of Beta users.
// https://www.blog.google/products/android/android-q-io/

1. Biometric Authentication Choice

Android Q has improved the biometric authentication where face or Iris authentication confirmation will be asked for some critical operation, like purchase. This is done by the flag setConfirmationRequired() to true.

public BiometricPrompt.Builder setConfirmationRequired (boolean requireConfirmation)

For low-risk transactions, the app would not ask for biometric confirmation.

Fallback support is provided in case of authentication is not successful using biometric for any reason. The system can prompt to allow a user with PIN, Pattern or Password by setting the flag setDeviceCredentialAllowed() to true.

BiometricManager.canAuthenticate() method is introduced in Android Q to check whether a device supports biometric authentication or not, prior to directly invoking.

2. TLS 1.3 Support

Android Q supports TLS 1.3. This protocol delivers performance benefits and enhanced security for internet connections. // https://www.ietf.org/blog/tls13/

When TLS 1.3 is negotiated, HandshakeCompletedListeners are called before sessions are added to the session cache (which is the opposite of TLS 1.2 and other previous versions).
// https://developer.android.com/reference/javax/net/ssl/HandshakeCompletedListener

3. WebView Hung Renderer Detection

Android Q adds a new WebViewRenderProcessClient abstract class, used to detect responsiveness of the webview by implementing the abstract methods onRenderProcessResponsive() and onRenderProcessUnresponsive().

onRenderProcessUnresponsive() will be called once the renderer associated with the view becomes unresponsive. This method will be called every 5 seconds as long as the renderer remains unresponsive.

4. Settings Panel

Settings panel API allows the app to show settings to the user in the application context. This helps the user in controlling the network or NFC setting changes instead of opening setting page outside the application.

Below code will make the settings panel open:

Intent panelIntent = new Intent(Settings.Panel.settings_panel_type);
startActivityForResult(panelIntent);

settings_panel_type can be ACTION_INTERNET_ACTIVITY, ACTION_WIFI, ACTION_NFC, ACTION_VOLUME.

5. Language Detection

TextClassifier now features the detectLanguage() method. This method works similarly to existing classification methods, receiving a TextLanguage.Request object and returning a TextLanguage object. This feature will be helpful in giving suggestions for the smart replies/ actions in notifications.

Android Q gives the ability to provide its own suggestions for replies within the notification. TextClassifier API is used to generate the suggestion replies.

6. Building Apps for Foldables

Android Q gives more support for foldable devices. Folding and unfolding the devices affect the screen size, density and aspect ratio.

Android Q introduces a new flag resizableActivity=true that tells the platform to support multi-window. Also, it gives support to a wider range of aspect ratios. Multiple foldable emulators support is available in Android Studio 3.5

Conclusion:

My primary focus in writing this blog is to give a brief picture of the privacy/security enhancements introduced in Android Q which keeps the developers, business and its users secure. Enterprise app developers should embrace the new features and implement the changes to allow their apps to leverage the power of Android Q.

Evoke’s Mobility Services

At Evoke Technologies, we are committed to helping more businesses like yours to discover how much they stand to gain from going mobile. With proven experience in developing native (iOS, Android) and cross-platform mobile applications, we learn the ins and outs of your work to pinpoint where mobility services can make a measurable difference. Our diverse mobile app development services enable enterprises to go mobile while keeping their long-term business goals into consideration.

Author

Krishna Chaitanya Pakki working as a Senior Technical Associate at Evoke Technologies, Krishna has hands-on experience in mobile technologies such as Android, Cordova, Kony, and React Native. He feels great about working in a team environment, exploring new technologies, and learning new skills.