Mystifying Things

A couple of items were introduced in Android 10 but were removed from being public-facing for the final release. It is possible that these will become more important in future versions of Android.

Roles

Q Beta 1 introduced roles and RoleManager.

Q Beta 2 removed the documentation and, um, primary role for RoleManager.

Q Beta 3 through the Android 10 release still have RoleManager, but there is no sign of whether it is being used.

Here is what we know about what roles were to be used for, in case they show up again.

What Is a Role?

A role is a bit like a runtime permission:

• You need to have stuff in the manifest to be eligible for it
• You need to have code to detect if you have the role — and if not, to ask the user to grant you the role
• The user can grant or revoke roles at any point (e.g., via the Settings app)
• The role helps determine what your app can do

However, a permission is a statement of a desired capability, such as “I want to be able to read files on external storage”. A role, rather, is a statement of what job the app will fulfill for the user.

According to the RoleManager JavaDocs, there are eight available roles:

• ROLE_ASSISTANT
• ROLE_BROWSER
• ROLE_CALL_REDIRECTION
• ROLE_CALL_SCREENING
• ROLE_DIALER
• ROLE_EMERGENCY
• ROLE_HOME
• ROLE_SMS

In general, the names of the roles indicate their purpose. For example, ROLE_BROWSER represents a Web browser, while ROLE_SMS represents a messaging client.

If your app requests and is granted a role, you get certain capabilities. For example, an app with ROLE_GALLERY has access to more of the device content than does an ordinary app, as part of the new scoped storage system.

There Can Only Be One

One substantial difference between permissions and roles is that any number of apps can hold a permission, while only one app can hold a role. If an app requests a role and some other app holds that role, if that second app asks the user for the role and is granted it, the first app loses the role.

For some roles, other system limitations already imply that only one app could fill a role. For example, an Android device cannot readily handle more than one home screen. In other cases, the “there can only be one” rule for roles may introduce some user headaches, such as when switching between Web browsers.

Becoming Role-Eligible

As noted above, to become eligible for a role, there are a few things that you will need in your manifest.

The direct determining factor of whether you are eligible for a role comes from an <intent-filter>.

On your MAIN/LAUNCHER activity, you need to add two more <category> elements:

• <category android:name="android.intent.category.DEFAULT" />, to declare your wish to be the default app for the role
• A second <category> element tied to the specific role

Unfortunately, for the current set of roles, the categories are undocumented.

Obtaining a Role

Just because you request a permission in the manifest does not mean that your app holds it — on Android 6.0+, you need to request dangerous permissions at runtime, using functions like ActivityCompat.requestPermissions().

Similarly, just because you have the right stuff in the manifest to be eligible for a role does not mean that your app holds that role. Instead, you need to ask the user for that role, using a RoleManager system service added to Android 10.

There are three key functions on RoleManager:

• isRoleAvailable() indicates if the version of Android and the device that you are on knows about a particular role that you want, identified by a ROLE_-prefixed name defined as constants on RoleManager. Google reserves the right to change the mix of roles over time, and it is conceivable that device manufacturers might make their own changes. So, you need to call isRoleAvailable() and be able to cope if it returns false.
• isRoleHeld() returns true if your app has been granted the role, false otherwise. This is reminiscent of calling checkSelfPermission() to see if you hold a runtime permission.
• createRequestRoleIntent() does pretty much what the name indicates: it creates an Intent for you to be able to ask the user to be able to hold a role. You pass that Intent to startActivityForResult(), and in onActivityResult() you can find out if you got the role (by looking for an ACTIVITY_OK response or calling isRoleHeld() again)

Losing a Role

The user is welcome to go into the Settings app and revoke your role.

Similar to losing a runtime permission, if you lose a role, Android will terminate your process. Hence, just as you should check to see if you hold a runtime permission on every start of your app, you should check to see if you hold any desired roles on every start of your app.

However, due to another bug, RoleManager will incorrectly return true from isRoleHeld() after a user revokes the role. As a result, there is no great way to determine whether you really hold the role or you held it previously and now no longer hold it.

Role Powers

Due to the very limited role documentation, it is unclear how to obtain roles and what apps holding those roles can do (and what apps without those roles) cannot do.

Bubbles

In 2013, Facebook debuted the “chat heads” UI for their Android app. These allowed the user to participate in Facebook chats while being (mostly) in other apps, by having a floating avatar of your chat partner appear over the UI of whatever app you were in.

Technically, this was somewhat of an abuse of the SYSTEM_ALERT_WINDOW permission and related system-level windows. Facebook’s “leadership” in this area led many other developers to apply the same technique. However, allowing arbitrary apps to interpose arbitrary UI in front of other UI has security risks, and Google is slowly starting to restrict the use of SYSTEM_ALERT_WINDOW as a result.

In Q Beta 1, Google announced that they were introducing “bubbles” and indicated that this would be a long-term replacement for SYSTEM_ALERT_WINDOW. In Q Beta 3, Google announced that bubbles would be limited to developers, with an opt-in toggle in the developer options to allow them to be seen. That remains the status with the shipping version of Android 10: bubbles are available for developers but not for ordinary users.

As a result, it is quite possible that bubbles never become available for users, just as Android 9.0’ slices have been largely unused, at least as of May 2019. Most likely, you should just leave bubbles alone until Android R, then worry about implementing them at that point.