I’ve been a loyal Android + Windows user for over a decade, but if there’s one thing that I really envy about iOS + macOS users, it’s the software integration they enjoy. The Android + Windows experience has gotten a lot better over the years thanks to Microsoft’s continued development and support for its Link to Windows/Phone Link app. Microsoft even partnered with Samsung early on to offer Galaxy users additional cross-device features, a move that led Google to counter with its own cross-device software experience for linking an Android phone to a Chromebook. Other PC brands like Dell, ASUS, and Realme have their own Android-to-PC cross-device apps, while Linux users have access to the open source KDE Connect.

These cross-device apps have a lot of features in common, such as making and receiving phone calls from your PC, syncing notifications, responding to text messages, sharing files and photos, and more. Because of the large number of features they offer, the Android client behind them needs to request a lot of different permissions. Take Microsoft’s Link to Windows app as an example. While setting it up, I had to grant it four different permissions back-to-back, followed by accepting a prompt to let the app ignore battery optimization, before it would let me start using it. But that’s just to get the basic features up and running; if I wanted to sync my notifications or call log, I’d have to grant it more permissions.

Having to tap through half a dozen permission dialogs just to use an app does not make for a great experience, which is why the Link to Windows app holds off on requesting certain permissions during setup. Still, it’d be nice if Android could lump many of these permission requests together into a single dialog, especially because, as I said before, cross-device apps have a lot of features in common (and thus need a lot of the same permissions). Android actually has a mechanism to do just that, and in Android 13, we’re seeing the beginnings of Google’s attempt to simplify linking your Android phone to your PC.

All the runtime permissions requested by Microsoft’s Link to Windows app.

The role of roles

In Android 10, Google introduced roles to the platform. An app holding a role will be granted access to all the permissions associated with that role. For example, an app holding the DIALER role will automatically be granted access to a plethora of permissions a typical dialer app needs to do its job. Not every app can hold the DIALER role, though, as there are a few qualifications that need to be met. This is true for most roles, though the qualifications to hold each role are different.

All of the “default apps” you can choose in settings are holders of their respective roles, but Android actually has a lot more roles than are shown in settings or documented in the SDK. Most of these roles are invisible to the user since they can only be held by a system app that is usually predefined by the OEM (such as the SYSTEM_UI role). These roles grant access to a ton of privileged APIs, so it makes sense that they can only be held by system apps.

Companion Device Profiles

There’s one role that can be held by a regular app but is still hidden from settings, and that’s the COMPANION_DEVICE_WATCH role. Introduced in Android 12, this role lets the holder app have access to many permissions that are needed to sync phone status and data to a wearable accessory. What’s unique about this role is the way it’s granted: through a new API called AssociationRequest. An app that holds the permission REQUEST_COMPANION_PROFILE_WATCH can request to be associated with a companion device of the “WATCH” profile. The Companion Device Manager system app will then grant that app access to the COMPANION_DEVICE_WATCH role, and all of the permissions that go along with it, for as long as the device is associated with the wearable. All users will see is a single permissions dialog that asks them to allow the app to manage the wearable, reducing the number of permission requests down to one. If the user removes the association between the device and the wearable (eg. by factory resetting the wearable), then the role and all its connected permissions are revoked from the app.

A permissions dialog that uses a companion device profile to request multiple permissions in a single request. Source: Google.

Computer and App Streaming Profiles

Android 13 expands the roles that can be managed by Companion Device Manager to include the new COMPANION_DEVICE_COMPUTER and COMPANION_DEVICE_APP_STREAMING roles. The COMPANION_DEVICE_COMPUTER role grants its holder notifications access as well as many storage-related permissions needed to access recent photos and media stored on the device. Apps that hold the COMPANION_DEVICE_APP_STREAMING role can create a virtual display capable of rendering Android applications and handle sending input events back and forth between the main and virtual displays. Thus, a cross-device app holding both of these roles would have enough permissions to be able to sync notifications, share photos and videos, and stream apps from an Android phone to a connected PC. Said app would only need to show the user two permissions dialogs (one for each role) rather than multiple dialogs and a trip to Android’s settings for the notification listener permission.

COMPANION_COMPUTER_DEVICE role
The role definition for COMPANION_COMPUTER_DEVICE
COMPANION_DEVICE_APP_STREAMING role
The role definition for COMPANION_DEVICE_APP_STREAMING

There are a few problems with these roles as they’re currently designed, however. First, the COMPANION_DEVICE_COMPUTER role doesn’t go far enough. Most cross-device apps ask for a lot more permissions than just notifications and storage access. This isn’t a huge problem, though, because Google can easily update the list of permissions granted by this role, and it won’t even require an OS update. This is possible because the Role API and all of the role definitions found in roles.xml are contained within the PermissionController Mainline module, which is distributed to Android devices through Google Play System Updates.

(As an aside, the COMPANION_DEVICE_COMPUTER role as it’s currently defined doesn’t even get the permission to sync notifications, as it only grants the new Android 13 permission to post notifications. I think this is evidence the role definition will be updated, however, because the strings in the PermissionController APK, as well as documentation on the Android Developers site, suggest that this role is intended to let apps sync notifications. Plus, it just makes sense.)

The bigger problem with these roles is that they can only be held by system apps. The descriptions for the REQUEST_COMPANION_PROFILE_COMPUTER and REQUEST_COMPANION_PROFILE_APP_STREAMING permissions state that they are “not for use by third-party applications.” Indeed, the protection level for both permissions is defined in Android 13’s framework as system|signature, meaning that they can only be granted to system apps or apps signed with the same certificate that signed the framework.

The logcat message when I try to grant a non-system app installed on my Pixel 6 Pro the new COMPANION_DEVICE_COMPUTER role.

In other words, only preinstalled OEM apps or trusted partner apps can make use of these roles. If I download Microsoft’s Link to Windows app on a Pixel running Android 13, it won’t be able to hold those roles, but Google’s preinstalled “Cross-Device Communication Service” app can. That app, by the way, does have code to request the COMPANION_DEVICE_APP_STREAMING role, because it needs the virtual display permissions to access the APIs needed for the new app streaming feature coming to Phone Hub.

Apart from a few references in the Android SDK, there isn’t much information out there about these new roles (probably because, as I just pointed out, Google plans to use them for a new Pixel feature that they want to stay tight-lipped about). I’m curious to see if Samsung and Microsoft will make use of these roles. Samsung already preinstalls Microsoft’s app as a privileged system app, so it could make use of them. From what I’ve seen of Microsoft’s app streaming feature, though, it doesn’t look like it makes use of the virtual display APIs that Google plans to use for its new app streaming feature. That’s a shame, because Google’s doing a lot of work behind the scenes to improve Android’s virtual display capabilities. For instance, Android 13 has a new virtual audio device API that, from what I’ve seen, enables capturing audio and injecting microphone data into apps running on virtual displays. Microsoft’s app streaming feature doesn’t support audio, but Google’s presumably will.

Since Google’s and Microsoft’s apps are closed source and proprietary, there’s not much more I can say about them, but I hope this discussion on permissions, roles, and companion device profiles has been informative. If you’re interested in learning more about these topics, check out Google’s documents on roles and permissions for system developers. For a more user-friendly overview, I also produced an Android Bytes podcast episode that goes over Android’s permission model. There are other new permissions and roles I haven’t talked about in this article, including many that are new to Android 13, but I’ll be documenting them (and a whole lot of other things) in my deep dive article.


Thanks for reading this week’s edition of Android Dessert Bites. If you liked this post, then please subscribe to The Android Edge newsletter to get links to future editions of my Android Dessert Bites column. You can find previous editions on this page.