How Android Q improves Privacy and Permission Controls over Android Pie

Android 9 Pie’s market penetration is barely a blip on the radar compared to older Android versions, but that won’t delay Google’s plans to release the next version of Android, Android Q. We expect Google to unveil the first Developer Preview of Android Q sometime next month, but ahead of Google’s announcement we’ve managed to get our hands on an Android Q build that’s likely quite far in Google’s development cycle. In our first article detailing the changes coming to the next dessert release, we talked about the new permission control interface. However, I only showed a few screenshots of the revamped permission management system, so I wanted to follow-up with more details. I have also done more testing and gathered more information on the new permissions in Android Q, the “roles” feature, the new package installer, and more. But first, here’s a brief recap of permission management in Android.

A Brief History of Permission Management in Android

Android 4.3 Jelly Bean first introduced granular permission management via the “App Ops” feature, though it was hidden from the user. Android 4.4 KitKat even introduced new user-controllable permissions in the App Ops interface, though you needed root access and an Xposed module to access it. Finally, Android 6.0 Marshmallow introduced the permissions system that we’re all familiar with, albeit with limitations on what permissions you could restrict. The older App Ops feature still exists in Android, although it can only be accessed via command line (cmd appops). Certain applications on the Google Play Store take advantage of App Ops’ command line implementation to provide a more powerful permission management interface. Google doesn’t expose App Ops to users since the user might not know what they’re doing, resulting in them denying an app some permissions it might really need to function properly. Unfortunately, since the introduction of permission management in Android Marshmallow, we haven’t seen any major changes to the feature—that is, until Android Q.

App Ops in Android 4.3 Jelly Bean

Android 6.0 Marshmallow also saw a major change in the way that certain permissions are granted to applications. Before Android 6.0, all permissions defined in an app’s manifest file are granted upon installation. With Android 6.0, Google introduced runtime permission management for certain permissions they deemed dangerous, such as external storage access, camera access, location access, and more. 

Runtime permissions are only granted after the installation of an app, and the user must explicitly consent to granting these permissions by tapping “allow” on a permission dialog box when requested. Until Google cracked down on apps targeting an older API level, app developers could bypass runtime permissions by targeting API level 22 or below (Android Lollipop or older.) Android Q will warn users trying to run an app targeting API level 22 or below, further incentivizing developers to update their apps to avoid being shamed by the OS. Thus, by the time Android Q makes its way to devices, nearly every app on a user’s device should be subjected to permission management controls introduced in Android 6.0+. With that in mind, Google is cleaning up the permission controls in Android Q to make it easier for users to manage what level of access apps have on their device.

Easier Permission Management in Android Q versus Android Pie

From Android 6.0 Marshmallow to Android 9 Pie, the existing runtime permission management only lets the user allow or deny an app certain permissions. We noted in our previous article that Android Q will allow the user to restrict a permission only while the app is in use. This feature got a lot of people excited, but we have to clarify that only the location permission can be restricted to when an app is in use. That means you can’t restrict the microphone or camera only while the app is in use. 

You shouldn’t be disappointed by that, though, since Android Pie already introduced some restrictions on the background use of the camera and microphone by requiring apps to be in the foreground or use a foreground service. In addition, Android Q expands on that by disclosing to the user whenever any app is using the microphone, camera, or accessing the device’s location. This is shown to the user as status bar icons in the top-right hand corner. When the status bar is expanded, text shown next to the icons tells the user which app is currently using one of these 3 sensitive permissions. Finally, if the user taps on this icon, a dialog is shown that tells the user which app(s) are using which permission(s). Again, this only applies to the camera, location, and microphone permissions.

Google seems to be encouraging users to restrict location access to only when an app is in use, as they’ve baked in a reminder in Android Q when the user has granted an app to always access their location. This reminder comes in the form of a notification that tells the user an app has been using their location and that it always has the ability to do so. Tapping on the notification brings you to the location permission page for that app, letting the user choose to restrict the location permission only while that app is in use. Kudos for that, Google.

Lastly, in the build that I have, the UI for the special app access permissions (like battery optimization, device admin, Do Not Disturb access, notification access, etc.) is unchanged. However, a new “Financial Apps SMS Access” special permission has been added to the list, though I’m unsure how it differs from the “Premium SMS access” permission which is what apps need to send text messages to premium numbers. It’s possible that this new permission is intended for banking apps that use SMS for certain transactions, in accordance with Google Play’s new policies restricting SMS and Call Log permissions.

Managing Permissions in Android Q

Here’s a screenshot gallery showing off the new permission management interface changes in Android Q. I’ve included detailed descriptions of each page in the captions of each image.

