Every new version of Android comes with new features, which means Android needs new permissions to gate access to these features. I found a lot of new permissions in Android Q’s framework (not all of which I’ll cover in this article because many of them aren’t interesting). Some of the permissions that I found didn’t have any descriptions, but their names are pretty self-explanatory anyway. Let’s dive in and discuss the new behind-the-scenes privacy enhancements in Android Q, as well as a few other interesting features that I found.
Special thanks to PNF Software for providing us a license to use JEB Decompiler. JEB Decompiler is a professional-grade reverse engineering tool for Android applications.
Blocking Background Clipboard Access
Did you know that every app in Android can read your clipboard, and you don’t have to grant them a runtime permission to do so? A lot of people probably copy sensitive information like usernames, passwords, addresses, etc. all the time, so it would be easy for any app to scrape this data in the background. That’s why a lot of password manager apps like KeePass have their own keyboards you can use to bypass the Android clipboard manager. Password manager apps often clear the clipboard for you after you copy and paste anything. The reason why Android apps need to read the clipboard is that they can’t accept any text from the clipboard without it, meaning you can’t paste any text that you’ve copied. Android Q is looking to change that, thankfully.
A new permission has been added called “READ_CLIPBOARD_IN_BACKGROUND” that sounds like it’ll do exactly what it says: limit what apps can read the clipboard in the background. The protection level of this permission is “signature,” meaning only apps signed by the OEM can be granted this permission.
<permission android:name="android.permission.READ_CLIPBOARD_IN_BACKGROUND" android:protectionLevel="signature"/>
Support for Downgrading Apps?
Have you ever installed an update for an app on Google Play and immediately regretted it? Sometimes a developer will push an update that breaks something they didn’t anticipate, but once the update has been pushed and installed it’s too late to do anything about it. The developer has to quickly issue a hotfix and the user either needs to stop using the app until an update is released or to uninstall the app and sideload an older version. There’s no way to downgrade an app unless you have a rooted device with an app like TitaniumBackup, because Android’s package manager blocks you from installing older versions of apps. There’s a good reason for doing so because installing an older version of an app could lead to breakage if the app’s data isn’t cleared, or it could expose the user to danger if the older version is vulnerable to a security flaw.
While we don’t know for sure if Google will allow users to rollback apps to an older version, we did find several permissions and commands in Android Q that suggest it’ll be possible. First, the new “PACKAGE_ROLLBACK_AGENT” and “MANAGE_ROLLBACKS” permissions suggest that the pre-installed market app can act as an agent to manage the rollback of application versions. The former permission is “signature” while the latter is “installer” on top of “signature,” so this means only a platform-signed app with the ability to install apps (typically only the package manager, Google Play Store, or other first-party app stores, depending on the device) can use these permissions. Two new protected broadcast intents have been added: “PACKAGE_ENABLE_ROLLBACK” and “PACKAGE_ROLLBACK EXECUTED.” These broadcasts cannot be sent by third-party apps, and are likely intended to allow the affected app to know when it has been downgraded (much like how apps are told when they’ve been updated, giving them a chance to display some message on the next start.) Lastly, a new flag has been added to the “pm install” shell command. The flag, called “--enable-rollback,” may let you rollback an application to an earlier version. I couldn’t get it to work, though.
<protected-broadcast android:name="android.intent.action.PACKAGE_ENABLE_ROLLBACK"/>
<protected-broadcast android:name="android.intent.action.PACKAGE_ROLLBACK_EXECUTED"/>
<permission android:name="android.permission.PACKAGE_ROLLBACK_AGENT" android:protectionLevel="signature"/>
<permission android:name="android.permission.MANAGE_ROLLBACKS" android:protectionLevel="installer|signature"/>
Securing Files on External Storage
Data storage in Android involves the “internal storage” (/data excluding /data/media) and “external storage” (/data/media and any mounted SD cards or USB drives). APKs and their most sensitive data are stored in internal storage, while any shared media like documents, images, videos, etc. are stored in external storage. By default, apps can only read and write files to a single directory in external storage: /data/media/[user]/Android/data/[package_name]. (To learn more about this behavior, I recommend you read my article on sdcardfs in Android Oreo.) Once the user grants an app any permission under the external storage permission group (READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE), the app can then read or write any file in external storage. This is problematic because you’re granting an app the ability to potentially harvest a lot of data about you when you just wanted to let it read or write certain files. To fix this, Google seems to be introducing a couple of new external storage-related permissions in Android Q. The permissions will gate the following features:
- Ability to read the locations from your media. (Likely blocking access to the metadata of images by default.)
- Ability to access music files.
- Ability to access photos.
- Ability to access videos.
For apps that already hold the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permissions before the Android Q update, they’ll get the new read permissions but not the new write permissions. For example, an app that has already been granted READ_EXTERNAL_STORAGE by the user will be automatically granted the READ_MEDIA_IMAGES permission but not the WRITE_MEDIA_IMAGES permission.
Relevant strings from Android Q's framework-res
<string name="permgroupdesc_aural">access your music</string>
<string name="permgrouplab_visual">Photos & Videos</string>
<string name="permgrouprequest_aural">Allow <b>%1$s</b> to access your music?</string>
<string name="permgroupdesc_visual">access your photos & videos</string>
<string name="permgrouplab_activityRecognition">Activity recognition</string>
<string name="permgrouplab_aural">Music</string>
<string name="permdesc_videoRead">Allows the app to read your video collection.</string>
<string name="permdesc_videoWrite">Allows the app to modify your video collection.</string>
<string name="permdesc_imagesRead">Allows the app to read your photo collection.</string>
<string name="permdesc_imagesWrite">Allows the app to modify your photo collection.</string>
<string name="permdesc_audioRead">Allows the app to read your music collection.</string>
<string name="permdesc_audioWrite">Allows the app to modify your music collection.</string>
<string name="permlab_audioRead">read your music collection</string>
<string name="permlab_audioWrite">modify your music collection</string>
<string name="permdesc_mediaLocation">Allows the app to read locations from your media collection.</string>
<!-- Apps holding either the legacy READ or WRITE permissions will inherit
the ability to <em>read</em> new typed permissions in the Q release; they
won't gain the ability to <em>write</em> that content. -->
<!-- STOPSHIP(b/112545973): change targetSdk to Q when SDK version finalised -->
<split-permission name="android.permission.READ_EXTERNAL_STORAGE"
targetSdk="10000">
<new-permission name="android.permission.READ_MEDIA_AUDIO" />
<new-permission name="android.permission.READ_MEDIA_VIDEO" />
<new-permission name="android.permission.READ_MEDIA_IMAGES" />
</split-permission>
<!-- STOPSHIP(b/112545973): change targetSdk to Q when SDK version finalised -->
<split-permission name="android.permission.WRITE_EXTERNAL_STORAGE"
targetSdk="10000">
<new-permission name="android.permission.READ_MEDIA_AUDIO" />
<new-permission name="android.permission.READ_MEDIA_VIDEO" />
<new-permission name="android.permission.READ_MEDIA_IMAGES" />
</split-permission>
The Return of Background Location Access
Android Oreo and Android 9 Pie took big steps forward in securing user privacy, but some users felt Google took things too far. One such area that may be considered a feature regression is in background location access. Location access in Android Oreo and later is heavily throttled if not outright killed for apps running in the background, so apps need to either be in the foreground or have a foreground service running if they want to continuously poll the device’s location. That blocks apps from spying on your location in the background, but it also blocks the user from mapping their own location using an app in the background. This is a problem we touched upon in a separate article, and it looks like Google is adding a new permission in Android Q to address the concerns of these developers and users.
In Android Q, a new permission has been added to allow an app to have background access to the device’s location. The permission’s description to the user warns that the “app will always have access to the location, even when you’re not using the app.” This permission may be granted “additionally to the approximate or precise location” permissions so the app “can access the location while running in the background.” In contrast, the coarse location permission can only get your location based on network sources like cell towers or Wi-Fi networks, but only when the app is in the foreground.
Relevant strings from Android Q's framework-res
<string name="permgroupbackgroundrequest_location">Always allow <b>%1$s</b> to access this device’s location?</string>
<string name="permgroupbackgroundrequestdetail_location">The app will always have access to the location, even when you’re not using the app.</string>
<string name="permdesc_accessBackgroundLocation">If this is granted additionally to the approximate or precise location access the app can access the location while running in the background.</string>
<string name="permdesc_accessCoarseLocation">This app can get your location based on network sources such as cell towers and Wi-Fi networks, but only when the app is in the foreground. These location services must be turned on and available on your phone for the app to be able to use them.</string>
<split-permission name="android.permission.ACCESS_FINE_LOCATION"
targetSdk="10000">
<new-permission name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</split-permission>
<!-- STOPSHIP(b/118882117): change targetSdk to Q when SDK version finalised -->
<split-permission name="android.permission.ACCESS_COARSE_LOCATION"
targetSdk="10000">
<new-permission name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</split-permission>
Physical Activity Recognition
A new permission has been added to Android Q that allows an app to “recognize your physical activity.” This technically isn’t new since it’s already part of Google Play Services, but it could mean that Google will decouple the permission from Play Services. With how integral Google Play Services has been in providing core Android features, it’s good to see some of its power given back to AOSP.
<string name="permgroupdesc_activityRecognition">recognize activity</string>
<string name="permgrouprequest_activityRecognition">Allow <b>%1$s</b> to recognize your physical activity?</string>
<string name="permdesc_activityRecognition">This app can recognize your physical activity.</string>
For more Android Q news, check out our tag with the latest news sorted by date. We recently published an article with a lot of evidence pointing towards Google working on supporting Face ID-like facial authentication hardware in Android Q. We also have an early hands-on of the leaked Android Q build (and there’s even a video) which you should check out here. We’ll be posting more of our findings from this early Android Q build we obtained, so stay tuned.
0 comments:
Post a Comment