Android Q, the upcoming 10th major release of the Android mobile operating system, was developed by Google with three major themes in mind: innovation, security, and privacy. Today, we are going to focus mostly on security and privacy, although there are still many potential changes and updates on the horizon that can be discussed.
Privacy has been a top priority in developing Android Q, as it’s important today to give users control and transparency over how their information is collected and used by apps and by our phones. There are significant changes made in Android Q across the platform to improve privacy, and we are going to inspect them one-by-one.
Note: Developers will need to review new privacy features and test their apps. Impacts can vary based on each app’s core functionality, targeting, and other factors.
Let’s start with location. Apps can still ask the user for permission to access location, but now in Android Q, the user sees a larger screen with more choices on when to allow access to location, as shown in Picture 1. Users will be able to give apps access to location data all the time or only when the app is in focus (in use and in the foreground).
This additional control became possible by Android Q introducing a new location permission ACCESS_BACKGROUND_LOCATION, that allows an app to access location in the background.
A detailed guide is available on how to adapt your app for the new location controls.
Outside of location, a new feature called “scoped storage” was introduced to give users more security and reduce app clutter. Android Q will still use the READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions, but now apps targeting Android Q by default are given a filtered view into external storage.
Such apps can only see their specific directory and specific types of media, thus need no permission to read or write any file in this folder. It also allows a developer to have their own space on the storage of your device that is private without asking for any specific permissions.
Note: There is a guide that describes how files are included in the filtered view, as well as how to update your app so that it can continue to share, access, and modify files that are saved on an external storage device.
From the security standpoint, this is a beneficial update. It stops malicious apps that depend on you granting access to sensitive data because you did not read what you saw in the dialog and just clicked “yes.”
Another important change is that developers have created restrictions on launching activities from the background without user interaction. This behavior helps reduce interruptions and keeps the user more in control of what’s shown on her screen.
This new change takes effect on all apps running on Android Q. Even if your app has API level 28 or lower and was originally installed on a device with Android 9, restrictions will work after the device is upgraded to Android Q.
Note: Apps running on Android Q can start activities only when one or more of the following conditions are met.
Data and identifiers
To prevent tracking, starting in Android Q, Google will require app developers to request a special privileged permission (READ_PRIVILEGED_PHONE_STATE) before they can access the device’s non-resettable identifiers, both IMEI and the serial number.
Note: Read the best practices to choose the right identifiers for your specific case, as many don’t need non-resettable device identifiers (for analytics purposes, for example).
Also, Android Q devices will now transmit a randomized MAC address by default. Although Google introduced MAC address randomization in Android 6.0, devices could only broadcast a random MAC address if the smartphone initiated a background Wi-Fi or Bluetooth scan. It’s worth mentioning, however, that security researchers proved they can still track devices with randomized MAC addresses.
Wireless network restrictions
Another new feature in Android Q is that apps cannot enable or disable Wi-Fi. The
WifiManager.setWifiEnabled() method always returns
As of now, with Android Q users are prompted to enable or disable Wi-Fi via the Settings Panel, an API which allows apps to show settings to users in the context of their app.
What’s more, to protect user privacy, manual configuration of the list of Wi-Fi networks is now restricted to system apps and device policy controllers (DPCs). A given DPC can be either the device owner or the profile owner.
Android Q changed the scope of the READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT and CAPTURE_SECURE_VIDEO_OUTPUT permissions. Now they’re signature-access only, so they will prevent silent access to the device’s screen content.
Apps that need access to the device’s screen content will use the MediaProjection API. If your app targets Android 5.1 (API level 22) or lower, users will see a permissions screen when running your app on Android Q for the first time, as shown in Picture 2. This gives users the opportunity to cancel/change access to permissions that the system previously granted to the app while installing.
In addition, Android Q introduces a new ACTIVITY_RECOGNITION permission for apps that need to detect the user’s step count or classify the user’s physical activity. This is done for the users to see how device sensor data is used in Settings.
Note: If your app relies on data from other built-in sensors on the device, such as the accelerometer and gyroscope, you don’t need to declare this new permission in your app.
Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and iris. To keep users secure, the API was expanded in Android Q to support additional use-cases, including both implicit and explicit authentication.
If we are talking about explicit authentication, users must perform an action to proceed. That can be a tap to the fingerprint sensor or, if it’s face or iris authentication, then the user must click an additional button to proceed. All high-value payments have to be done via explicit flow, for example.
Implicit flow does not require an additional user action. Most often, sign-in and autofill are used in these cases, as there is no need to perform complex actions on simple, unimportant transactions that can be easily reversed.
One more interesting change made in Android Q is support for TLS 1.3. It is claimed that secure connections can be established as much as 40 percent faster with TLS 1.3 compared to TLS 1.2. From a security perspective, TLS 1.3 is cleaner, less error prone, and more reliable. And from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.
Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu.
The last feature we wanted to point out is Adiantum, a storage encryption that protects your data if your phone falls into someone else’s hands. Adiantum is an innovation in cryptography designed to make storage encryption more efficient for devices without cryptographic acceleration to ensure that all devices can be encrypted.
In Android Q, Adiantum will be part of the Android platform, and Google intends to update the Android Compatibility Definition Document (CDD) to require that all new Android devices be encrypted using one of the allowed encryption algorithms.
Beta 5 and beyond
Android Q Beta 1 was launched on March 13, and we already have Beta 5 available to download. If you would like to try the Beta version, please proceed to android.com/beta to check if your device is in the supported list and download the beta.
There is still one more beta before the final build drops sometime before Q3 is over, according to timeline. Developers should dive into Android Q and start learning about the new features and APIs they can use in their apps before adjusting.
And perhaps the most important question of all—what will Android Q be named? The list of desserts starting with Q is rather small, and some suggestions that already came up among network users are:
What would you call it? And do you think these changes will better protect user privacy and security? Sound off in the comments.