The screen that lists user-controllable app permissions hasn’t changed since Android Pie (Settings –> Apps & notifications –> App permissions). However, tapping on any of these permissions brings up the permission control screen with an entirely new UI.

The new UI clearly distinguishes between which apps have been “allowed” and which apps have been “denied” a certain permission. In this case, we’re taking a look at which apps have the microphone permission.

Tapping on any of the listed apps brings up a subpage of the app info screen. In the leaked Android Q build I’m running, all 3 options up top are grayed out regardless of what app I choose, perhaps because it’s incomplete. Below those buttons, you can allow or deny an app access to a certain permission. Note that the location permission also allows you to “allow only while the app is in use.” If the developer chooses, they can specify a reason why their app needs a certain permission at the bottom.

Tapping on “view detailed permissions usage” will bring you to a page that shows which permission(s) an app has used, how many times those permissions were accessed, and the last time those permissions were accessed.

The new “Permissions usage” page shows you a summary of the permission usage by apps on the device. Although there’s a new “Privacy” top-level Settings page, currently the only way to access this detailed permission overview is by going to Settings –> Location –> View details. I’m sure that’ll be changed, though, as Google has pulled all permission management features into a single system app called “PermissionController.”

The overflow menu in the top right lets you show or hide system apps from the permission overview, or filter by a specific permission. Alternatively, you can quickly switch between filtered permissions by tapping on any of the permission icons in the overview page.

With the dropdown menu in the top left, you can filter the permission access by time to see how often app(s) use certain permission(s).

With the dropdown menu in the top right (beneath the overflow menu), you can also switch between 3 different options: “most permissions,” “most accesses,” and “recent.” “Most accesses” (shown here) lets you see how often a specific app has used a specific permission. “Most permissions” and “recent” currently show the same thing in this view—which apps have used which permission most recently.

Lastly, if you tap “see all usage,” the permission overview displays a list of all apps with icons representing all the permissions that the app has accessed. If the filter is set to “most permissions,” then the list is sorted by apps which have accessed the highest number of permissions. If the filter is set to “most accesses,” then the list is sorted by which apps have tallied the highest number of permission accesses. Lastly, if the filter is set to “recent,” then the list of sorted by which app has accessed any permission most recently.

You can expand to see which permissions an app has used when you’re in the “see all usage” screen.

Granting Permissions in Android Q

Here are screenshots showing off runtime permission management in Android Q. We’ve already talked about what the first two screenshots show, but the third screenshot is an entirely new Android Q feature that I haven’t discussed before. The ability for Android to allow the user to control permissions before running a legacy app (defined as an app targeting API level < 23) is something that’s already possible in Android Pie with the right configuration, but Google has finally flipped the switch and enabled it in Android Q.

In Android Q, the location permission has the unique ability to be granted only when an app is in use.

All other permissions like the microphone permission can only be granted or denied.

Like CopperheadOS, stock Android Q now lets the user disable all requested dangerous permissions before running an app for the first time. This only applies to apps targeting API level 22 or below, which is before runtime permissions were introduced (in Android Marshmallow.)

Real-time Monitoring of Permissions in Android Q

Here are screenshots that show how Android Q will alert the user when an app is accessing one of several sensitive/dangerous permissions including camera, location, and microphone.

When any app is actively using one or more sensitive permissions, status bar icons are shown representing sensitive permissions that are in active use. For example, the camera app is using both the camera and location permissions, so a camera and location icon are shown in the status bar.

If you pull down the status bar and tap on the icons, a dialog box pops up which lists the apps that are using sensitive permissions. This way, you can quickly see if an unwanted app is accessing a sensitive permission in the background.

For the location permission, Android Q will occasionally remind you if you’ve granted an app the ability to access your location at any time. Tapping on this notification brings you to the location permission page for the app, letting you change it to only allow location access while the app is in use or to deny access entirely.

New Restrictions on Clipboard Access, External File Access

Background Clipboard Access Restrictions

In my previous article, I noted a new permission in Android Q’s framework that suggested that non-system apps running in the background will no longer be able to read the system clipboard. After we got the Google Play Store working, I decided to install a few popular clipboard manager apps like Clipboard Manager, Clipper, and Clip Stack to test whether I was right. For better or worse, Google is blocking background clipboard access in Android Q, as none of the apps I tested could detect any text I copied into the clipboard. I even confirmed that these apps do have the “READ_CLIPBOARD” permission they requested by using the following App Ops command:

adb shell cmd appops query-op --user 0 READ_CLIPBOARD allow

Fortunately, copying and pasting text to and from any app still works, but apps running in the background can no longer read the text that’s being copied. It’s too early to say if this change will kill clipboard manager apps because there’s a possibility Google may introduce a new API to make an app a default “clipboard manager” handler. However, I don’t see any evidence of that happening in Android Q.

