À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Identifiants des appareils

Android 10 modifie les autorisations des identifiants d'appareil afin que tous les identifiants d'appareil soient désormais protégés par l'autorisation READ_PRIVILEGED_PHONE_STATE. Avant Android 10, les identifiants d'appareil persistants (IMEI/MEID, IMSI, SIM et numéro de série de la build) étaient protégés par l'autorisation d'exécution READ_PHONE_STATE. L'autorisation READ_PRIVILEGED_PHONE_STATE n'est accordée qu'aux applications signées avec la clé de plate-forme et aux applications système privilégiées.

Pour en savoir plus sur les nouvelles exigences en matière d'autorisations, consultez les pages Javadoc de TelephonyManager.java et de Build.java.

Cette modification affecte les API suivantes:

TelephonyManager#getDeviceId
TelephonyManager#getImei
TelephonyManager#getMeid
TelephonyManager#getSimSerialNumber
TelephonyManager#getSubscriberId
Build#getSerial

Accès des applications de l'opérateur sans autorisation READ_PRIVILEGED_PHONE_STATE

Les applications préchargées du transporteur qui ne sont pas éligibles à l'autorisation READ_PRIVILEGED_PHONE_STATE peuvent implémenter l'une des options du tableau ci-dessous.

Option	Description	Limites
Droits de l'opérateur sur la carte UICC	La plate-forme Android charge les certificats stockés sur la carte UICC et autorise les applications signées par ces certificats à appeler des méthodes spéciales.	Les anciens opérateurs disposent d'un grand nombre de cartes SIM établies, qui ne sont pas facilement actualisables. De plus, les opérateurs qui ne disposent pas des droits d'auteur pour les nouvelles SIM (par exemple, les MVNO qui disposent de SIM émises par des MNO) ne peuvent pas ajouter ni mettre à jour de certificats sur les SIM.
Ajout d'OEM à la liste d'autorisation	Les OEM peuvent utiliser `OP_READ_DEVICE_IDENTIFIER` pour fournir des identifiants d'appareil aux applications de l'opérateur figurant sur la liste d'autorisation.	Cette solution n'est pas évolutive pour tous les opérateurs.
Code d'allocation de type (TAC)	Utilisez la méthode `getTypeAllocationCode`, introduite dans Android 10, pour exposer le TAC qui renvoie les informations sur le fabricant et le modèle.	Les informations de la demande d'assistance technique ne permettent pas d'identifier un appareil spécifique.
MSISDN	Les opérateurs peuvent utiliser le numéro de téléphone (MSISDN), disponible sous `TelephonyManager` avec le groupe d'autorisations `PHONE`, pour rechercher l'IMEI dans leurs systèmes backend.	Cela nécessite d'importants investissements pour les opérateurs. Les opérateurs qui mappent leurs clés réseau à l'aide de l'IMSI ont besoin de ressources techniques importantes pour passer à l'MSISDN.

Toutes les applications de l'opérateur peuvent accéder aux identifiants de l'appareil en mettant à jour le fichier CarrierConfig.xml avec le hachage du certificat de signature de l'application de l'opérateur. Lorsque l'application de l'opérateur appelle une méthode pour lire des informations privilégiées, la plate-forme recherche une correspondance entre le hachage du certificat de signature de l'application (signature SHA-1 ou SHA-256 du certificat) dans le fichier CarrierConfig.xml. Si une correspondance est trouvée, les informations demandées sont renvoyées. Si aucune correspondance n'est trouvée, une exception de sécurité est renvoyée.

Pour mettre en œuvre cette solution, les transporteurs DOIVENT suivre ces étapes:

Mettez à jour CarrierConfig.xml avec le hachage du certificat de signature de l'application du transporteur et envoyez un correctif.
Demandez aux OEM de mettre à jour leur build avec QPR1 ou version ultérieure (recommandé) OU ces correctifs de plate-forme requis et le correctif contenant le fichier CarrierConfig.xml mis à jour de l'étape 1 ci-dessus.

Implémentation

Mettez à jour votre liste d'autorisation d'autorisations privilégiées pour accorder l'autorisation READ_PRIVILEGED_PHONE_STATE aux applications privilégiées qui nécessitent l'accès aux identifiants de l'appareil.

Pour en savoir plus sur la liste d'autorisation, consultez Liste d'autorisation des autorisations privilégiées.

Pour appeler les API concernées, une application doit répondre à l'une des exigences suivantes:

Si l'application est une application privilégiée préchargée, elle a besoin de l'autorisation READ_PRIVILEGED_PHONE_STATE déclarée dans AndroidManifest.xml. L'application doit également ajouter cette autorisation privilégiée à la liste d'autorisation.
Les applications distribuées via Google Play nécessitent des droits d'accès de l'opérateur. Pour en savoir plus sur l'attribution de droits au transporteur, consultez la page Droits du transporteur UICC.
Une application propriétaire de l'appareil ou du profil à laquelle l'autorisation READ_PHONE_STATE a été accordée.

