Android roles

A role is a unique name within the system associated with certain permissions and privileges. Apps can request to hold certain roles through the Android API, specifically by invoking methods in the RoleManager class.

See the following list for available roles and their corresponding requirements:

Role Requirements
ASSISTANT At least one of:
  • The app has an activity that performs assist actions, given the information about the user's context when they requested the assist (for example, the package name for the current foreground app and its contextual information).
  • The app has an always-on voice interaction service gated by the android.permission.BIND_VOICE_INTERACTION permission, which can perform voice recognition and host active voice interaction sessions. Additionally, the app has an explicit flag indicating that the service is capable of handling the assist action.
BROWSER All of:
  • The app has an activity that apps can invoke through implicit intent requests, which displays a web page corresponding to an http:// address.
  • The app needs to handle navigation between links. That is, if the user is viewing a web page and clicks an http:// address in the text, the app needs to be able to display the content corresponding to the selected link without additional user intervention.
  • The app needs to be able to provide the device's current geolocation information to web pages when it's requested and the user approves the request.
DIALER All of:
  • The app has an activity that apps can invoke through implicit intent requests, which provides the in-call user interface while the device is in a call.
  • The app can handle incoming call intents, display the information related to the call (for example, the caller's phone number) to the user, and let the user answer or decline the call.
  • The app provides the user with a means to initiate calls and see a history of calls on their device.
SMS All of:
  • The app satisfies all the requirements for SMS apps.
  • The app has an activity that apps can invoke through implicit intent requests, which can send a message to a phone number.
  • The app has a service gated by the android.permission.SEND_RESPOND_VIA_MESSAGE permission and invokable by implicit intents, which can deliver messages received from the Phone app when the user opts to respond-via-message during an incoming call. The app can deliver messages through its own messaging system.
  • The app has two broadcast receivers, one gated by the android.permission.BROADCAST_SMS permission and one gated by the android.permission.BROADCAST_WAP_PUSH permission, which can listen for text-based SMS and MMS messages sent to the device, respectively. The app is then responsible for writing the messages to the SMS provider and notifying the users.
EMERGENCY All of:
  • The app is a system app .
  • The app has an activity that presents the user's emergency information. Anyone can navigate to this screen through the Emergency button on the Emergency Dialer activity.
HOME The app has an activity that can launch the home screen when the user presses the home button. The home screen should show app icons, widgets, and support navigation based on buttons or gestures (for example, swiping up to see all the apps).
CALL_REDIRECTION The app has a service gated by the android.permission.BIND_CALL_REDIRECTION_SERVICE permission, which the telecom framework can bind to. The service receives the outgoing phone number from the telecom framework and performs one of the following actions:
  • Allow the call to be placed as is.
  • Change the outgoing number to route through a proxy number.
  • Cancel the call.
CALL_SCREENING The app has a service gated by the android.permission.BIND_SCREENING_SERVICE permission, which performs two functions:
  • Call blocking and screening: The service can choose which calls should be sent to the dialer app on the phone (and potentially ring, given DND or volume), and which should be silently sent to voicemail.
  • Call identification: The service can identify and display information about a call through a user interface.
SYSTEM_GALLERY All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app provides a UI for users to store, organize and display their videos and images.
SYSTEM_AUTOMOTIVE_CLUSTER All of:
  • The app is a system app on Automotive.
  • Only OEMs can grant this role to the app.
  • The app provides capability for an automotive cluster display (typically adjacent to the steering wheel) for users to answer phone calls and access contact lists and call logs.
COMPANION_DEVICE_WATCH The app can make requests to be associated with and to manage a watch device (by using the API provided by the CompanionDeviceManager class). When the watch and the app are connected through the UI provided by the app, users can manage their watch from the app, including syncing contacts and calendar, and managing notifications and phone calls.
SYSTEM_AUTOMOTIVE_PROJECTION All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app enables the phone screen to be projected on the in-vehicle display. It lets drivers access and control apps on Android phones, including music, navigation, phone calls, and search, using input mechanisms on the vehicle, including touch, steering wheel controls, and voice commands.
SYSTEM_SHELL All of:
  • The app is a system app that is assigned the Process.SHELL_UID UID.
  • Only OEMs can grant this role to the app.
  • The app provides an interface that works at the command-line level so users can interact with the Android OS. For example, displaying the contents of a folder or launching apps. Shell commands can be executed programmatically by apps (given necessary permissions have been granted), or from the ADB tool.
SYSTEM_CONTACTS All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app provides a UI for users to manage their contacts (for example, view, share, add, remove, or search for a contact). The app updates the Contacts provider when the user updates their contacts from the app. Users can also call, email or send text messages to their contacts from the app.
SYSTEM_SPEECH_RECOGNIZER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app provides a service that can perform speech recognition.
  • When the app receives live microphone streams from another app for speech recognition, it correctly attributes the microphone usage to the calling app and updates the app operation statistics accordingly.
SYSTEM_WIFI_COEX_MANAGER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app has a service that dynamically sets a list of Wi-Fi channels that the device should avoid using due to cellular interference.
SYSTEM_WELLBEING All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app should provide the capability for users to reduce distraction and to give users statistics about how they use their device (for example, their screen time per week).
SYSTEM_TELEVISION_NOTIFICATION_HANDLER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app must show heads-up notifications to users on TV devices. The app must also show current active notifications when the android.app.action.TOGGLE_NOTIFICATION_HANDLER_PANEL intent is sent (from SystemUI).
SYSTEM_COMPANION_DEVICE_PROVIDER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app must be able to detect peripheral devices in its vicinity. It must have a UI where the user can confirm that a given peripheral device should be associated with and managed by an app. When the user confirms, the managing app grants the associated app permission to access the peripheral device (for example, its name, address, class, and bonding state) and it can start the bonding process.
SYSTEM_DOCUMENT_MANAGER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app has an activity that lets users access existing documents and to create new documents on the device.
  • The app must fulfill all requirements outlined in the Android CDD section 2.2.3. Software under the heading [3.2.3.1/H-0-1].
SYSTEM_ACTIVITY_RECOGNIZER All of:
SYSTEM_UI All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app has an interface for users to interact with their phones. For example, the phone's main screen, navigation, recent apps, quick settings, notification bar, lockscreen, volume control.
SYSTEM_TELEVISION_REMOTE_SERVICE All of:
  • The app is a system app on Android TV.
  • Only OEMs can grant this role to the app.
  • The app has a service that can communicate with the TV remote control HID device (for example, over BLE), inject events (for example, button clicks), and send other data (for example, audio stream from a microphone built into the remote) into the platform.
SYSTEM_UI_INTELLIGENCE All of:
  • Being a preinstalled service that provides, through framework APIs (public or system APIs), an on-device intelligent processor for system UI features (for example, predicting and showing next apps for the users).
  • The service must fulfill all requirements outlined in the Android CDD section 9.8.6 Content Capture.
  • The service can't have the android.permission.INTERNET permission. Instead, it must access the Internet through well-defined APIs in an open source project.
  • The service can't bind to apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. Each allowed binding must be set up explicitly through the <allow-association> configuration in the system config.
  • The service can't share data with apps unless there is a direct user action (for example, the user explicitly presses a button every time the data is shared).
SYSTEM_AMBIENT_AUDIO_INTELLIGENCE All of:
  • Identical to conditions for SYSTEM_UI_INTELLIGENCE, except that the preinstalled service provides an on-device intelligent processor for ambient audio (for example, recognizing songs playing near the device).
SYSTEM_AUDIO_INTELLIGENCE All of:
  • Identical to conditions for SYSTEM_UI_INTELLIGENCE, except that the preinstalled service provides an on-device intelligent processor for audio (for example, captioning videos, podcasts, phone calls, video calls, and audio messages).
SYSTEM_NOTIFICATION_INTELLIGENCE All of:
  • Identical to conditions for SYSTEM_UI_INTELLIGENCE, except that the preinstalled service provides an on-device intelligent processor for notifications (for example, suggesting replies and actions for message notifications).
SYSTEM_TEXT_INTELLIGENCE All of:
  • Identical to conditions for SYSTEM_UI_INTELLIGENCE, except that the preinstalled service provides an on-device intelligent processor for text (for example, providing live translation or autofill).
SYSTEM_VISUAL_INTELLIGENCE All of:
  • Identical to conditions for SYSTEM_UI_INTELLIGENCE, except that the preinstalled service provides an on-device intelligent processor for visual features that involves analyzing camera data. For example, keeping the phone's screen alive while the user is looking at it or determining the ideal screen orientation based on the user's face orientation from the front-facing camera on the device.
COMPANION_DEVICE_APP_STREAMING All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • Allowed use cases:
    • Streaming, casting, or mirroring of apps, which allow streaming, casting, or mirroring, from an Android-powered device such as mobile phone or tablet to desktop or laptop computer.
  • When establishing the initial connection from device A to device B:
    • Pairing MUST be authorized by a one-time code displayed on the source device (A) and entered on the connected device (B). Alternatively, if both devices have at least one matching account in their Android AccountManager, the user MAY confirm the pairing by entering the account password on the connected device (B).
    • Both devices need to be in proximity 1 to each other during pairing.
  • Both devices need to be in proximity 1 to each other while streaming.
  • The app can create and manage communication channels with connected devices so that the devices can exchange data. The app and the connected devices MUST successfully authenticate each other (for example, by proving their knowledge of shared keys) to establish these communication channels. The communication channels MUST have end-to-end encryption protection.
  • The app can send notifications from the source device (A) to the connected device (B) to let the user take action on the notifications on the connected device (B).
  • Be able to stream the metadata necessary for app streaming to the connected device (B), such as the list of apps available on the source device (A).
  • Be able to stream apps from the source device (A) to the connected device (B) after the user has indicated their preference to do so with explicit consent (either on the source device (A) or on the connected device (B)).
  • Be able to replay (inject) events that happen on a streamed app on the connected device (B) back on the source device (A). For example, replaying a touch event on the connected device (B) at the same coordinates as on the source device (A), or replaying an input event that occurred on the connected device (B) with the same input semantics as on the source device (A).
  • The app can replace the source device's microphone stream with a connected device's microphone stream while a streamed app is using the microphone.
  • The app captures audio from the source device (A) and streams it to the connected device (B).
  • It is RECOMMENDED to block access to settings apps and app stores from the connected device (B).
  • Starting Android 16, screenshotting and screen reading of sensitive content, such as secure windows and surfaces, MUST be prevented on the connected device (B).
  • MUST verify the integrity of the connected device's OS build (for example, by using device attestation as in VerifiedBootState).
  • Only stream apps where there is only one matching account in the on-device account registry, (for example, the AccountManager class on Android) on both devices. If this isn't the case, streaming MUST be authorized with a one-time code shown on the source device (A) and entered on the connected device (B). Note that in case of devices that support multi-users (and not multi-accounts) with the same reliable data isolation like in Android multi-user, a user counts as a device.
  • MUST stop streaming and disconnect from the connected device (B) immediately if the authentication of the account on the connected device (B) expires or is revoked.
  • MUST stop streaming and disconnect from the connected device (B) upon idle timeout of the connected device (B) on which the display content is visible. MAY keep the connected device's screen on for cases such as WakeLock, that keep the Android device's screen on. An idle timeout MUST be present. If the connected device (B) does not have an idle timeout by itself, an idle timeout of a maximum of 5 minutes MUST be used.
  • If the source device (A) uses Lockscreen Knowledge Factor (LSKF), when the screen is locked, the app MUST not stream apps to a connected device (B) unless the connected device (B) has a lock screen and is unlocked.
  • If the source device (A) is managed by an admin, the app MUST respect policies set by the admin about enabling or disabling streaming to nearby devices (for example, using DevicePolicyManager settings in Android).
  • MUST ensure that the remote displays and all sources of remote input events belong to the same logical device (for example, a remote display and a connected keyboard) from the user perspective and events are routed accordingly.
  • The user MUST be able to end streaming from the source device (A), for example, by using a button in a persistent notification. This behavior is gated by the lockscreen, if the source device (A) has a screen lock set. MUST show this persistent affordance on the source device (A) that is always visible and above the fold.
  • MUST show an affordance on the source device (A) when the streaming is happening on another device, like an icon in the status bar or a persistent notification.
DEVICE_POLICY_MANAGEMENT All of:
  • Only OEMs can grant this role to the app. Apps can't request this role as it's meant to be granted out of box to the package name defined by the OEM when the device is shipped.
  • The app must be able to provision a managed profile (profile owner) or a managed device (device owner), including downloading and installing the appropriate Device Policy Client to be the device/profile owner if required.
  • The app can optionally, dynamically update resources such as strings, drawables used for device policy management.
  • The app can either be a preinstalled system app or be downloaded and installed, prior to provisioning.
  • For profile owner provisioning cases, when the role holder app is installed on a given Android user, it must be installed on all applicable profiles for that user.
SYSTEM_APP_PROTECTION_SERVICE All of:
  • The app is a system app .
  • The only purpose of the app is to detect potentially harmful apps (apps that could put users, user data, or devices at risk such as trojans, phishing, and spyware apps) or Mobile Unwanted Software.
  • The app must fulfill all requirements outlined in the Android CDD section 9.8.6. OS-level and ambient data.
  • The app must not declare the android.permission.INTERNET normal permission. Instead it must access the Internet through well-defined APIs in an open source project.
  • The app must not bind to apps, except for the following system apps: Permission Controller, and components providing Telephony and Internet APIs. Each allowed binding must be set up explicitly through the <allow-association> configuration in the system config.
  • The app must not share data with apps unless there is a direct user action (for example, the user explicitly presses a button every time the data is shared).
SYSTEM_AUTOMOTIVE_CALENDAR_SYNC_MANAGER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • The app must transfer calendar data from the user's iOS or Android phone to the Android Auto device. The Android Auto device must store this calendar data in the calendar provider.
  • The app must provide a UI component on the phone the user can use to turn on calendar sync and select the calendars to sync. The app must provide a UI component on the phone the user can use to turn off calendar sync.
  • The app should operate without an internet connection. For example, by using direct wired or wireless connections.
AUTOMOTIVE_NAVIGATION All of:
  • The app has an activity that apps can invoke through implicit intent requests, which shows the user's current location and surroundings.
  • The app has an activity that apps can invoke through implicit intent requests, which lets the user navigate to a specified geo-location.
  • The app has an activity that is launched on the instrument cluster when the app holds navigation focus. The activity must show the user's current location, surroundings, and let them navigate to a specified geo-location.
COMPANION_DEVICE_COMPUTER All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • Enable users to mirror notifications and access photos and media from the phone on a connected computer.
SYSTEM_SETTINGS_INTELLIGENCE At least one of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • Has a service that provides intelligence features for the Settings app, such as suggestions and search.
NOTES All of:
COMPANION_DEVICE_GLASSES The app can make requests to be associated with and to manage a glasses device (by using the API provided by the CompanionDeviceManager class). When the glasses device and the app are connected using the UI provided by CDM, users can manage their glasses device by giving it access to contacts, and permission to manage notifications and phone calls.
COMPANION_DEVICE_NEARBY_DEVICE_STREAMING All of:
  • The app is a system app .
  • Only OEMs can grant this role to the app.
  • Allowed use cases:
    • App streaming from an Android-powered device such as mobile phone or tablet to a vehicle.
    • App streaming from an Android-powered device such as mobile phone or tablet to an XR device.
  • When establishing the initial connection from device A to device B:
    • Pairing MUST be authorized by a one-time code displayed on the source device (A) and entered on the connected device (B). Alternatively, if both devices have at least one matching account in their Android AccountManager, the user MAY confirm the pairing by entering the account password on the connected device (B).
    • Both devices need to be in proximity 1 to each other during pairing.
  • Both devices need to be in proximity 1 to each other while streaming.
  • The app can create and manage communication channels with connected devices so that the devices can exchange data. The app and the connected devices MUST successfully authenticate each other (for example, by proving their knowledge of shared keys) to establish these communication channels. The communication channels MUST have end-to-end encryption protection.
  • The app can send notifications from the source device (A) to the connected device (B) to let the user take action on the notifications on the connected device (B).
  • Be able to stream the metadata necessary for app streaming to the connected device (B), such as the list of apps available on the source device (A).
  • Be able to stream apps from the source device (A) to the connected device (B) after the user has indicated their preference to do so with explicit consent (either on the source device (A) or on the connected device (B)).
  • Be able to replay (inject) events that happen on a streamed app on the connected device (B) back on the source device (A). For example, replaying a touch event on the connected device (B) at the same coordinates as on the source device (A), or replaying an input event that occurred on the connected device (B) with the same input semantics as on the source device (A).
  • The app can replace the source device's microphone stream with a connected device's microphone stream while a streamed app is using the microphone.
  • The app captures audio from the source device (A) and streams it to the connected device (B).
  • It is RECOMMENDED to block access to settings apps and app stores from the connected device (B).
  • Starting Android 25Q2 Screenshotting and screen reading of sensitive content, such as secure windows and surfaces, MUST be prevented on the connected device (B).
  • MUST verify the integrity of the connected device's OS build (for example, by using device attestation as in VerifiedBootState).
  • Only stream apps where there is only one matching account in the on-device account registry, (for example, the AccountManager class on Android) on both devices. If this isn't the case, streaming MUST be authorized with a one-time code shown on the source device (A) and entered on the connected device (B). Note that in case of devices that support multi-users (and not multi-accounts) with the same reliable data isolation like in Android multi-user, a user counts as a device.
  • MUST stop streaming and disconnect from the connected device (B) immediately if the authentication of the account on the connected device (B) expires or is revoked.
  • MUST stop streaming and disconnect from the connected device (B) upon idle timeout of the connected device (B) on which the display content is visible. MAY keep the connected device's screen on for cases such as WakeLock, that keep the Android device's screen on. An idle timeout MUST be present. If the connected device (B) does not have an idle timeout by itself, an idle timeout of a maximum of 5 minutes MUST be used.
  • If the source device (A) uses Lockscreen Knowledge Factor (LSKF), when the screen is locked, the app MUST not stream apps to a connected device (B) unless the connected device (B) has a lock screen and is unlocked.
  • If the source device (A) is managed by an admin, the app MUST respect policies set by the admin about enabling or disabling streaming to nearby devices (for example, using DevicePolicyManager settings in Android).
  • MUST ensure that the remote displays and all sources of remote input events belong to the same logical device (for example, a remote display and a connected keyboard) from the user perspective and events are routed accordingly.
  • The user MUST be able to end streaming from the source device (A), for example, by using a button in a persistent notification. This behavior is gated by the lockscreen, if the source device (A) has a screen lock set. MUST show this persistent affordance on the source device (A) that is always visible and above the fold.
  • MUST show an affordance on the source device (A) when the streaming is happening on another device, like an icon in the status bar or a persistent notification.
WALLET One of:
  • The app has an NFC APDU service that statically registers at least one AID in the PAYMENT category.
  • The app implements an instance of QuickAccessWalletService.

1 Proximity is defined by the two devices being within Bluetooth or Wi-Fi range of each other, or using the same local network.