External Storage File Access

I covered pretty much everything about this change in my earlier article, but here’s a summary of what Google is changing in Android Q with respect to external storage file access. First, we need to define what “external storage” means. In Android, external storage is the location where all the files and folders that you can see when you plug your phone into a computer, like Downloads, DCIM, Music, Movies, and Pictures, are stored. Apps are supposed to only store files in external storage that other apps might want to access, like music, images, videos, documents, etc.

For an app to access files on external storage, the app needs to hold the READ_EXTERNAL_STORAGE and/or WRITE_EXTERNAL_STORAGE permissions, which are both runtime permissions. Once an app has these permissions, there are no restrictions on what files on external storage it can read or modify. In Android Q, Google is breaking down these two permissions into more granular permissions, allowing the user to restrict an app so it can only read or write certain file types. Specifically, the new permissions in Android Q will let the user restrict an app so it can only:

• Read the locations from your media.
• Read or write music files.
• Read or write photos/image files.
• Read or write video files.

An app that has already been granted the READ_EXTERNAL_STORAGE permission prior to the user upgrading to Android Q will automatically be granted the “read” permissions listed above, but not the “write” permissions.

Background Location Access

Last year, a report from The New York Times shined a light at the pervasiveness of apps tracking users’ locations to sell to advertisers. Improper location tracking is a problem that Google is well aware of, having been accused of it themselves. Android 8.0 Oreo introduced restrictions on how frequently apps running in the background can access a device’s location. Location requests from apps running in the background are heavily throttled, so if an app wants to track your location with any degree of precision, it needs to disclose that it’s doing so with a visible activity or a foreground service and a persistent notification.
However, every time Google changes the way that core Android APIs work, developers whose apps legitimately used those APIs as intended are affected. We’ve seen this play out recently with Google Play’s restrictions on SMS and Call Log permissions, resulting in many popular apps losing key functionality. The same situation happened when Google limited background location access, with users of a popular golfing app complaining that they could no longer use it to track their shots. Fortunately, Android Q is adding a new “ACCESS_BACKGROUND_LOCATION” permission which, when granted, always allows an app to have access to a device’s location, even when the app is running in the background. Thus, the new Android version will not only continue to protect users from undesired background location access, but will also provide a mechanism for users to allow apps of their choosing to monitor their location in the background.

The Addition of “Roles” in Android Q

In Daniel’s hands-on video for our XDA TV YouTube channel, you may have heard him mention a new “Roles” section in the Default apps settings (Settings –> Apps & notifications –> Default apps). The only “roles” that were shown in the video were for Browser, Phone, and Messaging, which seemed redundant since there are already default app categories for browser, phone apps, and SMS apps. After spending some more time with Android Q on the Pixel 3 XL, I discovered a “role” service that I could dump the state for via the ‘dumpsys role’ command. After doing so, I found several “roles” that don’t match any of the default app categories that already exist: CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, and PROXY_CALLING_APP. After installing a few of Google’s first-party applications, I managed to get the “Car mode phone app” and “Call screening app” to show up in the “roles” pages, as shown below.

I decompiled the new system APK responsible for Android Q’s permission management interface, a new app called “PermissionController,” and found a roles.xml file that hints at what “roles” will do in the next Android version. I’m not going to paste the whole XML here, but I’ll share a snippet of one of the roles that should help you understand what roles will do.

PermissionController.apk/res/xml/roles.xml

Let’s say I select an app to have the “gallery” role. In order for an app to show up as a valid gallery app, it needs to have one required component: an activity that launches with the action and category intent filters android.intent.action.MAIN and android.intent.category.APP_GALLERY respectively. If that’s true and the app is given the “gallery” role by the user, then the app will automatically be granted permissions in the “media_visual” permission set, which I believe refers to the new audio, video, and images permission I described earlier. In fact, the new WRITE_MEDIA_VIDEO and WRITE_MEDIA_IMAGES permissions are explicitly allowed for an app with the “gallery” roll. Lastly, the app becomes the preferred handler when another app sends an intent to call a gallery app.
Basically, any app that’s granted a certain “role” and has the required components and permissions declared are automatically granted other permission sets relevant to their use cases. In the example I posted above, an app with the gallery “role” is automatically given permission to file access related permission sets that it needs to work. Presumably, this means an app that has been granted the gallery role by the user wouldn’t need to ask the user for permission to read or write image or video files.
Judging by the names, the CAR_MODE_DIALER_APP, CALL_COMPANION_APP, CALL_SCREENING_APP, and PROXY_CALLING_APP roles will let the user choose a different dialer app when they’re driving, an app to perform various functions while the user is in a phone call, an app to screen phone calls before the user picks up, and an app to facilitate calling with an intermediary number, respectively. We don’t believe the call screening role is directly related to the Google Pixel‘s Call Screen feature, judging by what we’ve seen in AOSP. Rather, it’s intended for apps that want to act as a bouncer for spam calls, like a call filter.

