Privacy on Android Q: Comparison to iOS 12

May 30, 2019 | Technology & Innovation

Google recently announced the latest version of the Android operation system, Android Q, with a number of privacy-focused features. Like Apple, it seems that Google understands that users are increasingly concerned about privacy, and bolstering privacy on the platform is critical to its long-term success. But how does the latest set of privacy enhancements compare to Apple’s current iOS 12 operating system? Are the changes significant enough to choose one over the other for privacy reasons? Let’s take a deeper dive into Android Q’s privacy enhancements and compare them to their equivalents on iOS.

Tighter Restrictions on App Access to External Data Storage

Android Q introduces a new feature for external storage devices called scoped storage. Scoped storage is designed to provide greater protections for data stored on external storage, such as SD cards inserted into the device. With scoped storage, developers can designate whether these files can only be accessed by the app that created them, or if they should be shared across apps, such as media or downloads files. Although scoped storage requires developers to opt-in to this feature, properly scoping access to files on external storage can increase privacy and security for the user.

On iOS 12 and earlier versions, this feature is largely irrelevant since iOS devices do not provide slots for external storage, such as SD cards. Instead, iOS apps can opt for networked storage, such as iCloud, shared app group containers or storage in a shared system “Documents” folder using explicit sharing. Apple tends to lock down their iOS devices fairly tightly, and it already has had strong file access protections.

Bottom line: Scoped storage is a great privacy and security enhancement on Android Q. If properly adopted by app developers, it can significantly protect users from apps accessing data that should not be available to them. However, it does not provide any significant privacy or security benefit over iOS 12.

Explicit Permissions for Sharing Location Data in Background

Android Q introduces a new permission that apps must request when collecting location data in the background. Recently, mobile users have become more aware of how much location data can be tracked by apps when they aren’t even interacting with them. This data can be sent to remote servers and analyzed or sold to third party companies. For some apps, this is a legitimate requirement, such as activity-tracking apps or map apps providing directions. Instead of allowing all apps that have been granted location access to collect data in the background, on Android Q apps that want to collect that data must explicitly ask permission for it.

On iOS 12 and earlier versions, apps must explicitly request access to use location in the background. Like Android Q, this makes it easier to understand when apps may be collecting location data.

Bottom line: By requiring apps to explicitly request access to location data while in the background, Android Q has caught up to iOS 12 and earlier versions. Location data is extremely sensitive personal information that reveals where we live and work, and what our daily routines are.

Preventing Apps from Displaying Content When Not Requested

Android Q introduces new restrictions on launching activities from the background without user interaction. This applies to all apps running on Android Q and only allows apps to present content in one of four constrained scenarios. First, an app can present content to a user if it has a visible window, such as when it is running in the foreground. This is the typical scenario when a user is using an app. The second scenario is when the app is launched from another app, for example, when sharing content. Third, an app can present content when it is launched from a pending intent, such as a push notification. Finally, apps can present content when certain system broadcast events are received.

On iOS 12 and earlier versions, apps are similarly limited in how they can launch into the foreground. Apps can respond to user interaction when they are active, open in response to push notifications, and integrate with various other iOS systems, such as CallKit call integration.

Bottom line: Limiting apps ability to present content to the user when not active is important for protecting privacy and security. Android Q is further tightening restrictions on when and how apps can present content. These improvements appear to be on par with existing iOS functionality.

Preventing Unauthorized Access to Hardware identifiers and Other Data

Android Q introduces new restrictions on access to hardware identifiers and some other data. These improvements are designed to limit apps from accessing information that can be used to uniquely identify a device across apps or other systems. Two non-resettable hardware identifier, the IMEI and serial number, require a special permission in Android Q. The device’s MAC address, used to connect to networks, is randomized by default, and access to network information via the /proc/net file system directory.

Two other data access changes appear in Android Q. First, apps with contact access can no longer determine which contacts are most frequently accessed, protecting this sensitive user information. Second, additional restrictions have been added to clipboard data. Only apps that are the default input method editor (IME) or the currently active app can access clipboard data.

On iOS 12 and earlier versions, these protections are largely in place. iOS has long limited access to IMEI and serial number, and randomizes MAC address for unknown networks. iOS also already has a limited API for apps that have access to contacts, not disclosing information about how frequently a contact is used. iOS has restrictions on clipboard data similar to Android Q, requiring an app to either be in the foreground or the default keyboard

Bottom line: Android Q provides better protection for device specific identifiers and other fingerprinting data than previously existed on Android, but this only brings it closer to parity with iOS.

Minimizing Availability of Camera and Network Configuration Data

Android Q introduces new limits on what camera properties apps have by default and what network configuration data they can read. Because of the breadth of camera metadata, apps can develop a fingerprint of the device based in part on how the camera is configured. Starting Android Q, apps querying the device’s camera metadata will only have access to a limited amount of information unless the user has given the app the camera permission. In addition to the camera metadata restrictions, apps targeting Android Q will no longer be able to read Wi-Fi network state, including configured networks and the results of certain network configuration requests.

On iOS 12 and earlier versions, camera permission is required to gain access to the device’s camera, but even with access to the device’s camera, only limited information is provided about the configuration. Instead, the desired configuration is typically provided. Because of this approach, iOS is not vulnerable to device fingerprinting via camera metadata.

iOS has had several tools to allow Wi-Fi configuration by apps, but they are limited in scope to adding and removing specific Wi-Fi hotspot configurations and cannot be used as a general tool for reading the device’s Wi-Fi configuration.

Bottom line: Android Q tightens down two potential leaks of private data with limits on camera metadata and network configuration data; however, this is only bringing it closer to equivalence with existing iOS restrictions.


Although Android Q introduces substantial improvements to privacy and security over earlier versions of Android, in all cases these appear to only bring it to a similar level as iOS. Given the increase of concern by consumers about their privacy, we can expect Android to continue to converge with Apple in terms of privacy protections. This is good news for Android users who want to remain on Google’s platform.

You May Also Like…