Une application qui ne répond à aucune de ces exigences présente le comportement suivant:

Si l'application cible la version pré-Q et que l'autorisation READ_PHONE_STATE n'est pas accordée, SecurityException est déclenché. Il s'agit du comportement actuel de la version pré-Q, car cette autorisation est requise pour appeler ces API.
Si l'application cible une version antérieure à Q et que l'autorisation READ_PHONE_STATE lui est accordée, elle reçoit une valeur nulle pour toutes les API TelephonyManager et Build.UNKNOWN pour la méthode Build#getSerial.
Si l'application cible Android 10 ou une version ultérieure et qu'elle ne répond à aucune des nouvelles exigences, elle reçoit une exception SecurityException.

Validation et test

La suite de tests de compatibilité (CTS) inclut des tests permettant de vérifier le comportement d'accès attendu aux identifiants d'appareil pour les applications disposant de droits d'opérateur, les propriétaires d'appareils et de profils, ainsi que les applications qui ne devraient pas avoir accès aux identifiants d'appareil.

Les tests CTS suivants sont spécifiques à cette fonctionnalité.

cts-tradefed run cts -m CtsCarrierApiTestCases -t
    android.carrierapi.cts.CarrierApiTest

cts-tradefed run cts -m CtsTelephonyTestCases -t
    android.telephony.cts.TelephonyManagerTest

cts-tradefed run cts -m CtsTelephony3TestCases

cts-tradefed run cts -m CtsPermissionTestCases -t
    android.permission.cts.TelephonyManagerPermissionTest

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCanGetDeviceIdentifiers

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.ManagedProfileTest#testProfileOwnerCannotGetDeviceIdentifiersWithoutPermission

cts-tradefed run cts -m CtsDevicePolicyManagerTestCases -t
    com.android.cts.devicepolicy.DeviceOwnerTest#testDeviceOwnerCannotGetDeviceIdentifiersWithoutPermission

Questions fréquentes

Combien d'applications peuvent être ajoutées à la liste d'autorisation dans `CarrierConfig.xml` pour un (CM, MN) donné ?

Le nombre de hachages de certificats inclus dans le tableau n'est pas limité.

Quels paramètres CarrierConfig dans `CarrierConfig.xml` dois-je utiliser pour qu'une application soit ajoutée à la liste d'autorisation ?

Utilisez l'élément de configuration de niveau supérieur suivant dans le CarrierConfig.xml spécifique des options AOSP que vous configurez:

<string-array name="carrier_certificate_string_array" num="2">
    <item value="BF02262E5EF59FDD53E57059082F1A7914F284B"/>
    <item value="9F3868A3E1DD19A5311D511A60CF94D975A344B"/>
</string-array>

Existe-t-il un modèle de base CarrierConfig que je peux utiliser ?

Utilisez le modèle suivant. Cette information doit être ajoutée à l' élément approprié.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<carrier_config>
    <string-array name="carrier_certificate_string_array"
num="1">
        <item value="CERTIFICATE_HASH_HERE"/>
    </string-array>
</carrier_config>

La carte SIM de l'opérateur doit-elle être insérée dans l'appareil pour accéder aux identifiants de l'appareil ?

L'CarrierConfig.xml utilisé est déterminé en fonction de la carte SIM actuellement insérée. Cela signifie que si l'application du transporteur X tente d'obtenir des droits d'accès alors que la carte SIM du transporteur Y est insérée, l'appareil ne trouvera pas de correspondance pour le hachage et renverra une exception de sécurité.

Sur les appareils multi-SIM, l'opérateur 1 ne dispose que des droits d'accès pour la carte SIM 1, et vice-versa.

Comment les opérateurs convertissent-ils le certificat de signature d'une application en hachage ?

Pour convertir les certificats de signature en hachage avant de les ajouter à CarrierConfig.xml, procédez comme suit:

Convertissez la signature du certificat de signature en tableau d'octets à l'aide de toByteArray.
Utilisez MessageDigest pour convertir le tableau d'octets en hachage au format byte[].

Convertit le hachage de byte[] au format de chaîne hexadécimale. Pour obtenir un exemple, consultez IccUtils.java.

List<String> certHashes = new ArrayList<>();
PackageInfo pInfo; // Carrier app PackageInfo
MessageDigest md =
MessageDigest.getInstance("SHA-256");
for (Signature signature : pInfo.signatures) {
    certHashes.add(bytesToHexString(md.digest(signature.toByteArray()));
}

Si certHashes est un tableau de taille 2 avec une valeur de 12345 et 54321, ajoutez ce qui suit au fichier de configuration de l'opérateur.
```
<string-array name="carrier_certificate_string_array" num="2">
    <item value="12345"/>
    <item value="54321"/>
</string-array>
```

Identifiants des appareils Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.