Revamped Package Installer

Android’s default package installer (the application that handles the installation of new apps) is getting a redesign. Rather than showing a fullscreen activity anytime you want to install a new app, the updated package installer in Android Q displays a small dialog in the middle of the screen. This mini package installer UI has been used for Android tablets for a long time, but this is the first we’re seeing it on Android smartphones.

In Android Q, running any app targeting API level 22 or below (Android 5.0 Lollipop) will show a warning that the app is outdated. That warning, I suspect, is enough to deter most users from bothering with apps targeting pre-Android Marshmallow versions. Couple that with the fact that Google will require any apps submitted to the Play Store after August 2019 to target API level 28, you can see how developers with outdated apps are forced to rework their apps to target a newer API level. How does all of that relate to the new package installer? Well, since Android 5.0 Lollipop is the last API level without mandatory runtime permission requests for certain sensitive permissions, the eventual death of apps targeting API level 22 and below means that Google no longer needs to make room in the package installer message to show a long list of permissions that an app is granted upon installation.

You probably won’t see this simplified package installer on all Android Q devices, though. Huawei, for example, customizes the package installer with a built-in virus and malware scanner (something I hate) as well as a built-in permission manager (something I love.) EMUI 10, therefore, will probably stick to the fullscreen package installer we’re all used to.

Sideloading an app in Android Q. The package installer doesn’t take up the entire screen anymore.

Sideloading an app in Android Pie. The package installer takes up the entire screen.

New Call Blocking Options

A feature we thought was coming in Android Pie actually made its way into Android Q, showing you just how close we actually are to the finalization of Android Q core features. The feature we found back then would let you block calls from unknown, private, pay phone numbers, or any numbers not in your contact list. Here’s a screenshot of the feature from the AOSP dialer app. The Google Phone app hasn’t been updated with this feature yet, but we assume it’ll get it sometime soon.

All Installed Apps Now Show Launcher Icons (Possible Bug?)

Most apps on your device have launcher icons because they’re meant to be gateways into their user interface. However, not every app has a UI, in which case a developer may choose to not declare an activity with the action and category intent filters android.intent.action.MAIN and android.intent.category.LAUNCHER respectively. I’m not sure if this is just a bug, but in Android Q, all apps, even those that try to hide their launcher icons in the manner described above, will show icons in the launcher. I tested this on the stock AOSP Launcher, Pixel Launcher, and Nova Launcher on a Google Pixel 3 XL running the leaked Android Q build, and compared it with a Google Pixel 2 XL running the latest Android 9 Pie build. When you tap on one of these icons, it simply brings you to that app’s information page in Settings.

Hyperion dock, an add-on for Hyperion Launcher, normally doesn’t show a launcher icon. It does in Android Q, though.

If this isn’t just a bug, then this would be a way for users to quickly tell if a new app has been installed, even if that app is trying to hide itself from the user.

“Sensors Off” Quick Setings tile

There’s a new Quick Settings tile called “sensors off” which not only turns on airplane mode but also disables all sensor readings on the device. I confirmed this by installing DevCheck from XDA Recognized Developer flar2 and comparing the output of the sensor readings with and without the “sensors off” toggle. When the “sensors off” tile is toggled on, the device stops reporting from all sensors on the device. I’m not sure if this Quick Setting tile is only for Google engineers to debug, but this would be a useful feature for anyone truly concerned about what data their device is collecting about their environment.

Download QR-Code

DevCheck Hardware and System Info

Developer: flar2

Price: Free⁺

---

More on Android Q

That’s everything privacy and permission-related that I’ve found so far in Android Q. Stay tuned for my final article covering all the smaller UI and UX tweaks. Follow our Android Q tag for more articles like this. Here’s a link to some of the articles that I referred back to more often, as well as a few others I think you should read:

• Exclusive: Early Android Q build has a System-wide Dark Theme, Permission Revamp, hints at a “Desktop Mode,” and more
• Exclusive: Google is working on a Face ID-like feature for Android Q
• Android Q May Block Background Clipboard Reads, Better Protect Your Media Files, Support Downgrading Apps, and more
• Android Q may ship with new Font, Icon Shape, and Accent Color Overlays
• “Dynamic Android” may let developers test an AOSP GSI on any Android Q device
• Android Q’s Dark Mode: How Google’s next Android OS will tackle blindingly light themes

SOURCE