Android 12 introduces support for a single registration model for providing MMTEL and RCS features. This model allows devices to have all IMS features managed through a single IMS registration provided by the device's ImsService and to comply with requirements introduced by some telecom carriers. Compared with a dual registration model, where multiple IMS registrations are managed on one device, single registration reduces traffic on the carrier's network and increases reliability.
Android 12 supports this single registration model
through an architecture with a
set of APIs that allow the AOSP telephony stack to manage both MMTEL features
and RCS features provided by the user-selected RCS messaging app. To support IMS
single registration, device manufacturers and SoC vendors must implement these
APIs to enable RCS features in the user-selected RCS messaging app.
Figure 1 illustrates the device's IMS stack when using the IMS single registration model. All IMS applications use the device's default ImsService for MMTEL and RCS features over a single IMS registration. This includes provisioning, SIP message forwarding, and RCS user capability exchange.
Figure 1. Single registration model architecture
Android 11 and lower only supports a dual registration model for providing MMTEL and RCS features, where MMTEL is provided by the device's ImsService and RCS features are implemented over the top and manage their own IMS stack and connection to the carrier's network independently.
Figure 2 illustrates the architecture for the dual registration model. In this model, each app is responsible for connecting to the carrier's network and establishing an IMS registration for MMTEL and RCS features. The device's ImsService implements MMTEL and operates completely over the top and independent of other RCS applications.
Figure 2. Dual registration model architecture
IMS single registration APIs
Devices that range on carriers that require IMS single registration must support
the IMS single registration APIs and define the Android feature
Figure 3 shows the APIs that support IMS single registration.
Figure 3. High-level API surfaces that support IMS single registration
Android devices that support IMS single registration as part of the AOSP telephony stack are required to support all of the AOSP APIs described in the following table.
|API Surface Area||RCS application APIs||Vendor IMS APIs||Description|
|RCS provisioning||ProvisioningManager||ImsConfigImplBase||Allows an OEM or carrier to provide an app to update the RCS provisioning status if the carrier uses a proprietary carrier entitlement mechanism. The ImsService must also support the standard AutoConfigurationServer (ACS) for provisioning for carriers that don't use a proprietary mechanism.|
|SIP message forwarding||SipDelegateManager||SipTransportImplBase||Allows an RCS application to first associate specific RCS feature tags with
|Dedicated bearer notifications||ConnectivityManager||DataCallResponse||Allows an app to listen to QoS notifications on a socket that's associated with a specific local port.|
|GBA authentication||bootstrapAuthenticationRequest||GbaService||Allows an RCS app to authenticate with the network and access keys used for RCS features such as file transfer.|
|RCS user capability exchange||ImsRcsManager||RcsCapabilityExchangeImplBase||Provides AOSP the ability to send its MMTEL and RCS capabilities to the vendor ImsService so that they can be published under one entity to the network for RCS user capability exchange. Also allows other apps interested in the RCS capabilities of one or more contacts to query the network for the contacts RCS capabilities.|
Security and permissions
Android 12 introduces the following permissions to ensure secure access to the carrier's network and user's data:
permission must be defined by the messaging app with the RCS features. For this
permission to be granted, the following must be true:
- The app must be installed as a privileged application, meaning that it's preinstalled on the device and is allowed to access privileged permissions
- The app must be set as the user's default SMS role using
If both of these conditions aren't met, the app is denied access to the
permission. This means that third party apps aren't allowed to access RCS single
registration APIs as they require carrier certification on the device.
permission when granted to an app that also has the READ_CONTACTS permission
allows the app to request the RCS capabilities of phone numbers using
For this permission to be granted, the following must be true:
- The app must be installed as a privileged application, meaning that it's preinstalled on the device and is allowed to access privileged permissions.
The app must be defined as one of the following
- Default messaging app: Set by the user.
- Default dialer app: Set by the user.
- Default contacts app: A role introduced in
Android 12 that
allows the OEM to define a package name through the
device overlay value
config_systemContacts, which must correspond to the device's contacts app. That app is then given the contacts role.
To access the IMS APN using
ConnectivityManager to set up and manage data
traffic, apps must also request the
Examples and source
Android provides an app in AOSP that implements a test messaging app with basic
RCS messaging support for testing and development purposes. You can find the app
When the app is installed on a device, it can be set as the user's default
messaging app and will have the permissions required to access the IMS single
Android also provides a sample implementation of ImsService for RCS. The source
code is at
For more implementation details, download IMS Single Registration in Android.
To validate your implementation of IMS single registration, do the following: