Android 5.1 introduced a mechanism to grant special privileges for APIs relevant to the owners of universal integrated circuit card (UICC) apps. The Android platform loads certificates stored on a UICC and grants permission to apps signed by these certificates to make calls to a handful of special APIs.
Android 7.0 extended this feature to support other storage sources for UICC carrier privilege rules, dramatically increasing the number of carriers that can use the APIs. For an API reference, see CarrierConfigManager; for instructions, see Carrier Configuration.
Carriers have full control of the UICC, so this mechanism provides a secure and flexible way to manage apps from the mobile network operator (MNO) hosted on generic app distribution channels (such as Google Play) while retaining special privileges on devices and without the need to sign apps with the per-device platform certificate or preinstall as a system app.
Rules on UICC
Storage on the UICC is compatible with the
Secure Element Access Control specification. The application identifier
(AID) on the card is
A00000015141434C00, and the standard
command is used to fetch rules stored on the card. You may update these rules
through card over-the-air (OTA) updates.
UICC rules use the following data hierarchy (the two-character letter and
number combination in parentheses is the object tag). Each rule is
E2) and consists of a concatenation of
DeviceAppID-REF-DOor a concatenation of
C1) stores the SHA-1 (20 bytes) or SHA-256 (32 bytes) signature of the certificate.
CA) is the full package name string defined in the manifest, ASCII encoded, max length 127 bytes.
E3) is extended to include
DB), which is an 8-byte bit mask representing 64 separate permissions.
PKG-REF-DO isn't present, any app signed by the certificate
is granted access; otherwise both the certificate and the package name need to
The app name is
com.google.android.apps.myapp and the
SHA-1 certificate in hex string is:
The rule on UICC in hex string is:
E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070 E30A DB08 0000000000000001
Access rule file (ARF) support
Android 7.0 adds support for reading carrier privilege rules from the access rule file (ARF).
The Android platform first attempts to select the access rule applet (ARA)
application identifier (AID)
A00000015141434C00. If it doesn't find
the AID on the UICC, it falls back to ARF by selecting PKCS15 AID
A000000063504B43532D3135. Android then reads the
access control rules file (ACRF) at
0x4300 and looks for entries
FFFFFFFFFFFF. Entries with different AIDs are ignored, so
rules for other use cases can co-exist.
Example ACRF content in hex string:
30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10
Example access control conditions file (ACCF) content:
30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81
In the example above,
0x4310 is the address for ACCF, which
contains the certificate hash
signed by this certificate are granted carrier privileges.
Android supports the following APIs.
- Method to allow the carrier app to ask UICC for a challenge/response:
- Method to check whether the calling app has been granted carrier
- Methods to override brand and number:
- Methods for direct UICC communication:
- Methods to set device mode to global:
Method to allow caller to create new incoming SMS messages:
Service that receives calls from the system when new SMS and MMS are sent
or received. To extend this class, declare the service in your manifest file
permission and include an intent filter with the
action. Methods include:
Content provider APIs to allow modifications (insert, delete, update, query)
to the telephony database. Values fields are defined at
Telephony.Carriers; for more details, refer to
Telephony API reference on developer.android.com.
On a detected UICC, the platform constructs internal UICC objects that
include carrier privilege rules as part of the UICC.
loads rules, parses them from the UICC card, and caches them in memory. When
a privilege check is needed,
UiccCarrierPrivilegeRules compares the
caller certificate with its own rules one by one. If the UICC is removed, the
rules are destroyed along with the UICC object.
The Compatibility Test Suite (CTS) includes
tests for carrier APIs in
CtsCarrierApiTestCases.apk. Because this feature depends on
certificates on the UICC, you must prepare the UICC to pass these tests.
Preparing the UICC
CtsCarrierApiTestCases.apk is signed by Android
developer key, with hash value
tests also print out the expected certificate hash if certificates on UICC
junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it. Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81
In order to validate the implementation through CTS using
CtsCarrierApiTestCases.apk, you must have a developer UICC with
the correct UICC rules or ARF support. You may ask the SIM card vendor
of your choice to prepare a developer UICC with the right ARF as described in
this section and use that UICC to run the tests. The UICC doesn't require
active cellular service to pass CTS tests.
For convenience, CTS supports a device token that restricts
tests to run only on devices configured with same token. Carrier API CTS tests
support the device token
sim-card-with-certs. For example, the
following device token restricts carrier API tests to run only on device
cts-tradefed run cts --device-token abcd1234:sim-card-with-certs
When running a test without using a device token, the test runs on all devices.
How can certificates be updated on the UICC?
A: Use the existing card OTA update mechanism.
Can UICC co-exist with other rules?
A: It's fine to have other security rules on the UICC under same AID; the platform filters them out automatically.
What happens when the UICC is removed for an app that relies on the certificates on it?
A: The app loses its privileges because the rules associated with the UICC are destroyed on UICC removal.
Is there a limit on the number of certificates on the UICC?
A: The platform doesn't limit the number of certificates; but because the check is linear, too many rules may incur a latency for check.
Is there a limit to the number of APIs that we can support with this method?
A: No, but we limit the scope to carrier-related APIs.
Are there some APIs prohibited from using this method? If so, how do you enforce them? (that is, do you have tests to validate which APIs are supported with this method?)
A: See the "API Behavioral Compatibility" section of the Android Compatibility Definition Document (CDD). We have some CTS tests to make sure that the permission model of the APIs isn't changed.
How does this work with the multi-SIM feature?
A: The default SIM specified by the user is used.
Does this in any way interact or overlap with other SE access technologies, for example, SEEK?
A: As an example, SEEK uses the same AID as on the UICC. So the rules
co-exist and are filtered by either SEEK or
When is it a good time to check carrier privileges?
A: After the SIM state loaded broadcast.
Can OEMs disable part of carrier APIs?
A: No. We believe that the current APIs are the minimal set, and we plan to use the bit mask for finer granularity control in the future.
setOperatorBrandOverride override ALL other forms
name strings? For example, SE13, UICC SPN, or network-based NITZ?
A: Refer to the SPN entry in TelephonyManager
What does the
injectSmsPdu method call do?
A: This method facilitates SMS backup/restore in the cloud. The
injectSmsPdu call enables the restore function.
For SMS filtering, is the
onFilterSms call based on
SMS UDH port filtering? Or do carrier apps have access to ALL incoming SMS?
A: Carriers have access to all SMS data.
The extension of
DeviceAppID-REF-DO to support
32 bytes appears to be
incompatible with the current GP spec (which allows 0 or 20 bytes only), so why
are you introducing this change? Isn't SHA-1 sufficient to
avoid collisions? Have you proposed this change to GP already, as this could
be backward incompatible with existing ARA-M/ARF?
A: For providing future-proof security, this extension introduces SHA-256
DeviceAppID-REF-DO in addition to SHA-1, which is currently
the only option in the GP SEAC standard. We highly recommend using SHA-256.
DeviceAppID is 0 (empty), do you apply the rule to
all device apps not covered by a specific rule?
A: Carrier APIs require
DeviceAppID-REF-DO be populated.
Being empty is intended for test purposes and isn't recommended for operational
According to your spec,
PKG-REF-DO used just by
DeviceAppID-REF-DO, shouldn't be accepted. But
it's still described in Table 6-4 as extending the definition of
REF-DO. Is this on purpose? How does the code
behave when only
PKG-REF-DO is used in
A: The option of having
PKG-REF-DO as a single value
REF-DO was removed in the latest version.
PKG-REF-DO should only occur in combination with
We assume that we can grant access to all carrier-based permissions or have finer-grained control. If so, what defines the mapping between the bit mask and the actual permissions? One permission per class? One permission per method? Are 64 separate permissions enough in the long run?
A: This is reserved for the future, and we welcome suggestions.
Can you further define
DeviceAppID for Android
specifically? This is the SHA-1 (20 bytes) hash value of the Publisher
certificate used to signed the given app, so shouldn't the name reflect that
purpose? (The name could be confusing to many readers as the rule is then
applicable to all apps signed with that same Publisher certificate.)
DeviceAppID storing certificates is supported by the
existing spec. We tried to minimize spec changes to lower the barrier for
adoption. For details, see Rules on UICC.