À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer à AOSP, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Définition de compatibilité Android 17 [APERÇU]

1. Introduction

Ce document énumère les exigences à respecter pour que les appareils soient compatibles avec Android 17.

L'utilisation des termes "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" est conforme à la norme IETF définie dans la RFC2119.

Dans ce document, un "intégrateur d'appareil" ou un "intégrateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 17. Une "implémentation d'appareil" ou "implémentation" désigne la solution matérielle/logicielle ainsi développée.

Pour être considérées comme compatibles avec Android 17, les implémentations d'appareils DOIVENT répondre aux exigences présentées dans la présente Définition de compatibilité, y compris tous les documents incorporés par référence.

Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'implémenteur de l'appareil d'assurer la compatibilité avec les implémentations existantes.

C'est pourquoi le Projet Android Open Source est à la fois la référence et l'implémentation privilégiée d'Android. Il est FORTEMENT RECOMMANDÉ aux implémenteurs d'appareils de baser leurs implémentations dans la mesure du possible sur le code source "en amont" disponible sur le projet Android Open Source. Bien que certains composants puissent théoriquement être remplacés par des implémentations alternatives, il est FORTEMENT DÉCONSEILLÉ de suivre cette pratique, car il deviendra beaucoup plus difficile de réussir les tests logiciels. Il incombe à l'implémenteur d'assurer une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

De nombreuses ressources liées dans ce document proviennent directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette Définition de compatibilité ou la suite de tests de compatibilité ne sont pas d'accord avec la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les ressources associées tout au long de ce document sont considérés comme faisant partie de cette définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

La section 2 contient toutes les exigences qui s'appliquent à un type d'appareil spécifique. Chaque sous-section de la section 2 est dédiée à un type d'appareil spécifique.

Toutes les autres exigences, qui s'appliquent universellement à toutes les implémentations d'appareils Android, sont listées dans les sections après la section 2. Dans ce document, ces exigences sont appelées "Exigences de base".

1.1.2. ID de l'exigence

Un ID d'exigence est attribué aux exigences MUST.

L'ID n'est attribué qu'aux exigences MUST.
Les exigences FORTEMENT RECOMMANDÉES sont marquées par [SR], mais aucun ID n'est attribué.
L'ID se compose de : ID du type d'appareil - ID de la condition - ID de l'exigence (par exemple, C-0-1).

Chaque ID est défini comme suit :

ID du type d'appareil (pour en savoir plus, consultez 2. Types d'appareils)
- C : Core (exigences appliquées à toutes les implémentations d'appareils Android)
- H : Appareil Android portable
- T : Appareil Android TV
- A: Implémentation Android Automotive
- W: Implémentation Android Watch
- Onglet : implémentation sur tablette Android
ID de la condition
- Lorsque l'exigence est inconditionnelle, cet ID est défini sur 0.
- Lorsque l'exigence est conditionnelle, la valeur 1 est attribuée à la première condition. Le nombre augmente de 1 dans la même section et pour le même type d'appareil.
ID de l'exigence
- Cet ID commence à 1 et augmente d'une unité dans la même section et la même condition.

1.1.3. ID de l'exigence dans la section 2

Les ID des exigences de la section 2 se composent de deux parties. Le premier correspond à un ID de section, comme décrit ci-dessus. La deuxième partie identifie le facteur de forme et l'exigence spécifique au facteur de forme.

ID de section suivi de l'ID d'exigence décrit ci-dessus.

L'ID de la section 2 se compose de l'ID de section / de type d'appareil, de l'ID de condition et de l'ID d'exigence (par exemple, 7.4.3/A-0-1).

2. Types d'appareils

Le projet Android Open Source fournit une pile logicielle pouvant être utilisée pour différents types d'appareils et facteurs de forme. Pour assurer la sécurité sur les appareils, la pile logicielle, y compris tout OS de remplacement ou toute autre implémentation du noyau, doit s'exécuter dans un environnement sécurisé, comme décrit dans la section 9 et ailleurs dans le présent CDD. Certains types d'appareils disposent d'un écosystème de distribution d'applications relativement bien établi.

Cette section décrit ces types d'appareils, ainsi que les exigences et recommandations supplémentaires applicables à chacun d'eux.

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils décrits DOIVENT toujours répondre à toutes les exigences des autres sections de cette définition de compatibilité.

2.1 Configurations de l'appareil

Pour connaître les principales différences de configuration matérielle par type d'appareil, consultez les exigences spécifiques aux appareils qui suivent dans cette section.

2.2. Exigences concernant les appareils mobiles

Un appareil portable Android fait référence à une implémentation d'appareil Android qui est généralement utilisée en la tenant à la main, comme un lecteur MP3, un téléphone ou une tablette.

Les implémentations d'appareils Android sont classées comme "Appareil mobile" si elles répondent à tous les critères suivants :

être alimenté par une source d'énergie mobile, comme une batterie ;
avoir une taille d'écran physique comprise entre 4 et 8 pouces (diagonale) ;
disposer d'une interface de saisie à écran tactile.

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils portables Android.

2.2.1. Matériel

Implémentations sur les appareils portables :

[7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible avec Android mesurant au moins 5,6 cm sur le bord court et 8,6 cm sur le bord long.
[7.1.1.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ de permettre aux utilisateurs de modifier la taille d'affichage (densité d'écran).
[7.1.1.1/H-0-2] DOIT prendre en charge la composition GPU des tampons graphiques au moins aussi grands que la résolution la plus élevée de tout écran intégré.
[7.1.1.1/H-0-3]^* DOIT mapper chaque affichage UI_MODE_NORMAL mis à disposition des applications tierces sur une zone d'affichage physique dégagée d'au moins 5,6 cm sur le bord court et 8,6 cm sur le bord long.
[7.1.1.3/H-0-1]^* DOIT définir DENSITY_DEVICE_STABLE sur une valeur égale ou supérieure à 92% de la densité physique réelle de l'écran correspondant.

Si les implémentations d'appareils portables incluent la compatibilité avec Vulkan, elles :

[7.1.4.2/H-1-1] DOIT répondre aux exigences spécifiées par le profil de référence Android 2021.

Si les implémentations d'appareils portables déclarent la prise en charge d'une ABI 64 bits (avec ou sans ABI 32 bits) et renvoient false pour ActivityManager.isLowRamDevice(), elles :

[7.1.4.2/H-2-1] DOIT être compatible avec Vulkan 1.1 ou version ultérieure.

Si les implémentations d'appareils portables affirment prendre en charge les écrans HDR (High Dynamic Range) via Configuration.isScreenHdr(), elles :

[7.1.4.5/H-1-1] DOIT annoncer la prise en charge des extensions EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace et VK_EXT_hdr_metadata.

Implémentations sur les appareils portables :

[7.1.4.6/H-0-1] DOIT indiquer si l'appareil est compatible avec la fonctionnalité de profilage du GPU via une propriété système graphics.gpu.profiler.support.

Si les implémentations d'appareils portables déclarent la compatibilité via une propriété système graphics.gpu.profiler.support, elles :

[7.1.4.6/H-1-1] DOIT générer en sortie une trace protobuf conforme au schéma des compteurs et des étapes de rendu GPU définis dans la documentation Perfetto.
[7.1.4.6/H-1-2] DOIT signaler des valeurs conformes pour les compteurs de GPU de l'appareil en suivant le proto de paquet gpu counter trace.
[7.1.4.6/H-1-3] DOIT signaler des valeurs conformes pour les RenderStages du GPU de l'appareil, conformément au proto de paquet de trace RenderStage.
[7.1.4.6/H-1-4] DOIT signaler un point de trace de fréquence GPU, comme spécifié par le format suivant : power/gpu_frequency.

Implémentations sur les appareils portables :

[7.1.5/H-0-1] DOIT inclure la prise en charge du mode de compatibilité des anciennes applications tel qu'il est implémenté par le code source ouvert Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ni les seuils d'activation du mode de compatibilité, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.
[7.2.1/H-0-1] DOIT inclure la prise en charge des applications tierces d'éditeur de méthode de saisie (IME).
[7.2.3/H-0-2] DOIT envoyer l'événement de pression normale et longue de la fonction Retour (KEYCODE_BACK) à l'application au premier plan. Ces événements NE DOIVENT PAS être consommés par le système et PEUVENT être déclenchés en dehors de l'appareil Android (par exemple, un clavier matériel externe connecté à l'appareil Android).
[7.2.3/H-0-3] DOIT fournir la fonction Accueil sur tous les écrans compatibles avec Android qui fournissent l'écran d'accueil.
[7.2.3/H-0-4] DOIT fournir la fonction Retour sur tous les écrans compatibles avec Android et la fonction Récents sur au moins l'un des écrans compatibles avec Android.
[7.2.4/H-0-1] DOIT être compatible avec la saisie sur écran tactile.
[7.2.4/H-SR-1] Il est FORTEMENT RECOMMANDÉ de lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité gérant ACTION_ASSIST en cas d'appui prolongé sur KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK si l'activité de premier plan ne gère pas ces événements d'appui prolongé.
[7.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à trois axes.

Si les implémentations d'appareils portables incluent un accéléromètre 3 axes, elles :

[7.3.1/H-1-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Si les implémentations d'appareils portables incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, elles :

[7.3.3/H-2-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore indiquée.
[7.3.3/H-2-2] DOIT signaler les pseudo-distances et les taux de pseudo-distances GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, en étant immobile ou en se déplaçant avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0,2 mètre par seconde près, au moins 95% du temps.

Si les implémentations d'appareils portables incluent un gyroscope à trois axes, elles :

[7.3.4/H-3-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
[7.3.4/H-3-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Implémentations d'appareils portables pouvant passer un appel vocal et indiquant une valeur autre que PHONE_TYPE_NONE dans getPhoneType :

[7.3.8/H] DOIT inclure un capteur de proximité.

Implémentations sur les appareils portables :

[7.3.11/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge le capteur de pose avec 6 degrés de liberté.

Si les implémentations d'appareils portables sont compatibles avec la connectivité aux données mobiles, elles :

[7.4.1/H-1-1] Vous DEVEZ déclarer le flag de fonctionnalité android.hardware.telephony.data.

Implémentations d'appareils portables compatibles avec le Bluetooth LE :

[7.4.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension de la longueur des paquets de données Bluetooth LE.

Remarque : Cette exigence [7.4.3/H-SR-1] deviendra OBLIGATOIRE dans une prochaine version d'Android.

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.11 (Wi-Fi), elles doivent :

[7.4.2.4/H-1-1] DOIT être compatible avec Wi-Fi Passpoint.

Si les appareils sont compatibles avec le protocole Wi-Fi NAN (Neighbor Awareness Networking) en déclarant PackageManager.FEATURE_WIFI_AWARE et avec la localisation Wi-Fi (Wi-Fi Round Trip Time – RTT) en déclarant PackageManager.FEATURE_WIFI_RTT, ils :

[7.4.2.5/H-1-1] DOIT signaler la plage avec précision à +/-1 mètre avec une bande passante de 160 MHz au 68e centile (calculé avec la fonction de distribution cumulative), à +/-2 mètres avec une bande passante de 80 MHz au 68e centile, à +/-4 mètres avec une bande passante de 40 MHz au 68e centile et à +/-8 mètres avec une bande passante de 20 MHz au 68e centile à des distances de 10 cm, 1 m, 3 m et 5 m, comme observé via l'API Android WifiRttManager#startRanging.
[7.4.2.5/H-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler la plage avec une précision de +/- 1 mètre à une bande passante de 160 MHz au 90e centile (calculée avec la fonction de distribution cumulative), +/- 2 mètres à une bande passante de 80 MHz au 90e centile, +/- 4 mètres à une bande passante de 40 MHz au 90e centile et +/- 8 mètres à une bande passante de 20 MHz au 90e centile à des distances de 10 cm, comme observé avec l'API Android WifiRttManager#startRanging.

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration de la mesure spécifiées dans Calibration de la présence.

Si les appareils portables sont compatibles avec le protocole de détection de proximité Wi-Fi en déclarant PackageManager.FEATURE_WIFI_PD et avec la localisation Wi-Fi (Wi-Fi Round Trip Time – RTT) en déclarant PackageManager.FEATURE_WIFI_RTT, ils :

[7.4.2.10/H-1-1] DOIT utiliser une bande passante d'au moins 160 MHz.
[7.4.2.10/H-1-2] DOIT signaler la plage avec précision à +/- 0,25 m près à une bande passante de 160 MHz au 68e centile (calculé avec la fonction de distribution cumulative), comme observé via l'API Android WifiRttManager#startRanging.

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration de la mesure spécifiées dans Calibration de la présence.

Si les implémentations d'appareils portables déclarent FEATURE_BLUETOOTH_LE, elles :

[7.4.3/H-1-3] DOIT mesurer et compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -50 dBm +/-15 dB à 1 mètre de distance d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH.
[7.4.3/H-1-4] DOIT mesurer et compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -50 dBm +/-15 dB lors de la recherche à partir d'un appareil de référence positionné à 1 mètre de distance et transmettant à ADVERTISE_TX_POWER_HIGH.

Si les implémentations d'appareils portables incluent au moins une caméra orientée vers l'arrière, elles :

[7.5.1/H-1-1] DOIT avoir une résolution d'au moins 2 mégapixels.

Si les implémentations d'appareils portables incluent un périphérique de caméras logiques qui liste les fonctionnalités à l'aide de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elles :

[7.5.4/H-1-1] DOIT avoir un champ de vision normal par défaut et DOIT être compris entre 50 et 90 degrés.

Implémentations sur les appareils portables :

[7.6.1/H-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition /data).
[7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsqu'il y a moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

Si les implémentations d'appareils portables ne déclarent la prise en charge que d'une ABI 32 bits :

[7.6.1/H-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 416 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 592 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-3-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-4-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à QHD (par exemple, QWXGA).

Si les implémentations d'appareils portables déclarent la prise en charge d'une ABI 64 bits (avec ou sans ABI 32 bits) :

[7.6.1/H-5-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-6-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-7-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-8-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à QHD (par exemple, QWXGA).

Notez que la "mémoire disponible pour le noyau et l'espace utilisateur" ci-dessus fait référence à l'espace mémoire fourni en plus de toute mémoire déjà dédiée aux composants matériels tels que la radio, la vidéo, etc., qui ne sont pas sous le contrôle du noyau sur les implémentations d'appareils.

Si les implémentations d'appareils portables incluent 1 Go de mémoire ou moins disponible pour le noyau et l'espace utilisateur, elles :

[7.6.1/H-9-1] DOIT déclarer le flag de fonctionnalité android.hardware.ram.low.
[7.6.1/H-9-2] DOIT disposer d'au moins 1,1 Go de stockage non volatile pour les données privées de l'application (c'est-à-dire la partition "/data").

Si les implémentations d'appareils portables incluent plus de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles :

[7.6.1/H-10-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").
DOIT déclarer le flag de fonctionnalité android.hardware.ram.normal.

Si les implémentations d'appareils portables incluent une mémoire disponible pour le noyau et l'espace utilisateur supérieure ou égale à 2 Go et inférieure à 4 Go, elles :

[7.6.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ de n'accepter que l'espace utilisateur 32 bits (applications et code système)

Si les implémentations d'appareils portables incluent moins de 2 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles :

[7.6.1/H-1-1] DOIT uniquement prendre en charge une seule ABI (64 bits uniquement ou 32 bits uniquement).

Implémentations sur les appareils portables :

[7.6.2/H-0-1] NE DOIT PAS fournir un stockage partagé d'application inférieur à 1 Gio.
[7.7.1/H] DOIT inclure un port USB prenant en charge le mode périphérique.

Si les implémentations d'appareils portables incluent un port USB avec un contrôleur fonctionnant en mode périphérique, elles :

[7.7.1/H-1-1] DOIT implémenter l'API Android Open Accessory (AOA).

Si les implémentations d'appareils portables incluent un port USB compatible avec le mode hôte, elles :

[7.7.2/H-1-1] DOIT implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.

Implémentations sur les appareils portables :

[7.8.1/H-0-1] DOIT inclure un micro.
[7.8.2/H-0-1] DOIT disposer d'une sortie audio et déclarer android.hardware.audio.output.

Si les implémentations d'appareils portables sont capables de répondre à toutes les exigences de performances pour la prise en charge du mode RV et incluent cette prise en charge, elles :

[7.9.1/H-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.vr.high_performance.
[7.9.1/H-1-2] DOIT inclure une application implémentant android.service.vr.VrListenerService qui peut être activée par les applications de VR via android.app.Activity#setVrModeEnabled.

Si les implémentations d'appareils portables incluent un ou plusieurs ports USB-C en mode hôte et implémentent (classe audio USB), en plus des exigences de la section 7.7.2, elles :

[7.8.2.2/H-1-1] DOIT fournir le mappage logiciel suivant des codes HID :

Fonction	Mappages	Contexte	Comportement
A	Page d'utilisation HID : 0x0C Utilisation HID : 0x0CD Clé du noyau : `KEY_PLAYPAUSE` Clé Android : `KEYCODE_MEDIA_PLAY_PAUSE`	Lecture de contenus multimédias	Entrée : appui bref sur Sortie : lecture ou pause
		Lecture de contenus multimédias	Entrée : appui prolongé sur Sortie : lancer la commande vocale Envoi : `android.speech.action.VOICE_SEARCH_HANDS_FREE` si l'appareil est verrouillé ou si son écran est éteint. Envoi de `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` dans le cas contraire
		Appel entrant	Entrée : appui bref sur Sortie : accepter l'appel
		Appel entrant	Entrée : appuyer de manière prolongée sur Sortie : refuser l'appel
		Appel en cours	Entrée : appui bref sur Sortie : mettre fin à l'appel
		Appel en cours	Entrée : appuyer de manière prolongée sur Sortie : activer ou couper le micro
B	Page d'utilisation HID : 0x0C Utilisation HID : 0x0E9 Clé du noyau : `KEY_VOLUMEUP` Clé Android : `VOLUME_UP`	Lecture de contenus multimédias, Appel en cours	Entrée : appui bref ou long Sortie : augmente le volume du système ou du casque
C	Page d'utilisation HID : 0x0C Utilisation HID : 0x0EA Clé du noyau : `KEY_VOLUMEDOWN` Clé Android : `VOLUME_DOWN`	Lecture de contenus multimédias, Appel en cours	Entrée : appuyez brièvement ou longuement sur Sortie : baisse le volume du système ou du casque
D	Page d'utilisation HID : 0x0C Utilisation HID : 0x0CF Clé du noyau : `KEY_VOICECOMMAND` Clé Android : `KEYCODE_VOICE_ASSIST`	Tous. Peut être déclenché dans n'importe quelle instance.	Entrée : appui bref ou long sur Sortie : lancement de la commande vocale

[7.8.2.2/H-1-2] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'un connecteur, mais uniquement après que les interfaces et points de terminaison audio USB ont été correctement énumérés afin d'identifier le type de terminal connecté.

Lorsque les types de terminaux audio USB 0x0302 sont détectés, ils :

[7.8.2.2/H-2-1] DOIT diffuser l'Intent ACTION_HEADSET_PLUG avec l'extra "microphone" défini sur 0.

Lorsque les types de terminaux audio USB 0x0402 sont détectés, ils :

[7.8.2.2/H-3-1] DOIT diffuser l'Intent ACTION_HEADSET_PLUG avec l'extra "microphone" défini sur 1.

Lorsque l'API AudioManager.getDevices() est appelée alors que le périphérique USB est connecté :

[7.8.2.2/H-4-1] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ de type de terminal audio USB est 0x0302.
[7.8.2.2/H-4-2] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ de type de terminal audio USB est 0x0402.
[7.8.2.2/H-4-3] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSource() si le champ de type de terminal audio USB est 0x0402.
[7.8.2.2/H-4-4] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSink() si le champ de type de terminal audio USB est défini sur 0x603.
[7.8.2.2/H-4-5] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSource() si le champ de type de terminal audio USB est défini sur 0x604.
[7.8.2.2/H-4-6] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSink() si le champ de type de terminal audio USB est défini sur 0x400.
[7.8.2.2/H-4-7] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSource() si le champ de type de terminal audio USB est défini sur 0x400.
[7.8.2.2/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'effectuer l'énumération des descripteurs USB, d'identifier les types de terminaux et de diffuser l'Intent ACTION_HEADSET_PLUG en moins de 1 000 millisecondes lors de la connexion d'un périphérique audio USB-C.

Pour les implémentations d'appareils portables qui déclarent android.hardware.audio.output et android.hardware.microphone, consultez les exigences RTL et TTL dans la section 5.6.

Un actionneur résonant linéaire (LRA) est un système à ressort à masse unique qui présente une fréquence de résonance dominante où la masse se déplace dans la direction du mouvement souhaité.

Si les implémentations d'appareils portables incluent au moins un actionneur résonant linéaire 7.10 à usage général, elles :

[7.10/H] DOIT positionner l'actionneur près de l'endroit où l'appareil est généralement tenu ou touché par les mains.
[7.10/H] DOIT déplacer l'actionneur haptique sur l'axe X (de gauche à droite) de l'orientation naturelle de l'appareil.

Si les implémentations d'appareils portables disposent d'un actionneur haptique à usage général qui est un actionneur à résonance linéaire (LRA) sur l'axe X, elles :

[7.10/H] La fréquence de résonance du LRA de l'axe X DOIT être inférieure à 200 Hz.

Si les implémentations d'appareils portables suivent le mappage des constantes haptiques, elles :

[7.10/H]^* DOIT vérifier l'état de l'implémentation en exécutant les API android.os.Vibrator.areAllEffectsSupported() et android.os.Vibrator.arePrimitivesSupported().
[7.10/H]^* DOIT effectuer une évaluation de la qualité pour les constantes haptiques.
[7.10/H]^* DOIT vérifier et mettre à jour, si nécessaire, la configuration de secours pour les primitives non compatibles, comme décrit dans les conseils d'implémentation pour les constantes.

2.2.2. Multimédia

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

[5.1/H-0-1] AMR-NB
[5.1/H-0-2] AMR-WB
[5.1/H-0-3] Profil AAC MPEG-4 (AAC LC)
[5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
[5.1/H-0-5] AAC ELD (AAC à latence faible amélioré)

[5.1/H-0-6] MPEG-D USAC avec MPEG-D DRC (Extended High Efficiency AAC)

2.2.3. Logiciel

Les implémentations sur les appareils portables DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.2/H-0-1] H.264 AVC
[5.2/H-0-2] VP8
[5.2/H-0-3] AV1

Les implémentations sur les appareils portables DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.3/H-0-1] H.264 AVC
[5.3/H-0-2] H.265 HEVC
[5.3/H-0-3] MPEG-4 SP
[5.3/H-0-4] VP8
[5.3/H-0-5] VP9
[5.3/H-0-6] AV1

2.2.3. Logiciel

Implémentations sur les appareils portables :

[3.2.3.1/H-0-1] DOIT disposer d'une application qui gère les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT tels que décrits dans la documentation du SDK, et qui permet à l'utilisateur d'accéder aux données du fournisseur de documents à l'aide de l'API DocumentsProvider.

[3.2.3.1/H-0-2]^* DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici. Remarque : La page "Intents courants des applications" inclura le nouvel intent obligatoire "android.settings.VPN_APP_EXCLUSION_SETTINGS".

[3.2.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une application de messagerie électronique capable de gérer les intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE pour envoyer un e-mail.
[3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
[3.4.2/H-0-1] DOIT inclure une application de navigateur autonome pour la navigation Web générale des utilisateurs.

[3.8.1/H-0-1] DOIT implémenter un lanceur d'applications par défaut qui permet d'épingler des widgets dans les applications.

[3.8.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui prend en charge l'épinglage dans l'application des raccourcis, des widgets et de widgetFeatures.
[3.8.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui offre un accès rapide aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
[3.8.1/H-SR-3] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lanceur d'applications par défaut qui affiche des badges pour les icônes d'application.

[3.8.2/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les widgets d'applications tierces.

[3.8.2/H-0-1] DOIT être compatible avec les widgets d'applications tierces.

[3.8.3/H-0-1] DOIT permettre aux applications tierces d'informer les utilisateurs d'événements notables via les classes d'API Notification et NotificationManager.
[3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
[3.8.3/H-0-3] DOIT prendre en charge les notifications heads-up.
[3.8.3/H-0-4] DOIT inclure un volet de notifications, permettant à l'utilisateur de contrôler directement les notifications (par exemple, répondre, mettre en veille, ignorer, bloquer) grâce à des affordances utilisateur telles que des boutons d'action ou le panneau de configuration tel qu'implémenté dans l'AOSP.
[3.8.3/H-0-5] DOIT afficher les choix fournis par le biais de RemoteInput.Builder setChoices() dans le volet de notification.
[3.8.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni par le biais de RemoteInput.Builder setChoices() dans le volet des notifications sans interaction supplémentaire de l'utilisateur.
[3.8.3/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis par le biais de RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
[3.8.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true en ligne avec les réponses affichées par Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action Assist.

Si les implémentations d'appareils portables sont compatibles avec les notifications MediaStyle, elles :

[3.8.3.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur (par exemple, un sélecteur de sortie) accessible depuis l'UI système qui permet aux utilisateurs de basculer entre les routes média disponibles appropriées (par exemple, les appareils Bluetooth et les routes fournies à MediaRouter2Manager) lorsqu'une application publie une notification MediaStyle avec un jeton MediaSession.

Une notification de mise à jour en direct d'une application peut être promue si l'application répond à toutes les caractéristiques de promotion. Dans ce document, cette notification est appelée "notification de mise à jour en direct sponsorisée". Les implémentations sur les appareils portables DOIVENT afficher de manière visible la notification de mise à jour en direct mise en avant conformément aux exigences suivantes.

Si les implémentations d'appareils portables déclarent le niveau d'API 36.1 ou supérieur, elles :

[3.8.3.1/H-0-1] DOIT afficher une notification de mise à jour en direct sponsorisée de manière visible sur l'écran de verrouillage.
[3.8.3.1/H-0-12] DOIT s'afficher en haut de la pile de notifications Notification prioritaire et au-dessus des notifications colorées (où setColorized est true) lorsque la notification de mise à jour en direct sponsorisée s'affiche parmi d'autres notifications.
- PEUT déterminer l'ordre des notifications de mise à jour en direct sponsorisées affichées dans la barre de notifications et sur l'écran de verrouillage lorsqu'une ou plusieurs applications sont éligibles à une notification de mise à jour en direct sponsorisée.
[3.8.3.1/H-0-2] DOIT afficher une notification de mise à jour en direct sponsorisée dans l'état développé.
[3.8.3.1/H-0-3] NE DOIT PAS fournir d'affordance utilisateur pour réduire la notification développée ci-dessus.
[3.8.3.1/H-0-4] DOIT afficher les styles de base (gras, italique et souligné) du contenu textuel dans une notification d'actualités en direct promue, tels que fournis par StyleSpan ou UnderlineSpan.
[3.8.3.1/H-0-5] DOIT afficher uniquement les objets d'action standards (via Notification.Action) et DOIT masquer les objets d'action non standards tels que les zones de saisie, les boutons de réponse et les actions contextuelles (via addRemoteInput() et setContextual()) dans une notification d'actualité en direct sponsorisée, même si la notification les contient.
[3.8.3.1/H-0-6] DOIT afficher une représentation compacte, également appelée puce d'état dans la documentation du SDK, pour une notification de mise à jour en direct sponsorisée qui DOIT inclure Notification.getSmallIcon().
- [3.8.3.1/H-0-7] Les autres champs sont facultatifs pour la représentation compacte, mais chaque fois que la représentation compacte peut être développée, Notification.getShortCriticalText() DOIT s'afficher, le cas échéant, ou Notification.when si Notification.getShortCriticalText n'est pas présent.
- [3.8.3.1/H-0-8] Lorsqu'il existe plusieurs notifications de mise à jour en direct sponsorisées, au moins l'une d'elles DOIT s'afficher dans la barre d'état sous forme de représentation compacte.
- [3.8.3.1/H-0-9] DOIT afficher la notification associée (méthode recommandée) ou ouvrir l'application associée (via Notification.contentIntent) lorsque l'utilisateur appuie sur la représentation compacte.
- [3.8.3.1/H-0-13] DOIT afficher le même contenu dans la notification associée que celui disponible dans le volet de notifications.
[3.8.3.1/H-0-10] DOIT fournir une option permettant à l'utilisateur de désactiver et d'activer l'affichage promotionnel des notifications d'applications individuelles.
[3.8.3.1/H-0-11] DOIT afficher correctement toutes les notifications de mise à jour en direct, y compris, mais sans s'y limiter, les notifications de mise à jour en direct non promotionnelles qui ne respectent pas ou ne respectent que partiellement les caractéristiques promotionnelles. Ces notifications non sponsorisées DOIVENT être affichées comme telles.

Si les implémentations d'appareils incluant la touche de navigation de la fonction "Récents" comme indiqué dans la section 7.2.3 modifient l'interface, elles :

[3.8.3/H-1-1] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer ou désactiver la fonctionnalité.

Si les implémentations d'appareils portables sont compatibles avec l'action Assist, elles :

[3.8.4/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la touche HOME comme interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3. DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité gérant l'intent ACTION_ASSIST.

Si les implémentations d'appareils portables sont compatibles avec conversation notifications et les regroupent dans une section distincte des notifications d'alerte et des notifications silencieuses non conversationnelles, elles :

[3.8.4/H-1-1]^* Les notifications de conversation DOIVENT s'afficher avant les notifications non liées à une conversation, à l'exception des notifications de service de premier plan en cours et des notifications avec importance:high.

Si les implémentations d'appareils portables Android sont compatibles avec un écran de verrouillage, elles :

[3.8.10/H-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles :

[3.9/H-1-1] DOIT implémenter l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android.

Si les implémentations d'appareils portables incluent la prise en charge des API ControlsProviderService et Control et permettent aux applications tierces de publier des commandes de l'appareil, elles :

[3.8.16/H-1-1] DOIT déclarer le flag de fonctionnalité android.software.controls et le définir sur true.
[3.8.16/H-1-2] DOIT fournir une affordance utilisateur permettant d'ajouter, de modifier, de sélectionner et d'utiliser les commandes de l'appareil préféré de l'utilisateur à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control.
[3.8.16/H-1-3] DOIT fournir un accès à cette affordance utilisateur en trois interactions à partir d'un lanceur d'applications par défaut.
[3.8.16/H-1-4] DOIT afficher précisément dans cette zone d'interaction le nom et l'icône de chaque application tierce qui fournit des commandes via l'API ControlsProviderService, ainsi que tous les champs spécifiés fournis par les API Control.
[3.8.16/H-1-5] DOIT fournir une option permettant à l'utilisateur de désactiver les commandes d'appareil triviales pour l'authentification désignées par l'application à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control Control.isAuthRequired.
[3.8.16/H-1-6] Les implémentations d'appareils DOIVENT afficher précisément l'affordance utilisateur comme suit :
- Si l'appareil a défini config_supportsMultiWindow=true et que l'application déclare les métadonnées META_DATA_PANEL_ACTIVITY dans la déclaration ControlsProviderService, y compris le ComponentName d'une activité valide (telle que définie par l'API), l'application DOIT intégrer cette activité dans cette affordance utilisateur.
- Si l'application ne déclare pas de métadonnées META_DATA_PANEL_ACTIVITY, elle DOIT afficher les champs spécifiés tels qu'ils sont fournis par l'API ControlsProviderService, ainsi que tous les champs spécifiés fournis par les API Control.
[3.8.16/H-1-7] Si l'application déclare les métadonnées META_DATA_PANEL_ACTIVITY, elle DOIT transmettre le paramètre défini dans [3.8.16/H-1-5] à l'aide de EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS lors du lancement de l'activité intégrée.

À l'inverse, si les implémentations d'appareils portables n'implémentent pas de tels contrôles, elles :

[3.8.16/H-2-1] DOIT signaler null pour les API ControlsProviderService et Control.
[3.8.16/H-2-2] DOIT déclarer le flag de fonctionnalité android.software.controls et le définir sur false.

Si les implémentations d'appareils portables ne s'exécutent pas en mode tâches verrouillées, lorsque du contenu est copié dans le presse-papiers, il se produit les actions suivantes :

[3.8.17/H-1-1] DOIT présenter à l'utilisateur une confirmation que les données ont été copiées dans le presse-papiers (par exemple, une miniature ou une alerte "Contenu copié"). Indiquez également si les données du presse-papiers seront synchronisées sur les appareils.

Implémentations sur les appareils portables :

[3.10/H-0-1] DOIT être compatible avec les services d'accessibilité tiers.
[3.10/H-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), tels que ceux fournis dans le projet Open Source TalkBack.
[3.11/H-0-1] DOIT permettre l'installation de moteurs TTS tiers.
[3.11/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS prenant en charge les langues disponibles sur l'appareil.
[3.13/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un composant UI Paramètres rapides.

Si les implémentations d'appareils portables Android déclarent la compatibilité avec FEATURE_BLUETOOTH ou FEATURE_WIFI, elles :

[3.16/H-1-1] DOIT prendre en charge la fonctionnalité d'association d'appareils associés.

Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran :

Implémentations sur les appareils portables :

[3.20.1/H-0-1] DOIT implémenter toutes les exigences relatives au flux audio de l'Assistant.

[7.2.3/H] La zone de reconnaissance des gestes pour la fonction Accueil NE DOIT PAS dépasser 32 dp de hauteur à partir du bas de l'écran.

Si les implémentations d'appareils portables fournissent une fonction de navigation par geste à partir de n'importe quel point sur les bords gauche et droit de l'écran :

[7.2.3/H-0-1] La zone de gestes de la fonction de navigation DOIT avoir une largeur inférieure à 40 dp de chaque côté. La zone de geste DOIT avoir une largeur de 24 dp par défaut.

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé et disposent d'au moins 2 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles :

[3.9/H-1-2] DOIT déclarer la prise en charge des profils gérés via le flag de fonctionnalité android.software.managed_users.

Si les implémentations d'appareils portables Android déclarent la prise en charge de l'appareil photo via android.hardware.camera.any, elles :

[7.5.4/H-1-1] DOIT respecter l'intention android.media.action.STILL_IMAGE_CAMERA et android.media.action.STILL_IMAGE_CAMERA_SECURE, et lancer l'appareil photo en mode photo, comme décrit dans le SDK.
[7.5.4/H-1-2] DOIT respecter l'intention android.media.action.VIDEO_CAMERA de lancer l'appareil photo en mode vidéo, comme décrit dans le SDK.

Si l'application de paramètres de l'implémentation de l'appareil implémente une fonctionnalité de fractionnement à l'aide de l'intégration d'activités, elle :

[3.2.3.1/ H-1-1] DOIT disposer d'une activité qui gère l'intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY lorsque la fonctionnalité de fractionnement est activée. L'activité DOIT être protégée par android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK et DOIT démarrer l'activité de l'Intent analysé à partir de Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

Si les implémentations d'appareils permettent aux utilisateurs de passer des appels de quelque nature que ce soit, elles

[7.4.1.2/H-0-1] DOIT déclarer le flag de fonctionnalité android.software.telecom.

[7.4.1.2/H-0-2] DOIT implémenter le framework télécom.

2.2.4. Performances et puissance

[8.1/H-0-1] Latence d'image cohérente. Une latence d'image incohérente ou un retard dans l'affichage des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
[8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées de liste, comme défini par la suite de tests de compatibilité (CTS) Android, en moins de 36 s.
[8.1/H-0-3] Multitâche. Lorsqu'une application déjà en cours d'exécution est relancée après le lancement de plusieurs applications, cela DOIT prendre moins d'une seconde.

Implémentations sur les appareils portables :

[8.2/H-0-1] DOIT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s.
[8.2/H-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
[8.2/H-0-3] DOIT garantir une performance de lecture séquentielle d'au moins 15 Mo/s.
[8.2/H-0-4] DOIT garantir une performance de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations d'appareils portables incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles :

[8.3/H-1-1] DOIT fournir à l'utilisateur un moyen d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
[8.3/H-1-2] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Implémentations sur les appareils portables :

[8.4/H-0-1] DOIT fournir un profil de consommation d'énergie par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de la batterie approximative causée par les composants au fil du temps, comme indiqué sur le site du Projet Android Open Source.
[8.4/H-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
[8.4/H-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[8.4/H-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.
[8.4/H] DOIT être attribué au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

Si les implémentations d'appareils portables incluent un écran ou une sortie vidéo, elles :

[8.4/H-1-1] DOIT respecter l'intention android.intent.action.POWER_USAGE_SUMMARY et afficher un menu de paramètres indiquant cette consommation d'énergie.

Implémentations sur les appareils portables :

[8.5/H-0-1] DOIT fournir une affordance utilisateur permettant de voir toutes les applications avec des services de premier plan actifs ou des jobs initiés par l'utilisateur, y compris la durée de chacun de ces services depuis son démarrage, comme décrit dans la documentation du SDK.
[8.5/H-0-2]DOIT fournir une affordance utilisateur pour arrêter une application qui exécute un service de premier plan ou une tâche initiée par l'utilisateur.

2.2.5. Modèle de sécurité

Implémentations sur les appareils portables :

[9/H-0-1] DOIT déclarer la fonctionnalité android.hardware.security.model.compatible.
[9.1/H-0-1] DOIT autoriser les applications tierces à accéder aux statistiques d'utilisation via l'autorisation android.permission.PACKAGE_USAGE_STATS et fournir un mécanisme accessible aux utilisateurs pour accorder ou révoquer l'accès à ces applications en réponse à l'intention android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Si les implémentations d'appareils portables incluent une application par défaut pour prendre en charge VoiceInteractionService, elles doivent :

[9.1/H-0-2] NE DOIT PAS accorder ACCESS_FINE_LOCATION comme valeur par défaut pour cette application.

Les implémentations d'appareils DOIVENT déclarer la compatibilité avec android.software.credentials et :

[9/H-0-2] DOIT respecter l'intention android.settings.CREDENTIAL_PROVIDER pour permettre la sélection d'un fournisseur préféré pour le Gestionnaire d'identifiants. Ce fournisseur sera activé pour la saisie automatique et sera également l'emplacement par défaut pour enregistrer les nouvelles identifiants saisis via Credential Manager.
[9/H-0-3] DOIT prendre en charge au moins deux fournisseurs d'identifiants simultanés et fournir une option utilisateur dans l'application Paramètres pour activer ou désactiver les fournisseurs.
[9.5/H-1-1] Exigence supprimée dans Android 16.

Implémentations sur les appareils portables :

[9.11/H-0-2] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/H-0-3] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA-1 et SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[9.11/H-0-4] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/H-0-5] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Il est IMPÉRATIF d'empêcher l'utilisation des clés de signature d'attestation comme identifiants d'appareil permanents.

Remarque : Pour répondre à cette exigence, vous devez partager la même clé d'attestation pour un SKU donné,sauf si au moins 100 000 unités de ce SKU sont produites. Si plus de 100 000 unités de ce SKU sont produites, une clé différente PEUT être utilisée pour chaque groupe de 100 000 unités supplémentaires. Vous pouvez également utiliser la solution de provisionnement de clés à distance pour provisionner des clés d'attestation de courte durée sur l'appareil.

Notez que si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore soutenu par un environnement d'exécution isolé et de prendre en charge l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint qui nécessite un keystore soutenu par un environnement d'exécution isolé.

Lorsque les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé, elles :

[9.11/H-1-1] DOIT permettre à l'utilisateur de choisir le délai de mise en veille le plus court, c'est-à-dire un temps de transition de l'état déverrouillé à l'état verrouillé, de 15 secondes ou moins.
[9.11/H-1-2] DOIT permettre à l'utilisateur de masquer les notifications et de désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond à l'exigence en tant que mode Blocage.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui implémentent l'API système TrustAgentService, elles :

[9.11.1/H-1-1] DOIT demander à l'utilisateur de s'authentifier à l'aide de l'une des méthodes d'authentification principale recommandées (code, schéma ou mot de passe, par exemple) plus d'une fois toutes les 72 heures.

Si les implémentations d'appareils portables disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui appellent l'API système TrustAgentService.grantTrust() avec l'indicateur FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, elles :

[9.11.1/H-1-1] DOIT appeler TrustManagerService.revokeTrust() après l'une des méthodes suivantes :
- 24 heures maximum à compter de l'octroi de la délégation.
- Une période d'inactivité de huit heures.

Si les implémentations d'appareils portables incluent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony, elles :

[9.5/H-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils portables incluent plusieurs utilisateurs et déclarent le flag de fonctionnalité android.hardware.telephony, elles :

[9.5/H-3-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.
[9.5/H-4-1] Exigence supprimée dans Android 16.
[9.5/H-4-2] Exigence supprimée dans Android 16.

Paramètres restreints

Les paramètres restreints affichent des avertissements visibles par l'utilisateur et lui demandent de confirmer pour accorder des autorisations à chaque application qui :

Installée après avoir été téléchargée via une application (par exemple, une application de messagerie ou un navigateur) autre qu'une application "plate-forme de téléchargement d'applications" identifiée par PackageManager comme PACKAGE_DOWNLOADED_FILE.
L'application est installée à partir d'un fichier local (par exemple, elle a été installée en mode sideload) identifié par PackageManager comme PACKAGE_SOURCE_LOCAL_FILE.

Pour toutes les autorisations appliquées et leurs identifiants associés listés dans [9.8/H-0-5] ci-dessous.

Ces applications sont désignées par le terme "Applications concernées" pour les exigences listées dans cette section.

Implémentations sur les appareils :

[9.8/H-0-1] DOIT implémenter les paramètres restreints décrits ci-dessus pour les éléments suivants :
- Autorisations spéciales
  - Accessibilité (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - Outil d'écoute des notifications (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - Applications d'administration de l'appareil (Manifest.permission.BIND_DEVICE_ADMIN)
  - Afficher au-dessus des autres applications (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - Accès aux données d'utilisation (AppOpsManager.OPSTR_GET_USAGE_STATS)
- Rôles (applications par défaut)
  - Téléphone (RoleManager.ROLE_DIALER)
  - SMS (RoleManager.ROLE_SMS)
- Autorisations d'exécution
  - Durée d'exécution du SMS (Manifest.permission_group.SMS)
[9.8/H-0-2] Il est IMPÉRATIF d'activer les paramètres restreints par défaut et il est FORTEMENT RECOMMANDÉ de ne pas permettre aux utilisateurs de désactiver les paramètres restreints pour toutes les applications.
[9.8/H-0-3] DOIT s'assurer d'obtenir la confirmation de l'utilisateur pour chaque Application concernée avant que l'une des Autorisations obligatoires puisse être accordée.
[9.8/H-0-4] DOIT uniquement autoriser l'obtention de la confirmation de l'utilisateur pour activer les paramètres restreints à partir de la page AppInfo de l'application concernée, à l'aide de l'API EnhancedConfirmationManager.
[9.8/H-0-5] Il est FORTEMENT RECOMMANDÉ d'intégrer et d'appeler EnhancedConfirmationManager pour toutes les autorisations spéciales, afin de déterminer de manière dynamique s'il s'agit d'un paramètre restreint.
- Alarmes et rappels : AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- Accès à tous les fichiers : AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- Superposer aux autres applis : AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- Installer des applications inconnues : AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- Gérer les contenus multimédias : AppOpsManager.OPSTR_MANAGE_MEDIA
- Modifier les paramètres système : AppOpsManager.OPSTR_WRITE_SETTINGS
- Picture-in-picture : AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- Activer l'écran : AppOpsManager.OPSTR_TURN_SCREEN_ON
- Notifications en plein écran : AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- Contrôle Wi-Fi : AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- Accessibilité : AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- Outil d'écoute des notifications : AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- Accès aux données d'utilisation : AppOpsManager.OPSTR_GET_USAGE_STATS
- Administrateur de l'appareil : Manifest.permission.BIND_DEVICE_ADMIN
- Ne pas déranger : Manifest.permission.MANAGE_NOTIFICATIONS

Android, via l'API système VoiceInteractionService, prend en charge un mécanisme de détection de mots clés sécurisée et continue sans indication d'accès au micro, ainsi qu'une détection de requêtes continue sans indication d'accès au micro ni à la caméra.

Si les implémentations d'appareils portables sont compatibles avec l'API système HotwordDetectionService ou un autre mécanisme de détection de mot clé sans indication d'accès au micro, elles :

[9.8/H-1-1] DOIT s'assurer que le service de détection de mot clé ne peut transmettre des données qu'au système, à ContentCaptureService ou au service de reconnaissance vocale sur l'appareil créé par SpeechRecognizer#createOnDeviceSpeechRecognizer().
[9.8/H-1-2] DOIT s'assurer que le service de détection de mot clé ne peut transmettre des données audio du micro ou des données dérivées de celles-ci au serveur système que par le biais de l'API HotwordDetectionService ou à ContentCaptureService par le biais de l'API ContentCaptureManager.
[9.8/H-1-3] NE DOIT PAS fournir d'audio micro de plus de 30 secondes pour une requête individuelle déclenchée par le matériel au service de détection de mot clé.
[9.8/H-1-4] NE DOIT PAS fournir d'audio micro mis en mémoire tampon de plus de huit secondes pour une requête individuelle au service de détection de mot clé.
[9.8/H-1-5] NE DOIT PAS fournir à un service d'interaction vocale ou à une entité similaire un flux audio de micro mis en mémoire tampon datant de plus de 30 secondes.
[9.8/H-1-6] NE DOIT PAS autoriser la transmission de plus de 100 octets de données (à l'exclusion des flux audio) hors du service de détection de mot clé à chaque résultat de mot clé réussi.
[9.8/H-1-7] NE DOIT PAS autoriser la transmission de plus de 5 bits de données hors du service de détection de mot clé pour chaque résultat de mot clé négatif.
[9.8/H-1-8] DOIT autoriser la transmission de données hors du service de détection de mot clé uniquement sur une demande de validation de mot clé provenant du serveur système.
[9.8/H-1-9] NE DOIT PAS autoriser une application installable par l'utilisateur à fournir le service de détection de mot clé.
[9.8/H-1-10] NE DOIT PAS afficher dans l'UI des données quantitatives sur l'utilisation du micro par le service de détection de mot clé.
[9.8/H-1-11] DOIT enregistrer le nombre d'octets inclus dans chaque transmission du service de détection de mots clés pour permettre aux chercheurs en sécurité d'inspecter les données.
[9.8/H-1-12] DOIT être compatible avec un mode débogage qui enregistre le contenu brut de chaque transmission du service de détection de mots clés pour permettre aux chercheurs en sécurité de l'inspecter.
[9.8/H-1-14] DOIT afficher l'indicateur de micro, comme décrit dans la section 9.8.2, lorsqu'un résultat de mot clé réussi est transmis au service d'interaction vocale ou à une entité similaire.
[9.8/H-1-15] DOIT s'assurer que les flux audio fournis en cas de détection réussie du mot clé sont transmis de manière unidirectionnelle du service de détection du mot clé au service d'interaction vocale.
[9.8/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer les utilisateurs avant de définir une application comme fournisseur du service de détection de mots clés.
[9.8/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'interdire la transmission de données non structurées en dehors du service de détection de mot clé.
[9.8/H-SR-3] Il est FORTEMENT RECOMMANDÉ de redémarrer le processus hébergeant le service de détection de mot clé au moins une fois par heure ou toutes les 30 déclenchements matériels, selon la première échéance.

Si les implémentations d'appareils incluent une application qui utilise l'API System HotwordDetectionService ou un mécanisme similaire pour la détection de mots clés sans indication d'utilisation du micro, l'application :

[9.8/H-2-1] DOIT fournir une notification explicite à l'utilisateur pour chaque expression de mot clé prise en charge.
[9.8/H-2-2] NE DOIT PAS conserver les données audio brutes ni les données qui en sont dérivées via le service de détection de mot clé.
[9.8/H-2-3] NE DOIT PAS transmettre de données audio, de données pouvant être utilisées pour reconstruire (en tout ou en partie) l'audio ou de contenus audio sans rapport avec le mot clé lui-même à partir du service de détection de mot clé, sauf au service de reconnaissance vocale ContentCaptureService ou sur l'appareil.

Si les implémentations d'appareils portables sont compatibles avec l'API système VisualQueryDetectionService ou un autre mécanisme de détection des requêtes sans indication d'accès au micro et/ou à la caméra, elles :

[9.8/H-3-1] DOIT s'assurer que le service de détection des requêtes ne peut transmettre des données qu'au système, à ContentCaptureService ou au service de reconnaissance vocale sur l'appareil (créé par SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/H-3-2] NE DOIT PAS autoriser la transmission d'informations audio ou vidéo hors de VisualQueryDetectionService, sauf vers ContentCaptureService ou le service de reconnaissance vocale sur l'appareil.
[9.8/H-3-3] DOIT afficher un avis à l'utilisateur dans l'UI du système lorsque l'appareil détecte l'intention utilisateur d'interagir avec l'application d'assistant numérique (par exemple, en détectant la présence de l'utilisateur via la caméra).
[9.8/H-3-4] DOIT afficher un indicateur de micro et la requête utilisateur détectée dans l'UI immédiatement après la détection de la requête utilisateur.
[9.8/H-3-5] NE DOIT PAS autoriser une application installable par l'utilisateur à fournir le service de détection des requêtes visuelles.

Si les implémentations d'appareils portables déclarent android.hardware.microphone, elles :

[9.8.2/H-4-1] L'indicateur de micro DOIT s'afficher lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est utilisé que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou les applications détenant les rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X].
[9.8.2/H-4-2] DOIT afficher la liste des applications récentes et actives utilisant le micro, telle qu'elle est renvoyée par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.
[9.8.2/H-4-3] NE DOIT PAS masquer l'indicateur de micro pour les applications système qui ont des interfaces utilisateur visibles ou une interaction utilisateur directe.
[9.8.2/H-4-4] DOIT afficher la liste des applications récentes et actives utilisant le micro, telle qu'elle est renvoyée par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.

Si les implémentations d'appareils portables déclarent android.hardware.camera.any, elles :

[9.8.2/H-5-1] DOIT afficher l'indicateur d'accès à l'appareil photo lorsqu'une application accède à des données d'appareil photo en direct, mais pas lorsque l'appareil photo n'est accessible que par des applications détenant les rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X].
[9.8.2/H-5-2] DOIT afficher les applications récentes et actives utilisant l'appareil photo, telles que renvoyées par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.
[9.8.2/H-5-3] NE DOIT PAS masquer l'indicateur d'accès à l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction de l'utilisateur directe.

Lorsqu'une application au premier plan non système accède à la position exacte d'un appareil, l'appareil :

[9.8.8/H-6-1] DOIT afficher un indicateur visible par l'utilisateur.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations d'appareil sont compatibles avec la fonctionnalité, elles :

[9.10/H-1-1] DOIT vérifier toutes les partitions en lecture seule montées lors de la séquence de démarrage d'Android, et le résumé VBMeta DOIT inclure toutes ces partitions vérifiées dans son calcul.

2.2.6. Compatibilité des outils et options pour les développeurs

Implémentations pour les appareils portables (* non applicable aux tablettes) :

[6.1/H-0-1]* DOIT être compatible avec la commande shell cmd testharness.

Implémentations sur les appareils portables :

Perfetto
- [6.1/H-0-2] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
- [6.1/H-0-3] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/H-0-4] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/H-0-5] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.
- [6.1/H-0-6] Le daemon de trace perfetto DOIT être activé par défaut (propriété système persist.traced.enable).

Nous avons apporté d'importantes modifications à la structure des exigences de la classe "Performances média". À partir de l'API 37, nous avons ajouté les niveaux 1, 10, 20 et 37. Nous avons également réduit la complexité des exigences en nous référant à une page sur les mesures de la classe de performances média, qui détaille chaque exigence mesurée par niveau MPC.

2.2.7. Classe de performances multimédias pour les appareils portables

Consultez la section 7.11 pour obtenir la définition de la classe de performances média et la définition de la classe de performances média pour toutes les mesures.

2.2.7.1. Contenus multimédias

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

DOIT répondre à toutes les exigences multimédias listées dans la section 2.2.7.1 du CDD Android 17 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-1] DOIT indiquer le nombre maximal de sessions de décodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints() correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-2] DOIT être compatible avec les sessions de décodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure), les instances simultanées et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-3] DOIT indiquer le nombre maximal de sessions d'encodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints() correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-4] DOIT être compatible avec les sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure), les instances simultanées et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-5] DOIT indiquer le nombre maximal de sessions d'encodeur et de décodeur vidéo matériels simultanées dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints() correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-6] DOIT être compatible avec les sessions de décodeur et d'encodeur vidéo matériels (AVC, HEVC, VP9, AV1 ou version ultérieure), les instances simultanées et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-7] DOIT avoir une latence d'initialisation du codec pour une session d'encodage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels lorsque la charge correspond au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-8] DOIT avoir une latence d'initialisation du codec pour une session d'encodage audio à un débit de 128 kbit/s ou moins pour tous les encodeurs audio en cas de charge correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-9] DOIT prendre en charge deux instances de sessions de décodeur vidéo matériel sécurisé (AVC, HEVC, VP9, AV1 ou version ultérieure) et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-10] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel non sécurisées ainsi qu'une instance de session de décodeur vidéo matériel sécurisée (quatre instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure), les résolutions et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-11] DOIT être compatible avec un décodeur sécurisé pour chaque décodeur matériel AVC, HEVC, VP9 ou AV1 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-12] DOIT avoir une latence d'initialisation du codec pour une session de décodage vidéo 1080p ou inférieure pour tous les décodeurs vidéo matériels lorsque la charge correspond au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-13] DOIT avoir une latence d'initialisation du codec pour une session de décodage audio à 128 kbit/s ou à un débit inférieur pour tous les décodeurs audio en cas de charge correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-14] DOIT être compatible avec le profil, la fonctionnalité et la méthode d'affichage du décodeur matériel AV1 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-15] DOIT disposer d'au moins un décodeur vidéo matériel prenant en charge la résolution 4K60 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-16] DOIT disposer d'au moins un encodeur vidéo matériel prenant en charge la résolution 4K60 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-17] DOIT disposer d'au moins un décodeur d'image matériel prenant en charge le profil de référence AVIF correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-18] DOIT être compatible avec un encodeur AV1 qui répond aux exigences de débit binaire, de fréquence d'images par seconde et de résolution correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-19] DOIT prendre en charge trois instances de sessions de décodeur et d'encodeur vidéo matériel 10 bits (HDR) (AVC, HEVC, VP9, AV1 ou version ultérieure), la résolution et les pertes d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-20] DOIT être compatible avec la fonctionnalité Feature_HdrEditing pour tous les encodeurs matériels AV1 et HEVC présents sur l'appareil correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-21] DOIT être compatible avec FEATURE_DynamicColorAspect pour tous les décodeurs vidéo matériels (AVC, HEVC, VP9, AV1 ou version ultérieure) correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.1/H-1-22] DOIT être capable d'encoder, de décoder, de modifier avec le GPU et d'afficher du contenu vidéo au format portrait correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.2/H-2-1] Si l'implémentation de l'appareil est compatible avec les encodeurs matériels AVC ou HEVC, elle DOIT respecter la cible de qualité minimale définie par les courbes de débit-distorsion de l'encodeur vidéo pour ces codecs, correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

[5.2/H-2-2] DOIT être compatible avec MMAP sur le chemin du haut-parleur correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

[5.3/H-1-1] DOIT répondre aux exigences de performances des sessions vidéo et de perte d'images correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.3/H-1-2] DOIT répondre aux exigences de performances liées au changement de résolution vidéo correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-1-1] DOIT respecter les exigences de latence du tapotement au son correspondant à la classe de performances multimédias déclarée de l'appareil.
[5.6/H-1-2] DOIT respecter les exigences de latence audio aller-retour correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-1-3] DOIT répondre aux exigences audio de 24 bits correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-1-4] DOIT être compatible avec les appareils audio USB à au moins quatre canaux correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-1-5] DOIT être compatible avec les appareils MIDI conformes à la classe et déclarer le flag de fonctionnalité MIDI correspondant au niveau de classe de performance multimédia déclaré de l'appareil.
[5.6/H-1-9] DOIT prendre en charge au moins 12 mixages de canaux correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

[5.6/H-3-1] DOIT être capable de passer de la lecture d'ondes sinusoïdales sans sous-exécution des tampons audio correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-3-2] DOIT répondre aux exigences concernant les canaux de sortie des appareils audio USB correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.6/H-3-3] DOIT répondre aux exigences concernant les canaux d'entrée des appareils audio USB correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

[5.6/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mixage des canaux audio correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.7/H-1-2] DOIT être compatible avec MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL avec les capacités de déchiffrement correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.12/H-1-2] DOIT respecter les exigences relatives au format de couleur pour les encodeurs matériels AV1 et HEVC correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[5.12/H-1-3] DOIT annoncer la prise en charge de l'extension EXT_YUV_target correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.1.4/H-1-1] DOIT répondre aux exigences de l'unité de traitement de l'affichage (DPU) correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

2.2.7.2. Appareil photo

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

DOIT répondre aux exigences de l'appareil photo listées dans la section 2.2.7.2 du CDD Android 17 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[7.5/H-1-1] DOIT répondre aux exigences principales concernant la résolution de la caméra arrière et la capture vidéo correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-2] DOIT respecter les exigences principales concernant la résolution de la caméra frontale et la capture vidéo correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-3] DOIT être compatible avec les exigences de la propriété android.info.supportedHardwareLevel correspondant au niveau de classe de performance multimédia déclaré de l'appareil.
[7.5/H-1-4] DOIT être compatible avec CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les caméras principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-5] DOIT respecter les exigences de latence de capture JPEG de Camera2 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-6] DOIT respecter les exigences de latence de démarrage de camera2 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-8] DOIT répondre aux exigences de capture d'images RAW de l'appareil correspondant au niveau de classe de performances multimédias déclaré.
[7.5/H-1-9] DOIT répondre aux exigences de capture vidéo haute vitesse de la caméra principale orientée vers l'arrière correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-10] DOIT respecter les exigences minimales concernant le rapport de zoom correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-11] DOIT implémenter le streaming simultané avant/arrière sur les caméras principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-12] DOIT être compatible avec la stabilisation vidéo pour la caméra arrière principale correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-13] DOIT être compatible avec la fonctionnalité LOGICAL_MULTI_CAMERA pour la caméra arrière principale correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-14] DOIT prendre en charge la fonctionnalité STREAM_USE_CASE pour les caméras avant et arrière principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-15] DOIT prendre en charge les extensions du mode Nuit via les extensions CameraX et Camera2 pour les caméras principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-16] DOIT être compatible avec la fonctionnalité DYNAMIC_RANGE_TEN_BIT pour les caméras principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-17] DOIT être compatible avec les fonctionnalités de détection des visages pour les caméras principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-18] DOIT être compatible avec JPEG_R pour les caméras arrière et avant principales correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-19] DOIT être compatible avec CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION pour la caméra arrière principale correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.5/H-1-20] DOIT générer par défaut JPEG_R pour les caméras arrière et avant principales dans l'application d'appareil photo native correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

[7.5/H-1-21] DOIT disposer d'au moins une caméra frontale ou une caméra arrière correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

2.2.7.3. Matériel

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

DOIT répondre aux exigences matérielles listées dans la section 2.2.7.3 du CDD Android 17 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[7.1.1.1/H-1-1] Cet élément est intentionnellement ignoré.
[7.1.1.1/H-2-1] DOIT avoir une résolution d'écran correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.1.1.3/H-1-1] Cet élément est intentionnellement ignoré.
[7.1.1.3/H-2-1] DOIT avoir une densité d'écran correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.1.1.3/H-3-1] DOIT être compatible avec les exigences d'affichage HDR correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.6.1/H-1-1] Cet élément est intentionnellement ignoré.
[7.6.1/H-2-1] DOIT répondre aux exigences de mémoire correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

2.2.7.4. Performances

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

DOIT répondre aux exigences de performances listées dans la section 2.2.7.4 du CDD Android 17 correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[8.2/H-1-1] DOIT garantir des performances d'écriture séquentielle correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[8.2/H-1-2] DOIT garantir des performances d'écriture aléatoire correspondant au niveau de classe de performances du support déclaré de l'appareil.
[8.2/H-1-3] DOIT garantir des performances de lecture séquentielle correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[8.2/H-1-4] DOIT garantir des performances de lecture aléatoire correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[8.2/H-1-5] DOIT garantir des performances de lecture et d'écriture séquentielles parallèles correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

2.2.7.5. Graphiques

Si les implémentations d'appareils portables renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[7.1.4.1/H-1-2] DOIT être compatible avec les extensions EGL requises correspondant au niveau de classe de performances multimédias déclaré de l'appareil.
[7.1.4.1/H-1-3] DOIT être compatible avec les fonctionnalités Vulkan requises correspondant au niveau de classe de performances multimédias déclaré de l'appareil.

2.3. Exigences concernant le téléviseur

Un appareil Android TV désigne une implémentation d'appareil Android qui est une interface de divertissement permettant de consommer des contenus multimédias numériques, des films, des jeux, des applications et/ou la télévision en direct pour les utilisateurs assis à environ trois mètres (une "interface utilisateur inclinée" ou "à trois mètres").

Les implémentations d'appareils Android sont classées comme télévisions si elles répondent à tous les critères suivants :

Fournir un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur l'écran qui peut se trouver à trois mètres de l'utilisateur.
Disposer d'un écran intégré d'une diagonale supérieure à 24 pouces OU inclure un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android TV.

2.3.1. Matériel

Implémentations d'appareils de télévision :

[7.2.2/T-0-1] DOIT être compatible avec le pavé directionnel.
[7.2.3/T-0-1] DOIT fournir les fonctions Accueil et Retour.
[7.2.3/T-0-2] DOIT envoyer l'événement de pression normale et longue de la fonction Retour (KEYCODE_BACK) à l'application au premier plan.
[7.2.6.1/T-0-1] DOIT inclure la prise en charge des manettes de jeu et déclarer le flag de fonctionnalité android.hardware.gamepad.
[7.2.7/T] DOIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder aux entrées de navigation sans contact et aux touches de navigation principales.

Si les implémentations d'appareils de télévision incluent un gyroscope à trois axes, elles doivent :

[7.3.4/T-1-1] DOIT être capable de signaler des événements à une fréquence d'au moins 100 Hz.
[7.3.4/T-1-2] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Implémentations d'appareils de télévision :

[7.4.3/T-0-1] DOIT être compatible avec Bluetooth et Bluetooth LE.
[7.6.1/T-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (également appelée partition "/data").

Si les implémentations d'appareils de télévision incluent un port USB compatible avec le mode hôte, elles :

[7.5.3/T-1-1] DOIT inclure la prise en charge d'une caméra externe qui se connecte via ce port USB, mais qui n'est pas nécessairement toujours connectée.

Si les implémentations d'appareils TV sont en 32 bits :

[7.6.1/T-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands

Si les implémentations des appareils TV sont 64 bits :

[7.6.1/T-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands

Implémentations d'appareils de télévision :

[7.8.1/T] DOIT inclure un micro.
[7.8.2/T-0-1] DOIT disposer d'une sortie audio et déclarer android.hardware.audio.output.

2.3.2. Multimédia

Les implémentations sur téléviseur DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

[5.1/T-0-1] Profil MPEG-4 AAC (AAC LC)
[5.1/T-0-2] Profil MPEG-4 HE AAC (AAC+)
[5.1/T-0-3] AAC ELD (AAC à latence faible amélioré)

[5.1/T-0-4] MPEG-D USAC avec MPEG-D DRC (Extended High Efficiency AAC)

Les implémentations de téléviseurs DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.2/T-0-1] H.264
[5.2/T-0-2] VP8
[5.2/T-0-3] AV1

Implémentations d'appareils de télévision :

[5.2.2/T-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'encodage H.264 des vidéos en résolution 720p et 1080p à 30 images par seconde.

Les implémentations sur téléviseur DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.3.3/T-0-1] MPEG-4 SP
[5.3.4/T-0-2] H.264 AVC
[5.3.5/T-0-3] H.265 HEVC
[5.3.6/T-0-4] VP8
[5.3.7/T-0-5] VP9
[5.3.1/T-0-6] MPEG-2
[5.3.2/T-0-7] AV1

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage MPEG-2, comme indiqué dans la section 5.3.1, aux fréquences d'images et résolutions vidéo standards, y compris :

[5.3.1/T-1-1] HD 1080p à 29,97 images par seconde avec le profil principal de niveau élevé.
[5.3.1/T-1-2] HD 1080i à 59,94 images par seconde avec le profil principal de niveau élevé. Ils DOIVENT désentrelacer les vidéos MPEG-2 entrelacées et les mettre à la disposition des applications tierces.

Les implémentations sur téléviseur DOIVENT être compatibles avec le décodage H.264, comme indiqué dans la section 5.3.4, aux fréquences d'images et résolutions vidéo standards, y compris :

[5.3.4/T-1-1] HD 1080p à 60 images par seconde avec profil de référence
[5.3.4/T-1-2] HD 1080p à 60 images par seconde avec profil principal
[5.3.4/T-1-3] HD 1080p à 60 images par seconde avec profil High niveau 4.2

Les implémentations de téléviseurs avec des décodeurs matériels H.265 DOIVENT prendre en charge le décodage H.265, comme indiqué dans la section 5.3.5, à des fréquences d'images vidéo standard et des résolutions allant jusqu'à :

[5.3.5/T-1-1] HD 1080p à 60 images par seconde avec profil principal de niveau 4.1

Si les implémentations de téléviseurs avec des décodeurs matériels H.265 sont compatibles avec le décodage H.265 et le profil de décodage UHD, elles :

[5.3.5/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil Main10 de niveau 5 Main Tier

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage VP8, comme indiqué dans la section 5.3.6, aux fréquences d'images et résolutions vidéo standards, y compris :

[5.3.6/T-1-1] Profil de décodage HD 1080p à 60 images par seconde

Les implémentations de téléviseurs avec des décodeurs matériels VP9 DOIVENT prendre en charge le décodage VP9, comme indiqué dans la section 5.3.7, à des fréquences d'images vidéo et des résolutions standards jusqu'à :

[5.3.7/T-1-1] HD 1080p à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits)

Si les implémentations de téléviseurs avec des décodeurs matériels VP9 prennent en charge le décodage VP9 et le profil de décodage UHD, elles :

[5.3.7/T-2-1] DOIT être compatible avec le profil de décodage UHD à 60 images par seconde avec le profil 0 (profondeur de couleur de 8 bits).
[5.3.7/T-SR1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 2 (profondeur de couleur de 10 bits).

Implémentations d'appareils de télévision :

[5.5/T-0-1] DOIT inclure la prise en charge du volume principal du système et de l'atténuation du volume de la sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de transmission directe de l'audio compressé (où aucun décodage audio n'est effectué sur l'appareil).

Si les implémentations de téléviseurs ne disposent pas d'un écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles :

[5.8/T-0-1] DOIT définir le mode de sortie HDMI sur la résolution la plus élevée pour le format de pixels choisi qui fonctionne avec une fréquence de rafraîchissement de 50 Hz ou 60 Hz pour l'écran externe, en fonction de la fréquence de rafraîchissement vidéo pour la région dans laquelle l'appareil est vendu.
[5.8/T-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur.
[5.8] DOIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, selon la fréquence d'actualisation vidéo de la région dans laquelle l'appareil est vendu.

Si les implémentations de téléviseurs ne disposent pas d'un écran intégré, mais prennent en charge un écran externe connecté via HDMI, elles :

[5.8/T-1-1] DOIT être compatible avec HDCP 2.2.

Si les implémentations d'appareils de télévision ne sont pas compatibles avec le décodage UHD, mais qu'elles prennent en charge un écran externe connecté via HDMI, elles :

[5.8/T-2-1] DOIT être compatible avec HDCP 1.4

2.3.3. Logiciel

Implémentations d'appareils de télévision :

[3/T-0-1] DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television.
[3.2.3.1/T-0-1] DOIT précharger un ou plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
[3.4.1/T-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

Si les implémentations d'appareils Android TV sont compatibles avec un écran de verrouillage, elles doivent :

[3.8.10/T-1-1] DOIT afficher les notifications de l'écran de verrouillage, y compris le modèle de notification multimédia.

Implémentations d'appareils de télévision :

[3.8.14/T-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le mode multifenêtre Picture-in-picture (PIP).
[3.10/T-0-1] DOIT prendre en charge les services d'accessibilité tiers.
[3.10/T-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), tels que fournis dans le projet Open Source TalkBack.

Si les implémentations d'appareils de télévision signalent la fonctionnalité android.hardware.audio.output, elles :

[3.11/T-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS prenant en charge les langues disponibles sur l'appareil.
[3.11/T-1-1] DOIT permettre l'installation de moteurs TTS tiers.

Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenus en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV.

Implémentations d'appareils de télévision :

[3/T-0-2] DOIT déclarer la fonctionnalité de la plate-forme android.software.live_tv.
[3/T-0-3] DOIT être compatible avec toutes les API TIF afin qu'une application qui utilise ces API et le service d'entrées tierces basées sur TIF puisse être installée et utilisée sur l'appareil.

Le framework Android Television Tuner (TF) unifie la gestion du contenu en direct du tuner avec le contenu en streaming de l'adresse IP sur les appareils Android Television. Le framework Tuner fournit une API standard pour créer des services d'entrée qui utilisent le tuner TV Android.

Si les implémentations d'appareils sont compatibles avec Tuner, elles :

[3/T-1-1] DOIT être compatible avec toutes les API du framework Tuner afin qu'une application qui utilise ces API puisse être installée et utilisée sur l'appareil.

2.3.4. Performances et puissance

[8.1/T-0-1] Latence d'image cohérente. Une latence d'image incohérente ou un retard dans le rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
[8.2/T-0-1] DOIT garantir une performance d'écriture séquentielle d'au moins 5 Mo/s.
[8.2/T-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
[8.2/T-0-3] DOIT garantir une performance de lecture séquentielle d'au moins 15 Mo/s.
[8.2/T-0-4] DOIT garantir une performance de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations de téléviseurs incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles :

[8.3/T-1-1] DOIT permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

Si les implémentations d'appareils télévisuels ne sont pas équipées d'une batterie :

[8.3/T-1-2] DOIT enregistrer l'appareil comme appareil sans batterie, comme décrit dans Prise en charge des appareils sans batterie.

Si les implémentations d'appareils de télévision sont équipées d'une batterie, elles doivent :

[8.3/T-1-3] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Implémentations d'appareils de télévision :

[8.4/T-0-1] DOIT fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de la batterie approximative causée par les composants au fil du temps, comme indiqué sur le site du Projet Android Open Source.
[8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
[8.4/T-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[8.4/T] DOIT être attribué au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.
[8.4/T-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.

2.3.5. Modèle de sécurité

Implémentations d'appareils de télévision :

[9/T-0-1] DOIT déclarer la fonctionnalité android.hardware.security.model.compatible.

Si les implémentations d'appareils de télévision incluent une application par défaut pour prendre en charge VoiceInteractionService, elles doivent :

[9.1/T-0-1] NE DOIT PAS accorder ACCESS_FINE_LOCATION comme valeur par défaut pour cette application.

Implémentations d'appareils de télévision :

[9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/T-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA-1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée tierce d'une isolation appropriée basée sur un hyperviseur sont d'autres options.
[9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/T-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Il est IMPÉRATIF d'empêcher l'utilisation des clés de signature d'attestation comme identifiants d'appareil permanents.

Remarque : Pour répondre à cette exigence, vous devez partager la même clé d'attestation pour un SKU donné,sauf si au moins 100 000 unités de ce SKU sont produites. Si plus de 100 000 unités de ce SKU sont produites, une clé différente PEUT être utilisée pour chaque groupe de 100 000 unités supplémentaires. Vous pouvez également utiliser la solution de provisionnement de clés à distance pour provisionner des clés d'attestation de courte durée sur l'appareil.

Si les implémentations d'appareils de télévision sont compatibles avec un écran de verrouillage sécurisé, elles :

[9.11/T-1-1] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour le passage de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes ou moins.

Si les implémentations d'appareils de télévision incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/T-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils télévisuels incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/T-3-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

Si les implémentations d'appareils de télévision déclarent android.hardware.microphone, elles :

[9.8.2/T-4-1] DOIT afficher l'indicateur de micro lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est utilisé que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou les applications détenant les rôles mentionnés dans la section 9.1 Autorisations avec l'identifiant CDD C-3-X.
[9.8.2/T-4-2] NE DOIT PAS masquer l'indicateur de micro pour les applications système qui ont des interfaces utilisateur visibles ou une interaction de l'utilisateur directe.

Si les implémentations d'appareils de télévision déclarent android.hardware.camera.any, elles :

[9.8.2/T-5-1] DOIT afficher l'indicateur d'accès à l'appareil photo lorsqu'une application accède à des données de caméra en direct, mais pas lorsque la caméra n'est accessible que par des applications détenant les rôles mentionnés dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
[9.8.2/T-5-2] NE DOIT PAS masquer l'indicateur d'accès à l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction de l'utilisateur directe.

2.3.6. Compatibilité des outils et options pour les développeurs

Implémentations d'appareils de télévision :

Perfetto
- [6.1/T-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
- [6.1/T-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/T-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/T-0-4] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.
- [6.1/T-0-5] Le daemon de trace perfetto DOIT être activé par défaut (propriété système persist.traced.enable).

2.4. Configuration requise pour la montre

Un appareil Android Watch désigne une implémentation d'appareil Android destinée à être portée sur le corps, par exemple au poignet.

Les implémentations d'appareils Android sont classées comme montres si elles répondent à tous les critères suivants :

Disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
être doté d'un mécanisme permettant de le porter sur le corps ;

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations d'appareils Android Wear.

2.4.1. Matériel

Implémentations des appareils connectés :

[7.1.1.1/W-0-1] DOIT disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
[7.2.3/W-0-1] DOIT proposer à l'utilisateur la fonction Accueil et la fonction Retour, sauf lorsqu'il se trouve dans UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DOIT prendre en charge la saisie sur écran tactile.
[7.3.1/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à trois axes.

Si les implémentations d'appareils Wear incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, elles :

[7.3.3/W-1-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore indiquée.
[7.3.3/W-1-2] DOIT signaler les pseudo-distances et les taux de pseudo-distances GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, en étant immobile ou en se déplaçant avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95% du temps.

Si les implémentations d'appareils Watch incluent un gyroscope à trois axes, elles doivent :

[7.3.4/W-2-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Si les implémentations de l'appareil Watch sont compatibles avec la connectivité aux données mobiles, elles :

[7.4.1/W-1-1] DOIT déclarer la fonctionnalité android.hardware.telephony.data.

Implémentations des appareils connectés :

[7.4.3/W-0-1] DOIT être compatible avec le Bluetooth.
[7.6.1/W-0-1] DOIT disposer d'au moins 1 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").
[7.6.1/W-0-2] DOIT disposer d'au moins 416 Mo de mémoire disponible pour le noyau et l'espace utilisateur.
[7.8.1/W-0-1] DOIT inclure un micro.
[7.8.2/W] PEUT avoir une sortie audio.

2.4.2. Multimédia

Mêmes conditions.

2.4.3. Logiciel

Implémentations des appareils connectés :

[3/W-0-1] MUST declare the feature android.hardware.type.watch.
[3/W-0-2] MUST support uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] DOIT précharger un ou plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.

Implémentations des appareils connectés :

[3.8.4/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

Implémentations d'appareils connectés qui déclarent le flag de fonctionnalité android.hardware.audio.output :

[3.10/W-1-1] DOIT être compatible avec les services d'accessibilité tiers.
[3.10/W-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), tels que fournis dans le projet Open Source TalkBack.

Si les implémentations de l'appareil Watch signalent la fonctionnalité android.hardware.audio.output, elles :

[3.11/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS prenant en charge les langues disponibles sur l'appareil.
[3.11/W-0-1] DOIT permettre l'installation de moteurs TTS tiers.

2.4.4. Performances et puissance

Si les implémentations de l'appareil Watch incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles :

[8.3/W-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.
[8.3/W-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

Implémentations des appareils connectés :

[8.4/W-0-1] DOIT fournir un profil de puissance par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de la batterie approximative causée par les composants au fil du temps, comme indiqué sur le site du Projet Android Open Source.
[8.4/W-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
[8.4/W-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[8.4/W-0-4] DOIT rendre cette consommation d'énergie disponible pour le développeur d'applications via la commande shell adb shell dumpsys batterystats.
[8.4/W] DOIT être attribué au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

2.4.5. Modèle de sécurité

Implémentations des appareils connectés :

[9/W-0-1] Vous DEVEZ déclarer la fonctionnalité android.hardware.security.model.compatible.

Si les implémentations de l'appareil Watch incluent une application par défaut pour prendre en charge VoiceInteractionService, elles :

[9.1/W-0-1] NE DOIT PAS accorder ACCESS_FINE_LOCATION comme valeur par défaut pour cette application.

Si les implémentations d'appareils Wear OS incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/W-1-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations de l'appareil Wear incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/W-2-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui implémentent l'API système TrustAgentService, elles :

[9.11.1/W-1-1] DOIT demander à l'utilisateur d'utiliser l'une des méthodes d'authentification principale recommandées (code, schéma ou mot de passe, par exemple) plus d'une fois toutes les 72 heures au moins une fois toutes les 336 heures (14 jours) .

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui appellent l'API système TrustAgentService.grantTrust() avec l'indicateur FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE, elles :

[9.11.1/W-2-1] DOIT remplir les conditions suivantes pour appeler grantTrust() avec cet indicateur :
- L'appareil est connecté à un appareil portable principal physique à proximité, doté de son propre écran de verrouillage.
- L'utilisateur a authentifié son identité à l'aide de l'écran de verrouillage ou de la biométrie de classe 3 au cours des 30 dernières secondes.
[9.11.1/W-2-2] DOIT définir l'état de l'appareil sur TrustState.TRUSTABLE lorsque l'accessoire connecté n'est plus au poignet ou sur le corps et que TrustAgent n'a pas révoqué la confiance.

2.5. Exigences pour le secteur automobile

L'implémentation Android Automotive fait référence à une unité principale de véhicule exécutant Android comme système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'information et de divertissement.

Les implémentations d'appareils Android sont classées comme Automotive si elles déclarent la fonctionnalité android.hardware.type.automotive ou répondent à tous les critères suivants.

sont intégrés à un véhicule automobile ou peuvent y être branchés.
utilisent un écran situé au niveau du siège conducteur comme écran principal.

Les exigences supplémentaires décrites dans le reste de cette section sont spécifiques aux implémentations d'appareils Android Automotive.

2.5.1. Matériel

Implémentations d'appareils automobiles :

[7.1.1.1/A-0-1] DOIT disposer d'un écran d'au moins 6 pouces de diagonale physique.
[7.1.1.1/A-0-2] DOIT avoir une mise en page de taille d'écran d'au moins 750 dp x 480 dp.
[7.1.1.1/A-0-3] DOIT être compatible avec la composition GPU des tampons graphiques au moins aussi grands que la résolution la plus élevée de tout écran intégré.

Si les implémentations d'appareils automobiles sont compatibles avec le mode multi-utilisateur simultané (où plusieurs utilisateurs Android peuvent interagir avec l'appareil simultanément, chacun utilisant son propre écran lorsque config_multiuserVisibleBackgroundUsers est activé), elles :

[7.1.1.1/A-1-1] DOIT disposer d'un écran distinct d'au moins 6 pouces de diagonale physique pour chaque zone d'occupant de l'écran principal. Chaque zone d'occupant doit être taguée comme CarOccupantZoneManager.DISPLAY_TYPE_MAIN.
[7.1.1.1/A-1-2] DOIT avoir une mise en page de taille d'écran d'au moins 750 dp x 480 dp pour chaque écran principal.

Si les implémentations d'appareils automobiles sont compatibles avec OpenGL ES 3.1, elles :

[7.1.4.1/A-0-1] DOIT déclarer OpenGL ES 3.1 ou version ultérieure.
[7.1.4.1/A-0-2] DOIT être compatible avec Vulkan 1.1.
[7.1.4.1/A-0-3] DOIT inclure le chargeur Vulkan et exporter tous les symboles.

Si les implémentations d'appareils automobiles incluent la prise en charge de Vulkan, elles :

[7.1.4.2/A-1-1] DOIT répondre aux exigences spécifiées par le profil de référence Android 2021.

Si les implémentations d'appareils automobiles indiquent qu'elles sont compatibles avec les écrans à plage dynamique élevée via Configuration.isScreenHdr(), elles :

[7.1.4.5/A-1-1] DOIT indiquer la prise en charge des extensions EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace et VK_EXT_hdr_metadata.

Implémentations d'appareils automobiles :

[7.1.4.6/A-0-1] DOIT indiquer si l'appareil est compatible avec la fonctionnalité de profilage du GPU via une propriété système graphics.gpu.profiler.support.

Si les implémentations d'appareils automobiles déclarent la prise en charge via une propriété système graphics.gpu.profiler.support, elles :

[7.1.4.6/A-1-1] DOIT générer en sortie une trace protobuf conforme au schéma des compteurs GPU et des étapes de rendu GPU définis dans la documentation Perfetto.
[7.1.4.6/A-1-2] DOIT signaler des valeurs conformes pour les compteurs de GPU de l'appareil en suivant le proto de paquet gpu counter trace.
[7.1.4.6/A-1-3] DOIT signaler des valeurs conformes pour les RenderStages du GPU de l'appareil en suivant le proto de paquet de trace de la phase de rendu.
[7.1.4.6/A-1-4] DOIT signaler un point de trace de fréquence GPU, comme spécifié par le format suivant : power/gpu_frequency.

Implémentations d'appareils automobiles :

[7.1.5/A-0-1] DOIT inclure la prise en charge du mode de compatibilité des anciennes applications tel qu'il est implémenté par le code Open Source Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ni les seuils d'activation du mode de compatibilité, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.

Implémentations d'appareils automobiles :

[7.1.7/A-0-1] DOIT configurer les écrans secondaires dans le champ de vision du conducteur comme FLAG_PRIVATE.
[7.2.3/A-0-1] DOIT fournir la fonction Accueil et PEUT fournir les fonctions Retour et Récents.
[7.2.3/A-0-2] DOIT envoyer l'événement d'appui normal et long de la fonction Retour (KEYCODE_BACK) à l'application au premier plan.
[7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.
[7.3/A-0-2] La valeur du flag NIGHT_MODE DOIT être cohérente avec le mode Jour/Nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.
[7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires du capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
[7.3/A-SR1] PEUT calculer à l'estime la position en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est estimée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants utilisés.
[7.3/A-0-4] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être mise en correspondance avec la carte.
[7.3.1/A-0-4] DOIT être conforme au système de coordonnées des capteurs automobiles Android.
[7.3/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à trois axes et un gyroscope à trois axes.
[7.3/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_HEADING.

[7.3/A-1-1] DOIT définir la valeur du flag NIGHT_MODE de manière cohérente avec le mode Jour/Nuit du tableau de bord sur tous les écrans, y compris ceux des sièges arrière.

Si les implémentations d'appareils automobiles incluent un accéléromètre, elles :

[7.3.1/A-1-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.

Si les implémentations d'appareils incluent un accéléromètre 3 axes, elles :

[7.3.1/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite pour l'accéléromètre à axes limités.

Si les implémentations d'appareils automobiles incluent un accéléromètre avec moins de trois axes, elles :

[7.3.1/A-1-3] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES.
[7.3.1/A-1-4] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils automobiles incluent un gyroscope, elles :

[7.3.4/A-2-1] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
[7.3.4/A-2-3] DOIT être capable de mesurer les changements d'orientation jusqu'à 250 degrés par seconde.
[7.3.4/A-SR-1] Il est FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope sur +/-250 dps afin de maximiser la résolution possible.

Si les implémentations d'appareils automobiles incluent un gyroscope à trois axes, elles :

[7.3.4/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite pour le gyroscope à axes limités.

Si les implémentations d'appareils automobiles incluent un gyroscope avec moins de trois axes :

[7.3.4/A-4-1] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES.
[7.3.4/A-4-2] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils automobiles incluent un récepteur GPS/GNSS, mais n'incluent pas de connectivité de données basée sur un réseau mobile, elles :

[7.3.3/A-3-1] DOIT déterminer la position la toute première fois que le récepteur GPS/GNSS est allumé ou après quatre jours ou plus, dans un délai de 60 secondes.
[7.3.3/A-3-2] DOIT respecter les critères de délai avant première localisation décrits dans 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres demandes de localisation (c'est-à-dire les demandes qui ne sont pas la première fois ou après quatre jours ou plus). L'exigence 7.3.3/C-1-2 est généralement respectée dans les véhicules sans connectivité de données basée sur le réseau mobile, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule avec la capacité de navigation à l'estime pendant au moins 60 secondes avec une précision de position satisfaisant 7.3.3/C-1-3, ou une combinaison des deux.

Si les implémentations d'appareils automobiles incluent un capteur TYPE_HEADING, elles :

[7.3.4/A-4-3] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 1 Hz.
[7.3.4/A-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler les événements jusqu'à une fréquence d'au moins 10 Hz.
DOIT être défini par rapport au nord géographique.
DOIT être disponible même lorsque le véhicule est à l'arrêt.
DOIT avoir une résolution d'au moins 1 degré.

Implémentations d'appareils automobiles :

[7.4.3/A-0-1] DOIT être compatible avec le Bluetooth et DOIT ÊTRE compatible avec le Bluetooth LE.
[7.4.3/A-0-2] Les implémentations Android Automotive DOIVENT être compatibles avec les profils Bluetooth suivants :
- Appels téléphoniques via le profil mains libres (HFP).
- Lecture de contenus multimédias via le profil de distribution audio (A2DP).
- Contrôle de la lecture multimédia via le profil de télécommande (AVRCP).
- Partage de contacts à l'aide du profil d'accès à l'annuaire téléphonique (PBAP).
[7.4.3/A-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil d'accès aux messages (MAP) si l'appareil se trouve dans la zone du conducteur.

[7.4.3/A-1-1] DOIT être indépendant et NE DOIT PAS interférer avec l'expérience Bluetooth des autres utilisateurs.

Implémentations d'appareils automobiles :

[7.4.5/A] DOIT inclure la prise en charge de la connectivité des données basée sur le réseau mobile.
[7.4.5/A] PEUT utiliser la constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID de l'API System pour les réseaux qui doivent être disponibles pour les applications système.

Si les implémentations d'appareils incluent la prise en charge de la radio AM/FM et exposent la fonctionnalité à une application, elles :

[7.4/A-1-1] DOIT déclarer la compatibilité avec FEATURE_BROADCAST_RADIO.

Une caméra orientée vers l'arrière est une caméra orientée vers le monde extérieur, qui peut être située n'importe où sur le véhicule et qui est orientée vers l'extérieur de l'habitacle. Elle filme des scènes situées à l'arrière du véhicule, comme la caméra de recul.

Une caméra frontale désigne une caméra orientée vers l'utilisateur, qui peut être située n'importe où dans le véhicule et qui est orientée vers l'intérieur de l'habitacle. Elle filme l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Implémentations d'appareils automobiles :

[7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure une ou plusieurs caméras orientées vers l'extérieur.
PEUT inclure une ou plusieurs caméras orientées vers l'utilisateur.
[7.5/A-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge la diffusion simultanée du flux de plusieurs caméras.

Si les implémentations d'appareils automobiles incluent au moins une caméra orientée vers l'extérieur, alors, pour cette caméra, elles :

[7.5/A-1-1] DOIT être orienté de sorte que la dimension longue de la caméra soit alignée sur le plan X-Y des axes des capteurs Android Automotive.
[7.5/A-SR-3] Il est FORTEMENT RECOMMANDÉ d'utiliser du matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
[7.5/A-1-2] DOIT avoir la caméra principale orientée vers l'extérieur comme caméra orientée vers l'extérieur avec l'ID de caméra le plus bas.

Si les implémentations d'appareils automobiles incluent au moins une caméra orientée vers l'utilisateur, alors pour cette caméra :

[7.5/A-2-1] La caméra principale visible par l'utilisateur DOIT être la caméra orientée vers l'utilisateur avec l'ID de caméra le plus bas.
PEUT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo au plan X-Y des axes des capteurs automobiles Android.

Si les implémentations d'appareils automobiles incluent une caméra accessible via l'API android.hardware.Camera ou android.hardware.camera2, elles :

[7.5/A-3-1] DOIT respecter les exigences de base de l'appareil photo de la section 7.5.

Si les implémentations d'appareils automobiles incluent une caméra qui n'est pas accessible via les API android.hardware.Camera ou android.hardware.camera2, elles doivent :

[7.5/A-4-1] DOIT être accessible via le service système Extended View System.

Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras accessibles via le service Extended View System, pour une telle caméra, elles :

[7.5/A-5-1] NE DOIT PAS faire pivoter ni inverser horizontalement l'aperçu de la caméra.
[7.5/A-SR-4] Il est FORTEMENT RECOMMANDÉ que leur résolution soit d'au moins 1,3 mégapixel.

Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras accessibles à la fois via le service Extended View System et les API android.hardware.Camera ou android.hardware.Camera2, alors, pour une telle caméra, elles :

[7.5/A-6-1] DOIT indiquer le même ID de caméra.

Si les implémentations d'appareils automobiles fournissent une API d'appareil photo propriétaire, elles doivent :

[7.5/A-7-1] DOIT implémenter une telle API de caméras en utilisant l'API android.hardware.camera2 ou l'API Extended View System.

Implémentations d'appareils automobiles :

[7.6.1/A-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (partition /data).
[7.6.1/A] DOIT formater la partition de données pour améliorer les performances et la durée de vie du stockage flash (par exemple, en utilisant le système de fichiers f2fs).

Si les implémentations d'appareils automobiles fournissent un stockage externe partagé via une partie du stockage interne non amovible, elles :

[7.6.1/A-SR-1] Il est FORTEMENT RECOMMANDÉ de réduire la surcharge d'E/S sur les opérations effectuées sur le stockage externe, par exemple en utilisant SDCardFS.

[7.6.1/A-1-1] DOIT disposer, sur une seule instance AAOS, d'au moins 4 Go de stockage non volatile disponible pour les données privées des applications (partition /data) pour chaque utilisateur Android simultané.

Si les implémentations d'appareils automobiles sont en 64 bits :

[7.6.1/A-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo par écran principal si l'une des densités suivantes est utilisée :
- 280 dpi ou moins sur les écrans de petite ou moyenne taille
- ldpi ou inférieur sur les écrans très grands
- mdpi ou inférieure sur les grands écrans
[7.6.1/A-2-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo par écran principal si l'une des densités suivantes est utilisée :
- xhdpi ou plus sur les écrans de petite ou moyenne taille
- hdpi ou résolution supérieure sur les grands écrans
- mdpi ou supérieur sur les écrans très grands
[7.6.1/A-2-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo par écran principal si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands
[7.6.1/A-2-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo par écran principal si l'une des densités suivantes est utilisée :
- 560 dpi ou plus sur les écrans de petite ou moyenne taille
- 400 dpi ou plus sur les grands écrans
- xhdpi ou plus sur les très grands écrans

Implémentations d'appareils automobiles :

[7.7.1/A] DOIT inclure un port USB compatible avec le mode périphérique.

Si les implémentations d'appareils automobiles incluent un port USB avec un contrôleur fonctionnant en mode périphérique, elles :

[7.7.1/A-1-1] DOIT implémenter l'API Android Open Accessory (AOA).

Si les implémentations de périphériques automobiles incluent un port USB compatible avec le mode hôte, elles :

[7.7.2/A-1-1] DOIT implémenter la classe audio USB décrite dans la documentation du SDK Android.

Implémentations d'appareils automobiles :

[7.8.1/A-0-1] DOIT inclure un micro.

Implémentations d'appareils automobiles :

[7.8.2/A-0-1] DOIT disposer d'une sortie audio et déclarer android.hardware.audio.output.

[7.8.2/A-1-1] DOIT disposer d'un périphérique de sortie audio pour chaque écran principal pour les systèmes multi-utilisateurs simultanés.
[7.8.2/A-1-2] DOIT disposer d'une zone audio du conducteur couvrant le haut-parleur global de l'habitacle. La zone passager avant peut partager la zone audio du conducteur ou avoir sa propre sortie audio.

Lorsque l'API AudioManager.getDevices() est appelée alors que le périphérique USB est connecté, elle :

[7.8.2.2/A-1-1] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ de type de terminal audio USB est 0x0302.
[7.8.2.2/A-1-2] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ du type de terminal audio USB est 0x0402.
[7.8.2.2/A-1-3] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ du type de terminal audio USB est 0x0603.
[7.8.2.2/A-1-4] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et de rôle isSink() si le champ de type de terminal audio USB est 0x0400.

2.5.2. Multimédia

Les implémentations d'appareils automobiles DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

[5.1/A-0-1] Profil MPEG-4 AAC (AAC-LC)
[5.1/A-0-2] Profil MPEG-4 HE AAC (AAC+)
[5.1/A-0-3] AAC ELD (AAC à latence faible amélioré)

[5.1/A-0-4] MPEG-D USAC avec MPEG-D DRC (Extended High Efficiency AAC)

Les implémentations d'appareils automobiles DOIVENT être compatibles avec les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.2/A-0-1] H.264 AVC
[5.2/A-0-2] VP8

Les implémentations d'appareils automobiles DOIVENT être compatibles avec les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

[5.3/A-0-1] H.264 AVC
[5.3/A-0-2] MPEG-4 SP
[5.3/A-0-3] VP8
[5.3/A-0-4] VP9

Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils automobiles soient compatibles avec le décodage vidéo suivant :

[5.3/A-SR-1] H.265 HEVC

[5.5.3/A-1-1] DOIT définir des courbes de volume identiques pour tous les flux de sortie audio mappés sur le même groupe de volume que celui défini dans le fichier de configuration audio du véhicule.

2.5.3. Logiciel

Implémentations d'appareils automobiles :

[3/A-0-1] DOIT déclarer la fonctionnalité android.hardware.type.automotive.
[3/A-0-2] DOIT être compatible avec uiMode = UI_MODE_TYPE_CAR.
[3/A-0-3] DOIT être compatible avec toutes les API publiques dans l'espace de noms android.car.*.

Si les implémentations d'appareils automobiles fournissent une API propriétaire à l'aide de android.car.CarPropertyManager avec android.car.VehiclePropertyIds, elles :

[3/A-1-1] NE DOIT PAS accorder de privilèges spéciaux à l'utilisation de ces propriétés par l'application système, ni empêcher les applications tierces d'utiliser ces propriétés.
[3/A-1-2] NE DOIT PAS répliquer une propriété de véhicule qui existe déjà dans le SDK.

Implémentations d'appareils automobiles :

[3.2.1/A-0-1] DOIT prendre en charge et appliquer toutes les constantes d'autorisation telles que documentées sur la page de référence sur les autorisations automobiles.
[3.2.3.1/A-0-1] DOIT précharger un ou plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
[3.2.3.1/A-0-2] DOIT disposer d'une application qui gère les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, et ACTION_CREATE_DOCUMENT comme décrit dans la documentation du SDK, et fournir à l'utilisateur la possibilité d'accéder aux données du fournisseur de documents à l'aide de l'API DocumentsProvider.

Si l'application de paramètres d'implémentation de l'appareil automobile implémente une fonctionnalité de fractionnement à l'aide de l'intégration d'activités, elle :

[3.2.3.1/A-1-1] DOIT disposer d'une activité qui gère l'intent Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY lorsque la fonctionnalité de fractionnement est activée. L'activité DOIT être protégée par android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK et DOIT démarrer l'activité de l'Intent analysé à partir de Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.
[3.4.1/A-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

[3.8/A-1-1] DOIT implémenter la liste prédéfinie suivante de UserRestrictions pour les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel, mais qui ont accès à l'interface utilisateur de l'écran qui leur est attribué. La liste des UserRestrictions est la suivante : DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, et DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] NE DOIT PAS autoriser les utilisateurs secondaires complets qui ne sont pas l'utilisateur de premier plan actuel, mais qui ont accès à l'interface utilisateur de l'écran qui leur est attribué, à modifier le mode jour/nuit, les paramètres régionaux, la date, l'heure, le fuseau horaire ou les fonctionnalités de couleur de l'écran (y compris la luminosité, l'éclairage nocturne, le bien-être numérique en nuances de gris et la réduction des couleurs vives) pour tout autre utilisateur via les paramètres ou une API.

Implémentations d'appareils automobiles :

[3.8.3/A-0-1] DOIT afficher les notifications qui utilisent l'API Notification.CarExtender lorsque des applications tierces le demandent.
[3.8.4/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

Si les implémentations d'appareils automobiles incluent un bouton "appuyer pour parler", elles doivent :

[3.8.4/A-1-1] DOIT utiliser une pression courte sur le bouton "appuyer pour parler" comme interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService.

Implémentations d'appareils automobiles :

[3.8.3.1/A-0-1] DOIT afficher correctement les ressources comme décrit dans la documentation du SDK Notifications on Automotive OS.
[3.8.3.1/A-0-2] DOIT afficher les actions "LIRE" et "COUPER LE SON" pour les actions de notification à la place de celles fournies par Notification.Builder.addAction()
[3.8.3.1/A] DOIT restreindre l'utilisation de tâches de gestion avancées telles que les contrôles par canal de notification. PEUT utiliser une affordance d'UI par application pour réduire les contrôles.

Si les implémentations d'appareils automobiles sont compatibles avec les propriétés User HAL, elles :

[3.9.3/A-1-1] DOIT implémenter toutes les propriétés du cycle de vie de l'utilisateur : INITIAL_USER_INFO, SWITCH_USER, CREATE_USER et REMOVE_USER.

Implémentations d'appareils automobiles :

[3.14/A-0-1] DOIT inclure un framework d'UI pour prendre en charge les applications tierces utilisant les API Media, comme décrit dans la section 3.14.
[3.14/A-0-2] DOIT permettre à l'utilisateur d'interagir de manière sécurisée avec les applications multimédias pendant la conduite.
[3.14/A-0-3] DOIT prendre en charge l'action d'intent implicite CAR_INTENT_ACTION_MEDIA_TEMPLATE avec l'extra CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] DOIT fournir une affordance pour accéder à l'activité de préférences d'une application multimédia, mais NE DOIT l'activer que lorsque les restrictions liées à l'expérience utilisateur du véhicule ne sont pas en vigueur.
[3.14/A-0-5] DOIT afficher les messages d'erreur définis par les applications multimédias et DOIT prendre en charge les options supplémentaires ERROR_RESOLUTION_ACTION_LABEL et ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] DOIT proposer une fonctionnalité de recherche intégrée pour les applications qui prennent en charge la recherche.
[3.14/A-0-7] DOIT respecter les définitions de CONTENT_STYLE_BROWSABLE_HINT et CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de la hiérarchie MediaBrowser.

Implémentations d'appareils automobiles :

[3.14/A-0-8] Vous DEVEZ déclarer le flag de fonctionnalité android.software.car.templates_host.
[3.14/A-0-9] DOIT déclarer le flag de fonctionnalité com.android.car.background_audio_while_driving.
[3.14/A-0-10] Vous DEVEZ déclarer le flag de fonctionnalité android.software.car.templates_host.media.

Si les implémentations d'appareils automobiles incluent une application de lanceur d'applications par défaut, elles :

[3.14/A-1-1] DOIT inclure les services multimédias et les ouvrir avec l'intention CAR_INTENT_ACTION_MEDIA_TEMPLATE.

Implémentations d'appareils automobiles :

[3.8/A] PEUT limiter les requêtes de l'application pour passer en mode plein écran, comme décrit dans immersive documentation.
[3.8/A] PEUT garder la barre d'état et la barre de navigation visibles à tout moment.
[3.8/A] PEUT limiter les requêtes d'applications visant à modifier les couleurs derrière les éléments de l'UI système, afin de s'assurer que ces éléments sont clairement visibles à tout moment.

Implémentations d'appareils automobiles :

[7.1.1/A-0-1] DOIT déclarer le flag de fonctionnalité android.software.car.display_compatibility.

Lorsque vous exécutez des applications au premier plan avec la fonctionnalité android.software.car.display_compatibility ou des applications sans la fonctionnalité android.hardware.type.automotive, les appareils automobiles :

[7.1.1/A-1-1] DOIT fournir la fonction Retour.

Si les implémentations d'appareils automobiles permettent aux utilisateurs de passer des appels de tout type, elles :

[7.4.1.2/A-1-1] DOIT déclarer le flag de fonctionnalité android.software.telecom.

[7.4.1.2/A-1-2] DOIT implémenter le framework de télécommunications.

2.5.4. Performances et puissance

[8.1/A-0-1] Latence d'image cohérente. Une latence d'image incohérente ou un retard dans l'affichage des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
[8.1/A-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
[8.1/A-0-3] Multitâche. Lorsqu'une application déjà en cours d'exécution est relancée après le lancement de plusieurs applications, elle DOIT prendre moins d'une seconde.

Implémentations d'appareils automobiles :

[8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans le stockage non volatile pour chaque UID de processus afin que les statistiques soient disponibles pour les développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence grâce au module de noyau uid_sys_stats.
[8.2/A-0-2] DOIT garantir une performance d'écriture séquentielle d'au moins 5 Mo/s.
[8.2/A-0-3] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
[8.2/A-0-4] DOIT garantir une performance de lecture séquentielle d'au moins 15 Mo/s.
[8.2/A-0-5] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations d'appareils automobiles renvoient android.os.Build.VERSION_CODES.U ou une valeur supérieure pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[8.2/A-1-1] DOIT garantir une performance d'écriture séquentielle d'au moins 150 Mo/s.
[8.2/A-1-2] DOIT garantir une performance d'écriture aléatoire d'au moins 10 Mo/s.
[8.2/A-1-3] DOIT garantir des performances de lecture séquentielle d'au moins 250 Mo/s.
[8.2/A-1-4] DOIT garantir des performances de lecture aléatoire d'au moins 100 Mo/s.
[8.2/A-1-5] DOIT garantir des performances de lecture et d'écriture séquentielles parallèles avec des performances de lecture x2 et d'écriture x1 d'au moins 50 Mo/s.
[8.3/A-1-3] DOIT être compatible avec le mode Garage.
[8.3/A] DOIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf si :
- La batterie est déchargée.
- Aucun job inactif n'est planifié.
- Le conducteur quitte le mode Garage.
[8.4/A-0-1] DOIT fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de la batterie approximative causée par les composants au fil du temps, comme indiqué sur le site Projet Android Open Source.
[8.4/A-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
[8.4/A-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[8.4/A] DOIT être attribué au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.
[8.4/A-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

Si les implémentations d'appareils automobiles sont compatibles avec plusieurs utilisateurs, elles :

[9.5/A-1-1] NE DOIT PAS autoriser les utilisateurs à interagir avec l'utilisateur système sans interface graphique ni à passer à cet utilisateur, sauf pour la préparation de l'appareil.
[9.5/A-1-2] DOIT passer à un utilisateur secondaire avant BOOT_COMPLETED.
[9.5/A-1-3] DOIT permettre de créer un utilisateur invité même lorsque le nombre maximal d'utilisateurs sur un appareil a été atteint.

Si les implémentations d'appareils automobiles sont compatibles avec l'API système VisualQueryDetectionService ou un autre mécanisme de détection des requêtes sans indication d'accès au micro et/ou à la caméra, elles :

[9.8/A-1-1] DOIT s'assurer que le service de détection des requêtes ne peut transmettre des données qu'au système, ContentCaptureService ou au service de reconnaissance vocale sur l'appareil (créé par SpeechRecognizer#createOnDeviceSpeechRecognizer()).
[9.8/A-1-2] NE DOIT PAS autoriser la transmission d'informations audio ou vidéo hors du VisualQueryDetectionService, sauf à ContentCaptureService ou au service de reconnaissance vocale sur l'appareil.
[9.8/A-1-3] DOIT afficher une notification utilisateur dans l'UI du système lorsque l'appareil détecte l'intention utilisateur d'interagir avec l'application d'assistant numérique (par exemple, en détectant la présence de l'utilisateur via l'appareil photo).
[9.8/A-1-4] DOIT afficher un indicateur de micro et la requête utilisateur détectée dans l'UI immédiatement après la détection de la requête utilisateur.
[9.8/A-1-5] NE DOIT PAS autoriser une application installable par l'utilisateur à fournir le service de détection des requêtes visuelles.

Si les implémentations d'appareils automobiles déclarent android.hardware.microphone, elles :

[9.8.2/A-1-1] L'indicateur de micro DOIT s'afficher lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est utilisé que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou les applications détenant les rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X].
[9.8.2/A-1-2] NE DOIT PAS masquer l'indicateur de micro pour les applications système qui ont des interfaces utilisateur visibles ou une interaction de l'utilisateur directe.
[9.8.2/A-1-3] DOIT fournir une affordance utilisateur pour activer ou désactiver le micro dans l'application Paramètres.

Si les implémentations d'appareils automobiles déclarent android.hardware.camera.any, elles :

[9.8.2/A-2-1] DOIT afficher l'indicateur d'accès à l'appareil photo lorsqu'une application accède aux données de l'appareil photo en direct, mais pas lorsque l'appareil photo n'est accessible que par des applications détenant les rôles définis dans la section 9.1 Autorisations avec l'identifiant CDD [C-4-X].
[9.8.2/A-2-2] NE DOIT PAS masquer l'indicateur d'accès à l'appareil photo pour les applications système qui disposent d'interfaces utilisateur visibles ou d'une interaction de l'utilisateur directe.
[9.8.2/A-2-3] DOIT fournir une option permettant d'activer ou de désactiver la caméra dans l'application Paramètres.
[9.8.2/A-2-4] DOIT afficher les applications récentes et actives utilisant la caméra, telles que renvoyées par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.

Implémentations d'appareils automobiles :

[9/A-0-1] Vous DEVEZ déclarer la fonctionnalité android.hardware.security.model.compatible.
[9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/A-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA-1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[9.11/A-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/A-0-4] DOIT prendre en charge l'attestation des clés, où la clé de signature de l'attestation est protégée par un matériel sécurisé et la signature est effectuée dans un matériel sécurisé. Il est IMPÉRATIF d'empêcher l'utilisation des clés de signature d'attestation comme identifiants d'appareil permanents.

Remarque : Pour répondre à cette exigence, vous devez partager la même clé d'attestation pour un SKU donné,sauf si au moins 100 000 unités de ce SKU sont produites. Si plus de 100 000 unités de ce SKU sont produites, une clé différente PEUT être utilisée pour chaque groupe de 100 000 unités supplémentaires. Vous pouvez également utiliser la solution de provisionnement de clés à distance pour provisionner des clés d'attestation de courte durée sur l'appareil.

Implémentations d'appareils automobiles :

[9.14/A-0-1] DOIT contrôler l'accès aux messages provenant des sous-systèmes du véhicule du framework Android (par exemple, en autorisant les types et les sources de messages).
[9.14/A-0-2] DOIT surveiller les attaques par déni de service provenant du framework Android ou d'applications tierces. Cela permet de se prémunir contre les logiciels malveillants qui inondent le réseau du véhicule de trafic, ce qui peut entraîner un dysfonctionnement des sous-systèmes du véhicule.

2.5.6. Compatibilité des outils et options pour les développeurs

Implémentations d'appareils automobiles :

Perfetto
- [6.1/A-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
- [6.1/A-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/A-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
- [6.1/A-0-4] DOIT fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.
- [6.1/A-0-5] Le daemon de trace perfetto DOIT être activé par défaut (propriété système persist.traced.enable).

2.6. Exigences liées aux tablettes

Une tablette Android désigne une implémentation d'appareil Android qui répond généralement à tous les critères suivants :

Utilisé en le tenant à deux mains.
Ne dispose pas d'une configuration à clapet ou convertible.
Les claviers physiques utilisés avec l'appareil se connectent à l'aide d'une connexion standard (par exemple, USB ou Bluetooth).
Il est alimenté par une source d'énergie qui lui permet de se déplacer, comme une batterie.
La taille d'affichage de l'écran est comprise entre 7 et 18 pouces (mesure diagonale).

Les exigences relatives aux implémentations de tablettes sont similaires à celles des implémentations d'appareils portables. Les exceptions sont indiquées par un astérisque (*) dans cette section et sont mentionnées pour référence dans cette section.

2.6.1. Matériel

Gyroscope

Si les implémentations de tablettes incluent un gyroscope à trois axes, elles :

[7.3.4/Tab-1-1] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.

Mémoire et stockage minimum (section 7.6.1)

Les densités d'écran listées pour les petits écrans/écrans normaux dans les exigences relatives aux appareils portables ne s'appliquent pas aux tablettes.

Mode Réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences en matière de réalité virtuelle ne s'appliquent pas aux tablettes.

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

Si les implémentations de tablettes incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/T-1-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations de tablettes incluent plusieurs utilisateurs et déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

[9.5/T-2-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'empêcher d'autres utilisateurs d'accéder aux appels vocaux et aux SMS.

2.6.2. Logiciel

[3.2.3.1/Tab-0-1] DOIT précharger un ou plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.

3. Logiciel

3.1. Compatibilité des API gérées

L'environnement d'exécution de bytecode Dalvik géré est le principal véhicule pour les applications Android. L'interface de programmation d'application (API) Android est l'ensemble des interfaces de la plate-forme Android exposées aux applications s'exécutant dans l'environnement d'exécution géré.

Implémentations sur les appareils :

[C-0-1] DOIT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android ou toute API décorée avec le marqueur "@SystemApi" dans le code source Android en amont.
[C-0-2] DOIT prendre en charge/préserver toutes les classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).
[C-0-3] NE DOIT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure d'opérations sans effet, sauf si cela est spécifiquement autorisé par la présente Définition de compatibilité.
[C-0-4] DOIT toujours conserver les API et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.
[C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, qui sont définies comme des méthodes et des champs dans les packages de langage Java qui se trouvent dans le chemin de classe de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation @hide, mais pas avec @SystemAPI, comme décrit dans les documents du SDK, ainsi que les membres de classe privés et package-privés.
[C-0-6] DOIT être fourni avec chaque interface non SDK sur les mêmes listes restreintes que celles fournies par le biais des indicateurs provisoires et de la liste de refus dans le chemin d'accès prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche du niveau d'API approprié dans AOSP.
[C-0-7] DOIT être compatible avec le mécanisme de mise à jour dynamique de la configuration signée pour supprimer les interfaces non SDK d'une liste restreinte en intégrant une configuration signée dans n'importe quel APK, à l'aide des clés publiques existantes présentes dans AOSP.

Toutefois, ils :
- PEUT, si une API cachée est absente ou implémentée différemment sur l'implémentation de l'appareil, déplacer l'API cachée dans la liste de refus ou l'omettre de toutes les listes restreintes.
- MAI, si une API masquée n'existe pas déjà dans l'AOSP, ajoutez-la à l'une des listes restreintes.

[C-0-8] NE DOIT PAS permettre l'installation d'applications ciblant un niveau d'API inférieur à 24 26.

3.1.1. Extensions Android

Android permet d'étendre la surface d'API gérée d'un niveau d'API particulier en mettant à jour la version de l'extension pour ce niveau d'API. L'API android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) renvoie la version de l'extension du apiLevel fourni, s'il existe des extensions pour ce niveau d'API.

Implémentations sur les appareils Android :

[C-0-1] DOIT précharger l'implémentation AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, les implémentations d'appareils Android 7.0, exécutant le niveau d'API 24, DOIVENT inclure au moins la version 1.
[C-0-2] MUST only return valid extension version number that have been defined by the AOSP.
[C-0-3] DOIT être compatible avec toutes les API définies par les versions d'extension renvoyées par android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la même manière que les autres API gérées, conformément aux exigences de la section 3.1.

3.1.2. Bibliothèque Android

En raison de l'abandon du client HTTP Apache, les implémentations d'appareils :

[C-0-1] NE DOIT PAS placer la bibliothèque org.apache.http.legacy dans le bootclasspath.
[C-0-2] DOIT ajouter la bibliothèque org.apache.http.legacy au classpath de l'application uniquement lorsque l'application remplit l'une des conditions suivantes :
- Cible le niveau d'API 28 ou inférieur.
- Déclare dans son fichier manifeste qu'elle a besoin de la bibliothèque en définissant l'attribut android:name de <uses-library> sur org.apache.http.legacy.

L'implémentation AOSP répond à ces exigences.

3.2. Compatibilité logicielle avec les API

En plus des API gérées de la section 3.1, Android inclut également une API "logicielle" importante, uniquement au moment de l'exécution, sous la forme d'intents, d'autorisations et d'aspects similaires des applications Android qui ne peuvent pas être appliqués au moment de la compilation de l'application.

3.2.1. Autorisations

[C-0-1] Les implémenteurs d'appareils DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence sur les autorisations. Notez que la section 9 liste des exigences supplémentaires liées au modèle de sécurité Android.

3.2.2. Créer des paramètres

Les API Android incluent un certain nombre de constantes sur la classe android.os.Build qui sont destinées à décrire l'appareil actuel.

[C-0-1] Pour fournir des valeurs cohérentes et pertinentes dans les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils DOIVENT se conformer.

Paramètre	Détails
VERSION.RELEASE	Version du système Android en cours d'exécution, dans un format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans Chaînes de version autorisées pour Android 17.
VERSION.SDK	Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 17, ce champ DOIT avoir la valeur entière 17_INT.
VERSION.SDK&lowbar;INT	Version du système Android en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 17, ce champ DOIT avoir la valeur entière 17&lowbar;INT.
VERSION.INCREMENTAL	Valeur choisie par l'implémenteur de l'appareil désignant la version spécifique du système Android actuellement en cours d'exécution, dans un format lisible par l'utilisateur. Cette valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. A typical use of this field is to indicate which build number or source-control change identifier was used to generate the build. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits imprimable et correspondre à l'expression régulière `^[^ :\/~]+$`.
JEUX DE SOCIÉTÉ	Valeur choisie par l'implémenteur de l'appareil, qui identifie le matériel interne spécifique utilisé par l'appareil, dans un format lisible par l'humain. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte qui alimente l'appareil. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9_-]+$`.
MARQUE	Valeur reflétant le nom de la marque associée à l'appareil tel qu'il est connu des utilisateurs finaux. DOIT être au format lisible par un humain et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9_-]+$`.
ABI COMPATIBLES	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives.
ABIS 32 BITS PRIS EN CHARGE	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives.
ABI 64 BITS PRIS EN CHARGE	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API :
CPU&lowbar;ABI	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives.
CPU&lowbar;ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API :
APPAREIL	Valeur choisie par l'intégrateur de l'appareil, contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et le design industriel de l'appareil. La valeur de ce champ DOIT pouvoir être encodée au format ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9_-]+$`. Le nom de cet appareil ne DOIT PAS changer pendant toute la durée de vie du produit.
FINGERPRINT	Chaîne qui identifie ce build de manière unique. Il DOIT être raisonnablement lisible par l'humain. Il DOIT respecter le modèle suivant : $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemple : acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys L'empreinte digitale ne DOIT PAS inclure d'espaces. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits.
MATÉRIEL	Nom du matériel (à partir de la ligne de commande du noyau ou de /proc). Il DOIT être raisonnablement lisible par un humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9_-]+$`.
HOST	Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans un format lisible. Il n'y a aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID	Identifiant choisi par l'implémenteur de l'appareil pour faire référence à une version spécifique, dans un format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent faire la distinction entre les versions logicielles. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9._-]+$`.
FABRICANT	Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Il n'y a aucune exigence concernant le format spécifique de ce champ, si ce n'est qu'il NE DOIT PAS être nul ni la chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
SOC&lowbar;MANUFACTURER	Nom commercial du fabricant du système sur une puce (SOC) principal utilisé dans le produit. Les appareils ayant le même fabricant de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits, DOIT correspondre à l'expression régulière `^([0-9A-Za-z ]+)`, NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égale à "unknown". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
SOC&lowbar;MODEL	Nom du modèle du système sur une puce (SOC) principal utilisé dans le produit. Les appareils dotés du même modèle de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^([0-9A-Za-z ._/+-]+)$`. Elle NE DOIT PAS commencer ni se terminer par un espace, et NE DOIT PAS être égale à "unknown" (inconnu). Ce champ ne DOIT PAS changer pendant la durée de vie du produit.
MODEL	Valeur choisie par l'intégrateur de l'appareil, contenant le nom de l'appareil tel qu'il est connu de l'utilisateur final. Il DOIT s'agir du même nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'y a aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide (""). Il est FORTEMENT RECOMMANDÉ de ne pas modifier ce champ pendant la durée de vie du produit.
PRODUIT	Valeur choisie par l'intégrateur de l'appareil, contenant le nom de développement ou le nom de code du produit spécifique (SKU), qui DOIT être unique au sein de la même marque. DOIT être lisible par un humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9_-]+$`. Le nom de ce produit NE DOIT PAS changer pendant toute sa durée de vie.
ODM&lowbar;SKU	Valeur facultative choisie par l'implémenteur de l'appareil, qui contient le SKU (unité de gestion des stocks) utilisé pour suivre des configurations spécifiques de l'appareil, par exemple, les périphériques inclus avec l'appareil lors de la vente. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^([0-9A-Za-z.,_-]+)$`.
SERIAL	DOIT renvoyer "UNKNOWN".
TAGS	Liste de tags choisis par l'intégrateur de l'appareil, séparés par une virgule, qui distinguent davantage la compilation. Les tags DOIVENT être encodables en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9._-]+`. Ils DOIVENT également avoir l'une des valeurs correspondant aux trois configurations de signature de plate-forme Android typiques : release-keys, dev-keys et test-keys.
TIME	Valeur représentant le code temporel du moment où la compilation a eu lieu.
TYPE	Valeur choisie par l'implémenteur de l'appareil, qui spécifie la configuration d'exécution de la build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques : user, userdebug ou eng.
UTILISATEUR	Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré la compilation. Il n'y a aucune exigence concernant le format spécifique de ce champ, si ce n'est qu'il NE DOIT PAS être nul ni la chaîne vide ("").
SECURITY&lowbar;PATCH	Valeur indiquant le niveau du correctif de sécurité d'une version. Il DOIT indiquer que la version n'est en aucun cas vulnérable aux problèmes décrits dans le bulletin de sécurité public Android désigné. Elle DOIT être au format [AAAA-MM-JJ], correspondant à une chaîne définie documentée dans le bulletin de sécurité public Android ou dans l' avis de sécurité Android, par exemple "2015-11-01".
BASE&lowbar;OS	Valeur représentant le paramètre FINGERPRINT de la version qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin public sur la sécurité d'Android. Il DOIT indiquer la valeur correcte et, si une telle version n'existe pas, indiquer une chaîne vide ("").
BOOTLOADER	Valeur choisie par l'implémenteur de l'appareil, qui identifie la version spécifique du bootloader interne utilisée dans l'appareil, dans un format lisible par l'utilisateur. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9._-]+$`.
getRadioVersion()	DOIT (être ou renvoyer) une valeur choisie par l'implémenteur de l'appareil identifiant la version spécifique de la radio/du modem interne utilisée dans l'appareil, dans un format lisible par l'humain. Si un appareil ne dispose d'aucune radio/aucun modem interne, il DOIT renvoyer NULL. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9._-,]+$`.
getSerial()	DOIT être ou renvoyer un numéro de série matériel, qui DOIT être disponible et unique pour les appareils ayant le même MODÈLE et le même FABRICANT. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière `^[a-zA-Z0-9]+$`.
STRONGBOX&lowbar;MANUFACTURER	Nom commercial du fabricant de la puce StrongBox utilisée dans le produit. Le fournisseur StrongBox fournit la constante appropriée. Les appareils ayant le même fournisseur StrongBox doivent utiliser la même valeur constante. La valeur de ce champ DOIT correspondre à l'expression régulière `^([0-9A-Za-z ]+)` et NE DOIT PAS être égale à "unsupported" (non pris en charge). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
STRONGBOX&lowbar;MODEL	Nom du modèle de la puce StrongBox utilisée dans le produit. Le fournisseur StrongBox fournit la constante appropriée. Les appareils ayant le même fournisseur StrongBox DOIVENT utiliser la même valeur constante. La valeur de ce champ DOIT correspondre à l'expression régulière `^([0-9A-Za-z ._/+-]+)$` et NE DOIT PAS être égale à "unsupported". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.

3.2.3. Compatibilité des intentions

3.2.3.1. Intents d'application courants

Les intents Android permettent aux composants d'application de demander des fonctionnalités à d'autres composants Android. Le projet en amont Android inclut une liste d'applications qui implémentent plusieurs modèles d'intent pour effectuer des actions courantes.

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger un ou plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici, et de fournir un traitement, c'est-à-dire de répondre aux attentes des développeurs pour ces intents d'application courants, comme décrit dans le SDK.

Veuillez consulter la section 2 pour connaître les intents d'application obligatoires pour chaque type d'appareil.

3.2.3.2. Résolution des intents

[C-0-1] Android étant une plate-forme extensible, les implémentations d'appareils DOIVENT permettre aux applications tierces de remplacer chaque modèle d'intent référencé dans la section 3.2.3.1, à l'exception des paramètres. L'implémentation Open Source Android en amont l'autorise par défaut.
[C-0-2] Les implémenteurs d'appareils NE DOIVENT PAS attribuer de privilèges spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et d'en prendre le contrôle. Cette interdiction inclut, sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir entre plusieurs applications qui gèrent toutes le même modèle d'intent.
[C-0-3] Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.
Toutefois, les implémentations d'appareil PEUVENT fournir des activités par défaut pour des modèles d'URI spécifiques (par exemple, http://play.google.com) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un modèle de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le modèle d'intent principal du navigateur pour "http://".

Android inclut également un mécanisme permettant aux applications tierces de déclarer un comportement de lien d'application par défaut faisant autorité pour certains types d'intents d'URI Web. Lorsque de telles déclarations faisant autorité sont définies dans les modèles de filtre d'intent d'une application, les implémentations d'appareil :

[C-0-4] DOIT tenter de valider tous les filtres d'intent en effectuant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'implémentées par le gestionnaire de packages dans le projet Android Open Source en amont.
[C-0-5] DOIT tenter de valider les filtres d'intent lors de l'installation de l'application et définir tous les filtres d'intent d'URI validés comme gestionnaires d'application par défaut pour leurs URI.
PEUT définir des filtres d'intent d'URI spécifiques comme gestionnaires d'applications par défaut pour leurs URI, si la validation est réussie, mais que d'autres filtres d'URI candidats échouent. Si une implémentation d'appareil le fait, elle DOIT fournir à l'utilisateur des remplacements de modèle par URI appropriés dans le menu des paramètres.
Vous DEVEZ fournir à l'utilisateur des commandes de liens d'application par application dans les paramètres, comme suit :
- [C-0-6] L'utilisateur DOIT pouvoir remplacer globalement le comportement par défaut des liens d'application pour qu'une application soit : toujours ouverte, toujours demandée ou jamais ouverte, ce qui doit s'appliquer à tous les filtres d'intent URI candidats de manière égale.
- [C-0-7] L'utilisateur DOIT pouvoir consulter la liste des filtres d'intent URI candidats.
- L'implémentation de l'appareil PEUT permettre à l'utilisateur de remplacer des filtres d'intent URI candidats spécifiques qui ont été validés, filtre d'intent par filtre d'intent.
- [C-0-8] L'implémentation de l'appareil DOIT permettre aux utilisateurs d'afficher et de remplacer des filtres d'intent d'URI candidats spécifiques si l'implémentation de l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.

3.2.3.3. Espaces de noms d'intent

[C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion utilisant une ACTION, une CATEGORY ou une autre chaîne clé dans l'espace de noms android.* ou com.android.*.
[C-0-2] Les développeurs d'appareils NE DOIVENT PAS inclure de composants Android qui respectent de nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATÉGORIE ou d'une autre chaîne clé dans un espace de package appartenant à une autre organisation.
[C-0-3] Les développeurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles d'intent listés dans la section 3.2.3.1.
Les implémentations d'appareils PEUVENT inclure des modèles d'intent à l'aide d'espaces de noms clairement et évidemment associés à leur propre organisation. Cette interdiction est analogue à celle spécifiée pour les classes de langage Java dans la section 3.6.

3.2.3.4. Intents de diffusion

Les applications tierces s'appuient sur la plate-forme pour diffuser certaines intentions afin de les informer des modifications apportées à l'environnement matériel ou logiciel.

Implémentations sur les appareils :

[C-0-1] DOIT diffuser les intents de diffusion publique listés ici en réponse aux événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'est pas en conflit avec la section 3.5, car les limites pour les applications en arrière-plan sont également décrites dans la documentation du SDK. De plus, certaines intentions de diffusion sont conditionnées par la prise en charge matérielle. Si l'appareil prend en charge le matériel nécessaire, il DOIT diffuser les intentions et fournir le comportement conforme à la documentation du SDK.

3.2.3.5. Intents d'application conditionnels

Android inclut des paramètres qui permettent aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple pour l'écran d'accueil ou les SMS.

Lorsque cela est pertinent, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le modèle de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK, comme indiqué ci-dessous.

Si les implémentations d'appareils signalent android.software.home_screen, elles :

[C-1-1] DOIT respecter l'intention android.settings.HOME_SETTINGS d'afficher un menu de paramètres d'application par défaut pour l'écran d'accueil.

Si les implémentations d'appareils signalent android.hardware.telephony.calling, elles :

[C-2-1] DOIT fournir un menu de paramètres qui appellera l'intention android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.
[C-2-2] DOIT respecter l'intention android.telecom.action.CHANGE_DEFAULT_DIALER d'afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut.
- DOIT utiliser l'interface utilisateur de l'application Téléphone par défaut sélectionnée par l'utilisateur pour les appels entrants et sortants, à l'exception des appels d'urgence, qui doivent utiliser l'application Téléphone préinstallée.
[C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour permettre à l'utilisateur de configurer le ConnectionServices associé à PhoneAccounts, ainsi qu'un PhoneAccount par défaut que l'opérateur de télécommunications utilisera pour passer des appels sortants. L'implémentation AOSP répond à cette exigence en incluant un menu "Option de compte d'appel" dans le menu des paramètres "Appels".
[C-2-4] DOIT autoriser android.telecom.CallRedirectionService pour une application qui détient le rôle android.app.role.CALL_REDIRECTION.
[C-2-5] DOIT permettre à l'utilisateur de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.
[C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW, et fournir une activité pour envoyer/afficher des SMS.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'honorer les intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW et android.intent.action.DIAL avec une application de numérotation préchargée qui peut gérer ces intents et fournir l'exécution décrite dans le SDK.

Si les implémentations d'appareils signalent android.hardware.nfc.hce, elles :

[C-3-1] DOIT respecter l'intention android.settings.NFC_PAYMENT_SETTINGS pour afficher un menu de paramètres d'application par défaut pour le paiement sans contact.
[C-3-2] DOIT respecter l'intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT pour afficher une activité qui ouvre une boîte de dialogue demandant à l'utilisateur de modifier le service d'émulation de carte par défaut pour une catégorie donnée, comme décrit dans le SDK.

Si les implémentations d'appareils signalent android.hardware.nfc, elles :

[C-4-1] DOIT respecter les intents android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED et android.nfc.action.TECH_DISCOVERED pour afficher une activité qui répond aux attentes des développeurs concernant ces intents, comme décrit dans le SDK.

Si les implémentations d'appareils signalent android.hardware.bluetooth, elles :

[C-5-1] DOIT respecter l'intent 'android.bluetooth.adapter.action.REQUEST_ENABLE' et afficher une activité système pour permettre à l'utilisateur d'activer le Bluetooth.
[C-5-2] DOIT respecter l'intent 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' et afficher une activité système qui demande le mode détectable.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité Ne pas déranger, elles :

[C-6-1] DOIT implémenter une activité qui répond à l'intention ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, qui, pour les implémentations avec UI_MODE_TYPE_NORMAL, DOIT être une activité où l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de la politique Ne pas déranger.

Si les implémentations d'appareils permettent aux utilisateurs d'utiliser des méthodes de saisie tierces sur l'appareil, elles :

[C-7-1] DOIT fournir un mécanisme accessible aux utilisateurs pour ajouter et configurer des méthodes de saisie tierces en réponse à l'intention android.settings.INPUT_METHOD_SETTINGS.

Si les implémentations d'appareils sont compatibles avec les services d'accessibilité tiers, elles :

[C-8-1] DOIT respecter l'intention android.settings.ACCESSIBILITY_SETTINGS de fournir un mécanisme accessible aux utilisateurs pour activer et désactiver les services d'accessibilité tiers en plus des services d'accessibilité préchargés.

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Easy Connect et exposent la fonctionnalité aux applications tierces, elles :

[C-9-1] DOIT implémenter les API d'intent Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI comme décrit dans la documentation du SDK.

Si les implémentations d'appareils fournissent le mode Économiseur de données, elles :

[C-10-1] DOIT fournir une interface utilisateur dans les paramètres, qui gère l'intention Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permettant aux utilisateurs d'ajouter des applications à la liste d'autorisation ou d'en supprimer.

Si les implémentations d'appareils ne fournissent pas le mode Économiseur de données, elles :

[C-11-1] DOIT disposer d'une activité qui gère l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mais PEUT l'implémenter en tant que no-op.

Si les implémentations d'appareil déclarent la compatibilité avec la caméra via android.hardware.camera.any, elles :

[C-12-3] DOIT gérer et DOIT uniquement autoriser les applications Android préinstallées à gérer les intents suivants : MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE et MediaStore.ACTION_VIDEO_CAPTURE, comme décrit dans la documentation du SDK.

Si les implémentations d'appareils signalent android.software.device_admin, elles :

[C-13-1] DOIT respecter l'intention android.app.action.ADD_DEVICE_ADMIN d'appeler une UI pour guider l'utilisateur dans l'ajout de l'administrateur de l'appareil au système (ou lui permettre de le refuser).
[C-13-2] DOIT respecter les intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD et android.app.action.START_ENCRYPTION, et disposer d'une activité pour répondre à ces intents, comme décrit dans le SDK ici.

Si les implémentations d'appareil déclarent l'indicateur de fonctionnalité android.software.autofill, elles :

[C-14-1] DOIT implémenter entièrement les API AutofillService et AutofillManager, et respecter l'intent android.settings.REQUEST_SET_AUTOFILL_SERVICE pour afficher un menu de paramètres d'application par défaut permettant d'activer et de désactiver la saisie automatique, et de modifier le service de saisie automatique par défaut pour l'utilisateur.

Si les implémentations d'appareils incluent une application préinstallée ou souhaitent autoriser les applications tierces à accéder aux statistiques d'utilisation, elles :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir un mécanisme accessible aux utilisateurs pour accorder ou révoquer l'accès aux données d'utilisation en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS pour les applications qui déclarent l'autorisation android.permission.PACKAGE_USAGE_STATS.

Si les implémentations d'appareils ont l'intention d'interdire à des applications, y compris les applications préinstallées, d'accéder aux statistiques d'utilisation, elles doivent :

[C-15-1] DOIT toujours disposer d'une activité qui gère le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais DOIT l'implémenter en tant qu'opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès est refusé à l'utilisateur.

Si les implémentations d'appareils affichent des liens vers les activités spécifiées par AutofillService_passwordsActivity dans les paramètres ou des liens vers les mots de passe des utilisateurs par le biais d'un mécanisme similaire, elles :

[C-16-1] DOIT afficher ces liens pour tous les services de saisie automatique installés.

Si les implémentations d'appareil sont compatibles avec VoiceInteractionService et que plusieurs applications utilisant cette API sont installées en même temps, elles :

[C-18-1] DOIT respecter l'intention android.settings.ACTION_VOICE_INPUT_SETTINGS d'afficher un menu de paramètres d'application par défaut pour la saisie et l'assistance vocales.

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.audio.output, elles :

[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'honorer les intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et android.speech.tts.engine.GET_SAMPLE_TEXT en fournissant une activité pour répondre à ces intents, comme décrit dans le SDK ici.

Android est compatible avec les économiseurs d'écran interactifs, appelés auparavant "Rêves". Les économiseurs d'écran permettent aux utilisateurs d'interagir avec des applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou placé dans une station d'accueil. Implémentations de l'appareil :

DOIT inclure la prise en charge des économiseurs d'écran et fournir une option de paramètre permettant aux utilisateurs de configurer les économiseurs d'écran en réponse à l'intention android.settings.DREAM_SETTINGS.

Si les implémentations d'appareils signalent android.hardware.nfc.uicc ou android.hardware.nfc.ese, elles :

[C-19-1] DOIT implémenter l'API Intent NfcAdapter.ACTION_TRANSACTION_DETECTED (en tant que "EVT_TRANSACTION" définie par la spécification technique TS.26 de la GSM Association : exigences relatives aux téléphones NFC).

3.2.4. Activités sur des écrans secondaires/multiples

Si les implémentations d'appareils autorisent le lancement d'activités Android normales sur plusieurs écrans, elles :

[C-1-1] DOIT définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
[C-1-2] DOIT garantir la compatibilité de l'API de la même manière qu'une activité s'exécutant sur l'écran principal.
[C-1-3] DOIT lancer la nouvelle activité sur le même écran que l'activité qui l'a lancée, lorsque la nouvelle activité est lancée sans spécifier d'écran cible via l'API ActivityOptions.setLaunchDisplayId().
[C-1-4] DOIT détruire toutes les activités lorsqu'un affichage avec le flag Display.FLAG_PRIVATE est supprimé.
[C-1-5] DOIT masquer de manière sécurisée le contenu sur tous les écrans lorsque l'appareil est verrouillé avec un écran de verrouillage sécurisé, sauf si l'appli choisit d'afficher le contenu au-dessus de l'écran de verrouillage à l'aide de l'API Activity#setShowWhenLocked().
DOIT avoir android.content.res.Configuration qui correspond à cet affichage pour être affiché, fonctionner correctement et maintenir la compatibilité si une activité est lancée sur un écran secondaire.

Si les implémentations d'appareils autorisent le lancement d'activités Android normales sur des écrans secondaires et qu'un écran secondaire comporte l'indicateur android.view.Display.FLAG_PRIVATE :

[C-3-1] Seul le propriétaire de l'écran, du système et des activités déjà présentes sur cet écran DOIT pouvoir les lancer. Tout le monde peut lancer une application sur un écran doté du flag android.view.Display.FLAG_PUBLIC.

3.3. Compatibilité avec les API natives

La compatibilité du code natif est difficile. Pour cette raison, les responsables de l'implémentation des appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Android Open Source en amont.

3.3.1. Interfaces binaires d'application

Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier ELF .so compilé pour l'architecture matérielle de l'appareil approprié. Comme le code natif dépend fortement de la technologie du processeur sous-jacent, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android.

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec une ou plusieurs ABI NDK Android définies.
[C-0-2] DOIT inclure la prise en charge du code s'exécutant dans l'environnement géré pour appeler le code natif, en utilisant la sémantique standard de l'interface Java Native Interface (JNI).
[C-0-3] DOIT être compatible avec la source (c'est-à-dire compatible avec l'en-tête) et compatible avec le binaire (pour l'ABI) avec chaque bibliothèque requise dans la liste ci-dessous.
[C-0-5] DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparées par une virgule et classées de la plus à la moins préférée.
[C-0-6] DOIT signaler, à l'aide des paramètres ci-dessus, un sous-ensemble de la liste suivante d'ABI et NE DOIT PAS signaler d'ABI ne figurant pas dans la liste.
- armeabi (n'est plus compatible avec le NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
- riscv64
[C-0-7] DOIT rendre toutes les bibliothèques suivantes, qui fournissent des API natives, disponibles pour les applications qui incluent du code natif :
- libaaudio.so (compatibilité audio native AAudio)
- libamidi.so (compatibilité MIDI native, si la fonctionnalité android.software.midi est revendiquée comme décrit dans la section 5.9)
- libandroid.so (prise en charge des activités Android natives)
- libc (bibliothèque C)
- libcamera2ndk.so
- libdl (éditeur de liens dynamiques)
- libEGL.so (gestion native des surfaces OpenGL)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (journalisation Android)
- libmediandk.so (compatibilité avec les API multimédias natives)
- libm (bibliothèque mathématique)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
- libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (compatibilité minimale avec C++)
- libvulkan.so (Vulkan)
- libz (compression Zlib)
- Interface JNI
[C-0-8] NE DOIT PAS ajouter ni supprimer les fonctions publiques des bibliothèques natives listées ci-dessus.
[C-0-9] DOIT lister les bibliothèques non-AOSP supplémentaires exposées directement aux applications tierces dans /vendor/etc/public.libraries.txt.
[C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, aux applications tierces ciblant le niveau d'API 24 ou supérieur, car elles sont réservées.
[C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et du pack d'extensions Android, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que tous les symboles DOIVENT être présents, mais la section 7.1.4.1 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
[C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction Vulkan 1.1 de base, ainsi que les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via la bibliothèque libvulkan.so. Notez que tous les symboles DOIVENT être présents, mais la section 7.1.4.2 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Android Open Source en amont.

Notez que les futures versions d'Android pourront prendre en charge d'autres ABI.

3.3.2. Compatibilité du code natif ARM 32 bits

Si les implémentations d'appareil indiquent la compatibilité avec l'ABI armeabi, elles :

[C-3-1] DOIT également être compatible avec armeabi-v7a et signaler sa compatibilité, car armeabi n'est utilisé que pour la rétrocompatibilité avec les anciennes applications.

Si les implémentations d'appareil indiquent la compatibilité avec l'ABI armeabi-v7a, pour les applications utilisant cet ABI, elles :

[C-2-1] MUST include the following lines in /proc/cpuinfo, and SHOULD NOT alter the values on the same device, even when they are read by other ABIs.
- Features:, suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives compatibles avec l'appareil.
- CPU architecture:, suivi d'un entier décrivant l'architecture ARM la plus élevée prise en charge par l'appareil (par exemple, "8" pour les appareils ARMv8).
[C-2-2] DOIT toujours maintenir les opérations suivantes disponibles, même dans le cas où l'ABI est implémenté sur une architecture ARMv8, soit par le biais d'une prise en charge native du processeur, soit par le biais d'une émulation logicielle :
- Instructions SWP et SWPB.
- Fonctionnement des barrières CP15ISB, CP15DSB et CP15DMB.
[C-2-3] DOIT inclure la prise en charge de l'extension Advanced SIMD (alias NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

Si les implémentations d'appareil fournissent une implémentation complète de l'API android.webkit.Webview, elles :

[C-1-1] DOIT signaler android.software.webview.
[C-1-2] DOIT utiliser la compilation du projet Chromium à partir du projet Android Open Source en amont sur la branche Android 17 pour l'implémentation de l'API android.webkit.WebView.
[C-1-3] La chaîne de l'agent utilisateur signalée par WebView pour les applications ciblant le niveau SDK 35 et les niveaux inférieurs DOIT être au format suivant :

Mozilla/5.0 (Linux; Android $(VERSION); \[$(MODEL)\] \[Build/$(BUILD)\]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- La valeur de la chaîne $(VERSION) DOIT être identique à celle de android.os.Build.VERSION.RELEASE.
- La chaîne $(MODEL) PEUT être vide, mais si elle ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
- "Build/$(BUILD)" PEUT être omis, mais si la chaîne $(BUILD) est présente, elle DOIT être identique à la valeur de android.os.Build.ID.
- La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Android Open Source en amont.
- Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.
Le composant WebView DOIT inclure la prise en charge du plus grand nombre possible de fonctionnalités HTML5 et, s'il prend en charge la fonctionnalité, DOIT être conforme à la spécification HTML5.
[C-1-4] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter avec un ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès réseau direct et n'avoir accès qu'aux services système requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

[C-1-5] La chaîne d'agent utilisateur par défaut du système signalée par WebView pour les applications ciblant le niveau SDK 36 et supérieur DOIT être au format suivant :
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) DOIT être la valeur statique 10.
- $(MODEL) DOIT être la lettre statique K.
- $(CHROMIUM_MAJOR_VER) DOIT correspondre à la version majeure de Chromium dans le projet Android Open Source en amont.
- Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

Notez que si les implémentations d'appareils sont en 32 bits ou déclarent le flag de fonctionnalité android.hardware.ram.low, elles sont exemptées de la section C-1-3.

3.4.2. Compatibilité du navigateur

Si les implémentations d'appareils incluent une application de navigateur autonome pour la navigation Web générale, elles :

[C-1-1] DOIT être compatible avec chacune des API associées à HTML5 :
[C-1-2] DOIT être compatible avec l'API Web Storage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que, comme les organismes de normalisation du développement Web privilégient IndexedDB par rapport au stockage Web, IndexedDB devrait devenir un composant obligatoire dans une future version d'Android.
MAY ship a custom user agent string in the standalone Browser application.
DOIT implémenter la prise en charge d'une partie aussi importante que possible de HTML5 dans l'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers).

Toutefois, si les implémentations d'appareils n'incluent pas d'application de navigateur autonome, elles :

[C-2-1] DOIT toujours prendre en charge les schémas d'intent public, comme décrit dans la section 3.2.3.1.

3.5. Compatibilité comportementale de l'API

Implémentations sur les appareils :

[C-0-9] DOIT s'assurer que la compatibilité comportementale de l'API est appliquée à toutes les applications installées, sauf si elles sont restreintes comme décrit dans la Section 3.5.1.
[C-0-10] NE DOIT PAS implémenter l'approche de la liste d'autorisation qui assure la compatibilité comportementale de l'API uniquement pour les applications sélectionnées par les implémenteurs d'appareils.

Le comportement de chacun des types d'API (gérée, logicielle, native et Web) doit être cohérent avec l'implémentation préférée du Projet Android Open Source en amont. Voici quelques exemples précis de compatibilité :

[C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'une intention standard.
[C-0-2] Les appareils NE DOIVENT PAS modifier le cycle de vie ni la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
[C-0-3] Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
Les appareils NE DOIVENT PAS modifier les limites imposées aux applications en arrière-plan. Plus précisément, pour les applications en arrière-plan :
- [C-0-4] Ils DOIVENT arrêter d'exécuter les rappels enregistrés par l'application pour recevoir les sorties de GnssMeasurement et GnssNavigationMessage.
- [C-0-5] Ils DOIVENT limiter la fréquence des mises à jour fournies à l'application via la classe d'API LocationManager ou la méthode WifiManager.startScan().
- [C-0-6] Si l'application cible le niveau d'API 25 ou supérieur, elle NE DOIT PAS autoriser l'enregistrement de récepteurs de diffusion pour les diffusions implicites des intents Android standards dans le fichier manifeste de l'application, sauf si l'intent de diffusion nécessite une autorisation "signature" ou "signatureOrSystem" protectionLevel ou figure dans la liste des exceptions.
- [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT arrêter les services d'arrière-plan de l'application, comme si l'application avait appelé la méthode stopSelf() des services, sauf si l'application est placée sur une liste d'autorisation temporaire pour gérer une tâche visible par l'utilisateur.
- [C-0-8] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT libérer les wakelocks qu'elle détient.
[C-0-11] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants comme sept premières valeurs du tableau à partir de la méthode Security.getProviders(), dans l'ordre indiqué et avec les noms indiqués (tels que renvoyés par Provider.getName()) et les classes, sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Les appareils PEUVENT renvoyer des fournisseurs supplémentaires après la liste de fournisseurs spécifiée ci-dessous.
1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL – com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider – sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround – android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE : com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) teste des parties importantes de la plate-forme pour vérifier la compatibilité comportementale, mais pas toutes. Il incombe à l'implémenteur d'assurer la compatibilité comportementale avec le projet Android Open Source. Pour cette raison, les implémenteurs d'appareils DOIVENT utiliser le code source disponible via le projet Android Open Source dans la mesure du possible, plutôt que de réimplémenter des parties importantes du système.

3.5.1. Restriction d'une application

Si les implémentations d'appareils mettent en œuvre un mécanisme propriétaire pour restreindre les applications (par exemple, en modifiant ou en limitant les comportements d'API décrits dans le SDK) et que ce mécanisme est plus restrictif que le bucket de mise en veille des applications restreint, elles :

[C-1-1] DOIT permettre à l'utilisateur de voir la liste des applications restreintes.
[C-1-2] DOIT permettre à l'utilisateur d'activer / désactiver toutes ces restrictions propriétaires sur chaque application.
[C-1-3] NE DOIT PAS appliquer automatiquement ces restrictions propriétaires sans preuve d'un comportement de mauvaise santé du système, mais PEUT appliquer les restrictions aux applications en cas de détection d'un comportement de mauvaise santé du système, comme des wakelocks bloqués, des services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les implémenteurs d'appareils, mais DOIVENT être liés à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas purement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés comme critères.
[C-1-4] NE DOIT PAS appliquer automatiquement ces restrictions propriétaires pour les applications lorsqu'un utilisateur a désactivé manuellement les restrictions d'application, et PEUT suggérer à l'utilisateur d'appliquer ces restrictions propriétaires.
[C-1-5] DOIT informer les utilisateurs si ces restrictions propriétaires sont appliquées automatiquement à une application. Ces informations DOIVENT être fournies dans les 24 heures précédant l'application de ces restrictions propriétaires.
[C-1-6] DOIT renvoyer la valeur "true" pour la méthode ActivityManager.isBackgroundRestricted() pour tous les appels d'API provenant d'une application.
[C-1-7] NE DOIT PAS limiter l'application au premier plan supérieure explicitement utilisée par l'utilisateur.
[C-1-8] DOIT suspendre ces restrictions propriétaires sur une application chaque fois qu'un utilisateur commence à l'utiliser explicitement, ce qui en fait l'application de premier plan.
[C-1-10] DOIT fournir un document ou un site Web public et clair décrivant comment les restrictions de propriété sont appliquées. Ce document ou site Web DOIT être accessible depuis les documents du SDK Android et DOIT inclure :
- Conditions de déclenchement des restrictions propriétaires.
- Ce qui peut être restreint dans une application et comment.
- Comment une application peut être exemptée de ces restrictions.
- Comment une application peut demander une exemption des restrictions propriétaires, si elle prend en charge une telle exemption pour les applications que l'utilisateur peut installer.

Si une application est préinstallée sur l'appareil et n'a jamais été explicitement utilisée par un utilisateur pendant plus de 30 jours, les sections [C-1-3] et [C-1-5] ne s'appliquent pas.

Si les implémentations d'appareils étendent les restrictions d'application implémentées dans AOSP, elles :

[C-2-1]DOIT suivre l'implémentation décrite dans ce document.

3.5.2. Hibernation des applications

Si les implémentations d'appareils incluent l'hibernation d'applications qui est incluse dans AOSP ou qui étend la fonctionnalité incluse dans AOSP, elles doivent :

[C-1-1] DOIT répondre à toutes les exigences de la section 3.5.1, à l'exception de [C-1-6] et [C-1-3].
[C-1-2] L'application NE DOIT appliquer la restriction à un utilisateur que lorsqu'il est prouvé que l'utilisateur n'a pas utilisé l'application pendant une certaine période. Nous vous RECOMMANDONS FORTEMENT de définir une durée d'un mois ou plus. L'utilisation DOIT être définie par une interaction de l'utilisateur explicite via l'API UsageStats#getLastTimeVisible() ou par tout élément qui entraînerait la sortie d'une application de l'état d'arrêt forcé, y compris les liaisons de service, les liaisons de fournisseur de contenu, les diffusions explicites, etc., qui seront suivies par une nouvelle API UsageStats#getLastTimeAnyComponentUsed().
[C-1-3] DOIT appliquer des restrictions affectant tous les utilisateurs de l'appareil uniquement lorsqu'il est prouvé que le package n'a été utilisé par AUCUN utilisateur pendant une certaine période. Nous vous RECOMMANDONS FORTEMENT de choisir une durée d'un mois ou plus.
[C-1-4] NE DOIT PAS rendre l'application incapable de répondre aux intents d'activité, aux liaisons de service, aux requêtes de fournisseur de contenu ou aux diffusions explicites.

La mise en veille des applications dans AOSP répond aux exigences ci-dessus.

3.6. Espaces de noms de l'API

Android suit les conventions d'espace de noms de package et de classe définies par le langage de programmation Java. Pour assurer la compatibilité avec les applications tierces, les intégrateurs d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) à ces espaces de noms de package :

java.*
javax.*
sun.*
android.*
androidx.*
com.android.*

Autrement dit, ils :

[C-0-1] NE DOIT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthodes ou de classes, ou en supprimant des classes ou des champs de classe.
[C-0-2] NE DOIT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes à des classes ou interfaces existantes) ni d'API de test ou système aux API dans les espaces de noms ci-dessus. Un "élément exposé publiquement" est une construction qui n'est pas décorée avec le marqueur "@hide" tel qu'il est utilisé dans le code source Android en amont.

Les implémenteurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications :

[C-0-3] NE DOIT PAS avoir d'incidence sur le comportement indiqué ni sur la signature en langage Java des API exposées publiquement.
[C-0-4] NE DOIT PAS être annoncé ni exposé aux développeurs.

Toutefois, les développeurs d'appareils PEUVENT ajouter des API personnalisées en dehors de l'espace de noms Android standard, mais les API personnalisées :

[C-0-5] NE DOIT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à celle-ci. Par exemple, les responsables de l'implémentation d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou à un espace de noms similaire : seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises.
[C-0-6] DOIT être empaqueté dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-library>) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.

Les implémenteurs d'appareils PEUVENT ajouter des API personnalisées dans des langages natifs, en dehors des API NDK, mais les API personnalisées :

[C-1-1] NE DOIT PAS se trouver dans une bibliothèque NDK ni dans une bibliothèque appartenant à une autre organisation, comme décrit ici.

Si un intégrateur d'appareils propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT consulter source.android.com et commencer le processus de contribution de modifications et de code, conformément aux informations de ce site.

Notez que les restrictions ci-dessus correspondent aux conventions standards pour nommer les API dans le langage de programmation Java. Cette section vise simplement à renforcer ces conventions et à les rendre contraignantes en les incluant dans cette définition de compatibilité.

3.7. Compatibilité de l'environnement d'exécution

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le format Dalvik Executable (DEX) complet et avec les spécifications et la sémantique du bytecode Dalvik.
[C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Consultez la section 7.1.1 pour obtenir les définitions de la taille et de la densité de l'écran.)
DOIT utiliser Android RunTime (ART), l'implémentation en amont de référence du format Dalvik Executable et le système de gestion de packages de l'implémentation de référence.
DOIT exécuter des tests de fuzzing dans différents modes d'exécution et architectures cibles pour assurer la stabilité du runtime. Consultez JFuzz et DexFuzz sur le site Web du projet Android Open Source.

Notez que les valeurs de mémoire spécifiées ci-dessous sont considérées comme des valeurs minimales et que les implémentations d'appareils PEUVENT allouer plus de mémoire par application.

Disposition de l'écran	Densité d'écran	Mémoire minimale de l'application
Montre Android	120 PPP (ldpi)	32 Mo
	140 dpi (140 ppp)
	160 ppp (mdpi)
	180 dpi (180 ppp)
	200 dpi (200 dpi)
	213 ppp (tvdpi)
	220 dpi (220 dpi)	36 Mo
	240 dpi (hdpi)
	280 dpi (280 dpi)
	320 ppp (xhdpi)	48 Mo
	360 dpi (360 ppp)	48 Mo
	400 PPP (400dpi)	56 Mo
	420 ppp (420dpi)	64 Mo
	480 dpi (xxhdpi)	88 Mo
	560 dpi (560 PPP)	112 Mo
	640 dpi (xxxhdpi)	154 Mo
petite/normale	120 PPP (ldpi)	32 Mo
	140 dpi (140 ppp)
	160 ppp (mdpi)
	180 dpi (180 ppp)	48 Mo
	200 dpi (200 dpi)
	213 ppp (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)
	320 ppp (xhdpi)	80 Mo
	360 dpi (360 ppp)	80 Mo
	400 PPP (400dpi)	96 Mo
	420 ppp (420dpi)	112 Mo
	480 dpi (xxhdpi)	128 Mo
	560 dpi (560 PPP)	192 Mo
	640 dpi (xxxhdpi)	256 Mo
grande	120 PPP (ldpi)	32 Mo
	140 dpi (140 ppp)	48 Mo
	160 ppp (mdpi)	48 Mo
	180 dpi (180 ppp)	80 Mo
	200 dpi (200 dpi)
	213 ppp (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)	96 Mo
	320 ppp (xhdpi)	128 Mo
	360 dpi (360 ppp)	160 Mo
	400 PPP (400dpi)	192 Mo
	420 ppp (420dpi)	228 Mo
	480 dpi (xxhdpi)	256 Mo
	560 dpi (560 PPP)	384 Mo
	640 dpi (xxxhdpi)	512 Mo
xlarge	120 PPP (ldpi)	48 Mo
	140 dpi (140 ppp)	80 Mo
	160 ppp (mdpi)	80 Mo
	180 dpi (180 ppp)	96 Mo
	200 dpi (200 dpi)
	213 ppp (tvdpi)
	220 dpi (220 dpi)
	240 dpi (hdpi)
	280 dpi (280 dpi)	144 Mo
	320 ppp (xhdpi)	192 Mo
	360 dpi (360 ppp)	240 Mo
	400 PPP (400dpi)	288 Mo
	420 ppp (420dpi)	336 Mo
	480 dpi (xxhdpi)	384 Mo
	560 dpi (560 PPP)	576 Mo
	640 dpi (xxxhdpi)	768 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur d'applications (écran d'accueil)

Android inclut une application de lanceur d'applications (écran d'accueil) et permet aux applications tierces de remplacer le lanceur d'applications de l'appareil (écran d'accueil).

Si les implémentations d'appareils autorisent les applications tierces à remplacer l'écran d'accueil de l'appareil, elles :

[C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.home_screen.
[C-1-2] DOIT renvoyer l'objet AdaptiveIconDrawable lorsque l'application tierce utilise la balise <adaptive-icon> pour fournir son icône et que les méthodes PackageManager permettant de récupérer les icônes sont appelées.

Si les implémentations d'appareils incluent un lanceur d'applications par défaut qui permet d'épingler des raccourcis dans les applications, elles :

[C-2-1] DOIT signaler true pour ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] DOIT demander à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode d'API ShortcutManager.requestPinShortcut().
[C-2-3] DOIT être compatible avec les raccourcis épinglés, ainsi qu'avec les raccourcis dynamiques et statiques, comme indiqué sur la page Raccourcis d'application.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec l'épinglage de raccourcis dans l'application, elles :

[C-3-1] MUST report false for ShortcutManager.isRequestPinShortcutSupported().

Si les implémentations d'appareils implémentent un lanceur d'applications par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager, elles :

[C-4-1] DOIT être compatible avec toutes les fonctionnalités de raccourci documentées (par exemple, les raccourcis statiques et dynamiques, l'épinglage de raccourcis) et implémenter entièrement les API de la classe d'API ShortcutManager.

Si les implémentations d'appareils incluent une application de lanceur par défaut qui affiche des badges pour les icônes d'application, elles :

[C-5-1] DOIT respecter la méthode d'API NotificationChannel.setShowBadge(). En d'autres termes, affichez une affordance visuelle associée à l'icône de l'application si la valeur est définie sur true, et n'affichez aucun système de badge d'icône d'application lorsque tous les canaux de notification de l'application ont défini la valeur sur false.
PEUT remplacer les badges d'icône d'application par son propre système de badges lorsque des applications tierces indiquent la prise en charge de ce système à l'aide d'API propriétaires, mais DOIT utiliser les ressources et les valeurs fournies par les API de badges de notification décrites dans le SDK, telles que les API Notification.Builder.setNumber() et Notification.Builder.setBadgeIconType().

Si les implémentations d'appareils sont compatibles avec les icônes monochromes, ces icônes :

[C-6-1] NE DOIVENT être utilisés que lorsqu'un utilisateur les active explicitement (par exemple, via le menu "Paramètres" ou le sélecteur de fond d'écran).

3.8.2. Widgets

Android prend en charge les widgets d'applications tierces en définissant un type de composant, ainsi que l'API et le cycle de vie correspondants, qui permettent aux applications d'exposer un AppWidget à l'utilisateur final.

Si les implémentations d'appareils sont compatibles avec les widgets d'applications tierces, elles :

[C-1-1] DOIT déclarer la compatibilité avec la fonctionnalité de plate-forme android.software.app_widgets.
[C-1-2] DOIT inclure une prise en charge intégrée des AppWidgets et exposer des affordances d'interface utilisateur pour ajouter, configurer, prévisualiser, supprimer, afficher et redimensionner les AppWidgets sauf si la sécurité de l'utilisateur (par exemple,la distraction du conducteur) est un problème.

[C-1-3] DOIT être capable d'afficher des widgets de taille 4x4 dans la taille de grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android.

[C-1-4] DOIT être compatible avec les aperçus de widgets générés de manière dynamique.
[C-1-5] DOIT permettre à l'utilisateur de confirmer l'ajout d'un widget demandé par les applications via AppWidgetManager.requestPinAppWidget().
[C-1-6] DOIT permettre l'épinglage des widgets dans l'application.
[C-1-7] DOIT signaler true pour AppWidgetManager.html.isRequestPinAppWidgetSupported().

MAY peut prendre en charge les widgets d'application sur l'écran de verrouillage.

Si les implémentations d'appareils sont compatibles avec les widgets d'applications tierces et l'épinglage de raccourcis dans les applications, elles :

[C-2-1] DOIT signaler true pour AppWidgetManager.html.isRequestPinAppWidgetSupported().
[C-2-2] DOIT demander à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode d'API AppWidgetManager.requestPinAppWidget().

3.8.3. Notifications

Android inclut les API Notification et NotificationManager qui permettent aux développeurs d'applications tierces d'informer les utilisateurs d'événements importants et d'attirer leur attention à l'aide des composants matériels (par exemple, le son, les vibrations et la lumière) et des fonctionnalités logicielles (par exemple, le volet des notifications et la barre système) de l'appareil.

3.8.3.1. Présentation des notifications

Si les implémentations d'appareils permettent aux applications tierces d'informer les utilisateurs d'événements importants, elles :

[C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK, et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil manque de matériel, les API correspondantes DOIVENT être implémentées en tant qu'opérations sans effet. Ce comportement est décrit plus en détail dans la section 7.
[C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, bien qu'il PUISSE fournir une expérience utilisateur alternative pour les notifications par rapport à celle fournie par l'implémentation Android Open Source de référence.
[C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API permettant de mettre à jour, de supprimer et de regrouper les notifications.
[C-1-4] DOIT fournir le comportement complet de l'API NotificationChannel documentée dans le SDK.
[C-1-5] DOIT fournir une fonctionnalité permettant à l'utilisateur de bloquer et de modifier les notifications d'une application tierce spécifique pour chaque canal et chaque package d'application.
[C-1-6] DOIT également fournir une option permettant à l'utilisateur d'afficher les canaux de notification supprimés.
[C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies par le biais de Notification.MessagingStyle avec le texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, DOIT afficher toutes les ressources, y compris les icônes fournies par le biais de android.app.Person dans une conversation de groupe définie par setGroupConversation.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir à l'utilisateur un moyen de contrôler les notifications exposées aux applications auxquelles l'autorisation d'écouteur de notifications a été accordée. La précision DOIT permettre à l'utilisateur de contrôler les types de notifications qui sont transférés à cet écouteur pour chaque écouteur de notification. Les types DOIVENT inclure les notifications "conversations", "alerting", "silent" et "important ongoing".
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de permettre aux utilisateurs de spécifier les applications à exclure de l'envoi de notifications à un écouteur de notifications spécifique.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'afficher automatiquement une option permettant à l'utilisateur de bloquer les notifications d'une application tierce spécifique pour chaque canal et chaque package d'application après que l'utilisateur a ignoré cette notification à plusieurs reprises.
DOIT prendre en charge les notifications enrichies.
DOIT présenter certaines notifications à priorité élevée sous forme de notifications prioritaires.
DOIT permettre à l'utilisateur de répéter les notifications.
MAY ne peut gérer que la visibilité et le calendrier des notifications d'événements importants que les applications tierces peuvent envoyer aux utilisateurs, afin d'atténuer les problèmes de sécurité tels que la distraction du conducteur.

Android 11 est compatible avec les notifications de conversation, qui sont des notifications utilisant MessagingStyle et fournissant un ID de raccourci Personne publié.

Implémentations sur les appareils :

[C-SR-4] Il est FORTEMENT RECOMMANDÉ de regrouper et d'afficher conversation notifications avant les notifications non conversationnelles, à l'exception des notifications de service de premier plan en cours et des notifications importance:high.

Si les implémentations d'appareils sont compatibles avec conversation notifications et que l'application fournit les données requises pour bubbles, elles :

[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher cette conversation sous forme de bulle. L'implémentation AOSP répond à ces exigences avec l'UI du système, les paramètres et le lanceur d'applications par défaut.

Si les implémentations d'appareils sont compatibles avec les notifications enrichies, elles :

[C-2-1] DOIT utiliser les ressources exactes fournies par le biais de la classe d'API Notification.Style et de ses sous-classes pour les éléments de ressources présentés.
DOIT présenter chaque élément de ressource (par exemple, l'icône, le titre et le texte récapitulatif) défini dans la classe d'API Notification.Style et ses sous-classes.

Les notifications prioritaires sont des notifications qui sont présentées à l'utilisateur à mesure qu'elles arrivent, indépendamment de la surface sur laquelle il se trouve. Si les implémentations d'appareils sont compatibles avec les notifications prioritaires, elles :

[C-3-1] DOIT utiliser la vue et les ressources de notification prioritaire décrites dans la classe d'API Notification.Builder lorsque des notifications prioritaires sont présentées.
[C-3-2] DOIT afficher les actions fournies par le biais de Notification.Builder.addAction() avec le contenu de la notification sans interaction supplémentaire de l'utilisateur, comme décrit dans le SDK.

3.8.3.2. Service d'écoute des notifications

Android inclut les API NotificationListenerService qui permettent aux applications (une fois explicitement activées par l'utilisateur) de recevoir une copie de toutes les notifications lorsqu'elles sont publiées ou mises à jour.

Implémentations sur les appareils :

[C-0-1] DOIT mettre à jour correctement et rapidement l'intégralité des notifications pour tous les services d'écoute installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.
[C-0-2] DOIT respecter l'appel d'API snoozeNotification(), et fermer la notification et effectuer un rappel après la durée de report définie dans l'appel d'API.

Si les implémentations d'appareils permettent à l'utilisateur de mettre en veille les notifications, elles :

[C-1-1] DOIT refléter correctement l'état de mise en veille de la notification via les API standards telles que NotificationListenerService.getSnoozedNotifications().
[C-1-2] DOIT permettre à l'utilisateur de mettre en veille les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.

3.8.3.3. Mode Ne pas déranger/Prioritaire

Si les implémentations d'appareils sont compatibles avec la fonctionnalité Ne pas déranger (également appelée mode Priorité), elles :

[C-1-1] DOIT, lorsque l'implémentation de l'appareil a fourni un moyen à l'utilisateur d'autoriser ou de refuser aux applications tierces l'accès à la configuration de la règle Ne pas déranger, afficher les Règles automatiques Ne pas déranger créées par les applications à côté des règles créées par l'utilisateur et prédéfinies.
[C-1-3] DOIT respecter les valeurs suppressedVisualEffects transmises avec NotificationManager.Policy. Si une application a défini l'un des indicateurs SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, elle DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.

3.8.3.4. Protection des notifications sensibles

Les informations sensibles dans les notifications incluent des contenus tels que des mots de passe à usage unique, des codes de confirmation à usage unique et des codes d'authentification ou de réinitialisation similaires qui peuvent apparaître dans les notifications envoyées aux utilisateurs.

Si les implémentations d'appareils permettent aux applications tierces d'informer les utilisateurs d'événements importants, elles :

[C-1-1] Les informations sensibles des notifications DOIVENT être masquées avant d'être transmises aux écouteurs de notifications, sauf si le service d'écouteur est l'un des suivants :
- Applications système signées avec un uid < 10000
- UI du système
- Coquillage
- Application associée désignée (définie par CompanionDeviceManager)
- Rôle SYSTEM_AUTOMOTIVE_PROJECTION
- Rôle SYSTEM_NOTIFICATION_INTELLIGENCE
- Rôle HOME

L'implémentation AOSP de NotificationAssistantServices illustre et respecte ces exigences. Pour consulter un exemple, voir android.ext.services.notification.

3.8.4. API Assist

Android inclut les API Assist pour permettre aux applications de choisir la quantité d'informations du contexte actuel à partager avec l'assistant sur l'appareil.

Si les implémentations d'appareils sont compatibles avec l'action Assistant, elles :

[C-2-1] DOIT indiquer clairement à l'utilisateur final quand le contexte est partagé, soit :
- Chaque fois que l'application d'assistance accède au contexte, une lumière blanche s'affiche autour des bords de l'écran pendant une durée et avec une luminosité égales ou supérieures à celles de l'implémentation du Projet Android Open Source.
- Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu des paramètres par défaut de l'application d'assistance et de saisie vocale, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une touche de navigation d'assistance.

[C-2-1] DOIT partager le contexte avec l'application d'assistance uniquement lorsque l'application est explicitement appelée par l'utilisateur via la touche de navigation d'assistance, un mot clé ou un autre point d'entrée désigné.

[C-2-2] L'interaction désignée pour lancer l'application d'assistance, telle que décrite dans la section 7.2.3, DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité gérant l'intent ACTION_ASSIST.

3.8.5. Alertes et toasts

Les applications peuvent utiliser l'API Toast pour afficher de courtes chaînes non modales à l'utilisateur final, qui disparaissent après une brève période, et utiliser l'API de type de fenêtre TYPE_APPLICATION_OVERLAY pour afficher des fenêtres d'alerte en superposition sur d'autres applications.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles :

[C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent TYPE_APPLICATION_OVERLAY. L'implémentation AOSP répond à cette exigence en intégrant des commandes dans le volet des notifications.
[C-1-2] DOIT respecter l'API Toast et afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.6. Thèmes

Android fournit des "thèmes" comme mécanisme permettant aux applications d'appliquer des styles à l'ensemble d'une activité ou d'une application.

Android inclut une famille de thèmes "Holo" et "Material" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent correspondre à l'apparence du thème Holo tel que défini par le SDK Android.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles :

[C-1-1] NE DOIT PAS modifier les attributs du thème Holo exposés aux applications.
[C-1-2] DOIT être compatible avec la famille de thèmes "Material" et NE DOIT PAS modifier les attributs du thème Material ni leurs ressources exposées aux applications.
[C-1-3] DOIT définir la famille de polices "sans-serif" sur Roboto version 2.x pour les langues prises en charge par Roboto, ou fournir une option permettant à l'utilisateur de modifier la police utilisée pour la famille de polices "sans-serif" et de la définir sur Roboto version 2.x pour les langues prises en charge par Roboto.
[C-1-4] DOIT générer des palettes tonales de couleurs dynamiques, comme spécifié dans la documentation AOSP de Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (voir android.theme.customization.system_palette et android.theme.customization.theme_style).
[C-1-5] DOIT générer des palettes tonales de couleurs dynamiques à l'aide des styles de thème de couleur énumérés dans la documentation Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES (voir android.theme.customization.theme_styles), à savoir TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD et MONOCHROMATIC.

"Couleur source" utilisée pour générer des palettes tonales de couleurs dynamiques lorsqu'elle est envoyée avec android.theme.customization.system_palette (comme indiqué dans Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).
[C-1-6] DOIT avoir une valeur de chroma CAM16 égale ou supérieure à 5.
- DOIT être dérivée du fond d'écran via com.android.systemui.monet.ColorScheme#getSeedColors, qui fournit plusieurs couleurs sources valides parmi lesquelles choisir.
- DOIT utiliser la valeur 0xFF1B6EF3 si aucune des couleurs fournies ne répond à l'exigence de couleur source ci-dessus.

Android inclut également une famille de thèmes "Device Default" (Par défaut de l'appareil) qui correspond à un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent que leur application corresponde à l'apparence du thème de l'appareil tel que défini par l'implémenteur de l'appareil.

Les implémentations d'appareil PEUVENT modifier les attributs du thème par défaut de l'appareil exposés aux applications.

Android est compatible avec un thème de variante avec des barres système translucides, ce qui permet aux développeurs d'applications de remplir la zone située derrière la barre d'état et la barre de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé sur les différentes implémentations d'appareils.

Si les implémentations d'appareils incluent une barre d'état système, elles doivent :

[C-2-1] DOIT utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique ou si une application demande une barre d'état claire à l'aide du flag WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
[C-2-2] Les implémentations d'appareils Android DOIVENT modifier la couleur des icônes d'état du système pour les passer en noir (pour en savoir plus, consultez R.style) lorsqu'une application demande une barre d'état claire.

3.8.7. Fonds d'écran animés

Android définit un type de composant, ainsi que l'API et le cycle de vie correspondants, qui permettent aux applications d'exposer un ou plusieurs fonds d'écran animés à l'utilisateur final. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des capacités d'entrée limitées qui s'affichent en tant que fond d'écran, derrière d'autres applications.

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effets indésirables sur les autres applications. Si des limitations matérielles entraînent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, une consommation excessive de processeur ou de batterie, ou une fréquence d'images inacceptablement basse, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne fonctionnera pas de manière fiable sur du matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés.

Si les implémentations d'appareils implémentent des fonds d'écran animés, elles :

[C-1-1] DOIT signaler le flag de fonctionnalité de la plate-forme android.software.live_wallpaper.

3.8.8. Changement d'activité

Le code source Android en amont inclut l'écran d'aperçu, une interface utilisateur au niveau du système pour changer de tâche et afficher les activités et tâches récemment consultées à l'aide d'une miniature de l'état graphique de l'application au moment où l'utilisateur l'a quittée pour la dernière fois.

Les implémentations d'appareils, y compris la touche de navigation de la fonction "Récents" détaillée dans la section 7.2.3, PEUVENT modifier l'interface.

Si les implémentations d'appareils incluant la touche de navigation de la fonction "Récents" comme indiqué dans la section 7.2.3 modifient l'interface, elles :

[C-1-1] DOIT prendre en charge au moins sept activités affichées.
DOIT au moins afficher le titre de quatre activités à la fois.
DOIT afficher la couleur de mise en surbrillance, l'icône et le titre de l'écran dans les éléments récents.
DOIT afficher une option de fermeture ("x"), mais PEUT la retarder jusqu'à ce que l'utilisateur interagisse avec les écrans.
DOIT implémenter un raccourci pour passer facilement à l'activité précédente.
DOIT déclencher l'action de changement rapide entre les deux applications les plus récemment utilisées lorsque l'utilisateur appuie deux fois sur la touche de fonction "Récents".
DOIT déclencher le mode multifenêtre à écran partagé, s'il est pris en charge, lorsque l'utilisateur appuie de manière prolongée sur la touche de fonction "Récents".
PEUT afficher les éléments récents affiliés sous forme de groupe qui se déplace ensemble.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface similaire basée sur des miniatures) pour l'écran "Récents".

3.8.9. Gestion des entrées

Android inclut la prise en charge de la gestion des entrées et des éditeurs de méthode de saisie tiers.

Si les implémentations d'appareils permettent aux utilisateurs d'utiliser des méthodes de saisie tierces sur l'appareil, elles :

[C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.input_methods et accepter les API IME telles que définies dans la documentation du SDK Android.

3.8.10. Contrôle des contenus multimédias sur l'écran de verrouillage

L'API Remote Control Client est obsolète depuis Android 5.0 au profit du modèle de notification multimédia qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage.

3.8.11. Économiseurs d'écran (anciennement Rêves)

Consultez la section 3.2.3.5 pour connaître l'intention de paramétrer les économiseurs d'écran.

3.8.12. Emplacement

Si les implémentations d'appareils incluent un capteur matériel (par exemple, un GPS) capable de fournir les coordonnées géographiques, elles :

[C-1-2] DOIT afficher l'état actuel de la localisation dans le menu "Localisation" des paramètres.
[C-1-3] NE DOIT PAS afficher les modes de localisation dans le menu "Position" des paramètres.

3.8.13. Unicode et police

Android est compatible avec les caractères emoji définis dans Unicode 10.0.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles :

[C-1-1] DOIT être capable d'afficher ces caractères emoji sous forme de glyphes en couleur.
[C-1-2] DOIT inclure la prise en charge des éléments suivants :
- Police Roboto 2 avec différentes épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
- Couverture complète d'Unicode 7.0 pour le latin, le grec et le cyrillique, y compris les plages Latin étendu A, B, C et D, et tous les glyphes du bloc de symboles monétaires d'Unicode 7.0.
[C-1-3] NE DOIT PAS supprimer ni modifier NotoColorEmoji.tff dans l'image système. (Il est acceptable d'ajouter une nouvelle police d'emoji pour remplacer les emoji dans NotoColorEmoji.tff.)
DOIT être compatible avec les emoji de couleur de peau et de famille diversifiée, comme spécifié dans le rapport technique Unicode #51.

Si les implémentations d'appareils incluent un IME, elles :

DOIT fournir à l'utilisateur une méthode de saisie pour ces caractères emoji.

Android est compatible avec l'affichage des polices birmanes. Le Myanmar dispose de plusieurs polices non conformes à Unicode, communément appelées "Zawgyi", pour afficher les langues du Myanmar.

Si les implémentations d'appareils sont compatibles avec le birman, elles :

[C-2-1] Le texte DOIT être affiché par défaut avec une police compatible avec Unicode. Une police non compatible avec Unicode NE DOIT PAS être définie comme police par défaut, sauf si l'utilisateur la choisit dans l'outil de sélection de langue.
[C-2-2] DOIT être compatible avec une police Unicode et une police non conforme à Unicode si une police non conforme à Unicode est prise en charge sur l'appareil. Une police non conforme à Unicode NE DOIT PAS supprimer ni remplacer la police Unicode.
[C-2-3] Le texte DOIT être affiché avec une police non conforme à Unicode UNIQUEMENT SI un code de langue avec le code de script Qaag est spécifié (par exemple, my-Qaag). Aucun autre code ISO de langue ou de région (qu'il soit attribué, non attribué ou réservé) ne peut être utilisé pour faire référence à une police non conforme à Unicode pour le Myanmar. Les développeurs d'applications et les auteurs de pages Web peuvent spécifier my-Qaag comme code de langue désigné, comme ils le feraient pour toute autre langue.

3.8.14. Mode multifenêtre

Si les implémentations d'appareils sont capables d'afficher plusieurs activités en même temps, elles :

[C-1-1] DOIT implémenter ce ou ces modes multifenêtre conformément aux comportements et aux API d'application décrits dans la documentation sur la prise en charge du mode multifenêtre du SDK Android et répondre aux exigences suivantes :
[C-1-2] Exigence supprimée dans Android 16.
[C-1-3] NE DOIT PAS proposer le mode Écran partagé ni le mode Format libre si la hauteur de l'écran est inférieure à 440 dp et si la largeur de l'écran est inférieure à 440 dp.
[C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp dans les modes multifenêtres autres que le mode Picture-in-picture.

[C-1-5] DOIT afficher les tâches avec la propriété selfMovable en pleine opacité, avec une décoration persistante distincte (par exemple, une barre de légende) et une méthode pour fermer ces tâches à partir de leurs décorations persistantes.

Les implémentations d'appareils avec une taille d'écran xlarge DOIVENT prendre en charge le mode forme libre.

Si les implémentations d'appareils sont compatibles avec le ou les modes multifenêtre et le mode écran partagé, elles :

[C-2-2] DOIT recadrer l'activité ancrée d'une fenêtre en mode multifenêtre en écran partagé, mais DOIT afficher une partie de son contenu si l'application Lanceur est la fenêtre sélectionnée.
[C-2-3] DOIT respecter les valeurs AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight déclarées de l'application de lanceur d'applications tierce et ne pas les remplacer lors de l'affichage de certains contenus de l'activité ancrée.

Si les implémentations d'appareils sont compatibles avec le ou les modes multifenêtre et le mode multifenêtre Picture-in-picture, elles :

[C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque l'application :
- Cibler le niveau d'API 26 ou supérieur et déclarer android:supportsPictureInPicture
- Cibler le niveau d'API 25 ou inférieur et déclarer android:resizeableActivity et android:supportsPictureInPicture.
[C-3-2] DOIT exposer les actions dans son SystemUI, comme spécifié par l'activité PIP actuelle via l'API setActions().
[C-3-3] DOIT être compatible avec les formats supérieurs ou égaux à 1:2.39 et inférieurs ou égaux à 2.39:1, comme spécifié par l'activité PIP via l'API setAspectRatio().
[C-3-4] DOIT utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP. Si le mode PIP n'est pas implémenté, la clé DOIT être disponible pour l'activité au premier plan.
[C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher en mode PIP. L'implémentation AOSP répond à cette exigence en proposant des commandes dans le volet des notifications.
[C-3-6] DOIT allouer la largeur et la hauteur minimales suivantes à la fenêtre PIP lorsqu'une application ne déclare aucune valeur pour AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight :
- Les appareils dont la valeur Configuration.uiMode est différente de UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur et une hauteur minimales de 108 dp.
- Les appareils dont la Configuration.uiMode est définie sur UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

Si les implémentations d'appareils incluent plusieurs zones d'affichage compatibles avec Android et mettent ces zones à la disposition des applications, elles :

[C-4-1] DOIT être compatible avec le mode multifenêtre.

Si les implémentations d'appareils sont compatibles avec le ou les modes multifenêtre, elles :

[C-5-1] DOIT implémenter la version correcte du niveau d'API Window Manager Extensions, comme décrit dans WindowManager Extensions.

3.8.15. Encoche

Android est compatible avec l'encoche, comme décrit dans la documentation du SDK. L'API DisplayCutout définit une zone sur le bord de l'écran qui peut ne pas être fonctionnelle pour une application en raison d'une encoche ou d'un écran incurvé sur le ou les bords.

Si les implémentations d'appareil incluent une ou plusieurs encoches, elles doivent :

[C-1-5] NE DOIT PAS comporter d'encoche(s) si le format de l'appareil est de 1.0(1:1).
[C-1-2] NE DOIT PAS comporter plus d'une encoche par bord.
[C-1-3] DOIT respecter les indicateurs d'encoche définis par l'application via l'API WindowManager.LayoutParams, comme décrit dans le SDK.
[C-1-4] DOIT signaler les valeurs correctes pour toutes les métriques de découpe définies dans l'API DisplayCutout.

3.8.16. Commandes de contrôle des appareils

Android inclut les API ControlsProviderService et Control pour permettre aux applications tierces de publier des commandes d'appareil permettant aux utilisateurs de consulter rapidement l'état et d'effectuer des actions.

Consultez la section 2_2_3 pour connaître les exigences spécifiques aux appareils.

3.8.17. Presse-papiers

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS envoyer de données du presse-papiers à un composant, une activité ou un service, ni via une connexion réseau, sans action explicite de l'utilisateur (par exemple, en appuyant sur un bouton de l'overlay) ou indication de contenu envoyé, à l'exception des services mentionnés dans 9.8.6 Capture de contenu et recherche d'applications.

Si les implémentations d'appareil génèrent un aperçu visible par l'utilisateur lorsque du contenu est copié dans le presse-papiers pour tout élément ClipData où ClipData.getDescription().getExtras() contient android.content.extra.IS_SENSITIVE, elles :

[C-1-1] DOIT masquer l'aperçu visible par l'utilisateur

L'implémentation de référence AOSP répond à ces exigences concernant le presse-papiers.

3.8.18. Bouton de localisation

Le bouton de localisation est un élément d'interface utilisateur Android que les développeurs d'applications peuvent intégrer à leurs applications pour obtenir une autorisation d'accéder à la position exacte pour la session de cette application.

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS ajouter, modifier ni supprimer les options de personnalisation fournies aux développeurs d'applications pour le bouton de localisation.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux outils de contrôle des règles relatives aux appareils d'effectuer des fonctions d'administration des appareils au niveau du système, telles que l'application de règles relatives aux mots de passe ou l'effacement à distance, via les API Device Policy Manager.

3.9.1. Préparation de l'appareil

3.9.1.1. Provisionnement du propriétaire de l'appareil

Si les implémentations d'appareil déclarent android.software.device_admin, elles :

[C-1-1] DOIT permettre d'enregistrer un outil de contrôle des règles relatives aux appareils (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
- Lorsque l'implémentation de l'appareil n'a ni utilisateur ni données utilisateur configurés, elle :
  - [C-1-5] DOIT enregistrer l'application DPC en tant qu'application propriétaire de l'appareil ou permettre à l'application DPC de choisir de devenir propriétaire de l'appareil ou propriétaire du profil, si l'appareil déclare la prise en charge de la communication en champ proche (NFC) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement avec le type MIME MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] DOIT envoyer l'intent ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire de l'appareil afin que l'application DPC puisse choisir de devenir propriétaire de l'appareil ou propriétaire du profil, en fonction des valeurs de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, sauf si le contexte permet de déterminer qu'il n'existe qu'une seule option valide.
  - [C-1-9] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE à l'application Propriétaire de l'appareil si un propriétaire de l'appareil est établi lors du provisionnement, quelle que soit la méthode de provisionnement utilisée. L'utilisateur ne doit pas pouvoir poursuivre la procédure dans l'assistant de configuration tant que l'application Device Owner n'est pas terminée.
- Lorsque l'implémentation de l'appareil comporte des utilisateurs ou des données utilisateur, elle :
  - [C-1-7] NE DOIT plus enregistrer d'application DPC en tant qu'application propriétaire de l'appareil.
[C-1-2] Exigence supprimée dans Android 15.
[C-2-1] Exigence supprimée dans Android 15.
[C-2-2] Exigence supprimée dans Android 15.
[C-2-3] Exigence supprimée dans Android 15.

3.9.1.2. Provisionnement de profils gérés

Si les implémentations d'appareil déclarent android.software.managed_users, elles :

[C-1-1] DOIT déclarer android.software.device_admin et implémenter les API permettant à une application d'outil de contrôle des règles relatives aux appareils (DPC) de devenir propriétaire d'un nouveau profil géré.
[C-1-2] Exigence supprimée dans Android 16.
[C-1-3] DOIT fournir les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur quand une fonction système particulière a été désactivée par l'outil de contrôle des règles relatives aux appareils (DPC) :
- Une icône cohérente ou une autre affordance utilisateur (par exemple, l'icône d'informations AOSP en amont) pour indiquer quand un paramètre particulier est limité par un administrateur de l'appareil.
- Message explicatif court, fourni par l'administrateur de l'appareil via setShortSupportMessage.
- Icône de l'application DPC.
[C-1-4] DOIT lancer le gestionnaire pour l'intent ACTION_PROVISIONING_SUCCESSFUL dans le profil professionnel si un propriétaire du profil est établi lorsque le provisionnement est lancé par l'intent android.app.action.PROVISION_MANAGED_PROFILE et que le DPC a implémenté le gestionnaire.
[C-1-5] DOIT envoyer une diffusion ACTION_PROFILE_PROVISIONING_COMPLETE au DPC du profil professionnel lorsque le provisionnement est initié par l'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-6] DOIT envoyer l'intent ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire du profil afin que l'application DPC puisse choisir de devenir propriétaire de l'appareil ou propriétaire du profil, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] DOIT envoyer l'intention ACTION_ADMIN_POLICY_COMPLIANCE au profil professionnel lorsqu'un propriétaire de profil est établi lors du provisionnement, quelle que soit la méthode de provisionnement utilisée, sauf lorsque le provisionnement est déclenché par l'intention android.app.action.PROVISION_MANAGED_PROFILE. L'utilisateur ne doit pas pouvoir poursuivre l'assistant de configuration tant que l'application Profile Owner n'est pas terminée.
[C-1-8] DOIT envoyer la diffusion ACTION_MANAGED_PROFILE_PROVISIONED au DPC du profil personnel lorsqu'un propriétaire de profil est établi, quelle que soit la méthode de provisionnement utilisée.

3.9.2. Assistance pour les profils gérés

Si les implémentations d'appareil déclarent android.software.managed_users, elles :

[C-1-1] DOIT être compatible avec les profils gérés via les API android.app.admin.DevicePolicyManager.
[C-1-2] DOIT autoriser la création d'un seul profil géré.
[C-1-3] DOIT utiliser un badge d'icône (semblable au badge professionnel en amont AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge tels que "Récents et notifications".
[C-1-4] DOIT afficher une icône de notification (semblable au badge AOSP en amont) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
[C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré lorsque l'appareil se réveille (ACTION_USER_PRESENT) et que l'application au premier plan se trouve dans le profil géré.
[C-1-6] Lorsqu'un profil géré existe, une indication visuelle DOIT être affichée dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si le contrôleur de règles de l'appareil l'a activé.
[C-1-7] Lorsqu'un profil géré existe, les affordances utilisateur suivantes DOIVENT être exposées pour l'utilisateur principal et le profil géré :
- Traçabilité distincte pour l'utilisation de la batterie, de la localisation, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
- Gestion indépendante des applications VPN installées dans le profil utilisateur principal ou géré.
- Gestion indépendante des applications installées dans le profil utilisateur principal ou géré.
- Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
[C-1-8] DOIT s'assurer que les applications de téléphone, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant à partir du profil géré (le cas échéant) en plus de celles du profil principal, si l'outil de contrôle des règles relatives aux appareils le permet.
[C-1-9] DOIT s'assurer de respecter toutes les exigences de sécurité applicables à un appareil sur lequel plusieurs utilisateurs sont activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.
[C-1-10] DOIT s'assurer que les données de la capture d'écran sont enregistrées dans l'espace de stockage du profil professionnel lorsqu'une capture d'écran est effectuée avec une fenêtre topActivity qui a le focus (celle avec laquelle l'utilisateur a interagi en dernier parmi toutes les activités) et appartient à une application de profil professionnel.
[C-1-11] NE DOIT PAS capturer d'autre contenu d'écran (barre système, notifications ou contenu de profil personnel) à l'exception de la ou des fenêtres de l'application du profil professionnel lors de l'enregistrement d'une capture d'écran dans le profil professionnel (pour s'assurer que les données du profil personnel ne sont pas enregistrées dans le profil professionnel).

Si les implémentations d'appareil déclarent android.software.managed_users et android.software.secure_lock_screen, elles :

[C-2-1] DOIT permettre de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications s'exécutant dans un profil géré uniquement.
- Les implémentations d'appareils DOIVENT respecter l'intention DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer un identifiant d'écran de verrouillage distinct pour le profil géré.
- Les identifiants de l'écran de verrouillage du profil géré DOIVENT utiliser les mêmes mécanismes de stockage et de gestion des identifiants que le profil parent, comme indiqué sur le site du projet Android Open Source.
- Les règles relatives aux mots de passe du DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
Lorsque les contacts du profil géré sont affichés dans le journal d'appels préinstallé, dans l'UI d'appel, dans les notifications d'appels en cours et manqués, dans les applications de contacts et de messagerie, ils DOIVENT être signalés par le même badge que celui utilisé pour indiquer les applications du profil géré.

3.9.3. Assistance pour les utilisateurs gérés

Si les implémentations d'appareil déclarent android.software.managed_users, elles :

[C-1-1] DOIT fournir une affordance utilisateur pour se déconnecter de l'utilisateur actuel et revenir à l'utilisateur principal dans une session multi-utilisateur lorsque isLogoutEnabled renvoie true. L'affordance utilisateur DOIT être accessible depuis l'écran de verrouillage sans déverrouiller l'appareil.

Si les implémentations d'appareils déclarent android.software.device_admin et fournissent une affordance utilisateur sur l'appareil pour ajouter des utilisateurs secondaires supplémentaires, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les mêmes informations de consentement du propriétaire de l'appareil AOSP que celles affichées dans le flux initié par android.app.action.PROVISION_MANAGED_DEVICE avant d'autoriser l'ajout de comptes dans le nouvel utilisateur secondaire, afin que les utilisateurs comprennent que l'appareil est géré.

3.9.4. Exigences concernant le rôle de gestion des règles relatives aux appareils

Si les implémentations d'appareil déclarent android.software.device_admin, elles :

[C-1-1] DOIT être compatible avec le rôle de gestion des règles relatives aux appareils tel que défini dans la section 9.1. L'application qui détient le rôle de gestion des règles de l'appareil PEUT être définie en définissant config_devicePolicyManagement sur le nom du package. Le nom du package DOIT être suivi d'un deux-points (:) et du certificat de signature, sauf si l'application est préchargée.

Si aucun nom de package n'est défini pour config_devicePolicyManagement comme décrit ci-dessus :

[C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec le provisionnement sans application de titulaire de rôle de gestion des règles de l'appareil (AOSP fournit une implémentation de référence).

Si un nom de package est défini pour config_devicePolicyManagement comme décrit ci-dessus :

[C-3-1] L'application DOIT être installée sur tous les profils d'un utilisateur.
[C-3-2] Les implémentations d'appareils PEUVENT définir une application qui met à jour le titulaire du rôle de gestion des règles de l'appareil avant le provisionnement en définissant config_devicePolicyManagementUpdater.

Si un nom de package est défini pour config_devicePolicyManagementUpdater comme décrit ci-dessus :

[C-4-1] L'application DOIT être préinstallée sur l'appareil.
[C-4-2] L'application DOIT implémenter un filtre d'intent qui résout android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER.

3.9.5. Framework de résolution des problèmes liés aux règles relatives aux appareils

Si les implémentations d'appareil déclarent android.software.device_admin, elles :

[C-1-1] DOIT résoudre les conflits de règles relatives aux appareils comme indiqué dans le Framework de résolution des règles relatives aux appareils.

3.10. Accessibilité

Android fournit une couche d'accessibilité qui aide les utilisateurs handicapés à naviguer plus facilement sur leurs appareils. De plus, Android fournit des API de plate-forme qui permettent aux implémentations de services d'accessibilité de recevoir des rappels pour les événements utilisateur et système, et de générer d'autres mécanismes de commentaires, tels que la synthèse vocale, le retour haptique et la navigation avec trackball/pavé directionnel.

Si les implémentations d'appareils sont compatibles avec les services d'accessibilité tiers, elles :

[C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android, comme décrit dans la documentation du SDK des API d'accessibilité.
[C-1-2] DOIT générer des événements d'accessibilité et fournir le AccessibilityEvent approprié à toutes les implémentations AccessibilityService enregistrées, comme indiqué dans le SDK.
[C-1-4] DOIT fournir une affordance utilisateur pour contrôler les services d'accessibilité qui déclarent AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. Notez que pour les implémentations d'appareils avec une barre de navigation système, elles DOIVENT permettre à l'utilisateur d'avoir l'option d'un bouton dans la barre de navigation du système pour contrôler ces services.

Si les implémentations d'appareils incluent des services d'accessibilité préinstallés, elles :

[C-2-1] DOIT implémenter ces services d'accessibilité préinstallés en tant qu'applications Direct Boot Aware lorsque le stockage de données est chiffré avec le chiffrement basé sur les fichiers (FBE).
DOIT fournir un mécanisme dans le flux de configuration prêt à l'emploi permettant aux utilisateurs d'activer les services d'accessibilité pertinents, ainsi que des options permettant d'ajuster la taille d'affichage, la taille de la police et les gestes d'agrandissement.

3.11. Text-to-Speech

Android inclut des API qui permettent aux applications d'utiliser des services de synthèse vocale (TTS, Text-To-Speech) et aux fournisseurs de services de fournir des implémentations de services TTS.

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.audio.output, elles :

[C-1-1] DOIT être compatible avec les API du framework Android TTS.

Si les implémentations d'appareils sont compatibles avec l'installation de moteurs TTS tiers, elles :

[C-2-1] DOIT fournir une affordance utilisateur permettant à l'utilisateur de sélectionner un moteur TTS à utiliser au niveau du système.

3.12. N/A

3.13. Réglages rapides

Android fournit un composant d'interface utilisateur Réglages rapides qui permet d'accéder rapidement aux actions fréquemment utilisées ou urgentes.

Si les implémentations d'appareils incluent un composant UI de Réglages rapides et prennent en charge les Réglages rapides tiers, elles :

[C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les tuiles fournies par les API quicksettings à partir d'une application tierce.
[C-1-2] NE DOIT PAS ajouter automatiquement un bloc à partir d'une application tierce directement aux Réglages rapides.
[C-1-3] DOIT afficher tous les blocs ajoutés par l'utilisateur à partir d'applications tierces à côté des blocs de réglages rapides fournis par le système.

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent des applications non activées par la voix (les Applications) qui interagissent avec des applications tierces via MediaBrowser ou MediaSession, les Applications :

[C-1-2] DOIT afficher clairement les icônes obtenues via getIconBitmap() ou getIconUri() et les titres obtenus via getTitle(), comme décrit dans MediaDescription. Les titres peuvent être raccourcis pour respecter les règles de sécurité (par exemple, la distraction du conducteur).
[C-1-3] DOIT afficher l'icône de l'application tierce chaque fois qu'il affiche du contenu fourni par cette application tierce.
[C-1-4] DOIT permettre à l'utilisateur d'interagir avec l'ensemble de la hiérarchie MediaBrowser. PEUT limiter l'accès à une partie de la hiérarchie pour respecter les règles de sécurité (par exemple, la distraction du conducteur), mais NE DOIT PAS accorder de traitement préférentiel en fonction du contenu ou du fournisseur de contenu.
[C-1-5] DOIT considérer le double-tap sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

Si les implémentations d'appareils sont compatibles avec les applications instantanées, elles DOIVENT répondre aux exigences suivantes :

[C-1-1] Les applications instantanées NE DOIVENT se voir accorder que les autorisations dont le paramètre android:protectionLevel est défini sur "instant".
[C-1-2] Les applis instantanées NE DOIVENT PAS interagir avec les applications installées via des intents implicites, sauf si l'une des conditions suivantes est remplie :
- Le filtre de modèle d'intent du composant est exposé et comporte CATEGORY_BROWSABLE.
- L'action est l'une des suivantes : ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
- La cible est explicitement exposée avec android:visibleToInstantApps.
[C-1-3] Les applis instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
[C-1-4] Les applications installées NE DOIVENT PAS voir les détails concernant les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.
Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes pour interagir avec les applis instantanées. L'AOSP répond aux exigences avec l'UI du système, les paramètres et le lanceur d'applications par défaut. Implémentations sur les appareils :
- [C-1-5] DOIT fournir une affordance utilisateur pour afficher et supprimer les applications instantanées mises en cache localement pour chaque package d'application.
- [C-1-6] DOIT fournir une notification utilisateur persistante qui peut être réduite lorsqu'une appli instantanée est exécutée au premier plan. Cette notification utilisateur DOIT indiquer que les applis instantanées ne nécessitent pas d'installation et fournir une affordance utilisateur qui redirige l'utilisateur vers l'écran d'informations sur l'application dans les paramètres. Pour les applications instantanées lancées via des intents Web, tels que définis en utilisant un intent avec une action définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance utilisateur supplémentaire DOIT permettre à l'utilisateur de ne pas lancer l'application instantanée et de lancer le lien associé avec le navigateur Web configuré, si un navigateur est disponible sur l'appareil.
- [C-1-7] DOIT autoriser l'accès aux applications instantanées en cours d'exécution à partir de la fonction "Récents" si celle-ci est disponible sur l'appareil.
[C-1-8] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent pour les intents listés dans le SDK ici et rendre les intents visibles pour les applications instantanées.

3.16. Association d'un appareil associé

Android inclut la prise en charge de l'association d'appareils associés pour gérer plus efficacement l'association avec les appareils associés et fournit l'API CompanionDeviceManager pour que les applications puissent accéder à cette fonctionnalité.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité d'association d'appareils associés, elles :

[C-1-1] DOIT déclarer le flag de fonctionnalité FEATURE_COMPANION_DEVICE_SETUP.
[C-1-2] DOIT s'assurer que les API du package android.companion sont entièrement implémentées.
[C-1-3] DOIT fournir des affordances utilisateur permettant à l'utilisateur de sélectionner/confirmer qu'un appareil associé est présent et opérationnel, qui DOIT utiliser le même message que celui implémenté dans AOSP sans ajout ni modification.

3.17. Applications gourmandes en ressources

Si les implémentations d'appareil déclarent la fonctionnalité FEATURE_CANT_SAVE_STATE, elles doivent :

[C-1-1] Une seule application installée spécifiant cantSaveState doit être en cours d'exécution dans le système à la fois. Si l'utilisateur quitte une telle application sans la fermer explicitement (par exemple, en appuyant sur le bouton d'accueil tout en quittant une activité active du système, au lieu d'appuyer sur le bouton Retour sans qu'il reste d'activité active dans le système), les implémentations d'appareil DOIVENT donner la priorité à cette application dans la RAM, comme elles le font pour d'autres éléments qui sont censés rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une telle application est en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, comme la limitation de l'accès au processeur et au réseau.
[C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participera pas au mécanisme normal d'enregistrement/restauration de l'état une fois que l'utilisateur aura lancé une deuxième application déclarée avec l'attribut cantSaveState.
[C-1-3] NE DOIT PAS appliquer d'autres modifications des règles aux applications qui spécifient cantSaveState, comme la modification des performances du processeur ou de la priorité de planification.

Si les implémentations d'appareil ne déclarent pas la fonctionnalité FEATURE_CANT_SAVE_STATE, elles :

[C-1-1] DOIT ignorer l'attribut cantSaveState défini par les applications et NE DOIT PAS modifier le comportement de l'application en fonction de cet attribut.

3.18. Contacts

Android inclut des API Contacts Provider permettant aux applications de gérer les informations de contact stockées sur l'appareil. Les données de contact saisies directement sur l'appareil sont généralement synchronisées avec un service Web, mais elles PEUVENT également résider uniquement en local sur l'appareil. Les contacts stockés uniquement sur l'appareil sont appelés contacts locaux.

Les RawContacts sont "associés à" ou "stockés dans" un compte lorsque les colonnes ACCOUNT_NAME et ACCOUNT_TYPE des contacts bruts correspondent aux champs Account.name et Account.type du compte.

Compte local par défaut : compte pour les contacts bruts qui ne sont stockés que sur l'appareil et qui ne sont pas associés à un compte dans AccountManager. Ils sont créés avec des valeurs null pour les colonnes ACCOUNT_NAME et ACCOUNT_TYPE.

Compte local personnalisé : compte pour les contacts bruts qui ne sont stockés que sur l'appareil et qui ne sont pas associés à un compte dans AccountManager. Ils sont créés avec des valeurs non nulles pour les colonnes ACCOUNT_NAME et ACCOUNT_TYPE.

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas créer de comptes locaux personnalisés.

Si les implémentations d'appareils utilisent un compte local personnalisé :

[C-1-1] Le ACCOUNT_NAME du compte local personnalisé DOIT être renvoyé par ContactsContract.RawContacts.getLocalAccountName.
[C-1-2] Le ACCOUNT_TYPE du compte local personnalisé DOIT être renvoyé par ContactsContract.RawContacts.getLocalAccountType.
[C-1-3] Les contacts bruts insérés par des applications tierces sans spécifier de compte DOIVENT être insérés dans le compte de contact par défaut de l'appareil. Si le compte de contacts par défaut est DEFAULT_ACCOUNT_STATE_LOCAL ou DEFAULT_ACCOUNT_STATE_NOT_SET, ces contacts bruts DOIVENT être stockés dans le compte local personnalisé.
[C-1-4] Les contacts bruts insérés dans le compte local personnalisé NE DOIVENT PAS être supprimés lorsque des comptes sont ajoutés ou supprimés.
[C-1-5] Les opérations de suppression effectuées sur le compte local personnalisé DOIVENT entraîner la suppression immédiate des contacts bruts (comme si le paramètre CALLER_IS_SYNCADAPTER était défini sur "true"), même si le paramètre CALLER_IS_SYNCADAPTER était défini sur "false" ou non spécifié.

Compte(s) SIM : compte(s) pour les contacts bruts qui sont mis en miroir à partir d'une ou de plusieurs cartes SIM physiques insérées dans l'appareil et qui ne sont pas associés à un compte dans AccountManager.

Implémentations sur les appareils :

Si les implémentations d'appareils utilisent des comptes SIM :

[C-1-6] Le ou les comptes SIM DOIVENT être restitués d'ici le ContactsContract.SimContacts.getSimAccounts.

3.18.2. Sélecteur de contacts système

Android est compatible avec un sélecteur de contacts système qui permet aux applications d'accéder à des informations de contact limitées sans nécessiter d'autorisations d'accès étendues.

Si les implémentations d'appareils sont compatibles avec les contacts Android, elles :

[C-1-1] DOIT implémenter le sélecteur de contacts système (com.android.contactspicker) pour les applications ciblant le niveau d'API 37 ou supérieur.
[C-1-2] DOIT implémenter l'intent Intent.ACTION_PICK_CONTACTS.

3.19. Paramètres de langue

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS fournir d'affordance utilisateur permettant de sélectionner un traitement linguistique spécifique au genre pour les langues qui ne prennent pas en charge les traductions spécifiques au genre. Pour en savoir plus, consultez Ressources grammaticales.

3.20. Expériences basées sur l'assistant

Le framework de développement de l'Assistant Android permet de contrôler les applications Android par commande vocale. Grâce à l'Assistant, les utilisateurs peuvent lancer des applications, effectuer des tâches, accéder à des contenus et plus encore à l'aide de commandes vocales.

Pour cette section, reportez-vous aux classifications suivantes pour les implémentations d'appareils spécialisés :

Volume fixe : un appareil à volume fixe est un appareil doté de commandes de volume, mais qui empêche les applications de modifier le niveau du flux audio à l'aide des méthodes AudioManager standards (par exemple, les voitures Android Automotive OS).
Volume maximal : un appareil à volume maximal est un appareil dont le volume est bloqué au niveau maximal et où le contrôle logiciel est empêché (par exemple, un téléviseur avec des enceintes externes).
Volume unique : un appareil à volume unique est un appareil qui mappe tous les flux audio à un flux à volume unique, ce qui fait que les ajustements de volume affectent tous les flux audio de manière uniforme (par exemple, un téléviseur).

3.20.1. Exigences concernant le flux audio de l'Assistant

Une application détenant l'autorisation MANAGE_ASSISTANT_AUDIO :

[C-0-1] DOIT être autorisé à modifier le volume de STREAM_ASSISTANT par programmation.

Si les implémentations d'appareils ne déclarent pas android.hardware.type.watch et ne sont pas à volume fixe, à volume unique ou à volume maximal, elles :

[C-1-1] DOIT implémenter STREAM_ASSISTANT en tant que flux audio découplé et NE DOIT PAS être associé à un autre flux.
[C-1-2] DOIT s'assurer que le volume de lecture audio à l'aide de AudioAttributes avec USAGE_ASSISTANT est contrôlé par STREAM_ASSISTANT.
[C-1-3] DOIT s'assurer que, pour un casque Bluetooth donné, l'index de volume STREAM_ASSISTANT reste le même lorsque le casque passe des profils audio A2DP à HFP.
[C-1-4] DOIT empêcher tout flux autre que STREAM_ASSISTANT de pouvoir modifier le volume de STREAM_ASSISTANT ou l'atténuation appliquée à la lecture de USAGE_ASSISTANT, tandis que MODE_ASSISTANT_CONVERSATION est actif.
[C-1-5] DOIT modifier le volume du flux STREAM_ASSISTANT et aucun autre volume de flux lorsque le volume est ajusté à l'aide des touches de volume de l'appareil ou d'un périphérique (comme un casque Bluetooth) et lorsque :
- MODE_ASSISTANT_CONVERSATION est actif.
- Il n'y a pas de personnalisation spécifique à l'application ni de lecture à distance active.
[C-1-6] DOIT refléter tout changement de volume de l'Assistant dans l'interface utilisateur.

3.21. Compatibilité avec les fonctionnalités de synchronisation des appareils associés

Android est compatible avec les fonctionnalités de synchronisation des données sur les appareils associés.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité de synchronisation du mode Ne pas déranger, elles :

[C-1-1] DOIT implémenter l'API ContextualModeManager#isModeSyncSupported.
[C-1-2] DOIT synchroniser le paramètre indiquant que le mode Ne pas déranger est activé via le canal sécurisé CompanionDeviceManager à l'aide d'un format de données compatible avec l'implémentation CompanionDeviceManagerService par défaut.
[C-1-3] Vous DEVEZ activer cette synchronisation si ContextualModeManager#isModeSyncEnabled renvoie true.

Si les implémentations d'appareils sont compatibles avec la fonctionnalité de synchronisation du mode Avion, elles :

[C-1-4] DOIT synchroniser le paramètre indiquant que le mode Avion est activé via le canal sécurisé CompanionDeviceManager à l'aide d'un format de données compatible avec l'implémentation CompanionDeviceManagerService par défaut.
[C-1-5] DOIT activer cette synchronisation si Settings.Global.AIRPLANE_MODE_SYNC est activé.

3.22. API ComputerControls

L'API ComputerControls permet aux agents compatibles d'effectuer des actions autonomes et non scriptées au nom de l'utilisateur pour accomplir des tâches sur un appareil Android.

[C-1-1] Si les implémentations d'appareil préchargent la bibliothèque d'extensions com.android.extensions.computercontrol pour prendre en charge ComputerControl, elles doivent :

Vous DEVEZ activer android.software.activities_on_secondary_display.
DOIT indiquer que la fonctionnalité système com.android.extensions.computercontrol est disponible.
Vous DEVEZ activer VirtualDeviceManager.
DOIT inclure com.android.extensions.computercontrol dans la liste renvoyée par PackageManager#getSharedLibraries().
Vous DEVEZ précharger l'application de plate-forme com.android.virtualdevicemanager (cible de compilation VirtualDeviceManager).

4. Compatibilité du packaging d'application

Implémentations des appareils :

[C-0-1] DOIT être capable d'installer et d'exécuter des fichiers ".apk" Android tels qu'ils sont générés par l'outil "aapt" inclus dans le SDK Android officiel.
- Comme l'exigence ci-dessus peut être difficile à respecter, il est RECOMMANDÉ aux implémentations d'appareils d'utiliser le système de gestion des packages de l'implémentation de référence AOSP.

[C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide d'APK Signature Scheme v3.2, APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 et JAR signing.

[C-0-3] NE DOIT PAS étendre les formats .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correctes de ces fichiers sur d'autres appareils compatibles.
[C-0-4] NE DOIT PAS autoriser les applications autres que l'"installateur de référence" actuel pour le package à désinstaller silencieusement l'application sans aucune confirmation de l'utilisateur, comme indiqué dans le SDK pour l'autorisation DELETE_PACKAGE. Les seules exceptions sont l'application de vérification des packages système qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application gestionnaire d'espace de stockage qui gère l'intent ACTION_MANAGE_STORAGE.
[C-0-5] DOIT disposer d'une activité qui gère l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NE DOIT PAS installer de packages d'application provenant de sources inconnues, sauf si l'application qui demande l'installation répond à toutes les exigences suivantes :
- Il DOIT déclarer l'autorisation REQUEST_INSTALL_PACKAGES ou définir android:targetSdkVersion sur 24 ou moins.
- L'utilisateur DOIT avoir autorisé l'installation d'applications provenant de sources inconnues.
DOIT fournir une affordance utilisateur pour accorder/révoquer l'autorisation d'installer des applications provenant de sources inconnues par application, mais PEUT choisir d'implémenter cela comme une no-op et de renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs d'avoir ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi ce choix ne lui est pas proposé.
[C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie par l'API système PackageManager.setHarmfulAppWarning à l'utilisateur avant de lancer une activité dans une application qui a été marquée par la même API système PackageManager.setHarmfulAppWarning comme potentiellement dangereuse.
DOIT fournir une option permettant à l'utilisateur de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.
[C-0-8] DOIT implémenter la prise en charge du système de fichiers incrémentiel, comme indiqué ici.
[C-0-9] DOIT permettre de valider les fichiers .apk à l'aide des schémas de signature d'APK v4 et v4.1.

5. Compatibilité multimédia

Implémentations sur les appareils :

[C-0-1] DOIT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans la section 5.1 pour chaque codec déclaré par MediaCodecList.
[C-0-2] DOIT déclarer et signaler la prise en charge des encodeurs et décodeurs disponibles pour les applications tierces via MediaCodecList.
[C-0-3] DOIT être capable de décoder correctement tous les formats qu'il peut encoder et de les mettre à la disposition des applications tierces. Cela inclut tous les flux binaires générés par ses encodeurs et les profils indiqués dans son CamcorderProfile.

Implémentations sur les appareils :

DOIT viser une latence de codec minimale, en d'autres termes, il
- NE DOIT PAS consommer ni stocker les tampons d'entrée, et ne doit renvoyer les tampons d'entrée qu'une fois traités.
- NE DOIT PAS conserver les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
- NE DOIT PAS conserver les tampons encodés plus longtemps que nécessaire pour la structure GOP.

Tous les codecs listés dans la section ci-dessous sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du projet Android Open Source.

Veuillez noter que ni Google ni l'Open Handset Alliance ne garantissent que ces codecs sont exempts de brevets tiers. Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou shareware, peuvent nécessiter des licences de brevet auprès des titulaires de brevet concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

Pour en savoir plus, consultez la section 5.1.3. Détails des codecs audio.

Si les implémentations d'appareils déclarent android.hardware.microphone, elles DOIVENT prendre en charge l'encodage des formats audio suivants et les mettre à la disposition des applications tierces :

[C-1-1] PCM/WAVE
[C-1-2] FLAC
[C-1-3] Opus

[C-1-4] MPEG-D USAC avec MPEG-D DRC (Extended High Efficiency AAC)

Tous les encodeurs audio DOIVENT être compatibles avec les éléments suivants :

[C-3-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API android.media.MediaCodec.

Lorsque vous encodez MPEG-D USAC avec l'audio MPEG-D DRC (Extended High Efficiency AAC) :

[C-3-2] Tous les flux binaires DOIVENT contenir les ensembles de métadonnées conformes au profil de contrôle du volume MPEG-D ou au profil de contrôle de la plage dynamique MPEG-D, niveau 1 ou supérieur, conformément à la norme ISO/IEC 23003-4.

5.1.2. Décodage audio

Pour en savoir plus, consultez la section 5.1.3. Détails des codecs audio.

Si les implémentations d'appareils déclarent la prise en charge de la fonctionnalité android.hardware.audio.output, elles doivent prendre en charge le décodage des formats audio suivants :

[C-1-1] Profil AAC MPEG-4 (AAC LC)
[C-1-2] Profil MPEG-4 HE AAC (AAC+)
[C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
[C-1-4] AAC ELD (AAC à faible latence amélioré)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE, y compris les formats audio haute résolution jusqu'à 24 bits, avec une fréquence d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne concerne que le décodage et qu'un appareil est autorisé à sous-échantillonner et à sous-mixer pendant la phase de lecture.
[C-1-10] Opus
[C-1-11] xHE-AAC (profil HE-AAC étendu ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de la plage dynamique ISO/IEC 23003-4)

Si les implémentations d'appareils sont compatibles avec le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge :

[C-2-1] Le décodage DOIT être effectué sans mixage réducteur (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, et un flux AAC 5.1 doit être décodé en six canaux PCM).
[C-2-2] Les métadonnées de plage dynamique DOIVENT être définies dans la section "Dynamic Range Control (DRC)" de la norme ISO/IEC 14496-3, et les clés DRC android.media.MediaFormat DOIVENT être utilisées pour configurer les comportements liés à la plage dynamique du décodeur audio. Les clés AAC DRC ont été introduites dans l'API 21 et sont les suivantes : KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ que les exigences C-2-1 et C-2-2 ci-dessus soient satisfaites par tous les décodeurs audio AAC.

Lors du décodage audio USAC, MPEG-D (ISO/IEC 23003-4) :

[C-3-1] Les métadonnées de volume et de DRC DOIVENT être interprétées et appliquées conformément au profil de contrôle de la plage dynamique MPEG-D DRC de niveau 1.
[C-3-2] Le décodeur DOIT se comporter conformément à la configuration définie avec les clés android.media.MediaFormat suivantes : KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_DRC_EFFECT_TYPE.

Décodeurs de profil MPEG-4 AAC, HE-AAC et HE-AACv2 :

MAY est compatible avec le contrôle du volume et de la plage dynamique à l'aide du profil de contrôle de la plage dynamique ISO/IEC 23003-4.

Si la norme ISO/IEC 23003-4 est prise en charge et si les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont présentes dans un flux binaire décodé :

Les métadonnées ISO/IEC 23003-4 doivent prévaloir.

Tous les décodeurs audio DOIVENT être capables de générer les éléments suivants :

[C-6-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API android.media.MediaCodec.

Si les implémentations d'appareil sont compatibles avec le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge :

[C-7-1] L'application DOIT pouvoir être configurée à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est mixé en stéréo (avec une valeur de 2) ou s'il est diffusé avec le nombre de canaux natif (avec une valeur égale ou supérieure à ce nombre). Par exemple, une valeur de 6 ou plus configure un décodeur pour qu'il génère six canaux lorsqu'il reçoit du contenu 5.1.
[C-7-2] Lors du décodage, le décodeur DOIT indiquer le masque de canal utilisé sur le format de sortie avec la clé KEY_CHANNEL_MASK, en utilisant les constantes android.media.AudioFormat (exemple : CHANNEL_OUT_5POINT1).

Tous les appareils portables ou tablettes dotés d'un effet Spatializer, ainsi que tous les appareils automobiles et téléviseurs :

[C-8-1] DOIT prendre en charge le décodage de IAMF v1.0 contenant des flux audio encodés en AAC, FLAC, Opus ou PCM, et DOIT présenter un décodeur IAMF via l'API android.media.MediaCodec.
[C-8-2] DOIT s'assurer que le décodeur IAMF respecte le masque de canal utilisé pour le configurer via la clé KEY_CHANNEL_MASK, en utilisant des constantes android.media.AudioFormat telles que CHANNEL_OUT_5POINT1.
[C-8-3] DOIT s'assurer que le décodeur IAMF annonce le masque de canal actif sur le format de sortie via la clé KEY_CHANNEL_MASK, en utilisant des constantes android.media.AudioFormat telles que CHANNEL_OUT_5POINT1.

Si les implémentations d'appareils sont compatibles avec des décodeurs audio autres que le décodeur audio AAC par défaut et sont capables de produire un son multicanal (c'est-à-dire plus de deux canaux) lorsqu'elles reçoivent du contenu multicanal compressé, alors :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'application puisse configurer le décodeur à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est mixé en stéréo (avec une valeur de 2) ou s'il est diffusé avec le nombre de canaux natif (avec une valeur égale ou supérieure à ce nombre). Par exemple, une valeur de 6 ou plus configure un décodeur pour qu'il génère six canaux lorsqu'il reçoit du contenu 5.1.
[C-SR-3] Lors du décodage, il est FORTEMENT RECOMMANDÉ que le décodeur indique le masque de canal utilisé sur le format de sortie avec la clé KEY_CHANNEL_MASK, en utilisant les constantes android.media.AudioFormat (exemple : CHANNEL_OUT_5POINT1).

5.1.3. Détails sur les codecs audio

Format/Codec	Détails	Types de fichiers/formats de conteneurs à prendre en charge
G.711 μ-law et A-law	Prise en charge du contenu mono/stéréo/5.1 échantillonné à 8 kHz	WAVE (.wav)
Profil AAC MPEG-4 (AAC LC)	Prise en charge des contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC brut ADTS (.aac, ADIF non accepté) MPEG-TS (.ts, non consultable, décodage uniquement) Matroska (.mkv, décodage uniquement)
Profil MPEG-4 HE AAC (AAC+)	Prise en charge des contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (AAC+ amélioré)	Prise en charge des contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC à faible délai amélioré)	Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC MPEG-D USAC avec MPEG-D DRC (Extended High Efficiency AAC)	Décodage : compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 7,35 à 48 kHz. Encodage : prise en charge du contenu mono/stéréo avec des taux d'échantillonnage de 44,1 et 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (.3gp)
AMR-WB	9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz, comme défini dans AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (.3gp)
FLAC	Les modes mono et stéréo DOIVENT être pris en charge pour l'encodeur et le décodeur. Les taux d'échantillonnage jusqu'à 192 kHz DOIVENT être pris en charge, et les résolutions 16 bits et 24 bits DOIVENT être prises en charge. La gestion des données audio FLAC 24 bits DOIT être disponible avec la configuration audio à virgule flottante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MP3	Mono/Stéréo, débit constant (CBR) ou variable (VBR) de 8 à 320 kbit/s	MP3 (.mp3) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MIDI	MIDI de type 0 et 1. DLS versions 1 et 2. XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody	Type 0 et 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	Décodage : prise en charge du contenu mono, stéréo, 5.0 et 5.1 avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz. Encodage : prise en charge du contenu mono et stéréo avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv) Webm (.webm)
PCM/WAVE	Le codec PCM DOIT être compatible avec le PCM linéaire 16 bits et le format à virgule flottante 16 bits. L'extracteur WAVE doit être compatible avec les formats PCM linéaire 16 bits, 24 bits et 32 bits, ainsi qu'avec le format à virgule flottante 32 bits (fréquences jusqu'à la limite du matériel). Les taux d'échantillonnage DOIVENT être compatibles de 8 kHz à 192 kHz.	WAVE (.wav)
Opus	Décodage : prise en charge des contenus mono, stéréo, 5.0 et 5.1 avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz. Encodage : prise en charge des contenus mono et stéréo avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv) Webm (.webm)

5.1.4. Encodage d'images

Pour en savoir plus, consultez la section 5.1.6. Détails des codecs d'image

Les implémentations d'appareils DOIVENT être compatibles avec l'encodage d'image suivant :

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- Les appareils doivent être compatibles avec BITRATE_MODE_CQ et le profil de référence.

Si les implémentations d'appareils sont compatibles avec l'encodage HEIC via android.media.MediaCodec pour le type de média MIMETYPE_IMAGE_ANDROID_HEIC, elles :

[C-1-1] DOIT fournir un codec d'encodeur HEVC à accélération matérielle compatible avec le mode de contrôle du débit binaire BITRATE_MODE_CQ, le profil HEVCProfileMainStill et la taille de trame de 512 x 512 px.

5.1.5. Décodage d'image

Pour en savoir plus, consultez la section 5.1.6. Détails des codecs d'image

Les implémentations d'appareils DOIVENT être compatibles avec le décodage de l'encodage d'image suivant :

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] Brut
[C-0-7] AVIF (profil de référence)

Si les implémentations d'appareils sont compatibles avec le décodage vidéo HEVC, elles :

[C-1-1] DOIT prendre en charge le décodage des images HEIF (HEIC).

Décodeurs d'images compatibles avec un format à haute profondeur de bits (9 bits ou plus par canal) :

[C-2-1] DOIT être compatible avec la sortie d'un format équivalent à 8 bits si l'application le demande, par exemple via la configuration ARGB_8888 de android.graphics.Bitmap.

5.1.6. Détails sur les codecs d'image

Format/Codec	Détails	Types de fichiers/formats de conteneurs compatibles
JPEG	Base+progressif	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Brut		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Image, collection d'images, séquence d'images	HEIF (.heif), HEIC (.heic)
AVIF (profil de référence)	Profils de référence Image, Collection d'images et Séquence d'images	Conteneur HEIF (.avif)

Encodeurs et décodeurs d'images exposés via l'API MediaCodec

[C-1-1] DOIT être compatible avec le format de couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) via CodecCapabilities.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le format de couleur RGB888 pour le mode Surface d'entrée.
[C-1-3] DOIT être compatible avec au moins un format de couleur YUV420 8:8:8 plan ou semi-plan : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'ils soient compatibles avec les deux.

5.1.7. Codecs vidéo

Pour une qualité acceptable des services de streaming vidéo et de visioconférence sur le Web, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel qui répond aux exigences.

Si les implémentations d'appareils incluent un décodeur ou un encodeur vidéo :

[C-1-1] Les codecs vidéo DOIVENT être compatibles avec les tailles de bytebuffer d'entrée et de sortie qui s'adaptent à la plus grande trame compressée et non compressée possible, comme le prévoient la norme et la configuration, mais sans surallocation.
[C-1-2] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec les formats de couleur flexibles YUV420 8:8:8 (COLOR_FormatYUV420Flexible) jusqu'à CodecCapabilities.
[C-1-3] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'ils soient compatibles avec les deux.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ que les encodeurs et décodeurs vidéo soient compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire optimisé pour le matériel (YV12, NV12, NV21 ou format équivalent optimisé par le fournisseur).
[C-1-5] Les décodeurs vidéo compatibles avec un format à haute profondeur de bits (9 bits ou plus par canal) DOIVENT être compatibles avec la sortie d'un format équivalent à 8 bits si l'application le demande. Cela DOIT se refléter dans la prise en charge d'un format de couleur YUV420 8:8:8 via android.media.MediaCodecInfo.

Si les implémentations d'appareils annoncent la compatibilité avec le profil HDR via Display.HdrCapabilities, elles :

[C-2-1] DOIT être compatible avec l'analyse et la gestion des métadonnées statiques HDR.

Si les implémentations d'appareil annoncent la prise en charge de l'actualisation intra par le biais de FEATURE_IntraRefresh dans la classe MediaCodecInfo.CodecCapabilities, elles :

[C-3-1] DOIT prendre en charge les périodes d'actualisation comprises entre 10 et 60 images, et fonctionner avec précision dans les limites de 20% de la période d'actualisation configurée.

Sauf indication contraire de l'application à l'aide de la clé de format KEY_COLOR_FORMAT, les implémentations de décodeur vidéo :

[C-4-1] DOIT utiliser par défaut le format de couleur optimisé pour l'affichage matériel s'il est configuré à l'aide de la sortie Surface.
[C-4-2] DOIT utiliser par défaut un format de couleur YUV420 8:8:8 optimisé pour la lecture du processeur s'il est configuré pour ne pas utiliser la sortie Surface.

Pour les implémentations d'appareils qui incluent un décodeur ou un encodeur vidéo :

[C-5-1] Les décodeurs vidéo utilisant une technologie de codage de 2003 ou ultérieure (tels qu'AV1, AVC, HEVC, VP8, VP9 ou VVC) DOIVENT :
- être d'une taille minimale de 144 x 144 px ;
- Faites la publicité de cette compatibilité via l'API VideoCapabilities, comme les méthodes getSupportedWidths() et getSupportedHeightsFor().
[C-5-2] Les encodeurs vidéo utilisant une technologie d'encodage de 2003 ou ultérieure (tels qu'AV1, AVC, HEVC, VP8, VP9 ou VVC) DOIVENT :
- La surface d'entrée doit avoir la taille minimale suivante pour chaque encodeur :
  - AVC : 160 x 160 px
  - VP8, HEVC, VP9 (si l'encodeur est fourni) : 160 x 160 px
  - AV1 (si l'encodeur est fourni) : 256 x 256 px
- PEUT générer un flux binaire avec une taille de frame supérieure à la taille minimale, à condition d'encoder la taille appropriée à l'aide des informations du rectangle de recadrage.

5.1.8. Liste des codecs vidéo

Format/Codec	Détails	Types de fichiers/formats de conteneurs à prendre en charge
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
H.264 AVC	Pour en savoir plus, consultez les sections 5.2 et 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, non compatible avec la recherche) Matroska (.mkv, décodage uniquement)
H.265 HEVC	Pour en savoir plus, consultez la section 5.3.	MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
MPEG-2	Main Profile	MPEG2-TS (.ts, non compatible avec la recherche) MPEG-4 (.mp4, décodage uniquement) Matroska (.mkv, décodage uniquement)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
VP8	Pour en savoir plus, consultez les sections 5.2 et 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Pour en savoir plus, consultez la section 5.3.	WebM (.webm) Matroska (.mkv)
AV1	Pour en savoir plus, consultez les sections 5.2 et 5.3.	MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)

5.1.9. Sécurité des codecs multimédias

Les implémentations d'appareils DOIVENT assurer la conformité avec les fonctionnalités de sécurité des codecs multimédias, comme décrit ci-dessous.

Android est compatible avec OMX, une API d'accélération multimédia multiplate-forme, ainsi qu'avec Codec 2.0, une API d'accélération multimédia à faible surcharge.

Si les implémentations d'appareils sont compatibles avec le multimédia, elles :

[C-1-1] DOIT prendre en charge les codecs multimédias via les API OMX ou Codec 2.0 (ou les deux) comme dans le Projet Android Open Source, et ne pas désactiver ni contourner les protections de sécurité. Cela ne signifie pas que chaque codec DOIT utiliser l'API OMX ou Codec 2.0, mais qu'au moins l'une de ces API DOIT être disponible et que la prise en charge des API disponibles DOIT inclure les protections de sécurité présentes.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la compatibilité avec l'API Codec 2.0.

Si les implémentations d'appareils ne sont pas compatibles avec l'API Codec 2.0, elles :

[C-2-1] DOIT inclure le codec logiciel OMX correspondant du projet Android Open Source (s'il est disponible) pour chaque format et type de contenu multimédia (encodeur ou décodeur) pris en charge par l'appareil.
[C-2-2] Codecs dont le nom commence par "OMX.google." DOIT être basé sur le code source du projet Android Open Source.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ que les codecs logiciels OMX s'exécutent dans un processus de codec qui n'a pas accès aux pilotes matériels autres que les mappeurs de mémoire.

Si les implémentations d'appareils sont compatibles avec l'API Codec 2.0, elles :

[C-3-1] DOIT inclure le codec logiciel Codec 2.0 correspondant du projet Android Open Source (s'il est disponible) pour chaque format et type de contenu multimédia (encodeur ou décodeur) pris en charge par l'appareil.
[C-3-2] DOIT héberger les codecs logiciels Codec 2.0 dans le processus de codec logiciel fourni dans le projet Android Open Source pour permettre d'accorder un accès plus limité aux codecs logiciels.
[C-3-3] Codecs dont le nom commence par "c2.android." DOIT être basé sur le code source du projet Android Open Source.

5.1.10. Caractérisation des codecs multimédias

Si les implémentations d'appareils sont compatibles avec les codecs multimédias, elles :

[C-1-1] DOIT renvoyer les valeurs correctes de la caractérisation du codec média via l'API MediaCodecInfo.

En particulier :

[C-1-2] Codecs dont le nom commence par "OMX." DOIT utiliser les API OMX et avoir des noms conformes aux consignes de dénomination OMX IL.
[C-1-3] Codecs dont le nom commence par "c2." DOIT utiliser l'API Codec 2.0 et avoir des noms conformes aux consignes de dénomination Codec 2.0 pour Android.
[C-1-4] Codecs dont le nom commence par "OMX.google." ou "c2.android." NE DOIT PAS être caractérisé comme un fournisseur ou comme une accélération matérielle.
[C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) et qui ont accès à des pilotes matériels autres que les allocateurs et les mappeurs de mémoire NE DOIVENT PAS être considérés comme des codecs logiciels uniquement.
[C-1-6] Les codecs qui ne sont pas présents dans le projet Android Open Source ou qui ne sont pas basés sur le code source de ce projet DOIVENT être caractérisés comme étant des codecs du fournisseur.
[C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés comme utilisant l'accélération matérielle.
[C-1-8] Les noms de codecs NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIVENT prendre en charge le décodage, et ceux nommés "encodeurs" DOIVENT prendre en charge l'encodage. Les codecs dont le nom contient des formats multimédias DOIVENT prendre en charge ces formats.

Si les implémentations d'appareils sont compatibles avec les codecs vidéo :

[C-2-1] Tous les codecs vidéo DOIVENT publier des données sur la fréquence d'images réalisable pour les tailles suivantes, si le codec les prend en charge :

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (encodeur MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (autre)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (encodeur MPEG4) 720 x 480 px (autre, AV1)	1 408 x 1 152 px (H263) 1 280 x 720 px (autre, AV1)	1 920 x 1 080 px (autre que MPEG4, AV1)	3 840 x 2 160 px (HEVC, VP9, AV1)

[C-2-2] Les codecs vidéo caractérisés comme étant à accélération matérielle DOIVENT publier des informations sur les points de performance. Chacun d'eux DOIT lister tous les points de performances standards acceptés (listés dans l'API PerformancePoint), sauf s'ils sont couverts par un autre point de performances standards accepté.
De plus, ils DOIVENT publier des points de performances étendus s'ils prennent en charge des performances vidéo soutenues autres que celles listées.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le mettent à la disposition des applications tierces, et définissent
MediaFormat.KEY_BITRATE_MODE sur BITRATE_MODE_VBR afin que l'encodeur fonctionne en mode à débit variable, le débit encodé :

NE DOIT PAS dépasser de plus de 15% le débit binaire entre les intervalles d'images intra-images (I-frames) sur une fenêtre glissante.
NE DOIT PAS dépasser 100% du débit binaire sur une fenêtre glissante d'une seconde.

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le mettent à la disposition des applications tierces, et si elles définissent MediaFormat.KEY_BITRATE_MODE sur BITRATE_MODE_CBR afin que l'encodeur fonctionne en mode à débit constant, le débit binaire encodé :

Il est FORTEMENT RECOMMANDÉ que [C-SR-2] ne dépasse pas 15% du débit cible sur une fenêtre glissante d'une seconde.

Si les implémentations d'appareils incluent un écran intégré d'une longueur diagonale d'au moins 2,5 pouces, un port de sortie vidéo ou déclarent la prise en charge d'un appareil photo via le flag de fonctionnalité android.hardware.camera.any, elles :

[C-1-1] DOIT inclure la prise en charge d'au moins l'un des encodeurs vidéo VP8 ou H.264, et le rendre disponible pour les applications tierces.
DOIT être compatible avec les encodeurs vidéo VP8 et H.264, et les mettre à la disposition des applications tierces.

Si les implémentations d'appareils sont compatibles avec l'un des encodeurs vidéo H.264, VP8, VP9 ou HEVC et le mettent à la disposition des applications tierces, elles :

[C-2-1] DOIT prendre en charge les débits configurables de manière dynamique.
DOIT être compatible avec les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son bit bucket en fonction de cette durée d'image.

Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le mettent à la disposition des applications tierces, elles :

DOIT être compatible avec les débits configurables de manière dynamique pour l'encodeur compatible.

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image accélérés par le matériel et prennent en charge une ou plusieurs caméras matérielles connectées ou enfichables exposées via les API android.camera :

[C-4-1] Tous les encodeurs vidéo et d'images avec accélération matérielle DOIVENT être compatibles avec l'encodage des frames provenant des caméras matérielles.
DOIT être compatible avec l'encodage des frames à partir des caméras matérielles via tous les encodeurs vidéo ou d'image.

Si les implémentations d'appareils fournissent un encodage HDR, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un plug-in pour l'API de transcodage fluide afin de convertir le format HDR en format SDR.

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et les mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT être compatible avec la résolution QCIF (176 x 144) en utilisant le profil de référence de niveau 45. La résolution SQCIF est facultative.

5.2.2. H.264

Si les implémentations d'appareils sont compatibles avec le codec H.264, elles :

[C-1-1] DOIT être compatible avec le profil de référence de niveau 3. Toutefois, la prise en charge d'ASO (Arbitrary Slice Ordering), de FMO (Flexible Macroblock Ordering) et de RS (Redundant Slices) est FACULTATIVE. De plus, pour maintenir la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
[C-1-2] MUST support the SD (Standard Definition) video encoding profiles in the following table.
DOIT être compatible avec le profil principal de niveau 4.
DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) indiqués dans le tableau suivant.

Si les implémentations d'appareils indiquent la prise en charge de l'encodage H.264 pour les vidéos en résolution 720p ou 1080p via les API Media, elles :

[C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	20 fps	30 ips	30 ips	30 ips
Débit vidéo	384 Kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.3. VP8

Si les implémentations d'appareils sont compatibles avec le codec VP8, elles :

[C-1-1] DOIT être compatible avec les profils d'encodage vidéo SD.
DOIT être compatible avec les profils d'encodage vidéo HD (haute définition) suivants.
[C-1-2] DOIT être compatible avec l'écriture de fichiers Matroska WebM.
DOIT fournir un codec VP8 matériel qui répond aux exigences de codage matériel RTC du projet WebM, afin de garantir une qualité acceptable des services de visioconférence et de streaming vidéo sur le Web.

Si les implémentations d'appareils indiquent la prise en charge de l'encodage VP8 pour les vidéos en résolution 720p ou 1080p via les API Media, elles :

[C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	800 Kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.4. VP9

Si les implémentations d'appareils sont compatibles avec le codec VP9, elles :

[C-1-2] DOIT être compatible avec le profil 0 niveau 3.
[C-1-1] DOIT être compatible avec l'écriture de fichiers Matroska WebM.
[C-1-3] DOIT générer des données CodecPrivate.
DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les profils de décodage HD indiqués dans le tableau suivant s'il existe un encodeur matériel.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils affirment prendre en charge le profil 2 ou le profil 3 via les API Media :

La prise en charge du format 12 bits est FACULTATIVE.

5.2.5. H.265

Si les implémentations d'appareils sont compatibles avec le codec H.265, elles :

[C-1-1] DOIT prendre en charge le profil principal de niveau 3 jusqu'à une résolution de 512 x 512.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil SD 720 x 480 et les profils d'encodage HD, comme indiqué dans le tableau suivant, si un encodeur matériel est disponible.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.2.6. AV1

Si les implémentations d'appareils sont compatibles avec le codec AV1, elles :

[C-1-1] DOIT être compatible avec le profil principal, y compris le contenu 8 bits et 10 bits.
[C-1-2] DOIT publier des données sur les performances, c'est-à-dire les signaler via les API getSupportedFrameRatesFor() ou getSupportedPerformancePoints() pour les résolutions compatibles dans le tableau ci-dessous.
[C-1-3] DOIT accepter les métadonnées HDR et les transmettre au flux binaire

Si l'encodeur AV1 est accéléré par le matériel, il :

[C-2-1] DOIT être compatible avec le profil d'encodage HD1080p inclus dans le tableau ci-dessous :

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	5 Mbit/s	8 Mbit/s	16 Mbit/s	50 Mbit/s

5.3. Décodage vidéo

Si les implémentations d'appareils sont compatibles avec les codecs VP8, VP9, H.264, H.265ou AV1, elles :

[C-1-1] DOIT être compatible avec le changement dynamique de résolution et de fréquence d'images vidéo via les API Android standards au sein du même flux pour tous les codecs VP8, VP9, H.264, H.265 et AV1 en temps réel et jusqu'à la résolution maximale prise en charge par chaque codec sur l'appareil.

5.3.1. MPEG-2

Si les implémentations d'appareils sont compatibles avec les décodeurs MPEG-2, elles :

[C-1-1] DOIT être compatible avec le profil principal de niveau élevé.

5.3.2. H.263

Si les implémentations d'appareils sont compatibles avec les décodeurs H.263, elles :

[C-1-1] DOIT être compatible avec le profil de référence de niveau 30 (résolutions CIF, QCIF et SQCIF à 30 fps et 384 kbit/s) et de niveau 45 (résolutions QCIF et SQCIF à 30 fps et 128 kbit/s).

5.3.3. MPEG-4

Si les implémentations d'appareils comportent des décodeurs MPEG-4, elles :

[C-1-1] DOIT être compatible avec le profil simple de niveau 3.

5.3.4. H.264

Si les implémentations d'appareils sont compatibles avec les décodeurs H.264, elles :

[C-1-1] DOIT être compatible avec le profil principal de niveau 3.1 et le profil de référence. La prise en charge d'ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (Redundant Slices) est FACULTATIVE.
[C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (définition standard) listés dans le tableau suivant et encodés avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
DOIT être capable de décoder les vidéos avec les profils HD (haute définition) indiqués dans le tableau suivant.

Si la hauteur signalée par la méthode Display.getSupportedModes() est supérieure ou égale à la résolution de la vidéo, les implémentations d'appareil :

[C-2-1] DOIT être compatible avec les profils de décodage vidéo HD 720p du tableau suivant.
[C-2-2] DOIT être compatible avec les profils de décodage vidéo HD 1080p du tableau suivant.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	60 fps	30 fps (60 fps^Télévision)
Débit vidéo	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.5. H.265 (HEVC)

Si les implémentations d'appareils sont compatibles avec le codec H.265, elles :

[C-1-1] DOIT être compatible avec le profil principal de niveau 3 et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
[C-1-2] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant s'il existe un décodeur matériel.

Si la hauteur signalée par la méthode Display.getSupportedModes() est supérieure ou égale à la résolution de la vidéo :

[C-2-1] Les implémentations d'appareils DOIVENT prendre en charge au moins le décodage H.265 ou VP9 des profils 720, 1080 et UHD.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	352 x 288 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30/60 fps (60 fps^{Télévision avec décodage matériel H.265})	60 fps
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils affirment être compatibles avec un profil HDR via les API Media :

[C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises de l'application, ainsi que prendre en charge l'extraction et la sortie des métadonnées HDR requises du flux binaire et/ou du conteneur.
[C-3-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.6. VP8

Si les implémentations d'appareils sont compatibles avec le codec VP8, elles :

[C-1-1] DOIT prendre en charge les profils de décodage SD du tableau suivant.
DOIT utiliser un codec matériel VP8 qui répond aux exigences.
DOIT prendre en charge les profils de décodage HD du tableau suivant.

Si la hauteur signalée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo :

[C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec les profils 720p du tableau suivant.
[C-2-2] Les implémentations d'appareils DOIVENT être compatibles avec les profils 1080p du tableau suivant.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 fps (60 fps^Télévision)	30 (60 fps^Télévision)
Débit vidéo	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.7. VP9

Si les implémentations d'appareils sont compatibles avec le codec VP9, elles :

[C-1-1] DOIT être compatible avec les profils de décodage vidéo SD indiqués dans le tableau suivant.
DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

Si les implémentations d'appareils sont compatibles avec le codec VP9 et un décodeur matériel :

[C-2-1] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant.

Si la hauteur signalée par la méthode Display.getSupportedModes() est supérieure ou égale à la résolution de la vidéo :

[C-3-1] Les implémentations d'appareils DOIVENT prendre en charge au moins le décodage VP9 ou H.265 des profils 720, 1080 et UHD.

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 fps (60 fps^{Télévision avec décodage matériel VP9})	60 fps
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils affirment être compatibles avec VP9Profile2 ou VP9Profile3 via les API multimédias CodecProfileLevel :

La prise en charge du format 12 bits est FACULTATIVE.

Si les implémentations d'appareils affirment être compatibles avec un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API Media :

[C-4-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises (KEY_HDR_STATIC_INFO pour tous les profils HDR, ainsi que 'KEY_HDR10_PLUS_INFO' pour les profils HDR10Plus) provenant de l'application. Ils DOIVENT également être capables d'extraire et de générer les métadonnées HDR requises à partir du flux binaire et/ou du conteneur.
[C-4-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

Si les implémentations d'appareils déclarent la prise en charge du décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION, elles :

[C-1-1] DOIT fournir un extracteur compatible Dolby Vision.
[C-1-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un écran externe connecté via un port de sortie vidéo standard (tel que HDMI).
[C-1-3] DOIT définir l'ID de piste de la ou des couches de base rétrocompatibles (le cas échéant) sur la même valeur que l'ID de piste de la couche Dolby Vision combinée.

5.3.9. AV1

Si les implémentations d'appareils sont compatibles avec le codec AV1 et le mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT être compatible avec le profil principal, y compris le contenu 8 bits et 10 bits.

Si les implémentations d'appareils sont compatibles avec le codec AV1 avec un décodeur à accélération matérielle, elles :

[C-2-1] DOIT être capable de décoder au moins les profils de décodage vidéo HD 720p du tableau ci-dessous lorsque la hauteur signalée par la méthode Display.getSupportedModes() est égale ou supérieure à 720p.
[C-2-2] DOIT être capable de décoder au moins les profils de décodage vidéo HD 1080p du tableau ci-dessous lorsque la hauteur signalée par la méthode Display.getSupportedModes() est égale ou supérieure à 1080p.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	5 Mbit/s	8 Mbit/s	16 Mbit/s	50 Mbit/s

Si les implémentations d'appareils sont compatibles avec le profil HDR via les API Media, elles :

[C-3-1] DOIT permettre d'extraire et de générer des métadonnées HDR à partir du flux binaire et/ou du conteneur.
[C-3-2] DOIT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient listées comme SHOULD (DOIT) depuis Android 4.3, la définition de compatibilité pour les futures versions prévoit de les remplacer par MUST (DOIT). Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences listées comme "SHOULD" (DOIVENT), sinon ils ne pourront pas atteindre la compatibilité Android lorsqu'ils seront mis à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

Si les implémentations d'appareil déclarent android.hardware.microphone, elles :

[C-1-1] DOIT autoriser la capture de contenu audio brut pour tout flux d'ENTRÉE AudioRecord ou AAudio ouvert avec succès. Au minimum, les caractéristiques suivantes DOIVENT être prises en charge :
- Format : PCM linéaire, 16 bits
- Taux d'échantillonnage : 8 000, 11 025, 16 000, 44 100, 48 000 Hz
- Canaux : mono
- Sources audio : DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Cela s'applique également aux préréglages d'entrée équivalents dans AAudio, par exemple AAUDIO_INPUT_PRESET_CAMCORDER.
DOIT autoriser la capture de contenu audio brut présentant les caractéristiques suivantes :
- Format : PCM linéaire, 16 bits et 24 bits
- Taux d'échantillonnage : 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
- Canaux : autant de canaux que de micros sur l'appareil
[C-1-2] MUST capture at above sample rates without up-sampling.
[C-1-3] DOIT inclure un filtre anti-aliasing approprié lorsque les taux d'échantillonnage ci-dessus sont capturés avec un sous-échantillonnage.
DOIT autoriser la capture de contenu audio brut de qualité radio AM et DVD, ce qui signifie les caractéristiques suivantes :
- Format : PCM linéaire, 16 bits
- Taux d'échantillonnage : 22 050, 48 000 Hz
- Chaînes : stéréo
[C-1-4] DOIT respecter l'API MicrophoneInfo et renseigner correctement les informations concernant les microphones disponibles sur l'appareil et accessibles aux applications tierces via l'API AudioManager.getMicrophones(), pour AudioRecord actif utilisant MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. Si les implémentations d'appareils autorisent la capture de contenu audio brut de qualité AM et DVD, elles :
[C-2-1] DOIT capturer sans suréchantillonner à un rapport supérieur à 16000:22050 ou 44100:48000.
[C-2-2] DOIT inclure un filtre anti-aliasing approprié pour tout suréchantillonnage ou sous-échantillonnage.

5.4.2. Capture pour la reconnaissance vocale

Si les implémentations d'appareil déclarent android.hardware.microphone, elles :

[C-1-1] DOIT capturer la source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION à l'un des taux d'échantillonnage suivants : 44 100 et 48 000.
[C-1-2] DOIT, par défaut, désactiver tout traitement audio de réduction du bruit lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
[C-1-3] DOIT, par défaut, désactiver tout contrôle automatique du gain lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
DOIT présenter des caractéristiques d'amplitude-fréquence relativement plates dans la gamme de fréquences moyennes, plus précisément ±3 dB de 100 Hz à 4 000 Hz pour chacun des micros utilisés pour enregistrer la source audio de reconnaissance vocale.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ que les niveaux d'amplitude dans la plage de basses fréquences (plus précisément de ±20 dB de 30 Hz à 100 Hz) soient comparables à ceux de la plage de moyennes fréquences pour chacun des microphones utilisés pour enregistrer la source audio de reconnaissance vocale.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ que les niveaux d'amplitude dans la plage de hautes fréquences (plus précisément de ±30 dB de 4 000 Hz à 22 kHz) soient comparables à ceux de la plage de moyennes fréquences pour chacun des microphones utilisés pour enregistrer la source audio de reconnaissance vocale.
DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 90 dB (mesuré à côté du micro) produise une réponse idéale de 2 500 RMS dans une plage comprise entre 1 770 et 3 530 pour les échantillons de 16 bits (ou -22,35 dB ±3 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chacun des micros utilisés pour enregistrer la source audio de reconnaissance vocale.
DOIT enregistrer le flux audio de reconnaissance vocale de sorte que les niveaux d'amplitude PCM suivent de manière linéaire les variations du niveau de pression acoustique d'entrée sur une plage d'au moins 30 dB, de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
DOIT enregistrer le flux audio de reconnaissance vocale avec une distorsion harmonique totale (THD) inférieure à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.

Si les implémentations d'appareils déclarent android.hardware.microphone et des technologies de suppression (réduction) du bruit adaptées à la reconnaissance vocale, elles :

[C-2-1] DOIT permettre de contrôler cet effet audio avec l'API android.media.audiofx.NoiseSuppressor.
[C-2-2] DOIT identifier de manière unique chaque implémentation de technologie de suppression du bruit à l'aide du champ AudioEffect.Descriptor.uuid.

5.4.3. Capture pour le reroutage de la lecture

La classe android.media.MediaRecorder.AudioSource inclut la source audio REMOTE_SUBMIX.

Si les implémentations d'appareil déclarent android.hardware.audio.output et android.hardware.microphone, elles :

[C-1-1] DOIT implémenter correctement la source audio REMOTE_SUBMIX afin que, lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle capture un mix de tous les flux audio, à l'exception des suivants :
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. Annulation de l'écho acoustique

Si les implémentations d'appareil déclarent android.hardware.microphone, elles :

DOIT implémenter une technologie d'annulation de l'écho acoustique (AEC, Acoustic Echo Canceler) adaptée à la communication vocale et appliquée au chemin de capture lors de la capture à l'aide de AudioSource.VOICE_COMMUNICATION.

Si les implémentations d'appareils fournissent un annuleur d'écho acoustique inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION est sélectionné, elles :

[C-SR-1] [C-1-1] are STRONGLY_RECOMMENDED MUST declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable() returning true.

[C-1-2] DOIT refléter l'activation de l'AEC sur le chemin audio via la méthode d'API AcousticEchoCanceler AcousticEchoCanceler.getEnabled(), qui doit renvoyer true lorsqu'elle est active et false lorsqu'elle est inactive.

[C-SR-2] [C-SR-1] sont FORTEMENT RECOMMANDÉS pour permettre de contrôler cet effet audio avec l'API AcousticEchoCanceler.
[C-SR-3] [C-SR-2] sont FORTEMENT RECOMMANDÉS pour identifier de manière unique chaque implémentation de la technologie AEC via le champ AudioEffect.Descriptor.uuid.

5.4.5. Capture simultanée

Si les implémentations d'appareil déclarent android.hardware.microphone, elles DOIVENT implémenter la capture simultanée comme décrit dans ce document. Plus précisément :

[C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité capturant avec AudioSource.VOICE_RECOGNITION et au moins une application capturant avec n'importe quel AudioSource.
[C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application qui capture avec n'importe quel AudioSource, à l'exception de AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
[C-1-3] DOIT couper le son capturé par toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application capture du son avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application capture un appel via AudioSource.VOICE_COMMUNICATION, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec l'autorisation CAPTURE_AUDIO_OUTPUT.
[C-1-4] Si deux applications ou plus capturent simultanément et qu'aucune d'elles n'a d'UI au premier plan, celle qui a commencé la capture le plus récemment reçoit l'audio.

5.5. Lecture audio

Android permet aux applications de lire du contenu audio via le périphérique de sortie audio, comme défini dans la section 7.8.2.

5.5.1. Lecture audio brute

Si les implémentations d'appareil déclarent android.hardware.audio.output, elles :

[C-1-1] DOIT autoriser la lecture de contenus audio bruts présentant les caractéristiques suivantes :
- Formats sources : PCM linéaire, 16 bits, 8 bits, float
- Canaux : mono, stéréo, configurations multicanaux valides avec jusqu'à huit canaux
- Taux d'échantillonnage (en Hz) :
  - 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 pour les configurations de canaux listées ci-dessus
  - 96 000 en mono et en stéréo

5.5.2. Effets audio

Android fournit une API pour les effets audio pour les implémentations d'appareils.

Si les implémentations d'appareil déclarent la fonctionnalité android.hardware.audio.output, elles :

[C-1-1] DOIT prendre en charge les implémentations EFFECT_TYPE_EQUALIZER et EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via les sous-classes AudioEffect Equalizer et LoudnessEnhancer.
[C-1-2] DOIT être compatible avec l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer.
[C-1-3] DOIT prendre en charge l'implémentation EFFECT_TYPE_DYNAMICS_PROCESSING contrôlable via la sous-classe AudioEffect DynamicsProcessing.
[C-1-4] DOIT prendre en charge les effets audio avec entrée et sortie à virgule flottante, lorsque les résultats des effets sont renvoyés au pipeline audio du framework. Il s'agit des effets d'insertion ou auxiliaires classiques, comme l'égaliseur. Un comportement équivalent est fortement recommandé lorsque les résultats des effets ne sont pas visibles par le pipeline audio du framework, tels que les effets de post-traitement ou déchargés.
[C-1-5] DOIT s'assurer que les effets audio sont compatibles avec plusieurs canaux jusqu'au nombre de canaux du mixeur, également appelé FCC_LIMIT, lorsque les résultats des effets sont renvoyés au pipeline audio du framework. Cela fait référence aux effets d'insertion ou auxiliaires typiques, mais exclut les effets spéciaux tels que les effets de mixage stéréo, de mixage mono ou de spatialisation qui modifient le nombre de canaux. Un comportement équivalent est recommandé lorsque les effets ne sont pas visibles par le pipeline audio du framework, tels que les effets de post-traitement ou déchargés.
DOIT être compatible avec les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlables par le biais des sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les effets en virgule flottante et multicanaux.

5.5.3. Volume de sortie audio

Implémentations d'appareils automobiles :

DOIT permettre de régler le volume audio séparément pour chaque flux audio en utilisant le type de contenu ou l'utilisation tels que définis par AudioAttributes et l'utilisation de l'audio de la voiture telle que définie publiquement dans android.car.CarAudioManager.

5.5.4. Déchargement audio

Si les implémentations d'appareils sont compatibles avec la lecture avec déchargement audio, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de supprimer le contenu audio sans interruption lu entre deux extraits de même format lorsque cela est spécifié par l'API AudioTrack sans interruption et le conteneur multimédia pour MediaPlayer.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter la lecture en décharge pour les formats AAC, MP3, OPUS et PCM.

Si les implémentations d'appareils déclarent la prise en charge du déchargement MMAP PCM (déclaré par un port de mixage avec des indicateurs contenant AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD et AUDIO_OUTPUT_FLAG_MMAP_NOIRQ), elles :

[C-1-1] DOIT prendre en charge au moins AUDIO_FORMAT_PCM_16_BIT, à 44,1 kHz et 48 kHz pour le stéréo et le mono.
[C-1-2] DOIT disposer d'une taille de mémoire tampon capable de stocker au moins 5 secondes d'audio au format PCM stéréo 16 bits par échantillon à 48 kHz.

5.5.5. Paramètres de lecture

Si les implémentations d'appareils sont compatibles avec l'API PlaybackParams, les paramètres de lecture :

[C-1-1] DOIT prendre en charge les vitesses comprises entre 0,5 et 2,0 avec une hauteur de 1,0.

5.6. Latence audio

La latence audio correspond au délai de transmission d'un signal audio dans un système. De nombreuses classes d'applications reposent sur de faibles latences pour obtenir des effets sonores en temps réel.

Dans le cadre de cette section, utilisez les définitions suivantes :

Latence de sortie : Intervalle entre le moment où une application écrit une trame de données codées PCM et le moment où le son correspondant est présenté à l'environnement au niveau d'un transducteur sur l'appareil ou où le signal quitte l'appareil via un port et peut être observé à l'extérieur.
Latence de sortie à froid : Temps écoulé entre le début d'un flux de sortie et le code temporel du premier frame, lorsque le système de sortie audio a été inactif et éteint avant la requête.
Latence de sortie continue Latence de sortie pour les frames suivants, une fois que l'appareil lit l'audio.
Latence d'entrée : Intervalle entre le moment où un son est présenté par l'environnement à un transducteur sur l'appareil ou où un signal entre dans l'appareil via un port, et le moment où une application lit la trame de données codées PCM correspondante.
Entrée perdue Portion initiale d'un signal d'entrée inutilisable ou indisponible.
Latence d'entrée à froid : Temps écoulé entre le début du flux et la réception de la première image valide, lorsque le système d'entrée audio est resté inactif et éteint avant la requête.
Latence d'entrée continue : Latence d'entrée pour les frames suivants, pendant que l'appareil enregistre l'audio.
latence aller-retour continue. La somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de mémoire tampon. La période tampon permet à l'application de traiter le signal et d'atténuer la différence de phase entre les flux d'entrée et de sortie.
API de file d'attente de tampon PCM OpenSL ES Ensemble d'API OpenSL ES liées à PCM dans Android NDK.
API audio native AAudio Ensemble d'API AAudio dans le NDK Android.
Timestamp. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Voir aussi AudioTimestamp.
glitch. Il s'agit d'une interruption temporaire ou d'une valeur d'échantillon incorrecte dans le signal audio, généralement causée par un dépassement négatif du tampon pour la sortie, un dépassement positif du tampon pour l'entrée ou toute autre source de bruit numérique ou analogique.
écart absolu moyen (MAD). Moyenne de la valeur absolue des écarts par rapport à la moyenne pour un ensemble de valeurs.
La latence entre le toucher et le son (TTL), telle que mesurée par CTS Verifier, correspond au délai entre le moment où l'écran est touché et le moment où un son généré à la suite de cette action est entendu sur le haut-parleur. Il s'agit d'une moyenne de cinq mesures utilisant l'API audio native AAudio pour la sortie.
La latence aller-retour, telle que mesurée par le CTS Verifier, correspond à la latence continue moyenne sur cinq mesures, mesurée sur un chemin de rebouclage qui renvoie la sortie à l'entrée, à l'aide de l'API audio native AAudio.

Les chemins de bouclage sont les suivants :
- Haut-parleur/micro : du haut-parleur intégré au micro intégré.
- Analogique : connecteur analogique 3,5 mm et adaptateur de boucle.
- USB : adaptateur USB vers 3,5 mm et adaptateur de rebouclage ou interface audio USB et câbles de rebouclage.
FEATURE_AUDIO_LOW_LATENCY. La fonctionnalité android.hardware.audio.low_latency est déclarée.
FEATURE_AUDIO_PRO. La fonctionnalité android.hardware.audio.pro est déclarée.
MPC. Classe de performances multimédias.
Latence du suivi de la tête : Temps écoulé entre le moment où le mouvement de la tête est capturé par l'unité de mesure inertielle (IMU) et le moment où les transducteurs du casque détectent le changement de son provoqué par ce mouvement.

Implémentations sur les appareils :

[C-0-1] DOIT s'assurer que lorsqu'une application appelle android.media.AudioManager.setCommunicationDevice() avec un device compatible (comme des casques filaires, des haut-parleurs ou des écouteurs intégrés, ou des casques USB), le rappel android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() est invoqué avec cet appareil audio dans les 1 500 ms suivant le retour de l'appel setCommunicationDevice() avec true.

Si les implémentations d'appareil déclarent android.hardware.audio.output, elles DOIVENT respecter ou dépasser les exigences suivantes :

[C-1-1] Exigence supprimée dans Android 15.
[C-1-2] Latence de l'affichage à froid de 500 millisecondes ou moins.
[C-1-3] L'ouverture d'un flux de sortie à l'aide de AAudioStreamBuilder_openStream()DOIT prendre moins de 1 000 millisecondes.
[C-1-4] Les latences aller-retour calculées en fonction des codes temporels d'entrée et de sortie renvoyés par AAudioStream_getTimestamp DOIVENT être inférieures à 200 ms par rapport à la latence aller-retour mesurée pour AAUDIO_PERFORMANCE_MODE_NONE et AAUDIO_PERFORMANCE_MODE_LOW_LATENCY pour les enceintes, les casques filaires et les casques sans fil.
[C-SR-1] Exigence supprimée dans Android 15.
[C-SR-2] Exigence supprimée dans Android 15.
[C-SR-4] Exigence supprimée dans Android 15.
[C-SR-5] Exigence supprimée dans Android 15.
[C-SR-6] Exigence supprimée dans Android 15.
[C-SR-7] Exigence supprimée dans Android 15.
[C-2-1] Exigence supprimée dans Android 15.

Si les implémentations d'appareil incluent android.hardware.microphone, elles DOIVENT répondre aux exigences suivantes concernant l'entrée audio :

[C-3-1] Exigence supprimée dans Android 15.
[C-3-2] Latence d'entrée à froid de 500 millisecondes ou moins.
[C-3-3] L'ouverture d'un flux d'entrée à l'aide de AAudioStreamBuilder_openStream() DOIT prendre moins de 1 000 millisecondes.
[C-SR-8] Exigence supprimée dans Android 15.
[C-SR-11] Exigence supprimée dans Android 15.
[C-SR-12] Exigence supprimée dans Android 15.

Le tableau suivant définit les exigences concernant le RTL pour les implémentations d'appareils portables, comme défini dans la section 2.2.1 qui déclare android.hardware.audio.output et android.hardware.microphone.

Appareil et déclarations	RTL (ms)	MAD (ms)	Chemins de bouclage
Caméra à la main	200	25	Haut-parleur/micro, analogique 3,5 mm (si pris en charge), USB (si pris en charge)
MPC_C (17) ou version ultérieure	65	10	tous les chemins de données compatibles
>= MPC_T (13) à MPC_B (16)	80	15	au moins un chemin d'accès.
FEATURE_AUDIO_LOW_LATENCY	50	10	au moins un chemin d'accès.
FEATURE_AUDIO_PRO	25	5	au moins un chemin d'accès.
FEATURE_AUDIO_PRO	20	5	analogique (si pris en charge)
FEATURE_AUDIO_PRO	25	5	USB (si l'analogique n'est pas pris en charge)

Le tableau suivant définit les exigences concernant le TTL pour les implémentations d'appareils portables, comme défini dans la section 2.2.1 qui déclare android.hardware.audio.output et android.hardware.microphone.

Appareil et déclarations	TTL (ms)
Caméra à la main	250
MPC_C (17) ou version ultérieure	65
>= MPC_T (13) à MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

Si les implémentations d'appareils incluent la prise en charge de spatial audio avec suivi de la tête et déclarent l'indicateur PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY, elles :

[C-4-1] La latence maximale entre le suivi de la tête et la mise à jour audio DOIT être de 300 ms.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT être compatibles avec les protocoles de réseau multimédia pour la lecture audio et vidéo, comme spécifié dans la documentation du SDK Android.

Pour chaque codec et format de conteneur qu'une implémentation d'appareil doit prendre en charge, l'implémentation d'appareil :

[C-1-1] DOIT être compatible avec ce codec ou ce conteneur via HTTP et HTTPS.
[C-1-2] DOIT être compatible avec les formats de segments multimédias correspondants, comme indiqué dans le tableau des formats de segments multimédias ci-dessous, sur la base du protocole HTTP Live Streaming, version 7.
[C-1-3] DOIT être compatible avec les formats de charge utile RTSP correspondants, comme indiqué dans le tableau RTSP ci-dessous. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau de la section 5.1.

Formats des segments multimédias

Formats de segments	Référence(s)	Compatibilité avec les codecs requise
MPEG-2 Transport Stream	ISO 13818	Codecs vidéo : H264 AVC MPEG-4 SP MPEG-2 Pour en savoir plus sur H264 AVC, MPEG2-4 SP, et MPEG-2, consultez la section 5.1.8. Codecs audio : AAC Pour en savoir plus sur le format AAC et ses variantes, consultez la section 5.1.3.
AAC avec encadrement ADTS et tags ID3	ISO 13818-7	Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1 .
WebVTT	WebVTT

Formats de segments

Référence(s)

Compatibilité avec les codecs requise

MPEG-2 Transport Stream

ISO 13818

Codecs vidéo :

H264 AVC
MPEG-4 SP
MPEG-2

Pour en savoir plus sur H264 AVC, MPEG2-4 SP,
et MPEG-2, consultez la section 5.1.8.

Codecs audio :

Pour en savoir plus sur le format AAC et ses variantes, consultez la section 5.1.3.

AAC avec encadrement ADTS et tags ID3

ISO 13818-7

Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1 .

WebVTT

RTSP (RTP, SDP)

Nom du profil	Référence(s)	Compatibilité avec les codecs requise
H264 AVC	RFC 6184	Pour en savoir plus sur H264 AVC, consultez la section 5.1.8.
MP4A-LATM	RFC 6416	Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Pour en savoir plus sur H263, consultez la section 5.1.8.
H263-2000	RFC 4629	Pour en savoir plus sur H263, consultez la section 5.1.8.
AMR	RFC 4867	Pour en savoir plus sur AMR-NB, consultez la section 5.1.3.
AMR-WB	RFC 4867	Pour en savoir plus sur AMR-WB, consultez la section 5.1.3.
MP4V-ES	RFC 6416	Pour en savoir plus sur MPEG-4 SP, consultez la section 5.1.8.
mpeg4-generic	RFC 3640	Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.3.
MP2T	RFC 2250	Pour en savoir plus, consultez Flux de transport MPEG-2 sous HTTP Live Streaming.

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec les sorties vidéo sécurisées et les surfaces sécurisées, elles :

[C-1-1] DOIT déclarer la prise en charge de Display.FLAG_SECURE.

Si les implémentations d'appareils déclarent la compatibilité avec Display.FLAG_SECURE et le protocole d'affichage sans fil, elles :

[C-2-1] DOIT sécuriser la liaison avec un mécanisme cryptographique fort tel que HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil tels que Miracast.

Si les implémentations d'appareils déclarent la compatibilité avec Display.FLAG_SECURE et la compatibilité avec un écran externe filaire, elles :

[C-3-1] DOIT être compatible avec HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible par l'utilisateur.

5.9. Musical Instrument Digital Interface (MIDI)

Si les implémentations d'appareil signalent la compatibilité avec la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager, elles :

[C-1-1] DOIT être compatible avec le protocole MIDI sur tous les transports matériels compatibles avec le protocole MIDI pour lesquels il fournit une connectivité générique non MIDI, où ces transports sont les suivants :
- Mode hôte USB, section 7.7
- MIDI sur Bluetooth LE agissant en tant que périphérique central, section 7.4.3
[C-1-2] DOIT être compatible avec le transport logiciel MIDI entre applications (appareils MIDI virtuels)
[C-1-3] DOIT inclure libamidi.so (compatibilité MIDI native)
DOIT prendre en charge le mode périphérique MIDI sur USB, section 7.7

5.10. Audio professionnel

Si les implémentations d'appareil signalent la compatibilité avec la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles :

[C-1-1] DOIT signaler la compatibilité avec la fonctionnalité android.hardware.audio.low_latency.
[C-1-2] DOIT respecter les exigences de latence pour FEATURE_AUDIO_PRO, telles que définies dans la section 5.6 Latence audio .
[C-1-3] DOIT inclure un ou plusieurs ports USB prenant en charge le mode hôte USB et le mode périphérique USB.
[C-1-4] DOIT signaler la compatibilité avec la fonctionnalité android.software.midi.
[C-1-5] DOIT respecter les exigences de latence audio USB en utilisant l'API AAudio native audio et AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] La latence de sortie à froid DOIT être inférieure ou égale à 200 millisecondes.
[C-1-7] La latence d'entrée à froid DOIT être inférieure ou égale à 200 millisecondes.

Si les implémentations d'appareils incluent un connecteur audio 3,5 mm à quatre conducteurs, elles :

[C-2-2] DOIT respecter la section Spécifications des appareils mobiles (connecteur) de la Spécification des casques audio filaires (v1.1).

Si les implémentations d'appareils omettent un connecteur audio 3,5 mm à quatre conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB, elles :

[C-3-1] DOIT implémenter la classe audio USB.

5.11. Capture pour "Non traité"

Android permet d'enregistrer de l'audio non traité via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, il est accessible avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si les implémentations d'appareils ont l'intention de prendre en charge la source audio brute et de la mettre à la disposition des applications tierces, elles :

[C-1-1] DOIT signaler la prise en charge via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] DOIT présenter des caractéristiques d'amplitude-versus-fréquence à peu près plates dans la gamme de fréquences moyennes : plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-3] DOIT présenter des niveaux d'amplitude dans la plage de basses fréquences, plus précisément de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de moyennes fréquences pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-4] DOIT présenter des niveaux d'amplitude dans la plage de hautes fréquences : plus précisément, de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de moyennes fréquences pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-5] DOIT définir la sensibilité de l'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 94 dB produise une réponse avec une valeur RMS de 520 pour les échantillons de 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chacun des microphones utilisés pour enregistrer la source audio brute.
[C-1-6] DOIT présenter un rapport signal/bruit (SNR) de 60 dB ou plus pour chacun des micros utilisés pour enregistrer la source audio brute. (alors que le SNR est mesuré comme la différence entre 94 dB SPL et le SPL équivalent du bruit propre, pondéré A).
[C-1-7] DOIT présenter un taux de distorsion harmonique totale (THD) inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-8] Le chemin ne DOIT PAS comporter d'autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou annulation de l'écho) qu'un multiplicateur de niveau pour ramener le niveau à la plage souhaitée. Autrement dit :
- [C-1-9] Si un traitement du signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et n'introduire aucun retard ni aucune latence supplémentaire dans le chemin du signal.
- [C-1-10] Le multiplicateur de niveau, bien qu'il puisse se trouver sur le chemin, NE DOIT PAS introduire de retard ni de latence dans le chemin du signal.

Toutes les mesures SPL sont effectuées directement à côté du microphone testé. Pour les configurations à plusieurs micros, ces exigences s'appliquent à chaque micro.

Si les implémentations d'appareils déclarent android.hardware.microphone, mais ne sont pas compatibles avec la source audio non traitée, elles :

[C-2-1] DOIT renvoyer null pour la méthode d'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), afin d'indiquer correctement l'absence de prise en charge.
Il est TOUJOURS FORTEMENT RECOMMANDÉ de respecter les exigences [C-SR-1] afin de satisfaire autant d'exigences que possible pour le chemin du signal de la source d'enregistrement non traitée.

5.12. Vidéo HDR

Android 13 est compatible avec les technologies HDR décrites dans un prochain document.

Format Pixel

Si un décodeur vidéo indique qu'il est compatible avec COLOR_FormatYUVP010, alors :

[C-1-1] DOIT être compatible avec le format P010 pour la lecture par le processeur (ImageReader, MediaImage, ByteBuffer). Dans Android 13, P010 est assoupli pour autoriser un pas arbitraire pour les plans Y et UV.
[C-1-2] La mémoire tampon de sortie P010 DOIT pouvoir être échantillonnée par le GPU (lorsqu'elle est allouée avec l'utilisation GPU_SAMPLING). Cela permet la composition du GPU et le mappage de tonalités personnalisé par les applications.

Si un décodeur vidéo indique qu'il est compatible avec COLOR_Format32bitABGR2101010, cela signifie qu'il :

[C-2-1] DOIT être compatible avec le format RGBA_1010102 pour la surface de sortie et la sortie ByteBuffer lisible par le processeur.

Si un encodeur vidéo annonce la compatibilité avec COLOR_FormatYUVP010, cela signifie qu'il :

[C-3-1] DOIT être compatible avec le format P010 pour la surface d'entrée et l'entrée accessible en écriture par le processeur (ImageWriter, MediaImage, ByteBuffer).

Si un encodeur vidéo annonce la compatibilité avec COLOR_Format32bitABGR2101010, cela signifie qu'il :

[C-4-1] DOIT être compatible avec le format RGBA_1010102 pour la surface d'entrée et l'entrée accessible en écriture par le processeur (ImageWriter, ByteBuffer). Remarque : Les encodeurs n'ont PAS besoin de convertir les différentes courbes de transfert.

Exigences relatives à la capture HDR

Pour tous les encodeurs vidéo compatibles avec les profils HDR, les implémentations d'appareils :

[C-5-1] NE DOIT PAS supposer que les métadonnées HDR sont précises. Par exemple, le frame encodé peut comporter des pixels au-delà du niveau de luminance maximal ou l'histogramme peut ne pas être représentatif du frame.
DOIT agréger les métadonnées dynamiques HDR pour générer les métadonnées statiques HDR appropriées pour les flux encodés et DOIT les générer à la fin de chaque session d'encodage.

Si les implémentations d'appareils sont compatibles avec la capture HDR à l'aide des API CamcorderProfile, elles :

[C-6-1] DOIT également être compatible avec la capture HDR via les API Camera2.
[C-6-2] DOIT être compatible avec au moins un encodeur vidéo à accélération matérielle pour chaque technologie HDR prise en charge.
[C-6-3] DOIT prendre en charge (au minimum) la capture HLG.
[C-6-4] DOIT permettre d'écrire les métadonnées HDR (le cas échéant pour la technologie HDR) dans le fichier vidéo capturé. Pour AV1, HEVC et DolbyVision, cela signifie inclure les métadonnées dans le flux binaire encodé.
[C-6-5] DOIT être compatible avec P010 et COLOR_FormatYUVP010.
[C-6-6] DOIT prendre en charge le mappage de tonalités HDR vers SDR dans le décodeur par défaut avec accélération matérielle pour le profil capturé. En d'autres termes, si un appareil peut capturer du contenu HEVC HDR10+, le décodeur HEVC par défaut DOIT être capable de décoder le flux capturé en SDR.

Exigences concernant le montage HDR

Si les implémentations d'appareils incluent des encodeurs vidéo compatibles avec le montage HDR, elles :

DOIT utiliser une latence minimale pour générer les métadonnées HDR en leur absence, et DOIT gérer correctement les situations où les métadonnées sont présentes pour certaines images et pas pour d'autres. Ces métadonnées DOIVENT être précises (par exemple, représenter la luminance maximale et l'histogramme réels du frame).

Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing, ces codecs :

[C-7-1] DOIT prendre en charge au moins un profil HDR.
[C-7-2] DOIT être compatible avec FEATURE_HdrEditing pour tous les profils HDR annoncés par ce codec. En d'autres termes, il DOIT être capable de générer des métadonnées HDR lorsqu'elles sont absentes pour tous les profils HDR compatibles qui utilisent des métadonnées HDR.
[C-7-3] DOIT être compatible avec les formats d'entrée de l'encodeur vidéo suivants qui préservent entièrement le signal HDR décodé :
- RGBA_1010102 (déjà dans la courbe de transfert cible) pour la surface d'entrée et ByteBuffer, et DOIT annoncer la compatibilité avec COLOR_Format32bitABGR2101010.

Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing, l'appareil :

[C-7-4] DOIT annoncer la prise en charge de l'extension OpenGL EXT_YUV_target.

Conditions requises pour l'écran HDR

Si les implémentations d'appareil reçoivent du contenu de tampon encodé avec ADATASPACE_TRANSFER_HLG et que ce contenu est envoyé à l'écran via SurfaceControl.Transaction#setBuffer, elles :

[C-8-1] DOIT suivre la recommandation de blanc graphique dans BT. 2408-7 et afficher uniquement le contenu qui est au maximum 4,926 fois supérieur au contenu SDR.

6. Compatibilité des outils et options pour les développeurs

6.1. Outils pour les développeurs

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec les outils pour les développeurs Android fournis dans le SDK Android.
Android Debug Bridge (adb)
[C-0-2] DOIT être compatible avec adb, comme indiqué dans le SDK Android et les commandes shell fournies dans l'AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys, cmd stats et Simpleperf.
[C-0-11] DOIT être compatible avec la commande shell cmd testharness. La mise à niveau des implémentations d'appareils à partir d'une version antérieure d'Android sans bloc de données persistant PEUT être exemptée de C-0-11.
[C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) enregistrés à l'aide de la commande dumpsys.
[C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell cmd stats et la classe d'API système StatsManager.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] Le démon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible à l'utilisateur DOIT permettre d'activer Android Debug Bridge.
[C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Secure adb permet d'activer adb sur des hôtes authentifiés connus.
[C-0-6] DOIT fournir un mécanisme permettant de connecter adb à partir d'une machine hôte. Plus précisément :

Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, elles :

[C-3-1] DOIT implémenter adb via un réseau local (tel qu'Ethernet ou le Wi-Fi).
[C-3-2] DOIT fournir des pilotes pour Windows 7, 8 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi ou Ethernet, elles :

[C-4-1] DOIT avoir la méthode AdbManager#isAdbWifiSupported() qui renvoie true.

Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via Wi-Fi ou Ethernet, et incluent au moins une caméra, elles :

[C-5-1] La méthode AdbManager#isAdbWifiQrSupported() DOIT renvoyer true.
Service Dalvik Debug Monitor (ddms)
- [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms telles que documentées dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
SysTrace
- [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT exister un mécanisme accessible à l'utilisateur pour activer Systrace.
Perfetto
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto écrive en sortie une trace protobuf conforme au schéma défini dans la documentation perfetto.
- [C-SR-4] Il est FORTEMENT RECOMMANDÉ de fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.
Tueur de mémoire faible
- [C-0-12] DOIT écrire un Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par Low Memory Killer.
Mode Atelier de test

Si les implémentations d'appareil sont compatibles avec la commande shell cmd testharness et exécutent cmd testharness enable, elles :
- [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DOIT implémenter le mode Atelier de test comme décrit dans la documentation du mode Atelier de test.
Informations sur le travail du GPU

Implémentations sur les appareils :
- [C-0-13] DOIT implémenter la commande shell dumpsys gpu --gpuwork pour afficher les données agrégées sur la charge de travail du GPU renvoyées par le point de trace du noyau power/gpu_work_period, ou n'afficher aucune donnée si le point de trace n'est pas pris en charge. L'implémentation AOSP est frameworks/native/services/gpuservice/gpuwork/.

Si les implémentations d'appareils indiquent la compatibilité avec Vulkan 1.0 ou version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version, elles :

[C-1-1] DOIT fournir une affordance permettant au développeur d'application d'activer/de désactiver les couches de débogage GPU.
[C-1-2] DOIT, lorsque les couches de débogage GPU sont activées, énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire ne faisant pas partie du package de plate-forme ou d'application) trouvées dans le répertoire de base des applications débogables pour prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_frequency sur true, elles :

[C-6-1] DOIT signaler un point de trace de fréquence GPU selon le format power/gpu_frequency, tel que défini dans power.proto.

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_counters sur true, elles :

[C-7-1] DOIT fournir un producteur de données Perfetto pour une source de données nommée gpu.counters, interrogeable à l'aide de : perfetto --query.
[C-7-2] DOIT signaler les descriptions des compteurs de GPU conformément au proto de paquet de trace du compteur de GPU.
[C-7-3] DOIT signaler des valeurs conformes pour les compteurs GPU de l'appareil en suivant le proto de paquet de trace du compteur GPU.
[C-7-4] DOIT enregistrer les descriptions textuelles de tous les compteurs GPU activés sans code temporel dans la trace Perfetto.
[C-7-6] DOIT fournir un ensemble non vide de compteurs de performances GPU par défaut pour le profilage, comme spécifié dans GpuCounterSpec#select_by_default.
- Il DOIT être possible d'activer tous ces compteurs par défaut en même temps.
- Ils DOIVENT tous émettre des valeurs vers Perfetto lorsqu'ils sont activés.
[C-7-7] DOIT refléter l'utilisation du GPU pour au moins un compteur sélectionné par défaut, en utilisant GpuCounterSpec#select_by_default.

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_counters.period sur true, elles :

[C-8-1] DOIT respecter counter_period_ns pour la fréquence d'échantillonnage des compteurs de GPU. Le taux d'échantillonnage accepté DOIT être de 1 ms ou plus rapide.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge une fréquence d'échantillonnage de 0,2 ms ou plus.

Si les implémentations d'appareil définissent les deux propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_counters.groups sur true, elles :

[C-9-1] DOIT comporter au moins un compteur dans chacun des groupes de compteurs de GPU suivants, comme spécifié par GpuCounterSpec : COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES et VERTICES.

Si les implémentations d'appareils définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_counters.groups sur true, et que l'appareil est compatible avec le ray tracing, elles :

[C-10-1] DOIT comporter un compteur dans le groupe RAY_TRACING.

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.gpu_counters.zeroes_optimization sur true, elles :
[C-11-1] Dans la même session de trace Perfetto, les compteurs GPU NE DOIVENT signaler des valeurs nulles que si la valeur signalée précédente ou suivante est non nulle.

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.render_stages sur true, elles :

[C-12-1] DOIT fournir un producteur de données Perfetto pour une source de données nommée gpu.renderstages, interrogeable à l'aide de perfetto --query.
[C-12-2] DOIT signaler des valeurs conformes pour les étapes de rendu du GPU en suivant le proto d'événement d'étape de rendu du GPU.

Si les implémentations d'appareil définissent les propriétés système graphics.gpu.profiler.support et graphics.gpu.profiler.support.render_stages.queue_submit sur true, elles :

[C-13-1] Pour chaque appel d'envoi de file d'attente Vulkan, le pilote Vulkan DOIT émettre un événement de trace Perfetto conformément à la spécification des messages d'événement de l'API Vulkan.
- Cet événement DOIT contenir un submission_id unique et croissant de manière monotone, qui correspond au submission_id de l'événement de phase de rendu GPU correspondant.

6.2. Options pour les développeurs

Android permet aux développeurs de configurer les paramètres liés au développement d'applications.

Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour les options pour les développeurs. Elles :

[C-0-1] DOIT respecter l'intention android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu d'options pour les développeurs par défaut et permet aux utilisateurs de lancer les options pour les développeurs après avoir appuyé sept fois sur l'élément de menu Paramètres > À propos de l'appareil > Numéro de version.
[C-0-2] Les options pour les développeurs DOIVENT être masquées par défaut.
[C-0-3] DOIT fournir un mécanisme clair qui ne favorise pas une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous DEVEZ fournir un document ou un site Web visible publiquement qui décrit comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible par un lien depuis les documents du SDK Android.
DOIT afficher une notification visuelle continue à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est menacée.
PEUT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant ou en le désactivant visuellement, pour éviter toute distraction dans les scénarios où la sécurité de l'utilisateur est préoccupante.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel spécifique qui dispose d'une API correspondante pour les développeurs tiers :

[C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant :

[C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) pour les API de composants DOIVENT toujours être présentées.
[C-0-3] Les comportements de l'API DOIVENT être implémentés comme des no-ops de manière raisonnable.
[C-0-4] Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
[C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations no-op des classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
[C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
[C-0-7] Les implémentations d'appareils DOIVENT systématiquement fournir des informations précises sur la configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte de build.

Un exemple typique de scénario où ces exigences s'appliquent est l'API de téléphonie : même sur les appareils autres que les téléphones, ces API doivent être implémentées en tant que no-ops raisonnables.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les composants et les mises en page de l'interface utilisateur des applications en fonction de l'appareil. Cela permet de s'assurer que les applications tierces fonctionnent correctement sur différents écrans et configurations matérielles. Un écran compatible avec Android est un écran qui implémente tous les comportements et toutes les API décrits dans Android Developers : aperçu de la compatibilité des écrans, dans cette section (7.1) et ses sous-sections, ainsi que tous les comportements spécifiques à un type d'appareil documentés dans la section 2 du présent CDD.

Implémentations sur les appareils :

[C-0-1] DOIT, par défaut, afficher les applications tierces uniquement sur les écrans compatibles avec Android.

Les unités auxquelles font référence les exigences de cette section sont définies comme suit :

taille physique de la diagonale. Distance en pouces entre deux angles opposés de la partie éclairée de l'écran.
density. Nombre de pixels inclus dans une étendue linéaire horizontale ou verticale de 2,54 cm, exprimé en pixels par pouce (ppi ou dpi). Lorsque des valeurs ppi et dpi sont indiquées, les valeurs dpi horizontales et verticales doivent être comprises dans la plage indiquée.
format. Rapport entre les pixels de la dimension la plus longue et ceux de la dimension la plus courte de l'écran. Par exemple, un écran de 480 x 854 pixels correspond à un format de 854 / 480 = 1,779, soit environ "16:9".
Pixel indépendant de la densité (dp) Unité de pixel virtuel normalisée pour une densité d'écran de 160. Pour une densité d et un nombre de pixels p, le nombre de pixels indépendants de la densité dp est calculé comme suit : dp = (160 / d) * p.

7.1.1. Configuration de l'écran

7.1.1.1. Taille et forme de l'écran

Le framework d'UI Android est compatible avec différentes tailles de mise en page d'écran logiques et permet aux applications d'interroger la taille de mise en page d'écran de la configuration actuelle via Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK et Configuration.smallestScreenWidthDp.

Implémentations sur les appareils :

[C-0-1] DOIT signaler la taille de mise en page correcte pour Configuration.screenLayout, telle que définie dans la documentation du SDK Android. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions logiques de l'écran en pixels indépendants de la densité (dp) comme suit :
- Les appareils dont la valeur de Configuration.uiMode est différente de UI_MODE_TYPE_WATCH et qui signalent une taille small pour Configuration.screenLayout DOIVENT avoir au moins 426 dp x 320 dp.
- Les appareils qui indiquent une taille normal pour Configuration.screenLayout DOIVENT avoir au moins 480 dp x 320 dp.
- Les appareils qui signalent une taille large pour Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
- Les appareils qui signalent une taille xlarge pour Configuration.screenLayout DOIVENT avoir au moins 960 dp x 720 dp.
[C-0-2] DOIT respecter correctement la compatibilité des applications avec les tailles d'écran indiquée par l'attribut <supports-screens> dans AndroidManifest.xml, comme décrit dans la documentation du SDK Android.
L'appareil PEUT être équipé d'un ou plusieurs écrans compatibles avec Android et dotés de coins arrondis.

Si les implémentations d'appareils sont compatibles avec les écrans capables de la configuration de taille UI_MODE_TYPE_NORMAL et utilisent des écrans physiques avec des coins arrondis pour afficher ces écrans, elles :

[C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est respectée pour chaque affichage :
- Le rayon des angles arrondis est inférieur ou égal à 38 dp.
- Lorsqu'une boîte de 18 dp sur 18 dp est ancrée à chaque angle de l'écran logique, au moins un pixel de chaque boîte est visible à l'écran.
DOIT inclure une affordance utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Si les implémentations d'appareils ne sont compatibles qu'avec la configuration du clavier NO_KEYS et qu'elles prévoient de signaler la compatibilité avec la configuration du mode UI UI_MODE_TYPE_NORMAL, elles doivent :

[C-4-1] DOIT avoir une taille de mise en page, à l'exclusion des encoches, d'au moins 596 dp x 384 dp.

Pour savoir comment implémenter correctement les API sidecar ou d'extension, consultez la documentation publique de Window Manager Jetpack.

[C-4-1] Exigence supprimée dans Android 15.

7.1.1.2. Format de l'écran

Cette section a été supprimée dans Android 14.

7.1.1.3. Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.

Implémentations de l'appareil :

[C-0-1] DOIT signaler l'une des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE. Cette valeur doit être statique pour chaque écran physique. Toutefois, l'appareil PEUT signaler un DisplayMetrics.density différent en fonction des modifications apportées par l'utilisateur à la configuration de l'écran (par exemple, la taille d'affichage) après le démarrage initial.
DOIT définir la densité du framework Android standard qui est numériquement la plus proche de la densité physique de l'écran, ou une valeur qui correspondrait aux mêmes mesures équivalentes du champ de vision angulaire d'un appareil mobile.

Si les implémentations d'appareil permettent de modifier la taille d'affichage de l'appareil, elles :

[C-1-1] NE DOIT PAS mettre à l'échelle l'affichage à plus de 1,5 fois DENSITY_DEVICE_STABLE ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première de ces conditions qui se produit.
[C-1-2] NE DOIT PAS réduire la taille de l'affichage à moins de 0,85 fois la DENSITY_DEVICE_STABLE.
Pour garantir une bonne facilité d'utilisation et des tailles de police cohérentes, il est RECOMMANDÉ de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
- Petite : 0,85x
- Valeur par défaut : 1x (échelle d'affichage natif)
- Grand : x 1,15
- Plus grand : x 1,3
- Très grand : x 1,45

7.1.2. Métriques display

Si les implémentations d'appareils incluent le ou les écrans compatibles avec Android ou la sortie vidéo vers le ou les écrans compatibles avec Android, elles :

[C-1-1] DOIT signaler les valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API android.util.DisplayMetrics.

Si les implémentations d'appareils n'incluent pas d'écran ni de sortie vidéo intégrés, elles :

[C-2-1] DOIT signaler les valeurs correctes de l'écran compatible avec Android, telles que définies dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations sur les appareils :

[C-0-1] DOIT indiquer les orientations d'écran qu'il prend en charge (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation prise en charge. Par exemple, un appareil avec un écran en mode paysage à orientation fixe, tel qu'un téléviseur ou un ordinateur portable, DOIT uniquement signaler android.hardware.screen.landscape.
[C-0-2] DOIT signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois qu'elle est demandée via les API android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Si les implémentations d'appareil sont compatibles avec les deux orientations d'écran, elles :

[C-1-1] Exigence supprimée dans Android 16.
[C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran signalées lors du changement d'orientation.
PEUT sélectionner l'orientation portrait ou paysage comme orientation par défaut.

7.1.4. Accélération graphique 2D et 3D

7.1.4.1. OpenGL ES

Implémentations sur les appareils :

[C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode GLES10.getString()) et les API natives.
[C-0-2] DOIT inclure la prise en charge de toutes les API gérées et natives correspondantes pour chaque version d'OpenGL ES qu'il a identifiée comme étant compatible.

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles :

[C-1-1] DOIT être compatible avec OpenGL ES 1.1, 2.0, 3.0 et 3.1, comme indiqué et détaillé dans la documentation du SDK Android.
[C-SR-1] Exigence supprimée dans Android 15.
DOIT être compatible avec OpenGL ES 3.2.

Les tests dEQP OpenGL ES sont divisés en plusieurs listes de tests, chacune associée à une date/un numéro de version. Ils se trouvent dans l'arborescence source Android à l'adresse external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Un appareil compatible avec OpenGL ES à un niveau auto-déclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests de ce niveau et des niveaux précédents.

Si les implémentations d'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles :

[C-2-1] DOIT signaler, via les API gérées et natives d'OpenGL ES, toute autre extension OpenGL ES qu'il a implémentée et, inversement, NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas en charge.
[C-2-2] DOIT être compatible avec les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers.
[C-2-3] DOIT signaler la version maximale des tests dEQP OpenGL ES compatibles via le flag de fonctionnalité android.software.opengles.deqp.level.
[C-2-4] DOIT au moins prendre en charge la version 132383489 (à partir du 1er mars 2020) telle qu'indiquée dans le flag de fonctionnalité android.software.opengles.deqp.level.
[C-2-5] DOIT réussir tous les tests dEQP OpenGL ES dans les listes de tests entre la version 132383489 et la version spécifiée dans le flag de fonctionnalité android.software.opengles.deqp.level, pour chaque version OpenGL ES prise en charge.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture qu'il prend en charge, qui est généralement spécifique au fournisseur.
DOIT être compatible avec les extensions EGL_IMG_context_priority et EGL_EXT_protected_content.

Si les implémentations d'appareils déclarent la compatibilité avec OpenGL ES 3.0, 3.1 ou 3.2, elles :

[C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension OES_EGL_image_external_essl3.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.2, elles :

[C-4-1] DOIT être entièrement compatible avec le pack d'extensions Android OpenGL ES.

Si les implémentations d'appareils sont entièrement compatibles avec le pack d'extensions Android d'OpenGL ES, elles :

[C-5-1] DOIT identifier la prise en charge via le flag de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareil exposent la compatibilité avec l'extension EGL_KHR_mutable_render_buffer, elles :

[C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2. Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple d'utilisation pour les graphismes 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.3.
[C-4-1] NE DOIT PAS être compatible avec une version variante de Vulkan (c'est-à-dire que la partie variante de la version principale de Vulkan DOIT être égale à zéro).

Si les implémentations d'appareils incluent un écran ou une sortie vidéo, elles :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure la compatibilité avec Vulkan 1.3.

Les tests dEQP Vulkan sont partitionnés en plusieurs listes de tests, chacune associée à une date/version. Ils se trouvent dans l'arborescence source Android à l'adresse external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un appareil compatible avec Vulkan à un niveau auto-déclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests de ce niveau et des niveaux précédents.

Si les implémentations d'appareils incluent la compatibilité avec Vulkan, elles :

[C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
[C-1-2] DOIT énumérer au moins un VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().
[C-1-3] DOIT implémenter entièrement les API Vulkan 1.1 pour chaque VkPhysicalDevice énuméré.
[C-1-4] DOIT énumérer les couches contenues dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire des bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties().

[C-1-5] NE DOIT PAS énumérer les couches fournies par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de tracer ou d'intercepter l'API Vulkan, sauf si l'application a l'attribut android:debuggable défini sur true ou les métadonnées com.android.graphics.injectLayers.enable définies sur true , à l'exception des couches OEM et de plate-forme conformément à la documentation Implémenter Vulkan.

[C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan, et inversement, NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.

[C-1-7] MUST support the following extensions:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[C-1-8] DOIT indiquer la version maximale des tests dEQP Vulkan compatibles via le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-1-9] DOIT au moins prendre en charge la version 132317953 (à partir du 1er mars 2019) telle qu'indiquée dans le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-1-10] DOIT réussir tous les tests dEQP Vulkan dans les listes de tests entre la version 132317953 et la version spécifiée dans le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-1-11] NE DOIT PAS énumérer la compatibilité avec les extensions VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.

[C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions suivantes :
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] NE DOIT PAS énumérer la prise en charge de l'extension VK_KHR_performance_query.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de satisfaire aux exigences spécifiées par le profil Android Baseline 2022.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ de prendre en charge VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory et VK_EXT_global_priority.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'utiliser SkiaVk avec HWUI.

Si les implémentations d'appareils incluent la compatibilité avec Vulkan, elles :

[C-SR-8] Il est FORTEMENT RECOMMANDÉ de ne pas modifier le chargeur Vulkan.
[C-1-14] NE DOIT PAS énumérer les extensions de périphérique Vulkan de type "KHR", "GOOGLE" ou "ANDROID", sauf si ces extensions sont incluses dans le flag de fonctionnalité android.software.vulkan.deqp.level.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles :

[C-2-1] NE DOIT PAS déclarer de commutateurs de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations d'appareils incluent la prise en charge de Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan décrits ici ou version ultérieure, elles :

[C-3-1] DOIT exposer la compatibilité avec les types de sémaphores et de gestion externes SYNC_FD et l'extension VK_ANDROID_external_memory_android_hardware_buffer.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ de rendre l'extension VK_KHR_external_fence_fd disponible pour les applications tierces et de permettre à l'application d'exporter et d'importer la charge utile de la clôture à partir des descripteurs de fichiers POSIX, comme décrit ici.

7.1.4.3. RenderScript

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4. Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations sur les appareils :

[C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT la désactiver si le développeur en fait la demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API Android View.
[C-0-2] DOIT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES à accélération matérielle en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations sur les appareils :

[C-0-3] DOIT être compatible avec l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5. Écrans à large gamme de couleurs

Si les implémentations d'appareils affirment prendre en charge les écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut(), elles :

[C-1-1] DOIT disposer d'un écran calibré en couleur.
[C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace CIE 1931 xyY.
[C-1-3] DOIT disposer d'un écran dont la gamme a une superficie d'au moins 90% de DCI-P3 dans l'espace CIE 1931 xyY.
[C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
[C-1-5] DOIT annoncer la prise en charge des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles :

[C-2-1] DOIT couvrir 100% ou plus de l'espace sRGB dans l'espace CIE 1931 xyY, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Mode de compatibilité avec les anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" équivalente (largeur de 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille de l'écran.

7.1.6. Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur un écran compatible avec Android. Les appareils DOIVENT être compatibles avec toutes ces API telles que définies par le SDK Android, sauf autorisation spécifique dans le présent document.

Tous les écrans compatibles avec Android d'une implémentation d'appareil :

[C-0-1] DOIT être capable d'afficher des graphiques en couleur 16 bits.
DOIT être compatible avec les écrans affichant des graphiques couleur 24 bits.
[C-0-2] DOIT être capable d'afficher des animations.
[C-0-3] MUST have a pixel aspect ratio (PAR) between 0.9 and 1.15. En d'autres termes, les proportions de pixels DOIVENT être presque carrées (1,0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires compatibles avec Android pour permettre le partage de contenus multimédias et les API de développeur pour accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou une connexion d'écran supplémentaire intégrée, elles :

[C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation SDK Android.

7.2. Périphériques d'entrée

Implémentations sur les appareils :

[C-0-1] DOIT inclure un mécanisme de saisie, tel qu'un écran tactile ou une navigation sans contact, pour naviguer entre les éléments de l'UI.

7.2.1. Clavier

Si les implémentations d'appareils incluent la prise en charge des applications tierces d'éditeur de méthode de saisie (IME), elles :

[C-1-1] DOIT déclarer le commutateur de fonctionnalité android.software.input_methods.
[C-1-2] DOIT implémenter entièrement Input Management Framework
[C-1-3] DOIT disposer d'un clavier virtuel préinstallé.

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS inclure de clavier matériel qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches).
DOIT inclure des implémentations de clavier virtuel supplémentaires.
PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, la trackball et la molette comme mécanismes de navigation non tactile.

Implémentations sur les appareils :

[C-0-1] DOIT signaler la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne disposent pas de navigations non tactiles, elles :

[C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification de texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source Android en amont inclut un mécanisme de sélection adapté aux appareils dépourvus de commandes de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour, généralement fournies par le biais d'une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils :

[C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées qui ont une activité avec <intent-filter> défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations sur les appareils de télévision. La fonction Accueil DOIT être le mécanisme permettant cette affordance utilisateur.
DOIT fournir des boutons pour les fonctions "Récents" et "Retour".

Si les fonctions "Accueil", "Récents" ou "Retour" sont fournies, elles :

[C-1-1] DOIT être accessible en une seule action (par exemple, un geste, un double-clic ou un appui) lorsque l'un d'eux est accessible.
[C-1-2] DOIT indiquer clairement quelle action unique déclenchera chaque fonction. Par exemple, vous pouvez afficher une icône visible sur le bouton, une icône logicielle sur la partie barre de navigation de l'écran ou guider l'utilisateur à travers une démonstration pas à pas lors de la configuration initiale.

Implémentations sur les appareils :

Il est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme de saisie pour la fonction de menu, car elle est obsolète au profit de la barre d'action depuis Android 4.0. [C-SR-1]
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir toutes les fonctions de navigation comme annulables. La fonctionnalité "Annulable" est définie comme la capacité de l'utilisateur à empêcher l'exécution de la fonction de navigation (par exemple, revenir à l'écran d'accueil, revenir en arrière, etc.) si le balayage n'est pas relâché au-delà d'un certain seuil.

Si les implémentations d'appareils fournissent la fonction Menu, elles :

[C-2-1] DOIT afficher le bouton de menu d'actions supplémentaires chaque fois que le pop-up du menu d'actions supplémentaires n'est pas vide et que la barre d'actions est visible.
[C-2-2] NE DOIT PAS modifier la position du pop-up de menu d'actions affiché en sélectionnant le bouton à développer dans la barre d'actions, mais PEUT afficher le pop-up de menu d'actions à une position modifiée sur l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareil ne fournissent pas la fonction Menu, pour la rétrocompatibilité, elles :

[C-3-1] DOIT rendre la fonction de menu disponible pour les applications lorsque targetSdkVersion est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils fournissent la fonctionnalité d'assistance, elles :

[C-4-1] La fonction d'assistance DOIT être accessible en une seule action (par exemple, un geste, un double-clic ou un appui) lorsque d'autres touches de navigation sont accessibles.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction ACCUEIL comme interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles :

[C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, non disponible pour les applications, et NE DOIVENT PAS masquer ni gêner la partie de l'écran disponible pour les applications.
[C-5-2] DOIT mettre à la disposition des applications une partie de l'écran qui répond aux exigences définies dans la section 7.1.1.
[C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (c'est-à-dire la barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

Si la fonction de navigation est fournie sous la forme d'une action gestuelle à l'écran :

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() NE DOIT être utilisé que pour signaler la zone de reconnaissance des gestes pour la maison.
[C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale spécifiée dans la documentation pour View#setSystemGestureExclusionRects().
[C-6-3] DOIT envoyer à l'application au premier plan un événement MotionEvent.ACTION_CANCEL une fois que les événements tactiles commencent à être interceptés pour un geste système, si un événement MotionEvent.ACTION_DOWN a déjà été envoyé à l'application au premier plan.
[C-6-4] DOIT fournir une affordance utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
DOIT fournir la fonction Accueil en balayant l'écran de bas en haut depuis le bord inférieur de l'orientation actuelle de l'écran.
DOIT fournir la fonction "Récents" en effectuant un balayage vers le haut et en maintenant le doigt appuyé avant de le relâcher, à partir de la même zone que le geste "Accueil".
Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est fournie à partir de n'importe quel point des bords gauche et droit de l'orientation actuelle de l'écran :

[C-7-1] La fonction de navigation DOIT être "Retour" et être accessible en balayant l'écran de gauche à droite ou de droite à gauche dans l'orientation actuelle de l'écran.
[C-7-2] Si des panneaux système personnalisés et balayables sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante indiquant que le fait de faire glisser le doigt vers l'intérieur invoque les panneaux susmentionnés, et non le bouton "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur du ou des bords de l'écran, mais il NE DOIT PAS utiliser plus d'un tiers du ou des bords.
[C-7-3] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, ce qui est documenté dans le SDK.
[C-7-4] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, les panneaux système personnalisés pouvant être balayés DOIVENT être masqués jusqu'à ce que l'utilisateur fasse apparaître ou éclaircisse les barres système (c'est-à-dire la barre de navigation et la barre d'état) telles qu'elles sont implémentées dans AOSP.

Si la fonction de retour en arrière est fournie et que l'utilisateur annule le geste Retour :

[C-8-1] OnBackInvokedCallback.onBackCancelled() DOIT être appelé.
[C-8-2] OnBackInvokedCallback.onBackInvoked() NE DOIT PAS être appelé.
[C-8-3] L'événement KEYCODE_BACK NE DOIT PAS être distribué.

Si la fonction de retour en arrière est fournie, mais que l'application au premier plan n'a PAS d'OnBackInvokedCallback enregistré, alors :

Le système DOIT fournir une animation pour l'application de premier plan qui suggère que l'utilisateur revient en arrière, comme indiqué dans AOSP.

Si les implémentations d'appareil sont compatibles avec l'API système setNavBarMode pour permettre à toute application système disposant de l'autorisation android.permission.STATUS_BAR de définir le mode de la barre de navigation, elles :

[C-9-1] DOIT prendre en charge les icônes adaptées aux enfants ou la navigation par boutons, comme indiqué dans le code AOSP.

7.2.4. Saisie sur écran tactile

Android est compatible avec différents systèmes de saisie au pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques de saisie tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur a l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune autre affordance pour indiquer les objets manipulés.

Implémentations sur les appareils :

DOIT disposer d'un système de saisie au pointeur (de type souris ou tactile).
DOIT être compatible avec les pointeurs entièrement suivis de manière indépendante.

Si les implémentations d'appareils incluent un écran tactile (à un ou plusieurs points de contact) sur un écran principal compatible avec Android, elles :

[C-1-1] MUST report TOUCHSCREEN_FINGER for the Configuration.touchscreen API field.
[C-1-2] DOIT signaler les indicateurs de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils incluent un écran tactile capable de suivre plusieurs points de contact sur un écran principal compatible avec Android, elles :

[C-2-1] DOIT signaler les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils s'appuient sur un périphérique d'entrée externe tel qu'une souris ou une trackball (c'est-à-dire sans toucher directement l'écran) pour la saisie sur un écran principal compatible avec Android et répondent aux exigences concernant les faux contacts dans la section 7.2.5, elles :

[C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen.
[C-3-2] DOIT signaler uniquement android.hardware.faketouch.
[C-3-3] DOIT signaler TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

7.2.5. Fausse saisie tactile

Une interface tactile simulée fournit un système d'entrée utilisateur qui se rapproche d'un sous-ensemble des capacités d'un écran tactile. Par exemple, une souris ou une télécommande qui oriente un curseur à l'écran se rapproche du toucher, mais nécessite que l'utilisateur pointe ou sélectionne d'abord, puis clique. De nombreux périphériques d'entrée, tels que la souris, le pavé tactile, la souris gyroscopique, le pointeur gyroscopique, le joystick et le pavé tactile multipoint, peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate une entrée tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé de fonctionnalités d'écran tactile.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie au pointeur qu'elles souhaitent rendre disponible, elles doivent :

DOIT déclarer la compatibilité avec le flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch, elles :

[C-1-1] DOIT signaler les positions absolues X et Y de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
[C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou remonte sur l'écran.
[C-1-3] DOIT prendre en charge les événements pointer down et pointer up sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
[C-1-4] DOIT prendre en charge les événements pointer down, pointer up, pointer down puis pointer up au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double-tap sur un objet à l'écran.
[C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
[C-1-6] DOIT permettre aux utilisateurs d'appuyer sur le pointeur, puis de déplacer rapidement l'objet vers une autre position sur l'écran, puis de relâcher le pointeur sur l'écran, ce qui permet aux utilisateurs de faire glisser un objet d'un geste vif sur l'écran.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct, elles :

[C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
[C-2-2] DOIT permettre le suivi distinct de deux entrées de pointeur indépendantes ou plus.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand, elles :

[C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
[C-3-2] DOIT prendre en charge le suivi distinct de cinq entrées de pointeur (suivi d'une main de doigts) ou plus de manière totalement indépendante.

7.2.6. Compatibilité avec les manettes de jeu

7.2.6.1. Mappages des boutons

Implémentations sur les appareils :

[C-1-1] DOIT être capable de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent un contrôleur ou sont fournies avec un contrôleur séparé dans la boîte qui permettrait de saisir tous les événements listés dans les tableaux ci-dessous, elles :

[C-2-1] DOIT déclarer le flag de fonctionnalité android.hardware.gamepad

Bouton	Utilisation HID²	Bouton Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Haut du pavé directionnel¹ Bas du pavé directionnel¹	0x01 0x0039³	AXIS_HAT_Y⁴
Flèche vers la gauche du pavé directionnel1 Flèche vers la droite du pavé directionnel¹	0x01 0x0039³	AXIS_HAT_X⁴
Bouton de tranche gauche¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton supérieur droit¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Appui sur le joystick gauche¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Appui sur le joystick droit¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Retour¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification Gamepad (0x01 0x0005).

3 Cette utilisation doit avoir un minimum logique de 0, un maximum logique de 7, un minimum physique de 0, un maximum physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme la rotation dans le sens des aiguilles d'une montre par rapport à l'axe vertical. Par exemple, une valeur logique de 0 représente l'absence de rotation et l'appui sur le bouton Haut, tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et l'appui sur les touches Haut et Gauche.

4 MotionEvent

Commandes analogiques¹	Utilisation HID	Bouton Android
Bouton de tranche gauche	0x02 0x00C5	AXIS_LTRIGGER
Bouton de tranche droit	0x02 0x00C4	AXIS_RTRIGGER
Joystick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Consultez la section 2.3.1 pour connaître les exigences spécifiques aux appareils.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et dans la documentation Android Open Source sur les capteurs.

Implémentations sur les appareils :

[C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs selon la classe android.content.pm.PackageManager.
[C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires.
[C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteur (par exemple, en renvoyant true ou false, le cas échéant, lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteur lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles :

[C-1-1] DOIT signaler toutes les mesures des capteurs en utilisant les valeurs du Système international d'unités (métriques) appropriées pour chaque type de capteur, telles que définies dans la documentation du SDK Android.
[C-1-2] DOIT signaler les données de capteur avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteur avec une latence maximale demandée de 0 ms lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
[C-1-3] DOIT signaler le premier échantillon de capteur dans les 400 millisecondes + 2 *sample_time suivant l'activation du capteur. Il est acceptable que cet échantillon ait une précision de 0.
[C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques qui DOIVENT avoir une gigue inférieure à 3%, où la gigue est définie comme l'écart-type de la différence entre les valeurs d'horodatage signalées entre les événements consécutifs.
[C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en mode veille ou de sortir du mode veille.
[C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android, représentant l'heure à laquelle l'événement s'est produit et synchronisée avec l'horloge SystemClock.elapsedRealtimeNano().
[C-SR-1] Il est FORTEMENT RECOMMANDÉ que l'erreur de synchronisation du code temporel soit inférieure à 100 millisecondes, et il est RECOMMANDÉ qu'elle soit inférieure à 1 milliseconde.
Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme des consommations d'énergie individuelles des capteurs.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles :

[C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler la valeur via la méthode d'API Sensor.getResolution().

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (Par exemple, le capteur d'orientation et le capteur d'accélération linéaire.)

Implémentations sur les appareils :

DOIT implémenter ces types de capteurs, lorsqu'ils incluent les capteurs physiques requis, comme décrit dans Types de capteurs.

Si les implémentations d'appareils incluent un capteur composite, elles :

[C-2-1] DOIT implémenter le capteur tel que décrit dans la documentation Android Open Source sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier qui possède une API correspondante pour les développeurs tiers et que le capteur ne signale qu'une seule valeur, les implémentations d'appareils :

[C-3-1] DOIT définir la résolution sur 1 pour le capteur et signaler la valeur via la méthode d'API Sensor.getResolution().

Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé à des développeurs tiers, elles :

[C-4-1] NE DOIT PAS inclure de paramètres de calibration fixes déterminés en usine dans les données fournies.

Si les implémentations d'appareils incluent une combinaison d'un accéléromètre 3 axes, d'un gyroscope 3 axes ou d'un capteur magnétomètre, elles sont :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ de s'assurer que l'accéléromètre, le gyroscope et le magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes des capteurs restent alignés et cohérents avec le système de coordonnées des capteurs dans tous les états de transformation possibles de l'appareil.

7.3.1. Accéléromètre

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 axes.

Si les implémentations d'appareil incluent un accéléromètre, elles :

[C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
[C-1-3] DOIT être conforme au système de coordonnées des capteurs Android, comme indiqué dans les API Android.
[C-1-4] DOIT être capable de mesurer une chute libre jusqu'à quatre fois la valeur gravity(4g) ou plus sur n'importe quel axe.
[C-1-5] DOIT avoir une résolution d'au moins 12 bits.
[C-1-6] DOIT avoir un écart-type inférieur ou égal à 0,05 m/s^, où l'écart-type doit être calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes à la fréquence d'échantillonnage la plus rapide.
DOIT signaler les événements jusqu'à au moins 200 Hz.
DOIT avoir une résolution d'au moins 16 bits.
DOIT être calibré pendant l'utilisation si les caractéristiques changent au cours du cycle de vie et compensées, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
DOIT être compensé en température.

Si les implémentations d'appareils incluent un accéléromètre 3 axes, elles :

[C-2-1] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est FORTEMENT RECOMMANDÉ d'utiliser des appareils Android pour répondre à cette exigence, car ils pourront être mis à niveau vers la future version de la plate-forme où cela pourrait devenir OBLIGATOIRE.
DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un accéléromètre avec moins de trois axes, elles :

[C-3-1] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils incluent un Accéléromètre 3 axes et l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER :

[C-4-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans une condition dynamique ou statique.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et un capteur gyroscope à trois axes, elles :

[C-5-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un accéléromètre à trois axes, un gyroscope à trois axes et un capteur de magnétomètre, elles :

[C-6-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à trois axes.

Si les implémentations d'appareil incluent un magnétomètre à trois axes, elles :

[C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
[C-1-2] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DOIT signaler des événements jusqu'à au moins 50 Hz.
[C-1-3] DOIT être conforme au système de coordonnées des capteurs Android, comme indiqué dans les API Android.
[C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant saturation.
[C-1-5] DOIT avoir une valeur de décalage ferreux inférieure à 700 µT et DOIT avoir une valeur inférieure à 200 µT en plaçant le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
[C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 µT.
[C-1-7] DOIT prendre en charge la calibration et la compensation en ligne du biais de fer doux, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
[C-1-8] La compensation du fer doux DOIT être appliquée. La calibration peut être effectuée pendant l'utilisation ou lors de la production de l'appareil.
[C-1-9] DOIT avoir un écart-type, calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes à la fréquence d'échantillonnage la plus rapide, ne dépassant pas 1,5 µT ; DOIT avoir un écart-type ne dépassant pas 0,5 µT.
[C-1-10] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope à trois axes, elles :

[C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes et un accéléromètre, elles :

PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles :

[C-3-1] DOIT consommer moins de 10 mW.
DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode batch à 10 Hz.

7.3.3. GPS

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un récepteur GPS/GNSS.

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et signalent la fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, elles :

[C-1-1] DOIT prendre en charge les sorties de localisation à un taux d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate.
[C-1-2] DOIT être en mesure de déterminer la position dans des conditions de ciel dégagé (signaux forts, multitrajet négligeable, HDOP < 2) en 10 secondes (temps rapide pour la première correction), lorsqu'il est connecté à une connexion Internet d'une vitesse de 0,5 Mbit/s ou supérieure. Pour ce faire, il est généralement nécessaire d'utiliser une technique de localisation GPS/GNSS assistée ou par prédiction afin de réduire le temps de verrouillage du GPS/GNSS (les données d'assistance incluent l'heure de référence, la position de référence et l'éphéméride/horloge du satellite).
- [C-1-6] Après avoir effectué un tel calcul de localisation, les implémentations d'appareils DOIVENT déterminer leur position en ciel dégagé dans un délai de cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même lorsque la requête suivante est effectuée sans connexion de données et/ou après arrêt et redémarrage.
Dans des conditions de ciel dégagé, après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré :
- [C-1-3] DOIT être en mesure de déterminer la position à 20 mètres près et la vitesse à 0,5 mètre par seconde près, et ce, au moins 95% du temps.
- [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une même constellation.
- DOIT être capable de suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, GPS + au moins l'une des constellations Glonass, Beidou ou Galileo).
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des données de localisation GPS/GNSS normales via les API GNSS Location Provider lors d'un appel téléphonique d'urgence.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler l'AGC et la fréquence de mesure GNSS.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris le cap, la vitesse et la précision verticale) pour chaque position GPS/GNSS.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'indiquer les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore indiquée.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ qu'ils signalent les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscopique.

Si les implémentations d'appareils incluent un gyroscope, elles :

[C-1-1] DOIT être capable de signaler des événements à une fréquence d'au moins 50 Hz.
[C-1-4] DOIT avoir une résolution de 12 bits ou plus.
[C-1-5] DOIT être compensé en température.
[C-1-6] DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
[C-1-7] DOIT avoir une variance ne dépassant pas 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du taux d'échantillonnage, mais DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à une fréquence d'échantillonnage de 1 Hz, elle NE DOIT PAS être supérieure à 1e-7 rad^2/s^2.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'erreur de calibration soit inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ que les flux STR aient une résolution de 16 bits ou plus.
DOIT signaler les événements jusqu'à au moins 200 Hz.

Si les implémentations d'appareils incluent un gyroscope à trois axes, elles :

[C-2-1] DOIT implémenter le capteur TYPE_GYROSCOPE.
[C-SR-4] Il est vivement recommandé d'implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED.

Si les implémentations d'appareils incluent un gyroscope avec moins de trois axes, elles :

[C-3-1] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils incluent un gyroscope à trois axes, un accéléromètre et un magnétomètre, elles :

[C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et un capteur gyroscope à trois axes, elles :

[C-5-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

7.3.5. Baromètre

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique).

Si les implémentations d'appareil incluent un baromètre, elles :

[C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
[C-1-2] DOIT pouvoir fournir des événements à 5 Hz ou plus.
[C-1-3] DOIT être compensé en température.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de pouvoir signaler des mesures de pression comprises entre 300 hPa et 1 100 hPa.
DOIT avoir une précision absolue de 1 hPa.
DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (ce qui équivaut à une précision d'environ 1 m pour une variation d'environ 200 m au niveau de la mer).

Implémentations d'appareils qui déclarent la propriété système sensor.barometer.high_quality.implemented :

[C-2-1] DOIT indiquer les mesures de pression dans la plage de 300 hPa à 1 100 hPa, avec une précision absolue de +/- 1 hPa.
[C-2-2] DOIT avoir une précision relative de 0,15 hPa sur une plage de 100 hPa, ce qui équivaut à une précision d'environ 1 m sur une variation d'environ 1 000 m au niveau de la mer.
[C-2-3] DOIT être stable à +/- 0, 5 hPa lorsque l'utilisateur appuie sur l'appareil, le presse ou le serre.
[C-2-4] DOIT être stable à +/- 0,15 hPa lorsque l'utilisateur marche avec l'appareil à la main ou dans sa poche.
[C-2-5] La fréquence ne DOIT PAS être lissée avec une constante de temps supérieure à 300 ms pour les activations supérieures à 5 Hz, et le lissage ne DOIT PAS se propager entre les activations des capteurs.
[C-2-6] DOIT être stable à +/- 0, 15 hPa lorsqu'il est exposé à l'éclairage quotidien et aux fréquences radio introduites par des sources courantes telles que le Bluetooth, la connexion au réseau mobile ou le Wi-Fi.

7.3.6. Thermomètre

Si les implémentations d'appareil incluent un thermomètre ambiant (capteur de température), elles :

[C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température ambiante. Le capteur DOIT mesurer la température ambiante (de la pièce/de l'habitacle du véhicule) à partir de l'endroit où l'utilisateur interagit avec l'appareil en degrés Celsius.

Si les implémentations d'appareils incluent un capteur de température qui mesure une température autre que la température ambiante, comme la température du processeur, elles :

[C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

Si les implémentations d'appareils incluent un capteur pour surveiller la température cutanée, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'API PowerManager.getThermalHeadroom.

7.3.7. Photomètre

Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité et qu'elles ne signalent qu'une lecture binaire "proche" ou "éloigné", elles :

[C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté de manière à détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareil incluent un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
[C-1-2] DOIT avoir une précision d'au moins 1 bit.
[C-1-3] DOIT utiliser 0 centimètre comme lecture de près et 5 centimètres comme lecture de loin.
[C-1-4] DOIT indiquer une plage et une résolution maximales de 5.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de qualité supérieure, tels que définis dans cette section, et les mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT identifier la fonctionnalité à l'aide du flag de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareil déclarent android.hardware.sensor.hifi_sensors, elles :

[C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui :
- DOIT avoir une plage de mesure d'au moins -8 g et +8 g, et il est FORTEMENT RECOMMANDÉ qu'elle soit d'au moins -16 g et +16 g.
- DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
- DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT être compatible avec SensorDirectChannel RATE_VERY_FAST.
- DOIT avoir un bruit de mesure ne dépassant pas 400 μg/√Hz.
- DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
- DOIT avoir une consommation d'énergie par lot ne dépassant pas 3 mW.
- [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
- DOIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
- DOIT présenter une variation du biais en fonction de la température ≤ +/- 1 mg/°C.
- DOIT présenter une non-linéarité de la ligne de régression ≤ 0,5 % et une variation de sensibilité en fonction de la température ≤ 0,03%/°C.
- DOIT avoir une sensibilité inter-axes < 2,5 % et une variation de sensibilité inter-axes < 0,2% dans la plage de températures de fonctionnement de l'appareil.
[C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.
[C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui :
- DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps au minimum.
- DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
- DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT être compatible avec SensorDirectChannel RATE_VERY_FAST.
- DOIT avoir un bruit de mesure ne dépassant pas 0,014 °/s/√Hz.
- [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
- DOIT avoir une marche aléatoire de taux inférieure à 0,001 °/s √Hz testée à température ambiante.
- La variation du biais en fonction de la température DOIT être inférieure ou égale à +/- 0,05 °/ s / °C.
- DOIT présenter une variation de sensibilité en fonction de la température ≤ 0,02% / °C.
- DOIT avoir une non-linéarité de la ligne de régression ≤ 0,2%.
- DOIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
- DOIT présenter une erreur de calibration inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est immobile.
- DOIT avoir une sensibilité g inférieure à 0,1 °/s/g.
- DOIT avoir une sensibilité à l'axe transversal inférieure à 4,0 % et une variation de sensibilité à l'axe transversal inférieure à 0,3% dans la plage de température de fonctionnement de l'appareil.
[C-2-4] DOIT avoir un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.
[C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui :
- DOIT avoir une plage de mesure comprise entre -900 et +900 μT au minimum.
- DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
- DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
- DOIT avoir un bruit de mesure ne dépassant pas 0,5 uT.
[C-2-6] DOIT avoir un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD et, en plus :
- DOIT implémenter une forme non-wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
- [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.
[C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui :
- DOIT avoir une plage de mesure comprise entre 300 et 1 100 hPa au minimum.
- DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
- DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
- DOIT avoir un bruit de mesure ne dépassant pas 2 Pa/√Hz.
- DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
- DOIT avoir une consommation d'énergie par lot ne dépassant pas 2 mW.
[C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.
[C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui :
- DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
- DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
[C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-13] Le code temporel de l'événement physique identique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être à moins de 2, 5 millisecondes l'un de l'autre. L'horodatage de l'événement physique identique signalé par l'accéléromètre et le gyroscope DOIT être à moins de 0,25 milliseconde l'un de l'autre.
[C-2-14] Les codes temporels des événements du capteur gyroscopique DOIVENT être basés sur la même base temporelle que le sous-système de caméras et présenter une marge d'erreur de 1 milliseconde.
[C-2-15] DOIT fournir des échantillons aux applications dans un délai de cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
[C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2,0 mW lorsqu'il est en mouvement, lorsque l'une des combinaisons de capteurs suivantes est activée :
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] PEUT disposer d'un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle inclut la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits auxiliaires, système de traitement dédié aux capteurs, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles :

[C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du niveau de taux de rapports directs via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
[C-3-2] DOIT être compatible avec au moins l'un des deux types de canaux directs de capteur pour tous les capteurs qui déclarent être compatibles avec le canal direct de capteur.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DOIT être compatible avec le signalement d'événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations d'appareils incluent un écran de verrouillage sécurisé, elles :

DOIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés comme classe 3 (anciennement forte),

Classe 2 (anciennement Faible) ou Classe 1 (anciennement Commodité), en fonction de leurs taux d'acceptation des usurpations d'identité et des impostures, et de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique à interagir avec la plate-forme et les applications tierces. Les capteurs doivent répondre à des exigences supplémentaires, détaillées ci-dessous, s'ils souhaitent être classés dans la classe 1, la classe 2 ou la classe 3. Les données biométriques de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Si les implémentations d'appareils mettent un capteur biométrique à la disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elles :

[C-4-1] DOIT répondre aux exigences de la biométrie de classe 3 ou classe 2, telles que définies dans le présent document.
[C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe Authenticators et toute combinaison de ceux-ci. À l'inverse, il NE DOIT PAS honorer ni reconnaître les constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de celles-ci.
[C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils disposant de données biométriques de classe 3 ou de classe 2. Cette action DOIT uniquement présenter les points d'entrée d'enregistrement pour les données biométriques de classe 3 ou classe 2.
[C-4-4] DOIT permettre aux applications d'ajouter du contenu personnalisé à BiometricPrompt à l'aide des formats d'affichage de contenu PromptContentView. Les formats d'affichage de contenu NE DOIVENT PAS être étendus pour autoriser les images, les liens, le contenu interactif ou d'autres formes de contenu multimédia qui ne font pas déjà partie de l'API BiometricPrompt. Vous pouvez apporter des ajustements stylistiques qui ne modifient, n'obscurcissent ni ne tronquent pas ce contenu (par exemple, en modifiant la position, la marge intérieure, la marge extérieure et la typographie).

Si les implémentations d'appareils sont compatibles avec la biométrie passive, elles :

[C-5-1] DOIT exiger par défaut une étape de confirmation supplémentaire (par exemple, appuyer sur un bouton).
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de disposer d'un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et d'exiger systématiquement une étape de confirmation.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation afin qu'une compromission du système d'exploitation ou du noyau ne puisse pas la falsifier. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche d'entrée/sortie à usage général (GPIO) en entrée uniquement d'un composant sécurisé (SE) qui ne peut être piloté que par une pression sur un bouton physique.
[C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), que les applications peuvent définir pour les flux de connexion.

Si les implémentations d'appareils comportent plusieurs capteurs biométriques, elles :

[C-7-1] DOIT également bloquer toutes les autres données biométriques d'une classe biométrique inférieure lorsqu'une donnée biométrique est verrouillée (c'est-à-dire désactivée jusqu'à ce que l'utilisateur la déverrouille avec l'authentification principale) ou verrouillée pour une durée limitée (c'est-à-dire temporairement désactivée jusqu'à ce que l'utilisateur attende un certain temps) en raison d'un trop grand nombre de tentatives infructueuses. En cas de verrouillage temporaire, le délai d'attente pour la validation biométrique DOIT être le délai d'attente maximal de toutes les données biométriques en cas de verrouillage temporaire.
[C-SR-12] Il est FORTEMENT RECOMMANDÉ, lorsqu'une méthode biométrique est verrouillée (c'est-à-dire désactivée jusqu'à ce que l'utilisateur la déverrouille avec l'authentification principale) ou verrouillée pour une durée limitée (c'est-à-dire temporairement désactivée jusqu'à ce que l'utilisateur attende un certain temps) en raison d'un trop grand nombre de tentatives infructueuses, de verrouiller également toutes les autres méthodes biométriques de la même classe. En cas de verrouillage limité dans le temps, il est FORTEMENT RECOMMANDÉ que l'intervalle entre les tentatives pour la validation biométrique soit l'intervalle maximal entre les tentatives de toutes les données biométriques en cas de verrouillage limité dans le temps.
[C-7-2] DOIT demander à l'utilisateur de fournir la méthode d'authentification principale recommandée (code, schéma ou mot de passe, par exemple) pour réinitialiser le compteur de verrouillage d'une méthode biométrique verrouillée. Les données biométriques de classe 3 PEUVENT être autorisées à réinitialiser le compteur de verrouillage pour une donnée biométrique verrouillée de même classe ou de classe inférieure. Les données biométriques de classe 2 ou classe 1 NE DOIVENT PAS être autorisées à effectuer une opération de réinitialisation du verrouillage pour les données biométriques.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule authentification biométrique par authentification (par exemple, si des capteurs d'empreinte digitale et de reconnaissance faciale sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé après la confirmation de l'un d'eux).

Pour que les implémentations d'appareils autorisent l'accès aux clés du Keystore aux applications tierces, elles doivent :

[C-6-1] DOIT répondre aux exigences de la classe 3 telles que définies dans la section ci-dessous.
[C-6-2] DOIT présenter uniquement des données biométriques de classe 3 lorsque l'authentification nécessite BIOMETRIC_STRONG ou lorsque l'authentification est appelée avec un CryptoObject.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Classe 1 (anciennement Commodité), elles doivent :

[C-1-1] DOIT avoir un taux de fausse acceptation inférieur à 0,002%.
[C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe fiables, et énumérer clairement les risques liés à son activation si les taux d'acceptation de l'usurpation d'identité et de l'imposture sont supérieurs à 7 %, comme indiqué dans les Protocoles de test biométrique Android.
[C-1-9] DOIT demander à l'utilisateur la méthode d'authentification principale recommandée (par exemple, code PIN, schéma, mot de passe) après au maximum 20 tentatives infructueuses et un intervalle entre les tentatives d'au moins 90 secondes pour la vérification biométrique. Une tentative infructueuse est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une donnée biométrique enregistrée.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de réduire le nombre total de faux essais pour la vérification biométrique spécifié dans [C-1-9] si les taux d'acceptation de l'usurpation d'identité et de l'imposteur sont supérieurs à 7 %, comme mesuré par les protocoles de test Android Biometrics.
[C-1-3] DOIT limiter le nombre de tentatives de vérification biométrique, où une tentative infructueuse est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une donnée biométrique enregistrée.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter le nombre de tentatives à au moins 30 secondes après cinq tentatives infructueuses de validation biométrique pour le nombre maximal de tentatives infructueuses par [C-1-9] (une tentative infructueuse est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une donnée biométrique enregistrée).
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'inclure toute la logique de limitation du débit dans le TEE.
[C-1-10] DOIT désactiver la biométrie une fois que l'intervalle entre les tentatives d'authentification principale a été déclenché pour la première fois, comme décrit dans [C-0-2] de la section 9.11.
[C-1-11] DOIT avoir un taux d'acceptation des usurpations et des imposteurs ne dépassant pas 30%, avec (1) un taux d'acceptation des usurpations et des imposteurs pour les espèces d'instruments d'attaque par présentation (IAP) de niveau A ne dépassant pas 30 % et (2) un taux d'acceptation des usurpations et des imposteurs pour les espèces d'IAP de niveau B ne dépassant pas 40%, tel que mesuré par les Protocoles de test biométriques Android.
[C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans établir d'abord une chaîne de confiance en demandant à l'utilisateur de confirmer une identifiant d'appareil existant ou d'en ajouter un nouveau (code/schéma/mot de passe) sécurisé par TEE. L'implémentation Android Open Source Project fournit le mécanisme dans le framework pour ce faire.
[C-1-5] DOIT supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris par le biais d'un rétablissement de la configuration d'usine) ou lorsque la méthode d'authentification principale recommandée (code PIN, schéma, mot de passe, etc.) est supprimée.
[C-1-6] DOIT respecter le signalement individuel pour cette donnée biométrique (c'est-à-dire DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
[C-1-7] DOIT demander à l'utilisateur de s'authentifier avec la méthode principale recommandée (code, schéma, mot de passe, etc.) au moins une fois toutes les 24 heures.
[C-1-8] DOIT demander à l'utilisateur de fournir la méthode d'authentification principale recommandée (code, schéma, mot de passe, etc.) ou une méthode biométrique de classe 3 (FORTE) dans les cas suivants :
- Un délai d'inactivité de quatre heures.
- Trois tentatives d'authentification biométrique ont échoué.
- La période de délai d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après toute confirmation réussie des identifiants de l'appareil.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils.
[C-SR-8] Il est FORTEMENT RECOMMANDÉ que le taux de faux rejets soit inférieur à 10%, tel que mesuré sur l'appareil.
[C-SR-9] Il est FORTEMENT RECOMMANDÉ que la latence soit inférieure à une seconde, mesurée à partir du moment où la donnée biométrique est détectée jusqu'au déverrouillage de l'écran, pour chaque donnée biométrique enregistrée.
[C-1-12] DOIT avoir un taux d'acceptation des usurpations d'identité et des impostures ne dépassant pas 40 % par espèce d'instrument d'attaque par présentation (IAP), tel que mesuré par les Protocoles de test biométrique Android.
[C-SR-13] Il est FORTEMENT RECOMMANDÉ d'avoir un taux d'acceptation des usurpations et des imposteurs ne dépassant pas 30 % par espèce d'instrument d'attaque par présentation (PAI), tel que mesuré par les Protocoles de test biométrique Android.
[C-SR-8] Il est FORTEMENT RECOMMANDÉ que le taux de faux rejets soit inférieur à 10%, tel que mesuré sur l'appareil.
[C-1-15] DOIT permettre aux utilisateurs de supprimer une ou plusieurs inscriptions biométriques.
[C-SR-14] Il est FORTEMENT RECOMMANDÉ de divulguer la classe biométrique du capteur biométrique et les risques correspondants liés à son activation.
[C-SR-17] Il est FORTEMENT RECOMMANDÉ d'implémenter les nouvelles interfaces AIDL (telles que IFace.aidl et IFingerprint.aidl).

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Classe 2 (anciennement Faible), elles doivent :

[C-2-1] DOIT répondre à toutes les exigences de la classe 1 ci-dessus.
[C-2-2] DOIT avoir un taux d'acceptation des usurpations d'identité et des imposteurs ne dépassant pas 20%, avec (1) un taux d'acceptation des usurpations d'identité et des imposteurs pour les espèces d'instruments d'attaque par présentation (IAP) de niveau A ne dépassant pas 20%, et (2) un taux d'acceptation des usurpations d'identité et des imposteurs pour les espèces d'IAP de niveau B ne dépassant pas 30%, tel que mesuré par les Protocoles de test biométrique Android.
[C-SR-15] Il est FORTEMENT RECOMMANDÉ que le taux d'acceptation des usurpations et des imposteurs ne dépasse pas 20 % par espèce d'instrument d'attaque par présentation (IAP), tel que mesuré par les Protocoles de test biométrique Android.
[C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du noyau Android, tel que l'environnement d'exécution sécurisé (TEE), sur une puce avec un canal sécurisé vers l'environnement d'exécution isolé ou sur une machine virtuelle protégée qui répond aux exigences de la section 9.17.
[C-2-4] DOIT avoir toutes les données identifiables chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site Projet Android Open Source ou dans une machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17.
[C-2-5] Lors de l'authentification ou de l'enregistrement biométriques basés sur une caméra :
- DOIT faire fonctionner la caméra dans un mode qui empêche la lecture ou la modification des images de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé ou d'une machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17.
- Pour les solutions RVB à une seule caméra, les frames de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT TOUJOURS PAS être modifiables.
[C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction entre les enregistrements biométriques individuels.
[C-2-7] NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni aux données qui en sont dérivées (telles que les intégrations) au processeur d'application en dehors du contexte de l'environnement d'exécution sécurisé (TEE) ou de la machine virtuelle protégée contrôlée par un hyperviseur qui répond aux exigences de la section 9.17. La mise à niveau des appareils lancés sur Android 9 ou version antérieure n'est pas exemptée de [C-2-7].
[C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre l'injection directe de données pour une authentification frauduleuse en tant qu'utilisateur.

Remarque : Si les implémentations d'appareils sont déjà lancées sur la version 9 d'Android ou une version antérieure et ne peuvent pas répondre à l'exigence [C-2-8] par le biais d'une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence.
[C-SR-10] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de présence pour toutes les modalités biométriques et la détection de l'attention pour la biométrie faciale.
[C-2-9] DOIT mettre le capteur biométrique à la disposition des applications tierces.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Classe 3 (anciennement Forte), elles doivent :

[C-3-1] DOIT répondre à toutes les exigences de la classe 2 ci-dessus, à l'exception de [C-1-7] et [C-1-8].
[C-3-2] DOIT disposer d'une implémentation de keystore intégré au matériel.
[C-3-3] DOIT avoir un taux d'acceptation des usurpations et des imposteurs ne dépassant pas 7%, avec (1) un taux d'acceptation des usurpations et des imposteurs pour les espèces d'instruments d'attaque par présentation (IAP) de niveau A ne dépassant pas 7 % et (2) un taux d'acceptation des usurpations et des imposteurs pour les espèces d'IAP de niveau B ne dépassant pas 20%, tel que mesuré par les Protocoles de test biométrique Android.
[C-3-4] DOIT demander à l'utilisateur de s'authentifier avec la méthode principale recommandée (code, schéma, mot de passe, etc.) au moins une fois toutes les 72 heures.
[C-3-5] DOIT régénérer l'ID de l'authentificateur pour toutes les données biométriques de classe 3 compatibles sur l'appareil si l'une d'elles est réenregistrée.
[C-3-6] Les clés du keystore protégées par authentification biométrique doivent être activées pour les applications tierces.
[C-SR-16] Il est FORTEMENT RECOMMANDÉ d'avoir un taux d'acceptation des usurpations et des impostures ne dépassant pas 7% par espèce d'instrument d'attaque par présentation (PAI, presentation attack instrument), tel que mesuré par les Protocoles de test biométriques Android.

Si les implémentations d'appareils contiennent un lecteur d'empreinte digitale sous l'écran (UDFPS), elles :

[C-SR-11] Il est FORTEMENT RECOMMANDÉ d'empêcher la zone tactile du capteur d'empreinte digitale sous l'écran d'interférer avec la navigation à trois boutons (dont certains utilisateurs peuvent avoir besoin pour des raisons d'accessibilité).

7.3.11. Capteur de posture

Implémentations sur les appareils :

PEUT prendre en charge le capteur de pose avec 6 degrés de liberté.

Si les implémentations d'appareils sont compatibles avec le capteur de pose à 6 degrés de liberté, elles :

[C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
[C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.12. Capteur d'angle de charnière

Si les implémentations d'appareil sont compatibles avec un capteur d'angle de charnière, elles :

[C-1-1] DOIT implémenter et signaler TYPE_HINGE_ANGLE.
[C-1-2] DOIT prendre en charge au moins deux lectures entre 0 et 360 degrés (inclus, c'est-à-dire y compris 0 et 360 degrés).
[C-1-3] DOIT renvoyer un capteur wakeup pour getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 (UWB)

Si les implémentations d'appareils incluent la prise en charge de la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, elles :

[C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.uwb.
[C-1-3] DOIT être compatible avec tous les ensembles de configuration suivants (combinaisons prédéfinies de paramètres FIRA UCI) définis dans l'implémentation AOSP.
- CONFIG_ID_1 : portée STATIC STS DS-TWR unicast définie par la FiRa, mode différé, intervalle de portée de 240 ms.
- CONFIG_ID_2 : portée STATIC STS DS-TWR de type un-à-plusieurs définie par la FiRa, mode différé, intervalle de portée de 200 ms. Cas d'utilisation typique : un smartphone interagit avec de nombreux appareils connectés.
- CONFIG_ID_3 : identique à CONFIG_ID_1, sauf que les données sur l'angle d'arrivée (AoA) ne sont pas signalées.
- CONFIG_ID_4 : identique à CONFIG_ID_1, sauf que le mode de sécurité P-STS est activé.
- CONFIG_ID_5 : identique à CONFIG_ID_2, sauf que le mode de sécurité P-STS est activé.
- CONFIG_ID_6 : identique à CONFIG_ID_3, sauf que le mode de sécurité P-STS est activé.
- CONFIG_ID_7 : identique à CONFIG_ID_2, sauf que le mode de clé de contrôle individuel P-STS est activé.
[C-1-4] DOIT fournir une affordance utilisateur permettant à l'utilisateur d'activer/désactiver l'état de la radio UWB.
[C-1-5] DOIT s'assurer que les applications utilisant la radio UWB disposent de l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICES).

La réussite des tests de conformité et de certification pertinents définis par les organismes de normalisation, y compris FIRA, CCC et CSA, permet de s'assurer que la norme 802.1.15.4 fonctionne correctement.

7.3.14. Capteurs personnalisés

Pour offrir une expérience différenciée, les implémentations d'appareils PEUVENT inclure des capteurs supplémentaires non couverts par Android ou Wear OS, auxquels les applications préchargées peuvent accéder.

Pour ces capteurs, l'ID du capteur :

[C-0-1] MUST be higher than 65536.

Si le capteur personnalisé est destiné à des fins liées à la santé ou à la forme physique, il :

[C-0-2] DOIT être protégé par une autorisation de plate-forme ou une autorisation système.

7.4. Connectivité des données

7.4.1. Téléphonie

Le terme "téléphonie" utilisé par les API Android et dans ce document fait spécifiquement référence au matériel lié à l'établissement d'appels vocaux et à l'envoi de messages SMS, ou à l'établissement de données mobiles via un réseau mobile (par exemple, GSM, CDMA, LTE, NR). Un appareil compatible avec la téléphonie peut choisir de proposer tout ou partie des services d'appel, de messagerie et de données en fonction du produit.

Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec les appareils autres que les téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles :

[C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony et d'autres flags de sous-fonctionnalité en fonction de la technologie.
[C-1-2] DOIT implémenter une compatibilité complète avec l'API pour cette technologie.
DOIT autoriser tous les types de services cellulaires disponibles (2G, 3G, 4G, 5G, etc.) lors des appels d'urgence (quels que soient les types de réseau définis par SetAllowedNetworkTypeBitmap()).

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles :

[C-2-1] DOIT implémenter les API complètes en tant qu'opérations sans effet.

Si les implémentations d'appareils sont compatibles avec les eUICCs ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire pour rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles :

[C-3-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony.euicc.

Si les implémentations d'appareils ne définissent pas la propriété système ro.telephony.iwlan_operation_mode sur legacy, elles :

[C-4-1] NE DOIT PAS signaler NETWORK_TYPE_IWLAN via NetworkRegistrationInfo#getAccessNetworkTechnology() lorsque NetworkRegistrationInfo#getTransportType() est signalé comme TRANSPORT_TYPE_WWAN pour la même instance NetworkRegistrationInfo.

Si les implémentations d'appareils sont compatibles avec un seul enregistrement IMS (IP Multimedia Subsystem) pour les fonctionnalités MMTEL (Multimedia Telephony Service) et RCS (Rich Communication Service) et qu'elles doivent respecter les exigences des opérateurs mobiles concernant l'utilisation d'un seul enregistrement IMS pour tout le trafic de signalisation IMS, elles :

[C-5-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony.ims et fournir une implémentation complète de l'API ImsService pour l'API User Capability Exchange MMTEL et RCS.
[C-5-2] DOIT déclarer le android.hardware.telephony.ims.singlereg flag de fonctionnalité et fournir une implémentation complète de l'API SipTransport, de l'API GbaService, des indications de support dédié à l'aide de l'IRadio 1.6 HAL et du provisionnement via le serveur de configuration automatique (ACS) ou un autre mécanisme de provisionnement propriétaire à l'aide de l'API de configuration IMS.

Si les implémentations d'appareil signalent la fonctionnalité android.hardware.telephony, alors :

[C-6-1] Les SmsManager#sendTextMessage et SmsManager#sendMultipartTextMessage DOIVENT entraîner des appels correspondants à CarrierMessagingService pour fournir une fonctionnalité de messagerie texte. SmsManager#sendMultimediaMessage et SmsManager#downloadMultimediaMessage DOIVENT entraîner des appels correspondants à CarrierMessagingService pour fournir une fonctionnalité de messagerie multimédia.
[C-6-2] L'application désignée par android.provider.Telephony.Sms#getDefaultSmsPackage DOIT utiliser les API SmsManager pour envoyer et recevoir des SMS et des MMS. L'implémentation de référence AOSP dans packages/apps/Messaging répond à cette exigence.
[C-6-3] L'application qui répond à Intent#ACTION_DIAL DOIT permettre la saisie de codes de numérotation arbitraires au format *#*#CODE#*#* et déclencher une diffusion TelephonyManager#ACTION_SECRET_CODE correspondante.
[C-6-4] L'application qui répond à Intent#ACTION_DIAL DOIT utiliser VoicemailContract.Voicemails#TRANSCRIPTION pour afficher la transcription de la messagerie vocale visuelle aux utilisateurs si elle prend en charge les transcriptions de la messagerie vocale visuelle.
[C-6-5] DOIT représenter toutes les SubscriptionInfo avec des UUID de groupe équivalents comme un seul abonnement dans toutes les affordances visibles par l'utilisateur qui affichent et contrôlent les informations de la carte SIM. Par exemple, les interfaces de paramètres qui correspondent à Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS.
[C-6-6] NE DOIT PAS afficher ni autoriser le contrôle d'un SubscriptionInfo avec un UUID de groupe non nul et un bit opportuniste dans les affordances visibles par l'utilisateur qui permettent la configuration ou le contrôle des paramètres de la carte SIM.

Si les rapports d'implémentation de l'appareil indiquent la fonctionnalité android.hardware.telephony et fournissent une barre d'état système, alors :

[C-7-1] DOIT sélectionner un abonnement actif représentatif pour un UUID de groupe donné à afficher à l'utilisateur dans toutes les affordances fournissant des informations sur l'état de la carte SIM. Par exemple, l'icône de signal cellulaire de la barre d'état ou le bloc de réglages rapides.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de choisir l'abonnement représentatif comme abonnement de données actif, sauf si l'appareil est en appel vocal, auquel cas il est FORTEMENT RECOMMANDÉ de choisir l'abonnement vocal actif comme abonnement représentatif.

Si les implémentations d'appareil signalent la fonctionnalité android.hardware.telephony, alors :

[C-6-7] DOIT être capable d'ouvrir et d'utiliser simultanément le nombre maximal de canaux logiques (20 au total) pour chaque UICC conformément à la norme ETSI TS 102 221.
[C-6-8] NE DOIT PAS appliquer automatiquement ou sans confirmation explicite de l'utilisateur les comportements suivants aux applications d'opérateur actives (désignées par TelephonyManager#getCarrierServicePackageName) :
- Révoquer ou limiter l'accès au réseau
- Révoquer les autorisations
- Limiter l'exécution des applications en arrière-plan ou au premier plan au-delà des fonctionnalités de gestion de l'alimentation existantes incluses dans AOSP
- Désactiver ou désinstaller l'application

Si les implémentations d'appareil signalent la fonctionnalité android.hardware.telephony et que tous les abonnements non opportunistes actifs qui partagent un UUID de groupe sont désactivés, physiquement supprimés de l'appareil ou marqués comme opportunistes, l'appareil :

[C-8-1] DOIT désactiver automatiquement tous les abonnements opportunistes actifs restants du même groupe.

Si les implémentations d'appareils incluent la téléphonie GSM, mais pas la téléphonie CDMA, elles :

[C-9-1] NE DOIT PAS déclarer PackageManager#FEATURE_TELEPHONY_CDMA.
[C-9-2] DOIT générer une IllegalArgumentException lors de toute tentative de définition de types de réseau 3GPP2 dans les masques de bits de type de réseau préféré ou autorisé.
[C-9-3] DOIT renvoyer une chaîne vide à partir de TelephonyManager#getMeid.

Si les implémentations d'appareils sont compatibles avec les eUICCs comportant plusieurs ports et profils, elles :

[C-10-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony.euicc.mep.

Si les implémentations d'appareils sont compatibles avec la connectivité aux données mobiles, elles :

[C-SR-11] Il est FORTEMENT RECOMMANDÉ de déclarer la fonctionnalité android.hardware.telephony.data.

Si les implémentations d'appareils signalent android.hardware.telephony.data, elles :

[C-12-1] DOIT prendre en charge au moins deux connexions simultanées au réseau de données cellulaires, telles que les contextes PDP, les connexions PDN et les connexions DN.

7.4.1.1. Compatibilité du blocage de numéros

Si les implémentations d'appareil signalent la fonctionnalité android.hardware.telephony.calling, elles :

[C-1-1] DOIT inclure la prise en charge du blocage de numéros
[C-1-2] DOIT implémenter entièrement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
[C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans BlockedNumberProvider sans aucune interaction avec les applications. La seule exception est lorsque le blocage de numéros est temporairement levé, comme décrit dans la documentation du SDK.
[C-1-4] DOIT écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué et DOIT filtrer les appels avec BLOCKED_TYPE hors de la vue par défaut du journal d'appels dans l'application de téléphone préinstallée.
[C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
[C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intention renvoyée par la méthode TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à afficher ni à modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. Toute l'UI liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT toujours être respectée.
DOIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil est mis à jour vers Android 7.0.
DOIT fournir une option permettant à l'utilisateur d'afficher les appels bloqués dans l'application de téléphone préinstallée.

7.4.1.2. API Telecom

Si les implémentations d'appareil déclarent android.hardware.microphone et android.hardware.audio.output, mais pas android.hardware.type.television, elles :

[7.4.1.2/C-0-1] DOIT déclarer le flag de fonctionnalité android.software.telecom.
[7.4.1.2/C-0-2] DOIT implémenter le framework de télécommunications.

Si les implémentations d'appareils signalent android.hardware.telephony.calling, elles :

[C-1-1] DOIT être compatible avec les API ConnectionService décrites dans le SDK.
[C-1-2] DOIT afficher un nouvel appel entrant et permettre à l'utilisateur d'accepter ou de refuser l'appel entrant lorsqu'il est en cours d'appel avec une application tierce qui ne prend pas en charge la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
[C-1-3] DOIT disposer d'une application qui implémente InCallService.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à l'appel en cours.

L'implémentation AOSP répond à ces exigences par le biais d'une notification prioritaire qui indique à l'utilisateur que répondre à un appel entrant entraînera l'interruption de l'autre appel.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de précharger l'application de téléphone par défaut qui affiche une entrée de journal d'appels et le nom d'une application tierce dans son journal d'appels lorsque l'application tierce définit la clé d'extras EXTRA_LOG_SELF_MANAGED_CALLS sur true dans son PhoneAccount.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom comme suit :
- Appelez Connection.onDisconnect() lorsqu'une pression courte sur l'événement clé est détectée pendant un appel en cours.
- Appelez Connection.onAnswer() lorsqu'une pression courte sur l'événement clé est détectée lors d'un appel entrant.
- Appelez Connection.onReject() lorsqu'une pression longue sur l'événement clé est détectée lors d'un appel entrant.
- Activez ou désactivez le son de CallAudioState.

7.4.1.3. Déchargement du signal de présence NAT-T cellulaire

Implémentations sur les appareils :

DOIT inclure la prise en charge du déchargement du signal de vie cellulaire.

Si les implémentations d'appareils incluent la prise en charge du déchargement de keepalive cellulaire et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] DOIT être compatible avec l'API SocketKeepAlive.
[C-1-2] DOIT prendre en charge au moins un emplacement de signal de présence simultané sur le réseau mobile.
[C-1-3] DOIT être compatible avec autant d'emplacements de keep-alive cellulaires simultanés que ceux pris en charge par la HAL de la radio cellulaire.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge au moins trois emplacements de keepalive cellulaire par instance radio.

Si les implémentations d'appareils ne sont pas compatibles avec le déchargement du message keepalive cellulaire :

[C-2-1] MUST return ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations sur les appareils :

DOIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.11 et exposent la fonctionnalité à une application tierce, elles :

[C-1-1] DOIT implémenter l'API Android correspondante.
[C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.wifi.
[C-1-3] DOIT implémenter l'API de multidiffusion comme décrit dans la documentation du SDK.
[C-1-4] DOIT être compatible avec mDNS et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251 ou ff02::fb) à tout moment de son fonctionnement, y compris lorsque l'écran n'est pas actif, sauf si le verrouillage multicast n'est pas maintenu et que les paquets sont filtrés par APF. Les paquets ne sont pas tenus de satisfaire aux opérations mDNS actuellement demandées par les applications via les API NsdManager. Toutefois, l'appareil PEUT filtrer les paquets mDNS si cela est nécessaire pour rester dans les limites de consommation d'énergie requises par les exigences réglementaires applicables au marché cible.
[C-1-5] NE DOIT PAS considérer l'appel de méthode de l'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif, qui est utilisé par défaut pour le trafic d'application et renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils NE PEUVENT désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils valident avec succès que le réseau Wi-Fi fournit un accès à Internet.
[C-1-6] Il est FORTEMENT RECOMMANDÉ de réévaluer l'accès à Internet sur le Network lorsque la méthode d'API ConnectivityManager.reportNetworkConnectivity() est appelée et, une fois que l'évaluation a déterminé que le Network actuel ne fournit plus d'accès à Internet, de passer à tout autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
[C-1-7] DOIT randomiser l'adresse MAC source et le numéro de séquence des trames de demande de sonde, une fois au début de chaque analyse, lorsque la STA est déconnectée.
[C-1-8] DOIT utiliser une adresse MAC cohérente (NE DOIT PAS randomiser l'adresse MAC à mi-parcours d'un scan).
[C-1-9] Le numéro de séquence de la requête de vérification DOIT être incrémenté normalement (de manière séquentielle) entre les requêtes de vérification d'une analyse.
[C-1-10] Le numéro de séquence de la requête de vérification DOIT être aléatoire entre la dernière requête de vérification d'une analyse et la première requête de vérification de l'analyse suivante.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source utilisée pour toutes les communications STA avec un point d'accès (AP) lors de l'association et après l'association.
- L'appareil DOIT utiliser une adresse MAC aléatoire différente pour chaque SSID (FQDN pour Passpoint) avec lequel il communique.
- L'appareil DOIT fournir à l'utilisateur une option permettant de contrôler l'aléatorisation par SSID (FQDN pour Passpoint) avec des options non aléatoires et aléatoires, et DOIT définir le mode par défaut pour les nouvelles configurations Wi-Fi sur aléatoire.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser un BSSID aléatoire pour tout PA créé.
- L'adresse MAC DOIT être aléatoire et persistante pour chaque SSID utilisé par le point d'accès.
- L'APPAREIL peut offrir à l'utilisateur la possibilité de désactiver cette fonctionnalité. Si une telle option est fournie, la randomisation DOIT être activée par défaut.

Si les implémentations d'appareils incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles :

DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert un verrouillage WIFI_MODE_FULL_HIGH_PERF ou un verrouillage WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire(), et que le verrouillage est actif.
[C-3-2] La latence moyenne aller-retour entre l'appareil et un point d'accès lorsque l'appareil est en mode Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrouillage à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles :

[C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la lecture de la valeur via la méthode d'API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implémentations sur les appareils :

DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Direct, elles :

[C-1-1] DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK.
[C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
[C-1-3] DOIT prendre en charge le fonctionnement normal du Wi-Fi.
[C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de sélectionner l'adresse MAC source de manière aléatoire pour toutes les nouvelles connexions Wi-Fi Direct.

7.4.2.2. Configuration de la liaison directe tunnelée Wi-Fi

Implémentations sur les appareils :

DOIT inclure la prise en charge de la configuration de la liaison directe tunnelisée Wi-Fi (TDLS), comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils incluent la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, elles :

[C-1-1] DOIT déclarer la compatibilité avec TDLS via WifiManager.isTdlsSupported.
Vous DEVEZ utiliser TDLS uniquement lorsque cela est possible ET bénéfique.
DOIT disposer d'une heuristique et NE DOIT PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles d'un point d'accès Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implémentations sur les appareils :

DOIT inclure la prise en charge de Wi-Fi Aware.

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] DOIT implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
[C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.aware.
[C-1-3] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Aware simultanément.
[C-1-4] L'adresse de l'interface de gestion Wi-Fi Aware DOIT être aléatoire à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure de distance Aware est en cours ou si un chemin de données Aware est actif (l'aléatoire n'est pas attendu tant que le chemin de données est actif).

Si les implémentations d'appareils incluent la prise en charge de Wi-Fi Aware et de la localisation Wi-Fi, comme décrit dans la Section 7.4.2.5, et exposent ces fonctionnalités aux applications tierces, elles :

[C-2-1] DOIT implémenter les API de découverte avec localisation : setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.11 (Wi-Fi), elles doivent :

DOIT être compatible avec Wi-Fi Passpoint.

Si les implémentations d'appareils incluent la prise en charge de Wi-Fi Passpoint, elles :

[C-1-2] DOIT implémenter les API WifiManager liées à Passpoint, comme décrit dans la documentation du SDK.
[C-1-3] DOIT être compatible avec la norme IEEE 802.11u, en particulier en ce qui concerne la découverte et la sélection du réseau, comme le Generic Advertisement Service (GAS) et l'Access Network Query Protocol (ANQP).
[C-1-4] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.passpoint.
[C-1-5] DOIT suivre l'implémentation AOSP pour découvrir, faire correspondre et associer les réseaux Passpoint.
[C-1-6] DOIT prendre en charge au moins le sous-ensemble suivant de protocoles de préparation de l'appareil, tel que défini dans Wi-Fi Alliance Passpoint R2 : authentification EAP-TTLS et SOAP-XML.
[C-1-7] DOIT traiter le certificat du serveur AAA comme décrit dans la spécification Hotspot 2.0 R3.
[C-1-8] DOIT permettre à l'utilisateur de contrôler le provisionnement via le sélecteur Wi-Fi.
[C-1-9] DOIT conserver les configurations Passpoint lors des redémarrages.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'acceptation des conditions d'utilisation.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'informations sur le lieu.

Si un bouton de désactivation Passpoint global est fourni, les implémentations :

[C-3-1] DOIT activer Passpoint par défaut.

7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi)

Implémentations sur les appareils :

DOIT inclure la prise en charge de la localisation Wi-Fi.

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] DOIT implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
[C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
[C-1-3] DOIT randomiser l'adresse MAC source pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.
[C-1-4] DOIT être précis à moins de 2 mètres à une bande passante de 80 MHz au 68e centile (tel que calculé avec la fonction de distribution cumulative).
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler la position avec une précision de 1,5 mètre à une bande passante de 80 MHz au 68e centile (calculé avec la fonction de distribution cumulative).

7.4.2.6. Déchargement du keepalive Wi-Fi

Implémentations sur les appareils :

DOIT inclure la prise en charge du déchargement de la fonctionnalité Wi-Fi Keep-Alive.

Si les implémentations d'appareils incluent la prise en charge du déchargement de keepalive Wi-Fi et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] DOIT être compatible avec l'API SocketKeepAlive.
[C-1-2] DOIT prendre en charge au moins trois emplacements de signaux de présence simultanés sur le Wi-Fi

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement de keepalive Wi-Fi :

[C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de configuration des appareils)

Implémentations sur les appareils :

DOIT inclure la prise en charge de Wi-Fi Easy Connect (DPP).

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Easy Connect et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer true.

7.4.2.8. Validation du certificat de serveur Wi-Fi Enterprise

Si le certificat du serveur Wi-Fi n'est pas validé ou si le nom de domaine du serveur Wi-Fi n'est pas défini, les implémentations d'appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas proposer à l'utilisateur d'ajouter manuellement un réseau Wi-Fi d'entreprise dans l'application Paramètres.

7.4.2.9. Faire confiance lors de la première utilisation (TOFU)

Si les implémentations d'appareils sont compatibles avec la fonctionnalité "Trust on first usage" (TOFU) et permettent à l'utilisateur de définir des configurations WPA/WPA2/WPA3-Enterprise, elles :

[C-4-1] DOIT fournir à l'utilisateur une option lui permettant de sélectionner l'utilisation de TOFU.

7.4.2.10. Détection de proximité Wi-Fi

Si les implémentations d'appareils incluent la prise en charge de la détection de proximité Wi-Fi, elles doivent :

[C-1-1] DOIT être compatible avec la détection de proximité.
[C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
[C-1-3] La méthode WifiRttManager#getProximityDetectionCharacteristics() DOIT renvoyer une valeur non nulle.
[C-1-4] DOIT implémenter les API de mesure continue de la distance WifiRttManager.
[C-1-5] DOIT prendre en charge les opérations de détection de proximité Wi-Fi et Wi-Fi simultanément.
[C-1-6] DOIT être précis à moins de 2 mètres à une bande passante de 80 MHz au 68e centile (calculé avec la fonction de distribution cumulative).
[C-1-7] DOIT effectuer une mesure de distance par détection de proximité (PD) dans la bande de fréquences la plus élevée disponible (6 GHz, 5 GHz ou 2,4 GHz) en utilisant la bande passante maximale prise en charge dans l'ordre de priorité suivant : 160 MHz, 80 MHz, 40 MHz et 20 MHz.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler la position avec une précision de 1,5 mètre à une bande passante de 80 MHz au 68e centile (calculé avec la fonction de distribution cumulative).
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge la mesure de distance 802.11az NTB.

7.4.3. Bluetooth

Si les implémentations d'appareils sont compatibles avec le profil audio Bluetooth, elles :

DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec HFP, A2DP et AVRCP, elles :

DOIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareil déclarent la fonctionnalité android.hardware.vr.high_performance, elles :

[C-1-1] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations d'appareils incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation, elles :

[C-2-1] DOIT déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le respectivement) et implémenter les API de plate-forme.
DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., selon l'appareil.

Si les implémentations d'appareils incluent la prise en charge du Bluetooth à basse consommation (BLE), elles doivent :

[C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
[C-3-2] DOIT activer les API Bluetooth basées sur GATT (Generic Attribute Profile) comme décrit dans la documentation du SDK et android.bluetooth.
[C-3-3] DOIT signaler la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() afin d'indiquer si la logique de filtrage des classes d'API ScanFilter est implémentée.
[C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() afin d'indiquer si la publicité à faible consommation d'énergie est prise en charge.
[C-3-5] DOIT implémenter un délai d'expiration pour les adresses privées résolvables (RPA) ne dépassant pas 15 minutes et faire tourner l'adresse à l'expiration du délai pour protéger la confidentialité de l'utilisateur lorsque l'appareil utilise activement le BLE pour la recherche ou la publicité. Pour éviter les attaques par temporisation, les intervalles de délai avant expiration DOIVENT également être aléatoires (entre 5 et 15 minutes).
DOIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
DOIT prendre en charge le déchargement de l'analyse par lots sur le chipset Bluetooth.
DOIT être compatible avec plusieurs annonces et au moins quatre emplacements.

Si les implémentations d'appareils sont compatibles avec Bluetooth LE et utilisent Bluetooth LE pour la recherche de position, elles :

[C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la prise en charge du profil Bluetooth LE et Appareils auditifs, comme décrit dans Prise en charge de l'audio des appareils auditifs avec Bluetooth LE, elles :

[C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Si les implémentations d'appareils incluent la prise en charge du Bluetooth ou du Bluetooth à basse consommation, elles :

[C-6-1] DOIT restreindre l'accès à toutes les métadonnées Bluetooth (telles que les résultats de l'analyse) qui pourraient être utilisées pour déterminer la position de l'appareil, sauf si l'application qui en fait la demande réussit une vérification des autorisations android.permission.ACCESS_FINE_LOCATION en fonction de son état actuel (premier plan/arrière-plan).

Si les implémentations d'appareils incluent la compatibilité avec le Bluetooth ou le Bluetooth à basse consommation et que le fichier manifeste de l'application n'inclut pas de déclaration du développeur indiquant qu'il ne déduit pas la position du Bluetooth, elles :

[C-6-2] L'accès au Bluetooth DOIT être contrôlé par android.permission.ACCESS_FINE_LOCATION.

Si les implémentations d'appareil renvoient true pour l'API BluetoothAdapter.isLeAudioSupported(), elles :

[C-7-1] DOIT être compatible avec le client unicast.
[C-7-2] DOIT être compatible avec la couche physique 2M.
[C-7-3] DOIT être compatible avec la publicité étendue LE.
[C-7-4] DOIT prendre en charge au moins deux connexions CIS dans un CIG.
[C-7-5] DOIT activer simultanément le client BAP en mode unicast, le coordinateur de l'ensemble CSIP, le serveur MCP, le contrôleur VCP et le serveur CCP.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'activer le client HAP en mode monodiffusion.

Si les implémentations d'appareil renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elles :

[C-8-1] DOIT prendre en charge au moins deux liens BIS dans un BIG.
[C-8-2] DOIT activer simultanément la source de diffusion BAP et l'assistant de diffusion BAP.
[C-8-3] DOIT être compatible avec la publicité périodique LE.

Si les implémentations d'appareil renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elles :

[C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
[C-9-2] DOIT être compatible avec la publicité périodique LE.

Si les implémentations d'appareil déclarent FEATURE_BLUETOOTH_LE, elles :

[C-10-1] Les mesures RSSI DOIVENT être comprises dans une plage de +/-9 dB pour 95% des mesures à 1 mètre d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH dans un environnement en visibilité directe.
[C-10-2] DOIT inclure des corrections Rx/Tx pour réduire les écarts par canal afin que 95% des mesures sur chacun des trois canaux, sur chacune des antennes (si plusieurs sont utilisées), soient à +/-3 dB les unes des autres.

Si les implémentations d'appareil déclarent FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, elles :

[C-11-1] DOIT signaler le flag de fonctionnalité matérielle android.hardware.bluetooth_le.channel_sounding.
[C-11-2] DOIT indiquer la plage avec précision à +/- 0,5 m près au 90e centile, tel que calculé avec la fonction de distribution cumulative, à la distance de 1 m.

Si les implémentations d'appareil déclarent FEATURE_BLUETOOTH_LE, elles :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Rx pour s'assurer que le RSSI BLE médian est de -60 dBm +/-10 dB à 1 mètre de distance d'un appareil de référence émettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de manière à se trouver sur des "plans parallèles" avec les écrans orientés dans la même direction.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage de transmission pour s'assurer que le RSSI BLE médian est de -60 dBm +/-10 dB lors de la recherche à partir d'un appareil de référence positionné à 1 mètre de distance et transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de manière à se trouver sur des "plans parallèles" avec les écrans orientés dans la même direction.

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration de la mesure spécifiées dans les exigences de calibration de la présence.

7.4.4. Communication en champ proche

Implémentations sur les appareils :

DOIT inclure un émetteur-récepteur et le matériel associé pour la communication en champ proche (NFC).
[C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord, même si elles n'incluent pas la prise en charge de la technologie NFC ou ne déclarent pas la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation des données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition des applications tierces, elles doivent :

[C-1-1] DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature().
DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes :
[C-1-2] DOIT être capable d'agir en tant que lecteur/enregistreur NFC Forum (tel que défini par la spécification technique NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NFC-F (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Types de tags NFC Forum 2, 3, 4 et 5 (définis par le NFC Forum)
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'être capable de lire et d'écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que, bien que les normes NFC soient fortement recommandées, la définition de compatibilité pour une future version prévoit de les remplacer par MUST. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les versions ultérieures. Nous encourageons vivement les appareils existants et nouveaux qui exécutent cette version d'Android à respecter ces exigences dès maintenant afin de pouvoir passer aux futures versions de la plate-forme.
[C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.
DOIT être en mode découverte NFC lorsque l'appareil est réveillé, que l'écran est actif et que l'écran de verrouillage est déverrouillé.
DOIT être capable de lire le code-barres et l'URL (si elle est encodée) des produits Thinfilm NFC Barcode.

Notez que les liens accessibles au public ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.

Android est compatible avec le mode d'émulation de carte hôte (HCE) NFC.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage de l'ID d'application (AID), elles :

[C-2-1] DOIT signaler la constante de fonctionnalité android.hardware.nfc.hce.
[C-2-2] DOIT être compatible avec les API NFC HCE telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles :

[C-3-1] DOIT signaler la constante de fonctionnalité android.hardware.nfc.hcef.
[C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent la prise en charge NFC générale décrite dans cette section et prennent en charge les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/enregistreur, elles :

[C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le SDK Android.
[C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard. Elle n'apparaît donc pas en tant que constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles et API de mise en réseau

7.4.5.1. Capacité réseau minimale

Implémentations sur les appareils :

[C-0-1] DOIT inclure la prise en charge d'une ou plusieurs formes de réseau de données. Plus précisément, les implémentations d'appareils DOIVENT inclure la prise en charge d'au moins une norme de données capable d'atteindre 200 Kbit/s ou plus. Parmi les technologies qui répondent à cette exigence, on peut citer EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth PAN.
Il DOIT également être compatible avec au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (telle qu'Ethernet) est la connexion de données principale.
PEUT implémenter plusieurs formes de connectivité des données.

7.4.5.2. IPv6

Implémentations sur les appareils :

[C-0-2] DOIT inclure une pile réseau IPv6 et être compatible avec la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
[C-0-3] DOIT activer IPv6 par défaut.
DOIT s'assurer que la communication IPv6 est aussi fiable que l'IPv4, par exemple :
[C-0-4] DOIT maintenir la connectivité IPv6 en mode veille.
[C-0-5] La limitation du débit ne DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau compatible IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.
[C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port se produisant localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort, ainsi que les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port sources pour les serveurs Internet (Web).

Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi, elles :

[C-1-1] DOIT être compatible avec le fonctionnement à double pile et uniquement IPv6 sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, elles :

[C-2-1] DOIT être compatible avec le fonctionnement à double pile et IPv6 uniquement sur Ethernet.

Si les implémentations d'appareils sont compatibles avec les données mobiles, elles :

[C-3-1] DOIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, le Wi-Fi et les données mobiles), elles :

[C-4-1] DOIT répondre simultanément aux exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

7.4.5.3. Portails captifs

Un portail captif désigne un réseau qui nécessite une connexion pour accéder à Internet.

Si les implémentations d'appareil fournissent une implémentation complète de android.webkit.Webview API, elles :

[C-1-1] DOIT fournir une application de portail captif pour gérer l'intention ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif en envoyant cette intention lors de l'appel à l'API système ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DOIT détecter les portails captifs et permettre la connexion via l'application de portail captif lorsque l'appareil est connecté à un réseau de quelque type que ce soit, y compris un réseau mobile/cellulaire, Wi-Fi, Ethernet ou Bluetooth.
[C-1-3] DOIT permettre la connexion aux portails captifs à l'aide du DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode strict du DNS privé.
[C-1-4] DOIT utiliser le DNS chiffré conformément à la documentation du SDK pour android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout le trafic réseau qui ne communique pas explicitement avec le portail captif.
[C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un portail captif, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback et utilisé par défaut par les API réseau Java telles que java.net.Socket et les API natives telles que connect()) est tout autre réseau disponible qui fournit un accès à Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations sur les appareils :

[C-0-1] La synchronisation automatique principale DOIT être activée par défaut pour que la méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, elles sont :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

Si les implémentations d'appareils fournissent le mode Économiseur de données, elles :

[C-1-1] DOIT être compatible avec toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.

Si les implémentations d'appareils ne fournissent pas le mode Économiseur de données, elles :

[C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Composants sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés Open Mobile API et les mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via l'API android.se.omapi.SEService.getReaders().
[C-1-2] DOIT déclarer les indicateurs de fonctionnalité corrects via android.hardware.se.omapi.uicc pour l'appareil avec des éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil avec des éléments sécurisés basés sur eSE et android.hardware.se.omapi.sd pour l'appareil avec des éléments sécurisés basés sur SD.

7.4.9. UWB

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, elles :

[C-1-1] DOIT implémenter l'API Android correspondante dans android.uwb.
[C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.uwb.
[C-1-3] DOIT être compatible avec tous les profils UWB pertinents définis dans l'implémentation Android.
[C-1-4] DOIT fournir une affordance utilisateur permettant à l'utilisateur d'activer/désactiver l'état de la radio UWB.
[C-1-5] DOIT s'assurer que les applications utilisant la radio UWB détiennent l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICES).
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organismes de normalisation, y compris FIRA, CCC et CSA.
[C-1-6] DOIT s'assurer que les mesures de distance sont comprises dans une marge de +/-15 cm pour 95% des mesures dans l'environnement en visibilité directe à 1 mètre de distance dans une chambre non réfléchissante.
[C-1-7] DOIT s'assurer que la médiane des mesures de distance à 1 mètre de l'appareil de référence se situe dans la plage [0,75 m, 1,25 m], où la distance réelle est mesurée à partir du bord supérieur de l'appareil testé.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration de la mesure spécifiées dans les Exigences de calibration de la présence.

7.5. Appareils photo

Si les implémentations d'appareil incluent au moins une caméra, elles :

[C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
[C-1-2] Il DOIT être possible pour une application d'allouer simultanément 3 RGBA_8888 bitmaps de taille égale à celle des images produites par le capteur de caméra de résolution la plus élevée sur l'appareil, tandis que la caméra est ouverte à des fins de prévisualisation de base et de capture d'images fixes.
[C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée qui gère les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque celle-ci ne dispose pas de ACCESS_FINE_LOCATION.

Si les implémentations d'appareils incluent au moins une caméra et que l'application de caméra préinstallée gère les intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE ou MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, elles :

[C-1-4] DOIT s'assurer que, lors du traitement de ces intents, l'application de caméras préinstallée supprime la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer aux applications de réception qui ne disposent pas de ACCESS_FINE_LOCATION.
[C-1-5] DOIT s'assurer que la photo animée renvoyée utilise la spécification du format Photo animée 1.0.

[C-1-6] DOIT attribuer un libellé à chaque type de caméra à l'aide du champ CameraCharacteristics.INFO_DEVICE_TYPE (BUILT_IN, EXTERNAL ou VIRTUAL). Vous DEVEZ également étiqueter chaque frame de sortie de la caméra à l'aide du champ CaptureResult.INFO_DEVICE_TYPE.
Il est particulièrement important de s'assurer que CaptureResult.INFO_DEVICE_TYPE est correctement libellé dans les situations où un ID de caméra est remappé de manière dynamique à une autre source de caméra.

Si les implémentations d'appareils sont compatibles avec la capacité de sortie HDR 10 bits, elles :

[C-2-1] DOIT être compatible au moins avec le profil HDR HLG pour chaque caméra prenant en charge la sortie 10 bits.
[C-2-2] DOIT prendre en charge la sortie 10 bits pour la caméra arrière principale ou la caméra avant principale.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la sortie 10 bits pour les caméras principales.
[C-2-3] DOIT être compatible avec les mêmes profils HDR pour toutes les sous-caméras physiques compatibles avec BACKWARD_COMPATIBLE d'une caméra logique, ainsi que pour la caméra logique elle-même.

Pour les appareils photo logiques compatibles avec le HDR 10 bits qui implémentent l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO, ils :

[C-3-1] DOIT permettre de basculer entre toutes les caméras physiques rétrocompatibles via le contrôle CONTROL_ZOOM_RATIO sur la caméra logique.

7.5.1. Caméra arrière

Une caméra orientée vers l'arrière est une caméra orientée vers le monde qui filme des scènes situées à l'opposé de l'appareil, comme une caméra traditionnelle. Sur les appareils portables, il s'agit d'une caméra située sur le côté de l'appareil opposé à l'écran.

Implémentations sur les appareils :

DOIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra orientée vers l'arrière, elles :

[C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera et android.hardware.camera.any.

~~[C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.~~

DOIT avoir un autofocus matériel ou logiciel implémenté dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
PEUT être équipé d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF).
PEUT inclure un flash.

Si la caméra inclut un flash :

[C-2-1] La lampe flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de la caméra, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée de l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra orientée vers l'utilisateur, généralement utilisée pour l'imagerie de l'utilisateur, par exemple pour les visioconférences et les applications similaires. Sur les appareils portables, il s'agit d'une caméra située du même côté de l'appareil que l'écran.

Implémentations sur les appareils :

PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra frontale, elles :

[C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
[C-1-2] DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
[C-1-3] NE DOIT PAS utiliser de caméra frontale comme caméra par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme caméra arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
[C-1-4] L'aperçu de la caméra DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque l'application actuelle a explicitement demandé la rotation de l'affichage de la caméra via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application actuelle ne demande pas explicitement la rotation de l'affichage de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
[C-1-5] NE DOIT PAS refléter l'image fixe ou les flux vidéo finaux capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
[C-1-6] DOIT refléter l'image affichée par la post-vue de la même manière que le flux d'images de prévisualisation de la caméra.
PEUT inclure des fonctionnalités (comme la mise au point automatique, le flash, etc.) disponibles pour les caméras orientées vers l'arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareil peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur) :

[C-2-1] L'aperçu de l'appareil photo DOIT être inversé horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Une caméra externe est une caméra qui peut être physiquement attachée ou détachée de l'implémentation de l'appareil à tout moment et qui peut être orientée dans n'importe quelle direction, comme les caméras USB.

Implémentations sur les appareils :

PEUT inclure la prise en charge d'une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations d'appareils incluent la prise en charge d'une caméra externe, elles :

[C-1-1] DOIT déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
[C-1-2] DOIT être compatible avec la spécification USB Video Class (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
[C-1-3] DOIT réussir les tests CTS de la caméra avec un appareil photo externe physique connecté. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
DOIT être compatible avec les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire les flux d'images brutes ou compressées indépendamment).
MAY peut prendre en charge plusieurs caméras.
MAY peut prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est pris en charge :

[C-2-1] Une diffusion simultanée non encodée / MJPEG (résolution QVGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. La nouvelle API android.hardware.camera2 expose un contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de rafale/streaming efficaces sans copie et des contrôles par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, de la réduction du bruit, de l'amélioration de la netteté, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la prise en charge continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de la mise au point automatique doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir une vitesse ou une qualité identiques, mais DOIVENT correspondre le plus fidèlement possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles. Implémentations sur les appareils :

[C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] DOIT également être au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données du byte[] sont transmises à onPreviewFrame(). En d'autres termes, NV21 DOIT être la valeur par défaut.
[C-0-3] DOIT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de caméra, à la fois pour les caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion au format YV12.)
[C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la fonctionnalité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
[C-0-5] DOIT toujours implémenter l'intégralité de l'API Camera incluse dans la documentation du SDK Android, que l'appareil inclue ou non la mise au point automatique matérielle ou d'autres fonctionnalités. Par exemple, les caméras sans autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour une caméra sans autofocus). Notez que cela s'applique aux caméras frontales. Par exemple, même si la plupart des caméras frontales ne prennent pas en charge la mise au point automatique, les rappels d'API doivent toujours être "simulés" comme décrit.
[C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans les classes android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées comme constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres de caméra standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres de caméra personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'images à l'aide de techniques d'imagerie à plage dynamique élevée (HDR) DOIVENT prendre en charge le paramètre de caméra Camera.SCENE_MODE_HDR.
[C-0-7] DOIT indiquer le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et indiquer les indicateurs de fonctionnalité du framework appropriés.
[C-0-8] DOIT également déclarer les capacités individuelles de la caméra android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir l'indicateur de fonctionnalité si l'un de ses appareils photo associés prend en charge la fonctionnalité.
[C-0-9] DOIT diffuser l'intention Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée à la galerie multimédia.
[C-0-10] DOIT diffuser l'intention Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au Media Store.
[C-0-11] TOUTES les caméras accessibles via l'API android.hardware.Camera obsolète DOIVENT également être accessibles via l'API android.hardware.camera2.
[C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS modifiée, y compris, mais sans s'y limiter, la géométrie du visage, le teint ou le lissage de la peau du visage pour toute API android.hardware.camera2 ou android.hardware.Camera.
[C-SR-1] Pour les appareils dotés de plusieurs caméras RVB à proximité et orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui liste la fonctionnalité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composée de toutes les caméras RVB orientées dans cette direction en tant que sous-appareils physiques.

Si les implémentations d'appareils fournissent une API de caméra propriétaire aux applications tierces, elles :

[C-1-1] DOIT implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
PEUT fournir des tags et/ou des extensions de fournisseur à l'API android.hardware.camera2.

Si les implémentations d'appareils ajustent leur pipeline de caméras tierces pour qu'il soit identique à leur pipeline de caméras intégrées pour la caméra avant principale et la caméra arrière principale, elles :

[C-2-1] DOIT déclarer la propriété système ro.camera.default_app_social_media_parity_enabled.

7.5.5. Orientation de la caméra

Si les implémentations d'appareils sont dotées d'une caméra avant ou arrière, cette ou ces caméras :

[C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode Paysage, les caméras DOIVENT capturer des images en mode Paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils dont l'orientation principale est le mode paysage, ainsi qu'à ceux dont l'orientation principale est le mode portrait.

Les appareils qui répondent à l'un des critères suivants sont exemptés de cette exigence :
- L'appareil implémente des écrans à géométrie variable, tels que des écrans pliables ou à charnière, ET lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe d'une orientation portrait principale à une orientation paysage principale (ou inversement).
- Implémentations d'appareils que l'utilisateur ne peut pas faire pivoter, comme les appareils automobiles.

7.6. Mémoire et stockage

7.6.1. Mémoire et espace de stockage minimum

Implémentations sur les appareils :

[C-0-1] DOIT inclure un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Il DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo dans l'emplacement de "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations sur les appareils :

[C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "espace de stockage externe partagé", "espace de stockage partagé par les applications" ou par le chemin Linux "/sdcard" sur lequel il est monté.
[C-0-2] DOIT être configuré avec un stockage partagé monté par défaut, en d'autres termes "prêt à l'emploi", que le stockage soit implémenté sur un composant de mémoire de stockage interne ou sur un support de stockage amovible (par exemple, un emplacement pour carte Secure Digital).
[C-0-3] DOIT monter le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux de sdcard vers le point de montage réel.
[C-0-4] DOIT activer l'espace de stockage cloisonné par défaut pour toutes les applications ciblant le niveau d'API 29 ou supérieur, sauf dans la situation suivante :
- Lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans son fichier manifeste.
[C-0-5] DOIT masquer les métadonnées de localisation, telles que les tags GPS Exif, stockées dans les fichiers multimédias lorsque ces fichiers sont consultés via MediaStore, sauf lorsque l'application appelante détient l'autorisation ACCESS_MEDIA_LOCATION.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'une des méthodes suivantes :

Un espace de stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte Secure Digital (SD).
Partie de l'espace de stockage interne (non amovible) telle qu'implémentée dans le Projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles :

[C-1-1] DOIT implémenter une interface utilisateur de type pop-up ou toast pour avertir l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le lecteur.
[C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur la boîte et sur les autres supports disponibles au moment de l'achat que le support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles :

DOIT utiliser l'implémentation AOSP du stockage partagé interne de l'application.
PEUT partager l'espace de stockage avec les données privées de l'application.

Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, elles :

[C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application depuis un ordinateur hôte.
DOIT exposer le contenu des deux chemins de stockage de manière transparente via le service de scanner multimédia d'Android et android.provider.MediaStore.
PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole de transfert de fichiers multimédias pour répondre à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole MTP (Media Transfer Protocol), elles :

DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
DOIT signaler une classe de périphérique USB de 0x00.
DOIT signaler un nom d'interface USB "MTP".

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile, contrairement à un téléviseur, les implémentations d'appareils sont les suivantes :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption des données.

Si le port du périphérique de stockage amovible se trouve dans un emplacement stable à long terme, par exemple dans le compartiment de la batterie ou sous un autre couvercle de protection, les implémentations de l'appareil sont les suivantes :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable.

7.7. USB

Définitions

Le mode hôte USB est activé lorsqu'une implémentation d'appareil sert d'hôte USB, alimente le bus et communique avec les périphériques.
Le mode périphérique USB (également appelé mode périphérique USB) se produit lorsqu'une implémentation d'appareil agit comme un périphérique USB, se connecte à un hôte via un port en amont et répond aux requêtes de l'hôte.
Un port USB est défini comme un mécanisme permettant de fournir une connectivité USB, qu'il s'agisse d'un réceptacle USB physique ou d'une interface non standard (par exemple, des broches pogo).

Si les implémentations d'appareils disposent d'un port USB, elles :

DOIT prendre en charge le mode appareil USB.
DOIT être compatible avec le mode hôte USB.
DOIT permettre de désactiver la signalisation des données via USB.

7.7.1. Mode appareil USB

Si les implémentations d'appareils incluent un port USB compatible avec le mode périphérique :

[C-1-1] Le port DOIT pouvoir être connecté à un hôte USB doté d'un port USB standard de type A ou de type C.
[C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur de périphérique standard USB via android.os.Build.SERIAL.
[C-1-3] DOIT détecter les chargeurs 1,5 A et 3,0 A conformément à la norme de résistance Type-C et DOIT détecter les changements dans la publicité s'il prend en charge l'USB Type-C.

[C-SR-1] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.

[C-SR-2] Le port DOIT être situé en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage soit correct lorsque l'appareil est orienté avec le port en bas. Nous vous RECOMMANDONS FORTEMENT de vous assurer que vos appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
[C-SR-3] DOIT implémenter la prise en charge du tirage de courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de batterie USB, révision 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/récepteur, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes USB Power Delivery standards. Bien que cela soit indiqué comme "FORTEMENT RECOMMANDÉ", il est possible que dans les futures versions d'Android, nous EXIGIONS que tous les appareils de type C soient entièrement interopérables avec les chargeurs de type C standards.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ qu'ils soient compatibles avec Power Delivery pour l'échange de rôle de données et d'alimentation lorsqu'ils sont compatibles avec le mode hôte USB et USB Type-C.
DOIT prendre en charge la technologie Power Delivery pour la recharge haute tension et les modes alternatifs tels que la sortie vidéo.
DOIT implémenter l'API et la spécification Android Open Accessory (AOA) telles que documentées dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, elles :

[C-2-1] DOIT déclarer la compatibilité avec la fonctionnalité matérielle android.hardware.usb.accessory.
[C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne de description de l'interface iInterface du stockage de masse USB.

7.7.2. Mode hôte USB

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte, elles :

[C-1-1] DOIT implémenter l'API hôte USB Android telle que documentée dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
[C-1-2] DOIT implémenter la prise en charge de la connexion de périphériques USB standards. Il DOIT disposer de l'un des éléments suivants :
- Un port USB Type-C sur l'appareil ou un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB Type-C standard (appareil USB Type-C).
- Un port USB Type-A sur l'appareil ou un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB Type-A standard.
- Un port micro-AB USB sur l'appareil, qui DOIT être fourni avec un câble d'adaptation à un port USB Type-A standard.
[C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant les ports USB Type-A ou micro-AB en port USB Type-C (prise).
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
DOIT prendre en charge la recharge du périphérique USB connecté en mode hôte, en annonçant un courant source d'au moins 1,5 A, comme spécifié dans la section "Termination Parameters" de la spécification USB Type-C Cable and Connector Revision 1.2 pour les connecteurs USB Type-C ou en utilisant la plage de courant de sortie du port de recharge en aval (CDP), comme spécifié dans les spécifications USB Battery Charging, révision 1.2 pour les connecteurs Micro-AB.
DOIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et la classe audio USB, elles :

[C-2-1] DOIT être compatible avec la classe USB HID.
[C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la demande d'utilisation de commandes vocales aux constantes KeyEvent comme indiqué ci-dessous :
- Page d'utilisation (0xC), ID d'utilisation (0x0CD) : KEYCODE_MEDIA_PLAY_PAUSE
- Page d'utilisation (0xC) ID d'utilisation (0x0E9) : KEYCODE_VOLUME_UP
- Page d'utilisation (0xC) ID d'utilisation (0x0EA) : KEYCODE_VOLUME_DOWN
- Page d'utilisation (0xC), ID d'utilisation (0x0CF) : KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le framework d'accès au stockage (SAF), elles :

[C-3-1] DOIT reconnaître tout appareil MTP (Media Transfer Protocol) connecté à distance et rendre son contenu accessible via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT.

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et l'USB Type-C, elles :

[C-4-1] DOIT implémenter la fonctionnalité Dual Role Power (DRP) telle que définie par la spécification USB Type-C (section 4.5.1.3.3). Pour les ports DRP, sur les appareils qui incluent une prise audio de 3,5 mm, la détection de l'alimentation USB (mode hôte) PEUT être désactivée par défaut, mais l'utilisateur DOIT pouvoir l'activer.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge DisplayPort.
- DOIT être compatible avec les débits de données USB SuperSpeed.
- sont FORTEMENT RECOMMANDÉS pour prendre en charge Power Delivery pour l'échange de rôle de données et d'alimentation.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la spécification des câbles et connecteurs USB-C, révision 1.2.
DOIT implémenter le modèle Try.* le plus approprié au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.7.3. USB Power Delivery

Si les implémentations d'appareils incluent un port USB-C, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe de connecteur USB Type-C du noyau et les nœuds nécessaires qui décrivent les connexions USB Type-C, ainsi que les rôles d'alimentation et de données. Pour en savoir plus sur l'implémentation, consultez la documentation Android sur l'USB Type-C.

Si les implémentations d'appareils incluent un port USB Type-C et prennent en charge l'alimentation, elles :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter tous les nœuds qui décrivent l'USB Power Delivery. Pour en savoir plus sur l'implémentation, consultez la documentation Android USB PD.

Si les implémentations d'appareils incluent un port USB Type-C et prennent en charge les modes alternatifs, elles :

[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'implémenter les modes alternatifs et les propriétés liées à l'identité de la classe de connecteur USB Type-C du noyau. Pour en savoir plus sur l'implémentation, consultez la documentation Android sur l'USB Type-C.

Si les implémentations d'appareils incluent un port USB Type-C et sont compatibles avec le mode alternatif Thunderbolt 3, elles :

[C-SR-4] Il est FORTEMENT RECOMMANDÉ d'implémenter la possibilité de remplacer le mode alternatif actuel via la classe de connecteur de type C.

7.8. Audio

7.8.1. Micro

Si les implémentations d'appareils incluent un micro, elles doivent :

[C-1-1] DOIT signaler la constante de fonctionnalité android.hardware.microphone.
[C-1-2] DOIT respecter les exigences relatives à l'enregistrement audio de la section 5.4.
[C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement des sons proches des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareil omettent un micro, elles :

[C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
[C-2-2] DOIT implémenter l'API d'enregistrement audio au moins en tant que no-ops, conformément à la section 7.

7.8.2. Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles :

[C-1-1] DOIT signaler la constante de fonctionnalité android.hardware.audio.output.
[C-1-2] DOIT répondre aux exigences de lecture audio de la section 5.5.
[C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la lecture des sons proches des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles :

[C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
[C-2-2] DOIT implémenter au moins les API liées à la sortie audio en tant qu'opérations sans effet.

Dans cette section, un "port de sortie" désigne une interface physique telle qu'un connecteur audio de 3, 5 mm, un port HDMI ou un port USB en mode hôte avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que Bluetooth, Wi-Fi ou le réseau mobile n'est pas considérée comme incluant un "port de sortie".

7.8.2.1. Ports audio analogiques

Pour être compatibles avec les casques et autres accessoires audio utilisant la prise audio de 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un port audio de type connecteur audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils disposent d'une prise audio 3,5 mm à quatre conducteurs, elles :

[C-1-1] DOIT être compatible avec la lecture audio sur des écouteurs stéréo et des casques stéréo avec micro.
[C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec l'ordre de broches CTIA.
[C-1-3] DOIT prendre en charge la détection et le mappage des codes de touches pour les trois plages suivantes d'impédance équivalente entre les conducteurs du microphone et de la masse sur la prise audio :
- 70 ohms ou moins : KEYCODE_HEADSETHOOK
- 210 à 290 ohms : KEYCODE_VOLUME_UP
- 360 à 680 ohms : KEYCODE_VOLUME_DOWN
[C-1-4] MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack.
[C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de tension de sortie sur une impédance de haut-parleur de 32 ohms.
[C-1-6] DOIT avoir une tension de polarisation du micro comprise entre 1,8 V et 2,9 V.
[C-1-7] DOIT détecter et mapper le code clé pour la plage suivante d'impédance équivalente entre les conducteurs du microphone et de la masse sur la prise audio :
- 110 à 180 ohms : KEYCODE_VOICE_ASSIST
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les connecteurs audio avec l'ordre des broches OMTP.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent android.intent.action.HEADSET_PLUG avec la valeur supplémentaire du micro définie sur 1, elles :

[C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.2.2. Ports audio numériques

Consultez la section 2.2.1 pour connaître les exigences spécifiques aux appareils.

7.8.3. Proche des ultrasons

La bande audio proche des ultrasons se situe entre 18,5 kHz et 20 kHz.

Implémentations sur les appareils :

DOIT signaler correctement la compatibilité avec la fonctionnalité audio proche des ultrasons via l'API AudioManager.getProperty comme suit :

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT répondre aux exigences suivantes :

[C-1-1] La réponse en puissance moyenne du microphone dans la bande de fréquences de 18,5 kHz à 20 kHz DOIT être inférieure d'au moins 15 dB à la réponse à 2 kHz.
[C-1-2] Le rapport signal/bruit non pondéré du micro entre 18,5 kHz et 20 kHz pour une tonalité de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est défini sur "true" :

[C-2-1] La réponse moyenne du haut-parleur entre 18,5 kHz et 20 kHz DOIT être inférieure d'au moins 40 dB à la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations sur les appareils :

DOIT fournir un chemin de signal audio sans problème pour les flux d'entrée et de sortie sur les appareils portables, tel que défini par zéro problème mesuré lors d'un test d'une minute par chemin. Testez à l'aide de OboeTester "Automated Glitch Test" (Test de glitch automatisé).

Le test nécessite un dongle de rebouclage audio, utilisé directement dans un connecteur 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. TOUS les ports de sortie audio DOIVENT être testés.

OboeTester est actuellement compatible avec les chemins AAudio. Les combinaisons suivantes DOIVENT donc être testées pour détecter les problèmes à l'aide d'AAudio :

Mode Performances	Partage	Taux d'échantillonnage de sortie	Dans les Chans	Out Chans
LOW_LATENCY	EXCLUSIFS	NON SPÉCIFIÉ	1	2
LOW_LATENCY	EXCLUSIFS	NON SPÉCIFIÉ	2	1
LOW_LATENCY	PARTAGÉ	NON SPÉCIFIÉ	1	2
LOW_LATENCY	PARTAGÉ	NON SPÉCIFIÉ	2	1
NONE	PARTAGÉ	48000	1	2
NONE	PARTAGÉ	48000	2	1
NONE	PARTAGÉ	44100	1	2
NONE	PARTAGÉ	44100	2	1
NONE	PARTAGÉ	16000	1	2
NONE	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants concernant le rapport signal/bruit (SNR) et la distorsion harmonique totale (THD) pour une sinusoïde de 2 000 Hz.

Transducteur	THD	SNR
Haut-parleur intégré principal, mesuré à l'aide d'un microphone de référence externe	< 3,0%	>= 50 dB
Microphone intégré principal, mesuré à l'aide d'un haut-parleur de référence externe	< 3,0%	>= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés à l'aide d'un adaptateur de rebouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés à l'aide d'un adaptateur de boucle	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des outils permettant de créer des applications de réalité virtuelle (RV), y compris des expériences de RV mobile de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android est compatible avec le mode VR, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants de l'interface utilisateur du système monoculaire lorsqu'une application de VR est sélectionnée par l'utilisateur.

7.9.2. Mode Réalité virtuelle : hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, elles :

[C-1-1] DOIT comporter au moins deux cœurs physiques.
[C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
[C-1-3] DOIT être compatible avec le mode Performances soutenues.
[C-1-4] DOIT être compatible avec OpenGL ES 3.2.
[C-1-5] DOIT prendre en charge android.hardware.vulkan.level 0.
DOIT être compatible avec android.hardware.vulkan.level 1 ou version ultérieure.
[C-1-6] DOIT implémenter EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content et EGL_EXT_image_gl_colorspace, et exposer les extensions dans la liste des extensions EGL disponibles.
[C-1-8] DOIT implémenter GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures et exposer les extensions dans la liste des extensions GL disponibles.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, et d'exposer les extensions dans la liste des extensions GL disponibles.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge Vulkan 1.1.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de l'exposer dans la liste des extensions Vulkan disponibles.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan où flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et où queueCount est au moins égal à 2.
[C-1-7] Le GPU et l'écran DOIVENT être capables de synchroniser l'accès au tampon avant partagé de sorte que le rendu alterné des yeux du contenu VR à 60 fps avec deux contextes de rendu s'affiche sans artefacts de déchirement visibles.
[C-1-9] DOIT implémenter la prise en charge des indicateurs AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, comme décrit dans le NDK.
[C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants : AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'attribution des AHardwareBuffer avec plusieurs calques, ainsi que les indicateurs et les formats spécifiés dans C-1-10.
[C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 fps, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 fps-10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 fps-20 Mbit/s).
[C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 fps compressé à une moyenne de 10 Mbit/s et DEVRAIT être capable de décoder 3 840 x 2 160 à 30 fps-20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 fps-5 Mbit/s).
[C-1-13] DOIT être compatible avec l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température cutanée.
[C-1-14] DOIT disposer d'un écran intégré dont la résolution DOIT être d'au moins 1 920 x 1 080.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'écran d'au moins 2 560 x 1 440.
[C-1-15] L'affichage DOIT se mettre à jour à au moins 60 Hz en mode VR.
[C-1-17] L'écran DOIT être compatible avec un mode à faible persistance (≤ 5 millisecondes), la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
[C-1-18] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE section 7.4.3.
[C-1-19] DOIT être compatible avec le type de canal direct et le signaler correctement pour tous les types de capteurs par défaut suivants :
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] Il est FORTEMENT RECOMMANDÉ de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
[C-1-21] DOIT répondre aux exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
[C-SR-8] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors.
[C-1-22] La latence de bout en bout entre le mouvement et le photon NE DOIT PAS dépasser 28 millisecondes.
[C-SR-9] Il est FORTEMENT RECOMMANDÉ que la latence de bout en bout entre le mouvement et le photon ne dépasse pas 20 millisecondes.
[C-1-23] DOIT avoir un ratio de première image d'au moins 85 %, qui correspond au rapport entre la luminosité des pixels de la première image après une transition du noir au blanc et la luminosité des pixels blancs en régime permanent.
[C-SR-10] Il est FORTEMENT RECOMMANDÉ que le ratio de la première image soit d'au moins 90%.
PEUT fournir un cœur exclusif à l'application au premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application au premier plan.

Si le cœur exclusif est pris en charge, le cœur :

[C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUT autoriser l'exécution de certains processus du noyau si nécessaire.

7.10. Technologie tactile

Les appareils portables ou à tenir à la main peuvent inclure un actionneur haptique à usage général, disponible pour les applications à des fins telles que l'attraction de l'attention par le biais de sonneries, d'alarmes, de notifications, ainsi que pour le retour tactile général.

Si les implémentations d'appareils N'INCLUENT PAS un tel actionneur haptique à usage général, elles :

[7.10/C] MUST renvoie "false" pour Vibrator.hasVibrator().

Si les implémentations d'appareils incluent au moins un tel actionneur haptique à usage général, elles :

[C-1-1] MUST renvoie "true" pour Vibrator.hasVibrator().
NE DOIT PAS utiliser d'actionneur haptique (vibreur) à masse rotative excentrée (ERM).
DOIT implémenter toutes les constantes publiques pour le retour haptique clair dans android.view.HapticFeedbackConstants, à savoir CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START et GESTURE_END.
DOIT implémenter toutes les constantes publiques pour les retours haptiques clairs dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK), et toutes les constantes PRIMITIVE_* publiques possibles pour les retours haptiques riches dans android.os.VibrationEffect.Composition, à savoir (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Certaines de ces primitives, telles que LOW_TICK et SPIN, ne peuvent être possibles que si le vibreur peut prendre en charge des fréquences relativement basses.
DOIT suivre les conseils de mappage des constantes publiques dans android.view.HapticFeedbackConstants aux constantes android.os.VibrationEffect recommandées, avec les relations d'amplitude correspondantes.
DOIT utiliser ces mappages de constantes haptiques associées.
DOIT suivre l'évaluation de la qualité pour les API createOneShot() et createWaveform().
DOIT vérifier que le résultat de l'API publique android.os.Vibrator.hasAmplitudeControl() reflète correctement les capacités de son vibreur.
DOIT vérifier les capacités de mise à l'échelle de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

Si les implémentations d'appareil suivent le mappage des constantes haptiques, elles :

DOIT vérifier l'état de l'implémentation en exécutant les API android.os.Vibrator.areAllEffectsSupported() et android.os.Vibrator.arePrimitivesSupported().
DOIT effectuer une évaluation de la qualité pour les constantes haptiques.
DOIT vérifier et mettre à jour, si nécessaire, la configuration de secours pour les primitives non compatibles, comme décrit dans les conseils d'implémentation pour les constantes.
DOIT fournir une assistance de secours pour atténuer le risque d'échec, comme décrit ici.

7.11. Classe de performances média

La classe de performances multimédias de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Les exigences relatives à la classe de performances média sont définies pour chaque version d'Android à partir de la version R (version 30). La valeur spéciale 0 indique que l'appareil n'appartient pas à une classe de performances multimédias.

Si les implémentations d'appareil renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.
[C-1-2] DOIT être une implémentation d'appareil portable.
[C-1-3] DOIT répondre à toutes les exigences de la "classe de performances multimédias" décrites dans la section 2.2.7.

En d'autres termes, la classe de performances multimédias dans Android T n'est définie que pour les appareils portables exécutant la version T, S ou R.

Consultez la section 2.2.7 pour connaître les exigences spécifiques aux appareils.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lors du développement d'une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final si certaines exigences minimales sont respectées pour garantir une fréquence d'images et des temps de réponse cohérents pour les applications et les jeux. Les implémentations d'appareils, selon le type d'appareil, PEUVENT avoir des exigences mesurables pour la latence de l'interface utilisateur et le changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

En fournissant une base de référence commune pour des performances d'accès aux fichiers cohérentes dans le stockage privé des données d'application (partition /data), les développeurs d'applications peuvent définir une attente appropriée qui les aidera à concevoir leur logiciel. En fonction du type d'appareil, les implémentations d'appareil PEUVENT être soumises à certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes :

Performances d'écriture séquentielle : Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
Performances d'écriture aléatoire Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 Ko.
Performances de lecture séquentielle Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
Performances de lecture aléatoire Mesuré en lisant un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

Si les implémentations d'appareils incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, Doze) ou étendent les fonctionnalités pour appliquer des restrictions plus strictes que le bucket de mise en veille des applications RESTRICTED, elles :

[C-1-1] NE DOIT PAS s'écarter de l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de réveil, ni pour l'utilisation des paramètres système globaux ou de DeviceConfig des modes d'économie d'énergie Mise en veille des applications et Sommeil.
[C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation des paramètres généraux ou de DeviceConfig afin de gérer la limitation des tâches, des alarmes et du réseau pour les applications de chaque bucket en mode Veille de l'application.
[C-1-3] NE DOIT PAS s'écarter de l'implémentation AOSP pour le nombre de buckets de mise en veille des applications utilisés pour la mise en veille des applications.
[C-1-4] DOIT implémenter les buckets Mise en veille des applications et le mode Veille prolongée, comme décrit dans Gestion de l'alimentation.
[C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
[C-1-6] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil ou de toute optimisation de la batterie, et DOIT implémenter l'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS pour demander à l'utilisateur d'autoriser une application à ignorer les optimisations de la batterie.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP et que cette extension applique des restrictions plus strictes que le bucket de mise en veille des applications "Rare", consultez la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter tout ou partie des quatre états d'alimentation en veille définis par l'interface ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles :

[C-1-1] L'appareil DOIT passer dans cet état uniquement après que l'utilisateur a effectué une action explicite pour le mettre dans un état inactif (par exemple, en fermant un couvercle qui fait physiquement partie de l'appareil ou en éteignant un véhicule ou un téléviseur) et avant que l'utilisateur ne le réactive (par exemple, en ouvrant le couvercle ou en rallumant le véhicule ou le téléviseur).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles :

[C-2-1] DOIT répondre à C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran, le processeur).

À l'inverse, il DOIT quitter l'état S3 lorsque des applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

Par exemple, alors que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur en fonctionnement via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer à l'état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris des mesures explicites pour mettre l'appareil dans un état inactif. À l'inverse, lorsqu'une tâche que les applications tierces implémentent via JobScheduler est déclenchée ou que Firebase Cloud Messaging est distribué aux applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a mis l'appareil en état inactif. Il ne s'agit pas d'exemples exhaustifs. L'AOSP implémente de nombreux signaux de réveil qui déclenchent une sortie de cet état.

8.4. Comptabilisation de la consommation électrique

Une comptabilisation et un reporting plus précis de la consommation d'énergie fournissent au développeur d'applications à la fois les incitations et les outils nécessaires pour optimiser le modèle d'utilisation de l'énergie de l'application.

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un profil de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de la batterie approximative causée par les composants au fil du temps, comme indiqué sur le site du Projet Android Open Source.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de signaler toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.
DOIT être attribuée au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

8.5. Constance des performances

Les performances peuvent fluctuer considérablement pour les applications de longue durée à hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison de la limitation de la fréquence du processeur due aux limites de température. Android inclut des interfaces programmatiques qui permettent à l'application de premier plan de demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations lorsque l'appareil en est capable.

Implémentations sur les appareils :

[C-0-1] DOIT signaler avec précision la prise en charge du mode Performances soutenues via la méthode d'API PowerManager.isSustainedPerformanceModeSupported().
DOIT être compatible avec le mode Performances soutenues.

Si les implémentations d'appareils indiquent la prise en charge du mode Performances soutenues, elles :

[C-1-1] DOIT fournir à l'application de premier plan la plus élevée un niveau de performances constant pendant au moins 30 minutes, lorsque l'application le demande.
[C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent deux cœurs de processeur ou plus, elles :

DOIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan.

Si les implémentations d'appareil permettent de réserver un cœur exclusif pour l'application de premier plan, elles :

[C-2-1] DOIT signaler via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs pouvant être réservés par l'application de premier plan supérieure.
[C-2-2] NE DOIT PAS autoriser les processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application, à s'exécuter sur les cœurs exclusifs, mais PEUT autoriser certains processus de noyau à s'exécuter si nécessaire.

Si les implémentations d'appareil ne sont pas compatibles avec un cœur exclusif, elles :

[C-3-1] DOIT renvoyer une liste vide via la méthode d'API Process.getExclusiveCores().

8.6. Limites de mémoire des applications

MemoryLimiter, un nouveau composant d'ActivityManagerService, et les limites de mémoire par défaut des applications, qui sont dérivées de la mémoire physique disponible, imposeront des limites à la quantité de DRAM utilisée par processus d'application individuel. Cette restriction s'applique à toute la mémoire allouée dans le processus de l'application, ce qui garantit que les limites fonctionnent comme un comportement contractuel essentiel avec les développeurs d'applications.

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS utiliser de méthodes, de listes d'autorisation ni de règles pour contourner les limites de mémoire d'exécution définies pour les applications.

9. Compatibilité du modèle de sécurité

Implémentations sur les appareils :

[C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API dans la documentation pour les développeurs Android.
[C-0-2] DOIT permettre l'installation d'applications auto-signées sans nécessiter d'autorisations ni de certificats supplémentaires de la part de tiers/autorités.

Si les implémentations d'appareil déclarent la fonctionnalité android.hardware.security.model.compatible, elles :

[C-1-1] DOIT prendre en charge les exigences listées dans les sous-sections suivantes.

9.1. Autorisations

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le modèle d'autorisations Android et le modèle de rôles Android, tels que définis dans la documentation pour les développeurs Android. Plus précisément, ils DOIVENT appliquer chaque autorisation et chaque rôle définis comme décrit dans la documentation du SDK. Aucune autorisation ni aucun rôle ne peuvent être omis, modifiés ni ignorés.
PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne se trouvent pas dans l'espace de noms android.\*.
[C-0-2] Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED NE DOIVENT être accordées qu'aux applications préinstallées dans le ou les chemins privilégiés de l'image système (ainsi qu'aux fichiers APEX) et doivent faire partie du sous-ensemble des autorisations explicitement autorisées pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations autorisées pour chaque application à partir des fichiers du chemin d'accès etc/permissions/ et en utilisant le chemin d'accès system/priv-app comme chemin privilégié.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de n'accorder les autorisations avec un protectionLevel de PROTECTION_SIGNATURE qu'à l'un des éléments suivants :
- Applications préinstallées sur l'image système (ainsi que les fichiers APEX).
- Applications ajoutées à la liste d'autorisation avec les autorisations autorisées si elles ne sont pas incluses dans l'image système.
Remarque : L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations figurant sur la liste d'autorisation pour chaque application à partir des fichiers du chemin d'accès etc/permissions/.

Les autorisations avec un niveau de protection "dangerous" sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations sur les appareils :

[C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder ou non les autorisations d'exécution demandées, et fournir également une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
[C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications, sauf si :
- Elles sont installées au moment de l'expédition de l'appareil, ET
- Le consentement de l'utilisateur peut être obtenu avant que l'application n'utilise l'autorisation.
OU
- Les autorisations d'exécution sont accordées par la règle d'autorisation par défaut ou pour détenir un rôle de plate-forme.
[C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage distant hors appareil, équipé d'un matériel sécurisé avec une protection équivalente ou supérieure à celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations sur les appareils :

[C-0-7] DOIT respecter les propriétés de l'autorisation d'accéder à la position Android lorsqu'une application demande les données de localisation ou les données d'activité physique via l'API Android standard ou un mécanisme propriétaire. Ces données incluent, entre autres :
- Position de l'appareil (latitude et longitude, par exemple), comme décrit dans la section 9.8.8.
- Informations permettant de déterminer ou d'estimer la position de l'appareil (par exemple, SSID, BSSID, ID de cellule ou position du réseau auquel l'appareil est connecté).
- Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils :

[C-0-8] L'application DOIT obtenir le consentement de l'utilisateur pour accéder aux données de localisation ou d'activité physique.
[C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application qui dispose d'une autorisation suffisante, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les seules exceptions aux propriétés d'autorisation d'accéder à la position Android ci-dessus concernent les applications qui n'accèdent pas à la localisation pour déterminer ou identifier la position de l'utilisateur. Plus précisément :

Lorsque les applications détiennent l'autorisation RADIO_SCAN_WITHOUT_LOCATION.
Pour la configuration et la configuration des appareils, où les applications système détiennent l'autorisation NETWORK_SETTINGS ou NETWORK_SETUP_WIZARD.

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

[C-0-10] Les autorisations marquées de l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si :
- Le fichier APK d'une application se trouve dans la partition système.
- L'utilisateur attribue à une application un rôle associé aux autorisations hardRestricted.
- Le programme d'installation accorde hardRestricted à une application.
- Une application se voit accorder l'autorisation hardRestricted sur une version antérieure d'Android.
[C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT bénéficier d'un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles ne sont pas ajoutées à la liste d'autorisation, comme décrit dans le SDK, où l'accès complet et l'accès limité sont définis pour chaque autorisation softRestricted (par exemple, READ_EXTERNAL_STORAGE).
[C-0-12] NE DOIT PAS fournir de fonctions ni d'API personnalisées pour contourner les restrictions d'autorisation définies dans les API setPermissionPolicy et setPermissionGrantState.
[C-0-13] DOIT utiliser les API AppOpsManager pour enregistrer et suivre chaque accès programmatique aux données protégées par des autorisations dangereuses à partir des activités et services Android.
[C-0-14] DOIT uniquement attribuer des rôles aux applications dont les fonctionnalités répondent aux exigences du rôle.
[C-0-15] NE DOIT PAS définir de rôles qui sont des doublons ou des supersets de fonctionnalités de rôles définis par la plate-forme.

Si les appareils incluent des capteurs de données exposant des données biométriques liées à la santé, telles que la fréquence cardiaque ou la température cutanée, ces données biométriques :

[C-0-16] DOIT être protégé par les autorisations de la plate-forme à partir de android.permission-group.HEALTH, s'il existe une autorisation correspondante dans HealthPermissions.
[C-0-17] DOIT être protégé par une autorisation système personnalisée si aucune autorisation de plate-forme ne correspond au type de données souhaité. (Par exemple, ELECTROCARDIOGRAM.)

Si les appareils signalent android.software.managed_users, cela signifie :

[C-1-1] NE DOIT PAS disposer des autorisations suivantes accordées silencieusement par l'administrateur :
- Lieu (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Caméra (CAMERA)
- Microphone (RECORD_AUDIO)
- Capteur corporel (BODY_SENSORS)
- Santé (HealthPermissions)
- Activité physique (ACTIVITY_RECOGNITION)

Si les appareils signalent android.software.managed_users, cela signifie :

[C-1-1] NE DOIT PAS disposer des autorisations suivantes accordées silencieusement par l'administrateur :
- Lieu (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- Caméra (CAMERA)
- Microphone (RECORD_AUDIO)
- Capteur corporel (BODY_SENSORS)
- Activité physique (ACTIVITY_RECOGNITION)

Si les implémentations d'appareil offrent à l'utilisateur la possibilité de choisir les applications qui peuvent se superposer à d'autres applications avec une activité qui gère l'intent ACTION_MANAGE_OVERLAY_PERMISSION, elles :

[C-2-1] DOIT s'assurer que toutes les activités avec des filtres d'intent pour l'intent ACTION_MANAGE_OVERLAY_PERMISSION ont le même écran d'UI, quelle que soit l'application à l'origine de l'intent ou les informations qu'elle fournit.

Si les implémentations d'appareils signalent android.software.device_admin, elles :

[C-3-1] DOIT afficher un avis de non-responsabilité lors de la configuration d'un appareil entièrement géré (configuration du propriétaire de l'appareil) indiquant que l'administrateur informatique pourra autoriser les applications à contrôler les paramètres du téléphone, y compris le micro, l'appareil photo et la position, avec des options permettant à l'utilisateur de poursuivre ou d'interrompre la configuration, SAUF si l'administrateur a désactivé le contrôle des autorisations sur l'appareil.

Si les implémentations d'appareils préinstallent des packages contenant l'un des rôles System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, les packages :

[C-4-1] DOIT répondre à toutes les exigences décrites pour les implémentations d'appareils dans les sections 9.8.6. Données au niveau de l'OS et données ambiantes et 9.8.15. Implémentations de l'API Sandboxed.

9.2. UID et isolation des processus

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le modèle de bac à sable de l'application Android, dans lequel chaque application s'exécute en tant qu'UID de style Unix unique et dans un processus distinct.
[C-0-2] DOIT permettre l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Autrement dit :

[C-0-1] Les environnements d'exécution alternatifs DOIVENT être eux-mêmes des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.
[C-0-2] Les runtimes alternatifs NE DOIVENT PAS avoir accès aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml du runtime via le mécanisme <uses-permission>.
[C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS permettre aux applications d'utiliser des fonctionnalités protégées par Android réservées aux applications système.
[C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf par le biais des mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.
[C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ou se voir accorder l'accès aux bacs à sable correspondant à d'autres applications Android.
[C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec, ni se voir accorder ou accorder à d'autres applications les privilèges du superutilisateur (root) ou de tout autre ID utilisateur.
[C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans l'image système des implémentations d'appareil, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses dans les implémentations d'appareil.
[C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.
[C-0-9] Lorsqu'une application doit utiliser une ressource de l'appareil pour laquelle il existe une autorisation Android correspondante (comme l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.
[C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les capacités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.
Les environnements d'exécution alternatifs DOIVENT installer les applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
Les environnements d'exécution alternatifs PEUVENT fournir un bac à sable Android unique partagé par toutes les applications utilisant l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et permet l'isolation complète des utilisateurs et le clonage des profils utilisateur avec une isolation partielle (c'est-à-dire un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE).

Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur si elles utilisent un support amovible pour le stockage externe principal.

Si les implémentations d'appareils incluent la prise en charge de plusieurs utilisateurs, elles :

[C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android tel que défini dans le document de référence sur la sécurité et les autorisations dans les API.
[C-1-3] DOIT disposer de répertoires de stockage d'applications partagées distincts et isolés (également appelés /sdcard) pour chaque instance utilisateur.
[C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et s'exécutant en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
[C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations d'appareils utilisent un support amovible pour les API de stockage externe. Comme cela rendra le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel.

Si les implémentations d'appareils sont compatibles avec plusieurs utilisateurs, alors pour tous les utilisateurs, à l'exception de ceux spécifiquement créés pour exécuter deux instances de la même application, ils :

[C-2-1] DOIT disposer de répertoires de stockage d'applications partagés distincts et isolés (également appelés /sdcard) pour chaque instance utilisateur.
[C-2-2] DOIT s'assurer que les applications appartenant à un utilisateur donné et s'exécutant en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.

Les implémentations d'appareils PEUVENT créer un profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE par rapport à l'utilisateur principal (et uniquement par rapport à l'utilisateur principal) afin d'exécuter deux instances de la même application. Ces deux instances partagent un espace de stockage partiellement isolé, sont présentées à l'utilisateur final dans le lanceur d'applications en même temps et apparaissent dans la même vue "Récents". Par exemple, cela peut être utilisé pour permettre à l'utilisateur d'installer deux instances distinctes d'une même application sur un appareil à double carte SIM.

Si les implémentations d'appareils créent le profil utilisateur supplémentaire mentionné ci-dessus, elles :

[C-3-1] DOIT uniquement fournir un accès au stockage ou aux données qui sont déjà accessibles au profil utilisateur parent ou qui appartiennent directement à ce profil utilisateur supplémentaire.
[C-3-2] NE DOIT PAS avoir ce profil comme profil professionnel.
[C-3-3] Les répertoires de données des applications privées DOIVENT être isolés du compte utilisateur parent.
[C-3-4] NE DOIT PAS autoriser la création d'un profil utilisateur supplémentaire si un propriétaire de l'appareil est provisionné (voir la section 3.9.1) ni autoriser le provisionnement d'un propriétaire de l'appareil sans supprimer d'abord le profil utilisateur supplémentaire.

Si les implémentations d'appareils créent le profil utilisateur supplémentaire mentionné ci-dessus, elles :

[C-4-1] DOIT permettre aux applications de l'utilisateur principal sur l'appareil de gérer les intents ci-dessous provenant du profil supplémentaire :
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] DOIT hériter de toutes les restrictions utilisateur des règles relatives aux appareils et des restrictions(list below) non utilisateur sélectionnés appliqués à l'utilisateur principal de l'appareil pour ce profil utilisateur supplémentaire.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] NE DOIT PAS exécuter de synchronisation des contacts pour les applications s'exécutant dans ce profil utilisateur supplémentaire.
[C-4-5] DOIT autoriser uniquement les applications du profil supplémentaire qui disposent d'une activité de lanceur à accéder aux contacts déjà accessibles au profil utilisateur parent.

Si les implémentations d'appareils créent le profil utilisateur supplémentaire mentionné ci-dessus, qu'elles incluent au moins une caméra et que l'application de caméra préinstallée gère les intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE ou MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, elles :

[C-5-1] MUST allow applications of the primary user to handle these intents originating from that additional user profile.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout SMS premium sortant. Les messages SMS premium sont des messages texte envoyés à un service enregistré auprès d'un opérateur et qui peuvent être facturés à l'utilisateur.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.telephony, elles :

[C-1-1] DOIT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT assurer la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) Security-Enhanced Linux (SELinux), le bac à sable seccomp et d'autres fonctionnalités de sécurité du kernel Linux. Implémentations sur les appareils :

[C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité sont implémentées sous le framework Android.
[C-0-2] NE DOIT PAS comporter d'interface utilisateur visible lorsqu'une faille de sécurité est détectée et bloquée par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT comporter une interface utilisateur visible lorsqu'une faille de sécurité non bloquée se produit et entraîne une exploitation réussie.
[C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android configurable par l'utilisateur ou le développeur d'applications.
[C-0-4] NE DOIT PAS autoriser une application qui peut affecter une autre application via une API (telle qu'une API d'administration des appareils) à configurer une règle qui rompt la compatibilité.
[C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin de pouvoir accorder un accès plus limité à chaque processus, comme décrit sur le site du Projet Android Open Source.
[C-0-6] DOIT implémenter un mécanisme de sandboxing d'application du noyau qui permet de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Android Open Source en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de groupe de threads (TSYNC), comme décrit dans la section "Configuration du noyau" de source.android.com.

L'intégrité et l'autoprotection du noyau font partie intégrante de la sécurité d'Android. Implémentations sur les appareils :

[C-0-7] DOIT implémenter des mécanismes de protection contre le dépassement de mémoire tampon de pile du noyau. CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG sont des exemples de tels mécanismes.
[C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau, où le code exécutable est en lecture seule, les données en lecture seule sont non exécutables et non accessibles en écriture, et les données accessibles en écriture sont non exécutables (par exemple, rodata et CONFIG_STRICT_KERNEL_RWX sont activés).
[C-0-9] DOIT implémenter la vérification des limites de taille des objets statiques et dynamiques des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils fournis à l'origine avec le niveau d'API 28 ou version ultérieure.
[C-0-10] NE DOIT PAS exécuter de mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, PXN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
[C-0-11] NE DOIT PAS lire ni écrire dans la mémoire de l'espace utilisateur du kernel en dehors des API d'accès usercopy normales (par exemple, PAN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
[C-0-12] DOIT implémenter l'isolation des tables de pages du noyau si le matériel est vulnérable à CVE-2017-5754 sur tous les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DOIT implémenter le renforcement de la prédiction de branchement si le matériel est vulnérable à CVE-2017-5715 sur tous les appareils initialement fournis avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation en lecture seule après l'initialisation (par exemple, __ro_after_init).
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de randomiser la disposition du code et de la mémoire du noyau, et d'éviter les expositions qui compromettraient la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).
[C-SR-3] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau pour fournir une protection supplémentaire contre les attaques par réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI), la pile d'appels fantôme (SCS) ni la désinfection des dépassements d'entiers (IntSan) sur les composants pour lesquels ces fonctionnalités sont activées.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tous les composants de l'espace utilisateur sensibles à la sécurité, comme expliqué dans CFI et IntSan.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour éviter l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les variables locales.
[C-SR-7] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas dans le noyau pour éviter l'utilisation d'allocations de tas non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Il est également DÉCONSEILLÉ de supposer la valeur utilisée par le noyau pour initialiser ces allocations.

Si les implémentations d'appareils utilisent un noyau Linux compatible avec SELinux, elles :

[C-1-1] DOIT implémenter SELinux.
[C-1-2] DOIT définir SELinux sur le mode d'application forcée global.
[C-1-3] DOIT configurer tous les domaines en mode "Appliquer". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil ou à un fournisseur.

[C-1-4] NE DOIT PAS :
- Modifier, omettre ou remplacer les règles "neverallow" présentes dans le dossier system/sepolicy fourni dans le projet Android Open Source (AOSP) en amont
- Ajout incorrect de libellés SELinux AOSP à des composants non AOSP
La règle DOIT être compilée avec toutes les règles "neverallow" présentes, à la fois pour les domaines SELinux AOSP et pour les domaines spécifiques à l'appareil/au fournisseur.

[C-1-5] DOIT exécuter les applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application avec des restrictions SELinux par application sur le répertoire de données privées de chaque application.
DOIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et ne l'étendre que pour sa propre configuration spécifique à l'appareil.

Si les implémentations d'appareils utilisent un noyau autre que Linux ou Linux sans SELinux, elles :

[C-2-1] DOIT utiliser un système de contrôle des accès obligatoire équivalent à SELinux.

Si les implémentations d'appareils utilisent des périphériques d'E/S compatibles avec le DMA, elles :

[C-SR-9] Il est FORTEMENT RECOMMANDÉ d'isoler chaque périphérique d'E/S compatible avec DMA à l'aide d'une IOMMU (par exemple, ARM SMMU).

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils. De plus, Android s'efforce de réduire les principales classes de bugs courants qui contribuent à une qualité et une sécurité médiocres.

Pour réduire les bugs de mémoire, les implémentations d'appareils doivent :

[C-SR-10] Il est FORTEMENT RECOMMANDÉ de les tester à l'aide d'outils de détection des erreurs de mémoire de l'espace utilisateur tels que MTE pour les appareils ARMv9, HWASan pour les appareils ARMv8+ ou ASan pour les autres types d'appareils.
[C-SR-11] Il est FORTEMENT RECOMMANDÉ de les tester à l'aide d'outils de détection des erreurs de mémoire du noyau tels que KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS pour les appareils ARMv9, CONFIG_KASAN_SW_TAGS pour les appareils ARMv8 ou CONFIG_KASAN_GENERIC pour les autres types d'appareils).
[C-SR-12] Il est FORTEMENT RECOMMANDÉ d'utiliser des outils de détection des erreurs de mémoire en production, comme MTE, GWP-ASan et KFENCE.

Si les implémentations d'appareils utilisent un TEE basé sur Arm TrustZone, elles :

[C-SR-13] Il est FORTEMENT RECOMMANDÉ d'utiliser un protocole standard pour le partage de mémoire entre Android et le TEE, comme Arm Firmware Framework pour Armv8-A (FF-A).
[C-SR-14] Il est FORTEMENT RECOMMANDÉ de limiter l'accès des applications de confiance à la mémoire qui leur a été explicitement partagée via le protocole ci-dessus. Si l'appareil est compatible avec le niveau d'exception Arm S-EL2, cela doit être appliqué par le gestionnaire de partition sécurisée. Sinon, cela devrait être appliqué par l'OS TEE.

Une technologie de sécurité de la mémoire est une technologie qui atténue au moins les classes de bugs suivantes avec une probabilité élevée (> 90%) dans les applications qui utilisent l'option de fichier manifeste android:memtagMode :

dépassement de tampon de tas de mémoire
utilisation après libération de la mémoire
double libération
wild free (libération d'un pointeur non malloc)

Implémentations sur les appareils :

[C-SR-15] Il est FORTEMENT RECOMMANDÉ de définir ro.arm64.memtag.bootctl_supported.

Si les implémentations d'appareil définissent la propriété système ro.arm64.memtag.bootctl_supported sur "true", elles :

[C-3-1] DOIT autoriser la propriété système arm64.memtag.bootctl à accepter une liste de valeurs séparées par des virgules, avec l'effet souhaité appliqué au prochain redémarrage :
- memtag : une technologie de sécurité de la mémoire telle que définie ci-dessus est activée
- memtag-once : une technologie de sécurité mémoire telle que définie ci-dessus est activée de manière transitoire et est automatiquement désactivée au prochain redémarrage.
- memtag-off : une technologie de sécurité mémoire telle que définie ci-dessus est désactivée.
[C-3-2] DOIT permettre à l'utilisateur du shell de définir arm64.memtag.bootctl.
[C-3-3] DOIT autoriser tout processus à lire arm64.memtag.bootctl.
[C-3-4] DOIT définir arm64.memtag.bootctl sur l'état actuellement demandé au démarrage. Il DOIT également mettre à jour la propriété si l'implémentation de l'appareil permet de modifier l'état sans changer la propriété système.
[C-SR-16] Il est FORTEMENT RECOMMANDÉ d'afficher un paramètre développeur qui définit memtag-once et redémarre l'appareil. Avec un bootloader compatible, le projet Android Open Source répond aux exigences ci-dessus grâce au protocole de bootloader MTE.

Si un appareil déclare android.hardware.telephony, prend en charge la fonctionnalité radio CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK et inclut un modem cellulaire compatible avec les connexions 2G, l'implémentation de l'appareil :

[C-SR-17] Il est FORTEMENT RECOMMANDÉ de permettre aux utilisateurs de désactiver et d'activer la 2G.
[C-SR-18] Il est FORTEMENT RECOMMANDÉ de ne pas remplacer la possibilité pour l'utilisateur de désactiver et d'activer la 2G via une autre entité d'appareil, sauf par un administrateur d'appareil à l'aide de UserManager.DISALLOW_CELLULAR_2G.
[C-SR-19] Il est FORTEMENT RECOMMANDÉ d'appeler TelephonyManager.setAllowedNetworkTypesForReason avec le motif ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G pour répondre à cette exigence.
[C-SR-20] Il est FORTEMENT RECOMMANDÉ de déterminer la compatibilité du modem cellulaire avec la 2G en appelant le TelephonyManager.getSupportedRadioAccessFamily. Pour en savoir plus, consultez Désactiver la 2G.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et le gère à l'aide de UsageStatsManager.

Implémentations sur les appareils :

[C-0-1] DOIT conserver un historique des utilisateurs pendant une période de conservation raisonnable.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle qu'elle est configurée par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via les API système StatsManager et IncidentManager.

Implémentations sur les appareils :

[C-0-2] DOIT uniquement inclure les champs marqués avec DEST_AUTOMATIC dans le signalement d'incident créé par la classe IncidentManager de l'API System.
[C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour enregistrer d'autres événements que ceux décrits dans la documentation du SDK StatsLog. Si des événements système supplémentaires sont enregistrés, ils PEUVENT utiliser un identifiant d'atome différent dans la plage comprise entre 100 000 et 200 000.

9.8.2. Enregistrement

Implémentations sur les appareils :

[C-0-1] Les composants logiciels préchargés ou distribués prêts à l'emploi NE DOIVENT PAS envoyer les informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran, le rapport de bug) hors de l'appareil sans le consentement de l'utilisateur ni des notifications claires et continues.
[C-0-2] DOIT afficher un avertissement à l'utilisateur et obtenir le consentement utilisateur explicite pour autoriser la capture de toute information sensible affichée sur son écran chaque fois qu'une session de capture d'écran ou d'enregistrement d'écran est activée via MediaProjection.createVirtualDisplay() ou des API propriétaires.
[C-0-3] Une notification d'activité en cours DOIT être affichée à l'utilisateur lorsque la diffusion ou l'enregistrement d'écran sont activés. AOSP répond à cette exigence en affichant une icône de notification d'activité en cours dans la barre d'état.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher un avertissement à l'utilisateur qui est exactement le même message que celui implémenté dans AOSP, mais qui PEUT être modifié à condition que le message avertisse clairement l'utilisateur que toute information sensible sur son écran est capturée.
[C-0-4] Exigence supprimée dans Android 16.

Implémentations sur les appareils :

[C-0-7] NE DOIT PAS enregistrer, projeter ni caster d'informations sensibles telles que :
- Contenu sensible des notifications listé dans la section 3.8.3.4, "Protection des notifications sensibles"
- Fenêtres d'activité d'application contenant des mots de passe à usage unique
- Contenu sensible tel que le nom d'utilisateur, le mot de passe et les informations de carte de crédit

Si les implémentations d'appareils incluent des fonctionnalités dans le système qui capturent le contenu affiché à l'écran et/ou enregistrent le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService, ou d'autres moyens propriétaires décrits dans la section 9.8.6, Données au niveau de l'OS et ambiantes, elles :

[C-1-1] Une notification d'activité en cours doit être affichée à l'utilisateur chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement des données.

Si les implémentations d'appareils incluent un composant activé prêt à l'emploi, capable d'enregistrer l'audio ambiant et/ou l'audio lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, elles :

[C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil l'audio brut enregistré ou tout format pouvant être reconverti en audio d'origine ou en une copie presque identique, sauf avec le consentement utilisateur explicite.

Un "indicateur de micro" désigne une vue à l'écran, constamment visible par l'utilisateur et qui ne peut pas être masquée, que les utilisateurs comprennent comme un micro en cours d'utilisation(grâce à un texte, une couleur, une icône ou une combinaison unique).

Un "indicateur d'accès à l'appareil photo" désigne une vue à l'écran, constamment visible par l'utilisateur et qui ne peut pas être masquée, qui indique aux utilisateurs qu'une caméra est en cours d'utilisation (par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Après la première seconde d'affichage, un indicateur peut changer visuellement, par exemple en devenant plus petit. Il n'est pas nécessaire qu'il s'affiche tel qu'il a été présenté et compris à l'origine.

L'indicateur de micro peut être fusionné avec un indicateur de caméra activement affiché, à condition que du texte, des icônes ou des couleurs indiquent à l'utilisateur que l'utilisation du micro a commencé.

L'indicateur d'accès à l'appareil photo peut être fusionné avec un indicateur de micro actif, à condition que du texte, des icônes ou des couleurs indiquent à l'utilisateur que l'utilisation de l'appareil photo a commencé.

Si les implémentations d'appareil déclarent android.hardware.microphone, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur de micro lorsqu'une application accède aux données audio du micro, mais pas lorsque le micro n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou par les applications détenant les rôles mentionnés dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher la liste des applications récentes et actives utilisant le micro, telle qu'elle est renvoyée par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de micro pour les applications système qui ont des interfaces utilisateur visibles ou une interaction directe avec l'utilisateur.

Si les implémentations d'appareil déclarent android.hardware.camera.any, elles :

[C-SR-4] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur d'accès à l'appareil photo lorsqu'une application accède à des données de caméra en direct, mais pas lorsque la caméra n'est accessible que par des applications détenant les rôles mentionnés dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher les applications récentes et actives utilisant la caméra, telles que renvoyées par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution associés.
[C-SR-6] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur d'accès à l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction de l'utilisateur directe.

9.8.3. Connectivité

Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, elles :

[C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations sur les appareils :

[C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin d'autorité de certification (CA) approuvé par le système que ceux fournis dans le projet Android Open Source en amont.
[C-0-2] DOIT être fourni avec un magasin d'autorité de certification racine utilisateur vide.
[C-0-3] DOIT afficher un avertissement à l'utilisateur indiquant que le trafic réseau peut être surveillé lorsqu'une CA racine utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations de l'appareil :

[C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant l'un des éléments suivants :
- Ce trafic réseau peut être surveillé.
- Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, en préchargeant un service VPN avec l'autorisation android.permission.CONTROL_VPN accordée), elles :

[C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si ce VPN est activé par l'outil de contrôle des règles relatives aux appareils via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas, l'utilisateur n'a pas besoin de fournir un consentement distinct, mais DOIT uniquement être averti.

Si les implémentations d'appareils implémentent une affordance utilisateur pour activer la fonction "VPN permanent" d'une application VPN tierce, elles :

[C-3-1] DOIT désactiver cette fonctionnalité pour les applications qui ne prennent pas en charge le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.8.5. Identifiants des appareils

Implémentations sur les appareils :

[C-0-1] DOIT empêcher l'accès au numéro de série de l'appareil et, le cas échéant, au code IMEI/MEID, au numéro de série de la carte SIM et à l'identité internationale de l'abonné mobile (IMSI) depuis une application, sauf si elle répond à l'une des exigences suivantes :
- est une application opérateur signée et validée par les fabricants d'appareils.
- a reçu l'autorisation READ_PRIVILEGED_PHONE_STATE.
- dispose de privilèges d'opérateur tels que définis dans UICC Carrier Privileges.
- est le propriétaire de l'appareil ou du profil et dispose de l'autorisation READ_PHONE_STATE.
- (Pour le numéro de série de la carte SIM/ICCID uniquement) est soumis aux exigences de la réglementation locale selon lesquelles l'application doit détecter les changements d'identité de l'abonné.

9.8.6. Protecteur des données au niveau de l'OS et des données ambiantes

Android, via les API système, fournit un mécanisme permettant aux implémentations d'appareils de capturer les données sensibles suivantes :

Texte et éléments graphiques affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure, les activités de capture du tampon d'écran et l'enregistrement du contenu de l'écran d'un appareil.

Données multimédias, telles que les données audio ou vidéo enregistrées ou lues par l'appareil.
Événements d'entrée (par exemple, clavier, souris, geste, voix, vidéo et accessibilité).
Tout écran ou autre donnée envoyé via AugmentedAutofillService au système.
Tout écran ou autre donnée accessible via les API Content Capture.
Toutes les données d'application transmises au système via l'API AppSearchManager et accessibles via AppSearchGlobalManager.query.
Tout texte ou autre donnée envoyée via TextClassifier API au TextClassifier du système, c'est-à-dire au service système pour comprendre la signification du texte, ainsi que pour générer les prochaines actions prévues en fonction du texte.
Données indexées par l'implémentation AppSearch de la plate-forme, y compris, mais sans s'y limiter, le texte, les graphiques, les données multimédias ou d'autres données similaires.
Données audio obtenues à la suite de l'utilisation de SpeechRecognizer#onDeviceSpeechRecognizer() par l'implémentation de l'outil de reconnaissance vocale.
Données audio obtenues en arrière-plan (en continu) via AudioRecord, SoundTrigger ou d'autres API audio, et ne donnant pas lieu à un indicateur visible par l'utilisateur
Données de l'appareil photo obtenues en arrière-plan (en continu) via CameraManager ou d'autres API de l'appareil photo, et n'entraînant pas d'indicateur visible par l'utilisateur

Toutes les données capturées par DynamicInstrumentationEventService

Si les implémentations d'appareils capturent ou partagent l'une des données sensibles ci-dessus, elles : sans intention utilisateur claire et distincte ni indicateur de confidentialité visible par l'utilisateur, les données DOIVENT être traitées dans un environnement d'exécution protégé. Cet environnement :

[C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées dans l'appareil ou en transit. Ce chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android ou de l'un des algorithmes de chiffrement listés comme version d'API 26 ou ultérieure, comme décrit dans Cipher SDK.
[C-1-2] NE DOIT PAS sauvegarder les données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ou de toute autre méthode de sauvegarde des données sensibles, comme décrit ci-dessus.

[C-1-3] NE DOIT PAS envoyer ces données hors de l'appareil, sauf dans l'une des conditions suivantes :
- Lorsque l'utilisateur l'initie explicitement^* pour le calcul spécifique chaque fois que les données sont partagées.
- Lorsque vous utilisez un mécanisme préservant la confidentialité, comme les technologies de confidentialité différentielle telles que RAPPOR ou les calculs fédérés confidentiels.
- Lorsque les données sont traitées dans un environnement d'exécution protégé qui les protège du fournisseur de services et de l'infrastructure, par exemple sans accès administrateur, avec une VM confidentielle, une attestation à distance, sans sortie de données privées, avec la journalisation désactivée, l'obscurcissement d'adresse IP et le chiffrement.
  - Toute implémentation utilisant cette méthode doit permettre aux utilisateurs de désactiver cette fonctionnalité.

[C-1-3] PEUT traiter les données dans un environnement cloud de base informatique de confiance qui les protège du fournisseur de services et de l'infrastructure (par exemple, pas d'accès administrateur, VM confidentielle, attestation à distance, pas de sortie de données privées, journalisation désactivée, masquage d'adresse IP et chiffrement). Toute implémentation utilisant cette méthode :
- DOIT fournir aux utilisateurs un moyen de désactiver la fonctionnalité.
- Vous DEVEZ fournir aux utilisateurs une méthode permettant de générer des journaux accessibles et complets détaillant l'entrée et la sortie des données de l'environnement.

[C-1-4] NE DOIT PAS associer ces données à une identité utilisateur (telle que Account) sur l'appareil, sauf avec le consentement utilisateur explicite chaque fois que les données sont associées.

[C-1-4] PEUT afficher ces données sur les surfaces d'UI appartenant au système.

[C-1-5] NE DOIT PAS partager ni associer ces données à une identité utilisateur (telle que Account), sauf avec le consentement explicite de l'utilisateur à chaque fois qu'elles sont partagées à chaque fois que les données sont associées, sinon l'association ne sera pas transmise aux autres composants de l'OS qui ne respectent pas les exigences décrites dans la présente section (9.8.6 Données au niveau de l'OS et ambiantes), à chaque fois qu'elles sont partagées. sauf si cette fonctionnalité est intégrée en tant qu'API du SDK Android (AmbientContext, HotwordDetectionService).
[C-1-6] DOIT fournir à l'utilisateur un moyen d'effacer les données collectées par l'implémentation ou par les moyens propriétaires lorsqu'elles sont stockées sous quelque forme que ce soit sur l'appareil ou dans l'environnement cloud de la base informatique sécurisée. Si l'utilisateur choisit d'effacer les données, toutes les données historiques collectées DOIVENT être supprimées.

[C-1-7] DOIT fournir une option permettant à l'utilisateur de désactiver l'affichage des données collectées via AppSearch ou par des moyens propriétaires sur la plate-forme Android (par exemple, le lanceur d'applications).

[C-1-8] DOIT fournir une méthode permettant de générer des journaux accessibles et complets détaillant l'entrée et la sortie des données de l'environnement.
[C-1-9] NE DOIT PAS avoir d'accès direct à Internet.
[C-1-10] PEUT afficher l'UI à distance, à condition qu'aucune donnée ne soit visible pour l'APK hôte affichant l'UI.
[C-1-11] DOIT séparer les services des autres composants du système (par exemple, ne pas lier le service ni partager les ID de processus avec des implémentations qui ne se trouvent pas dans l'environnement d'exécution protégé).
[C-1-12] NE DOIT autoriser la sortie des données sensibles que lorsque :
- Être explicitement initié par l'intention utilisateur* pour le calcul spécifique à chaque fois que les données sont partagées ; OU
- Utiliser un mécanisme protégeant la confidentialité (par exemple, des technologies de confidentialité différentielle telles que RAPPOR / les calculs fédérés confidentiels).
[C-1-13] DOIT uniquement autoriser l'exfiltration de données sensibles par le biais des éléments suivants :
- Un service système qui figure sur la liste d'autorisation du service système PCCSandbox ET qui respecte lui-même les exigences relatives à un environnement d'exécution protégé (9.8.6)
- Un fichier APK de passerelle Private Compute Core (PCC) désigné (défini dans la section 9.8.15).
[C-1-14] NE DOIT PAS effectuer de sauvegardes cloud des données déduites de données sensibles, sauf si elles sont chiffrées de bout en bout (par exemple, à l'aide du service de sauvegarde Android).

[C-SR-1] Il est FORTEMENT DÉCONSEILLÉ de demander l'autorisation INTERNET.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de n'accéder à Internet que par le biais d'API structurées reposant sur des implémentations Open Source accessibles au public.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de les implémenter avec l'API SDK Android ou un dépôt Open Source similaire appartenant à l'OEM, et / ou de les effectuer dans une implémentation en bac à sable (voir 9.8.15 Implémentations d'API en bac à sable).

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService ou tout service propriétaire qui capture les données comme décrit ci-dessus, elles :

[C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer les services par une application ou un service installable par l'utilisateur et NE DOIT autoriser que les services préinstallés à capturer ces données.
[C-2-2] NE DOIT PAS autoriser d'autres applications que le mécanisme de services préinstallés à capturer ces données.
[C-2-3] DOIT fournir une affordance utilisateur claire et accessible pour désactiver les services.
[C-2-4] NE DOIT PAS omettre la possibilité pour l'utilisateur de gérer les autorisations Android détenues par les services et doit suivre le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de séparer les services des autres composants du système (par exemple, en ne liant pas le service ni en partageant les ID de processus), à l'exception des éléments suivants :
- Téléphonie, Contacts, UI du système et Multimédia

9.8.7. Accès au presse-papiers

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS renvoyer de données tronquées du presse-papiers (par exemple, via l'API ClipboardManager), sauf si l'application tierce est l'IME par défaut ou l'application actuellement sélectionnée.
[C-0-2] DOIT effacer les données du presse-papiers au plus tard 60 minutes après leur dernière insertion ou lecture.

9.8.8. Emplacement

L'emplacement inclut des informations de la classe Android Location( comme la latitude, la longitude et l'altitude), ainsi que des identifiants pouvant être convertis en emplacement. La précision de la localisation peut aller du DGPS (Differential Global Positioning System) à la localisation au niveau du pays (comme le code pays, c'est-à-dire le MCC, Mobile Country Code).

Vous trouverez ci-dessous une liste des types de lieux qui dérivent directement de la position d'un utilisateur ou qui peuvent être convertis en position d'un utilisateur. Cette liste n'est pas exhaustive, mais elle doit être utilisée comme exemple de ce à partir de quoi la position peut être dérivée directement ou indirectement :

GPS/GNSS/DGPS/PPP
- Solution de positionnement mondial ou système mondial de navigation par satellite ou solution de positionnement différentiel mondial
- Cela inclut également les mesures GNSS brutes et l'état du GNSS.
  - La localisation précise peut être déduite des mesures GNSS brutes.
Technologies sans fil avec des identifiants uniques, telles que :
- Points d'accès Wi-Fi (adresse MAC, BSSID, nom ou SSID)
- Bluetooth/BLE (adresse MAC, BSSID, nom ou SSID)
- UWB (MAC, BSSID, nom ou SSID)
- ID de la tour de téléphonie mobile (3G, 4G, 5G, etc., y compris toutes les futures technologies de modem cellulaire disposant d'identifiants uniques)

Pour obtenir un point de référence principal, consultez les API Android qui nécessitent les autorisations ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS activer/désactiver le paramètre de localisation de l'appareil ni les paramètres d'analyse Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ou sans que l'utilisateur en soit à l'origine.
[C-0-2] DOIT fournir à l'utilisateur un moyen d'accéder aux informations liées à la localisation, y compris les demandes de localisation récentes, les autorisations au niveau de l'application et l'utilisation de la recherche Bluetooth/Wi-Fi pour déterminer la position.
[C-0-3] DOIT s'assurer que l'application utilisant l'API Emergency Location Bypass LocationRequest.setLocationSettingsIgnored() est une session d'urgence initiée par l'utilisateur (par exemple, appel ou message au 112). Toutefois, pour Automotive, un véhicule PEUT lancer une session d'urgence sans interaction active de l'utilisateur en cas de détection d'un accident (par exemple, pour répondre aux exigences eCall).
[C-0-4] DOIT préserver la capacité des API de contournement de la localisation d'urgence à contourner les paramètres de localisation de l'appareil sans les modifier.
[C-0-5] DOIT planifier une notification qui rappelle à l'utilisateur qu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation ACCESS_BACKGROUND_LOCATION.

Lorsqu'une application de premier plan non système accède à la position exacte d'un appareil, celui-ci :

[C-SR-1] FORTEMENT RECOMMANDÉ d'afficher un indicateur visible par l'utilisateur

9.8.9. Applications installées

Par défaut, les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas voir les détails des autres applications installées (consultez la section Visibilité des packages dans la documentation du SDK Android).

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou supérieur des informations sur une autre application installée, sauf si l'application est déjà en mesure de voir des informations sur l'autre application installée via les API gérées. Cela inclut, sans s'y limiter, les détails exposés par les API personnalisées ajoutées par l'intégrateur de l'appareil ou accessibles via le système de fichiers.
[C-0-2] NE DOIT PAS accorder à une application un accès en lecture ou en écriture aux fichiers situés dans le répertoire dédié et spécifique à une autre application dans l'espace de stockage externe. Les seules exceptions sont les suivantes :
- Autorité du fournisseur de stockage externe (par exemple, les applications comme DocumentsUI).
- Télécharger le fournisseur qui utilise l'autorité du fournisseur "downloads" pour télécharger des fichiers dans le stockage de l'application.
- Applications de protocole de transfert multimédia (MTP) signées par la plate-forme qui utilisent l'autorisation privilégiée ACCESS_MTP pour permettre le transfert de fichiers vers un autre appareil.
- Les applications qui installent d'autres applications et qui disposent de l'autorisation INSTALL_PACKAGES ne peuvent accéder qu'aux répertoires "obb" à des fins de gestion des fichiers d'extension APK.

9.8.10. Rapport de bug de connectivité

Si les implémentations d'appareil déclarent l'indicateur de fonctionnalité android.hardware.telephony, elles :

[C-1-1] DOIT permettre de générer des rapports de bug de connectivité via BUGREPORT_MODE_TELEPHONY avec BugreportManager.
[C-1-2] DOIT obtenir le consentement utilisateur chaque fois que BUGREPORT_MODE_TELEPHONY est utilisé pour générer un rapport et NE DOIT PAS inviter l'utilisateur à consentir à toutes les futures demandes de l'application.
[C-1-3] NE DOIT PAS renvoyer le rapport généré à l'application qui en a fait la demande sans le consentement explicite de l'utilisateur.
[C-1-4] Les rapports générés à l'aide de BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes :
- TelephonyDebugService : décharge
- TelephonyRegistry : décharge
- WifiService : décharge
- ConnectivityService : décharge
- Dump de l'instance CarrierService du package appelant (si elle est liée)
- Tampon du journal radio
- SubscriptionManagerService : décharge
[C-1-5] NE DOIT PAS inclure les éléments suivants dans les rapports générés :
- Tout type d'informations qui ne sont pas directement liées au débogage de la connectivité.
- Tout type de journaux de trafic d'applications installées par l'utilisateur ou de profils détaillés d'applications/packages installés par l'utilisateur (les UID sont acceptés, mais pas les noms de package).
PEUT inclure des informations supplémentaires qui ne sont associées à aucune identité utilisateur. (par exemple, les journaux des fournisseurs).

Si les implémentations d'appareils incluent des informations supplémentaires (par exemple, des journaux de fournisseurs) dans les rapports de bug et que ces informations ont un impact sur la confidentialité, la sécurité, la batterie, le stockage ou la mémoire, elles :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ que le paramètre développeur soit désactivé par défaut. L'implémentation de référence AOSP répond à cette exigence en fournissant l'option Enable verbose vendor logging dans les paramètres du développeur pour inclure des journaux de fournisseurs spécifiques à l'appareil dans les rapports de bug.

9.8.11. Partage de blobs de données

Android, via BlobStoreManager, permet aux applications de fournir des blobs de données au système pour qu'ils soient partagés avec un ensemble d'applications sélectionnées.

Si les implémentations d'appareils prennent en charge les blobs de données partagés, comme décrit dans la documentation du SDK, elles :

[C-1-1] NE DOIT PAS partager les blocs de données appartenant aux applications au-delà de ce qu'elles ont prévu d'autoriser (c'est-à-dire la portée de l'accès par défaut et les autres modes d'accès qui peuvent être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess() NE DOIVENT PAS être modifiés). L'implémentation de référence AOSP répond à ces exigences.
[C-1-2] NE DOIT PAS envoyer hors de l'appareil ni partager avec d'autres applications les hachages sécurisés des blocs de données (qui sont utilisés pour contrôler l'accès).

9.8.12. Reconnaissance musicale

Android, via l'API système MusicRecognitionManager, fournit un mécanisme permettant aux implémentations d'appareils de demander la reconnaissance musicale à partir d'un enregistrement audio et de déléguer la reconnaissance musicale à une application privilégiée implémentant l'API MusicRecognitionService.

Si les implémentations d'appareils incluent un service qui implémente l'API système MusicRecognitionManager ou tout service propriétaire qui diffuse des données audio comme décrit ci-dessus, elles :

[C-1-1] DOIT s'assurer que l'appelant de MusicRecognitionManager dispose de l'autorisation MANAGE_MUSIC_RECOGNITION
[C-1-2] DOIT s'assurer qu'une seule application de reconnaissance musicale préinstallée implémente MusicRecognitionService.
[C-1-3] NE DOIT PAS autoriser les utilisateurs à remplacer MusicRecognitionManagerService ou MusicRecognitionService par une application ou un service installable par l'utilisateur.
[C-1-4] DOIT s'assurer que lorsque MusicRecognitionManagerService accède à l'enregistrement audio et le transmet à l'application implémentant MusicRecognitionService, l'accès audio est suivi via les appels de AppOpsManager.noteOp / startOp.

Si les implémentations d'appareils de MusicRecognitionManagerService ou MusicRecognitionService stockent des données audio capturées, elles :

[C-2-1] NE DOIT PAS stocker de données audio brutes ni d'empreintes audio sur le disque, ni en mémoire pendant plus de 14 jours.
[C-2-2] NE DOIT PAS partager ces données en dehors de MusicRecognitionService, sauf avec le consentement utilisateur explicite à chaque fois qu'elles sont partagées.

9.8.13. SensorPrivacyManager

Si les implémentations d'appareils offrent à l'utilisateur une possibilité logicielle de désactiver l'entrée de la caméra et/ou du micro pour l'implémentation de l'appareil, elles :

[C-1-1] MUST accurately return 'true' for the relevant supportsSensorToggle() API method.
[C-1-2] DOIT, lorsqu'une application tente d'accéder à un micro ou à une caméra bloqués, présenter à l'utilisateur une affordance non dismissable qui indique clairement que le capteur est bloqué et nécessite un choix pour continuer à bloquer ou débloquer, conformément à l'implémentation AOSP qui répond à cette exigence.
[C-1-3] DOIT uniquement transmettre des données de caméra et audio vides (ou factices) aux applications, et ne pas signaler de code d'erreur si l'utilisateur n'a pas activé la caméra ni le micro via l'affordance utilisateur présentée dans [C-1-2] ci-dessus.

9.8.14. N/A

9.8.15. Implémentations de Private Compute Core et de l'application Gateway

Android fournit un mécanisme permettant de traiter les données sécurisées au niveau de l'OS et les données ambiantes grâce à un ensemble d'API de délégation. Ce traitement peut être délégué à un fichier APK préinstallé avec un accès privilégié et des capacités de communication réduites, appelé "implémentation d'API dans un bac à sable".

Il est FORTEMENT RECOMMANDÉ aux implémentations d'appareils qui incluent des applications effectuant un traitement sur l'appareil des données sensibles décrites dans la section 9.8.6 (données au niveau de l'OS et ambiantes) d'utiliser le framework Private Compute Core (PCC) décrit ci-dessous.

Tous les composants d'implémentation de l'API mise en bac à sable dans l'environnement PCC :

[C-0-1] NE DOIT PAS demander l'autorisation INTERNET.

[C-0-1] DOIT être déclaré avec un attribut android:isPrivateComputeCoreProcess="true" dans sa déclaration de fichier manifeste.

[C-0-2] DOIT accéder à Internet uniquement via des API structurées reposant sur des implémentations Open Source accessibles au public utilisant des mécanismes de protection de la confidentialité, ou indirectement via les API du SDK Android. Le mécanisme protégeant la confidentialité est défini comme "ceux qui n'autorisent que l'analyse agrégée et empêchent la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher toute introspection des données par utilisateur (par exemple, implémenté à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).

[C-0-2] DOIT être préchargé sur l'image système de l'appareil.

[C-0-3] Les services DOIVENT être séparés des autres composants du système (par exemple, ne pas lier le service ni partager les ID de processus sauf pour les éléments suivants :
- Téléphonie, Contacts, UI système et Média avec des implémentations ne s'exécutant pas en tant qu'UID PCC).
[C-0-4] NE DOIT PAS autoriser les utilisateurs à remplacer les services par une application ou un service installable par l'utilisateur
[C-0-5] NE DOIT autoriser que les services préinstallés désignés par l'OEM (disposant d'un rôle système approprié défini dans le service système PCC Manager) et disposant des autorisations appropriées à capturer ces données. Sauf si la fonctionnalité de remplacement est intégrée à AOSP (par exemple, pour les applications d'assistant numérique) données ambiantes sensibles décrites dans la section 9.8.6.
[C-0-6] NE DOIT PAS autoriser d'autres applications que le mécanisme de services préinstallés à capturer de telles données. Sauf si cette fonctionnalité de capture est implémentée avec une API SDK Android.
[C-0-7] DOIT fournir à l'utilisateur la possibilité de désactiver les services.
[C-0-8] NE DOIT PAS omettre la possibilité pour l'utilisateur de gérer les autorisations Android détenues par les services et doit suivre le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.

[C-0-9] DOIT s'exécuter dans un processus dédié avec un UID unique attribué par le framework, distinct du processus d'application principal et des autres composants en bac à sable.

Tout accès réseau requis par les composants de l'environnement PCC DOIT être transmis par proxy via un APK désigné agissant en tant qu'application de passerelle PCC. Le ou les composants désignés :

[C-1-1] DOIT disposer de l'autorisation privilégiée android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES. Cette autorisation désigne l'application comme une application de passerelle PCC.
[C-1-2] Le code source DOIT être mis à disposition pour que le public puisse le vérifier.
[C-1-3] DOIT utiliser des mécanismes préservant la confidentialité pour toute sortie de données, comme défini dans la section 9.8.6
[C-1-4] DOIT être compatible avec le mode audit du framework PCC, qui inclut la journalisation des requêtes réseau, des points de terminaison de serveur et d'autres données pertinentes pour vérifier le comportement protégeant la confidentialité lorsqu'il est activé.

9.8.16. Données audio et vidéo continues

Si les implémentations d'appareils capturent des données telles que décrites dans les sections 9.8.2 ou 9.8.6, et si ces implémentations utilisent des données audio obtenues en arrière-plan (en continu) via AudioRecord, SoundTrigger ou d'autres API audio, OU des données de caméra obtenues en arrière-plan (en continu) via CameraManager ou d'autres API de caméra, elles :

[C-0-1] DOIT appliquer un indicateur correspondant (appareil photo et/ou micro, conformément à la section 9.8.2 Enregistrement), sauf si :
- Cet accès est effectué dans une implémentation en bac à sable (voir 9.8.15 Implémentation de l'API en bac à sable), via un package contenant un ou plusieurs des rôles suivants : Intelligence de l'UI du système, Intelligence audio ambiante du système, Intelligence audio du système, Intelligence des notifications du système, Intelligence textuelle du système ou Intelligence visuelle du système.
- L'accès est effectué via un bac à sable, implémenté et appliqué par des mécanismes dans AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector).
- L'accès audio est effectué à des fins d'assistance par l'application Assistant numérique, qui fournit SOURCE_HOTWORD comme source audio.
- L'accès est effectué par le système et implémenté avec du code Open Source.
[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exiger le consentement utilisateur pour chaque fonctionnalité utilisant ces données et de les désactiver par défaut.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'appliquer le même traitement (c'est-à-dire de respecter les restrictions décrites dans les sections 9.8.2 Enregistrement, 9.8.6 Données au niveau de l'OS et ambiantes, 9.8.15 Implémentations d'API en bac à sable et 9.8.16 Données audio et de caméras continues) aux données de caméras provenant d'un accessoire connecté à distance.

Si les implémentations d'appareils reçoivent des données d'appareil photo ou de micro d'un accessoire connecté à distance et que les données sont accessibles sous forme non chiffrée en dehors de l'OS Android, de l'implémentation en bac à sable ou d'une fonctionnalité en bac à sable créée par WearableSensingManager, elles :

[C-1-1] DOIT indiquer à l'accessoire connecté distant d'afficher un indicateur supplémentaire.

Si les appareils permettent d'interagir avec une application d'assistance numérique sans le mot clé attribué (en traitant les requêtes utilisateur génériques ou en analysant la présence de l'utilisateur via la caméra), ils :

[C-2-1] DOIT s'assurer que cette implémentation est fournie par un package détenant le rôle android.app.role.ASSISTANT.
[C-2-2] DOIT s'assurer que cette implémentation utilise les API Android HotwordDetectionService et/ou VisualQueryDetectionService.

9.8.17. Télémétrie

Android stocke les journaux système et d'application à l'aide des API StatsLog. Ces journaux sont gérés via les API StatsManager, qui peuvent être utilisées par les applications système privilégiées.

StatsManager permet également de collecter des données classées comme sensibles en termes de confidentialité à partir d'appareils dotés d'un mécanisme de préservation de la confidentialité. En particulier, l'API StatsManager::query permet d'interroger les catégories de métriques restreintes définies dans StatsLog.

Toute implémentation interrogeant et collectant des métriques restreintes à partir de StatsManager :

[C-0-1] DOIT être la seule application/implémentation sur l'appareil et détenir l'autorisation READ_RESTRICTED_STATS.
[C-0-2] DOIT envoyer uniquement les données de télémétrie et le journal de l'appareil à l'aide d'un mécanisme protégeant la confidentialité. Le mécanisme protégeant la confidentialité est défini comme "ceux qui permettent uniquement l'analyse agrégée et empêchent la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher toute introspection des données par utilisateur (par exemple, implémentée à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
[C-0-3] NE DOIT PAS associer ces données à une identité utilisateur (telle qu'un compte) sur l'appareil.
[C-0-4] NE DOIT PAS partager ces données avec d'autres composants de l'OS qui ne respectent pas les exigences décrites dans la présente section (9.8.17. Télémétrie).
[C-0-5] DOIT fournir une option permettant à l'utilisateur d'activer/de désactiver la collecte, l'utilisation et le partage de données de télémétrie protégeant la confidentialité.
[C-0-6] DOIT fournir à l'utilisateur la possibilité d'effacer les données collectées par l'implémentation si elles sont stockées sous quelque forme que ce soit sur l'appareil. Si l'utilisateur a choisi d'effacer les données, TOUTES les données actuellement stockées sur l'appareil DOIVENT être supprimées.
[C-0-7] DOIT divulguer l'implémentation du protocole sous-jacent protégeant la confidentialité dans un dépôt Open Source.
[C-0-8] DOIT appliquer les règles de sortie des données de cette section pour contrôler la collecte des données dans les catégories de métriques restreintes définies dans StatsLog.

9.8.18. Confidentialité des fonctions agentiques

Implémentations sur les appareils :

[C-0-1] DOIT s'assurer que tous les composants exécutant des AppFunctions disposent de l'autorisation EXECUTE_APP_FUNCTIONS ou EXECUTE_APP_FUNCTIONS_SYSTEM.
[C-0-2] DOIT appeler une AppFunction uniquement à la suite directe d'une action explicite de l'utilisateur, et DOIT indiquer clairement à l'utilisateur l'application appelée et l'action principale à effectuer dans cette application.
[C-0-3] NE DOIT PAS servir de proxy ni modifier la requête d'une application tierce pour découvrir ou exécuter des AppFunctions, sauf si [C-0-1] et [C-0-2] sont respectées.
[C-0-4] NE DOIT PAS autoriser l'utilisation de données sensibles au niveau de l'OS ou ambiantes (telles que définies dans 9.8.6 Protections des données au niveau de l'OS et ambiantes) ou de leurs dérivés par les composants système pour générer ou paramétrer des incitations, sauf si les composants système fonctionnent dans un environnement d'exécution protégé tel que défini dans 9.8.6.

Terme clé : Un "nudge" est un point d'entrée généré de manière proactive dans une application à partir d'une surface système, initié sans action utilisateur directement précédente. Les incitations suggèrent ou guident l'utilisateur vers une action sans restreindre sa liberté de choix.

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT répondre aux exigences de la section 9.9.1. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. Ils DOIVENT en revanche répondre aux exigences de la section 9.9 du document de définition de la compatibilité Android correspondant au niveau d'API avec lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations sur les appareils :

[C-0-1] DOIT implémenter les API du mode Direct Boot même si elles ne sont pas compatibles avec le chiffrement du stockage.
[C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que les emplacements de stockage chiffrés par l'appareil (DE) et chiffrés par les identifiants (CE) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations sur les appareils :

[C-0-1] DOIT chiffrer les données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) si elle constitue une partie permanente et non amovible de l'appareil.
[C-0-2] DOIT activer le chiffrement du stockage des données par défaut une fois que l'utilisateur a terminé la configuration initiale.
[C-0-3] DOIT répondre aux exigences ci-dessus en matière de chiffrement du stockage des données en implémentant l'une des deux méthodes de chiffrement suivantes :
- Chiffrement basé sur les fichiers (FBE) et chiffrement des métadonnées, comme décrit dans la section 9.9.3.1.
- Chiffrement au niveau des blocs par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareil sont chiffrées, elles :

[C-1-1] DOIT démarrer sans demander d'identifiants à l'utilisateur et autoriser les applications compatibles avec le démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] NE DOIT PAS autoriser l'accès au stockage des identifiants chiffrés (CE) tant que les deux conditions suivantes ne sont pas remplies :
- L'utilisateur déverrouille l'appareil à l'aide d'une méthode d'authentification principale (mot de passe, schéma ou code, par exemple).
- Le message ACTION_USER_UNLOCKED est diffusé.
[C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller l'espace de stockage protégé par CE sans les identifiants fournis par l'utilisateur, une clé de dépôt enregistrée ou une implémentation de reprise au redémarrage répondant aux exigences de la section 9.9.4.
[C-1-4] DOIT utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers avec chiffrement des métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec le chiffrement des métadonnées, elles :

[C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide d'AES-256-XTS ou d'Adiantum. AES-256-XTS fait référence à Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme spécifié sur https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que la taille des fichiers, la propriété, les modes et les attributs étendus (xattrs).
[C-1-6] DOIT chiffrer les noms de fichiers à l'aide d'AES-256-CBC-CTS, d'AES-256-HCTR2 ou d'Adiantum.
[C-1-12] Si l'appareil dispose d'instructions AES (Advanced Encryption Standard) (telles que les extensions de chiffrement ARMv8 sur les appareils basés sur ARM ou AES-NI sur les appareils basés sur x86), les options basées sur AES ci-dessus pour le nom de fichier, le contenu du fichier et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisées, et non Adiantum.
[C-1-13] DOIT utiliser une fonction de dérivation de clé cryptographiquement robuste et non réversible (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, les clés par fichier) à partir des clés CE et DE. "Cryptographiquement robuste et non réversible" signifie que la fonction de dérivation de clé a une robustesse de sécurité d'au moins 256 bits et se comporte comme une famille de fonctions pseudo-aléatoires sur ses entrées.
[C-1-14] NE DOIT PAS utiliser les mêmes clés ou sous-clés de chiffrement basé sur les fichiers (FBE) pour différentes fins cryptographiques (par exemple, à la fois pour le chiffrement et la dérivation de clés, ou pour deux algorithmes de chiffrement différents).
[C-1-15] DOIT s'assurer que tous les blocs non supprimés de contenu de fichier chiffré sur le stockage persistant ont été chiffrés à l'aide de combinaisons de clé de chiffrement et de vecteur d'initialisation (IV) qui dépendent à la fois du fichier et de l'offset dans le fichier. De plus, toutes ces combinaisons DOIVENT être distinctes, sauf si le chiffrement est effectué à l'aide d'un matériel de chiffrement intégré qui ne prend en charge qu'une longueur d'IV de 32 bits.
[C-1-16] DOIT s'assurer que tous les noms de fichiers chiffrés non supprimés sur le stockage persistant dans des répertoires distincts ont été chiffrés à l'aide de combinaisons distinctes de clé de chiffrement et de vecteur d'initialisation (VI).
[C-1-17] DOIT s'assurer que tous les blocs de métadonnées du système de fichiers chiffrés sur le stockage persistant ont été chiffrés à l'aide de combinaisons distinctes de clé de chiffrement et de vecteur d'initialisation (IV).
Clés protégeant les zones de stockage CE et DE, et les métadonnées du système de fichiers :
- [C-1-7] DOIT être lié de manière cryptographique à un Keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine de confiance matérielle de l'appareil.
- [C-1-8] Les clés CE DOIVENT être liées aux identifiants de l'écran de verrouillage d'un utilisateur.
- [C-1-9] Les clés CE DOIVENT être liées à un mot de passe par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage.
- [C-1-10] DOIT être unique et distinct. En d'autres termes, la clé CE ou DE d'un utilisateur ne doit correspondre à la clé CE ou DE d'aucun autre utilisateur.
- [C-1-11] DOIT utiliser les algorithmes de chiffrement, les longueurs de clé et les modes obligatoirement compatibles.
- [C-1-12] DOIT être effacé de manière sécurisée lors du déverrouillage et du verrouillage du bootloader, comme décrit ici.
DOIT rendre les applications essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) compatibles avec le démarrage direct.

Le projet Android Open Source en amont fournit une implémentation privilégiée du chiffrement basé sur les fichiers, basé sur la fonctionnalité de chiffrement "fscrypt" du noyau Linux, et du chiffrement des métadonnées, basé sur la fonctionnalité "dm-default-key" du noyau Linux.

9.9.3.2. Chiffrement au niveau des blocs par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau des blocs par utilisateur, elles :

[C-1-1] DOIT activer la prise en charge multi-utilisateur, comme décrit dans la section 9.5.
[C-1-2] DOIT fournir des partitions par utilisateur, soit à l'aide de partitions brutes, soit à l'aide de volumes logiques.
[C-1-3] DOIT utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des périphériques de stockage sous-jacents.
[C-1-4] DOIT utiliser AES-256-XTS pour le chiffrement au niveau des blocs des partitions utilisateur.
Clés protégeant les appareils chiffrés au niveau des blocs par utilisateur :
- [C-1-5] DOIT être lié de manière cryptographique à un Keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine de confiance matérielle de l'appareil.
- [C-1-6] DOIT être lié aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau des blocs par utilisateur peut être implémenté à l'aide de la fonctionnalité "dm-crypt" du noyau Linux sur les partitions par utilisateur.

9.9.4. Reprendre la lecture après un redémarrage

La reprise au redémarrage permet de déverrouiller le stockage CE de toutes les applications, y compris celles qui ne sont pas encore compatibles avec le démarrage direct, après un redémarrage initié par une mise à jour OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

Une implémentation de la reprise au redémarrage doit continuer à garantir que, lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour ce pirate de récupérer les données chiffrées par identifiants de l'utilisateur, même si l'appareil est allumé, que le stockage CE est déverrouillé et que l'utilisateur a déverrouillé l'appareil après avoir reçu une mise à jour OTA. Pour résister aux attaques internes, nous supposons également que le pirate informatique a accès aux clés de signature cryptographiques de diffusion.

Plus précisément :

[C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour le pirate informatique qui a physiquement l'appareil et qui dispose des capacités et des limites suivantes :
- Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
- Peut entraîner la réception d'une mise à jour OTA par l'appareil.
- Peut modifier le fonctionnement de tout matériel (AP, flash, etc.) sauf comme indiqué ci-dessous, mais une telle modification implique un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.
- Vous ne pouvez pas modifier le fonctionnement du matériel inviolable (par exemple, Titan M).
- Impossible de lire la RAM de l'appareil en direct.
- Vous ne pouvez pas obtenir les identifiants de l'utilisateur (code, schéma ou mot de passe) ni l'obliger à les saisir.

Par exemple, une implémentation d'appareil qui implémente et respecte toutes les descriptions disponibles ici sera conforme à [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état de l'intégrité de l'appareil. Implémentations sur les appareils :

[C-0-1] DOIT indiquer correctement via la méthode de l'API System PersistentDataBlockManager.getFlashLockState() si l'état de son bootloader permet le flashage de l'image système.
[C-0-2] DOIT prendre en charge le démarrage validé pour l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans prise en charge du démarrage validé sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations d'appareil sont compatibles avec la fonctionnalité, elles :

[C-1-1] DOIT déclarer le flag de fonctionnalité de la plate-forme android.software.verified_boot.
[C-1-2] DOIT effectuer une vérification à chaque séquence de démarrage.
[C-1-3] DOIT commencer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et remonter jusqu'à la partition système.
[C-1-4] DOIT implémenter chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
[C-1-5] DOIT utiliser des algorithmes de validation aussi puissants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
[C-1-6] NE DOIT PAS autoriser le démarrage à se terminer en cas d'échec de la vérification du système, sauf si l'utilisateur accepte de tenter le démarrage quand même, auquel cas les données de tous les blocs de stockage non vérifiés NE DOIVENT PAS être utilisées.
[C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
[C-1-8] DOIT utiliser un stockage inviolable pour indiquer si le bootloader est déverrouillé. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été falsifié depuis Android.
[C-1-9] DOIT inviter l'utilisateur à confirmer physiquement la transition du mode bootloader verrouillé au mode bootloader déverrouillé pendant l'utilisation de l'appareil.
[C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (par exemple, les partitions de démarrage et système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée de l'OS.
[C-1-11] DOIT effacer de manière sécurisée toutes les données utilisateur lors du déverrouillage et du verrouillage du bootloader, conformément à la section 9.12. Suppression des données" (y compris la partition des données utilisateur et tous les espaces NVRAM).
[C-1-14] DOIT valider la signature au moins une fois par démarrage pour les packages autorisés listés comme require-strict-signature dans la configuration système.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ de valider tous les fichiers APK des applications privilégiées avec une chaîne de confiance ancrée dans les partitions protégées par le démarrage validé.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de valider tout artefact exécutable chargé par une application privilégiée en dehors de son fichier APK (tel que du code chargé dynamiquement ou du code compilé) avant de l'exécuter, ou de ne pas l'exécuter du tout.
DOIT implémenter une protection contre le rollback pour tout composant avec un micrologiciel persistant (par exemple, le modem ou la caméra) et DOIT utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégrée au bootloader utilisé pour charger Android.

Si les implémentations d'appareils peuvent valider le contenu des fichiers page par page, elles doivent :

[C-2-1] Prend en charge la vérification cryptographique du contenu des fichiers sans lire l'intégralité du fichier.
[C-2-2] NE DOIT PAS autoriser les requêtes de lecture sur un fichier protégé à aboutir lorsque le contenu lu n'est pas validé conformément à [C-2-1] ci-dessus.
[C-2-4] DOIT renvoyer la somme de contrôle du fichier en O(1) pour les fichiers activés.

Si les implémentations d'appareils sont déjà lancées sans possibilité de valider le contenu des fichiers par rapport à une clé de confiance sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence. Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations sur les appareils :

[C-0-1] DOIT permettre d'importer ou de générer au moins 8 192 clés.
[C-0-2] L'authentification sur l'écran de verrouillage DOIT implémenter un intervalle de temps entre les tentatives infructueuses. Si n correspond au nombre de tentatives infructueuses, l'intervalle de temps DOIT être d'au moins 30 secondes pour 9 < n < 30. Pour n > 29, la valeur de l'intervalle de temps DOIT être d'au moins 30*2^floor((n-30)/10) secondes ou d'au moins 24 heures, selon la valeur la plus petite.
NE DOIT PAS limiter le nombre de clés pouvant être générées.

Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle :

[C-1-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.

[C-1-2] DOIT implémenter les algorithmes de chiffrement RSA, AES, ECDSA, ECDH (si IKeyMintDevice est compatible), 3DES et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA-1 et SHA-2 les algorithmes de chiffrement et les fonctions de hachage requis par la version IKeyMintDevice ou IKeymasterDevice compatible pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce d'une isolation appropriée basée sur un hyperviseur sont également possibles.

[C-1-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[C-1-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Il est IMPÉRATIF d'empêcher l'utilisation des clés de signature d'attestation comme identifiants d'appareil permanents.

Remarque : Pour répondre à cette exigence, vous devez partager la même clé d'attestation pour un SKU donné,sauf si au moins 100 000 unités de ce SKU sont produites. Si plus de 100 000 unités de ce SKU sont produites, une clé différente PEUT être utilisée pour chaque groupe de 100 000 unités supplémentaires. Vous pouvez également utiliser la solution de provisionnement de clés à distance pour provisionner des clés d'attestation de courte durée sur l'appareil.

[C-1-5] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes. Les appareils automobiles qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur est changé NE DOIVENT PAS avoir la configuration du délai d'inactivité.
[C-1-6] DOIT être compatible avec IKeymasterDevice 3.0 ou version ultérieure, ou avec IKeyMintDevice version 1 ou version ultérieure.

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'appliquer un intervalle de temps minimal entre les tentatives d'échec uniques pour leurs principales méthodes d'authentification (telles que le code, le schéma ou le mot de passe), en fonction des éléments suivants :

Nombre de tentatives infructueuses uniques	Délai avant expiration minimal
0-4	0
5	1 minute
6	5 minutes
7	15 minutes
8	30 minutes
9	90 minutes
10	4 heures
11	12 heures
12	24 heures
13	4 jours
14	13 jours
15	41 jours
16	123 jours
17	1 an
18	3 ans
19	9 ans

9.11.1. Écran de verrouillage sécurisé, authentification et appareils virtuels

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux dans lequel une authentification principale basée sur un facteur de connaissance peut être soutenue soit par une authentification biométrique forte secondaire, soit par des modalités tertiaires plus faibles.

Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes d'authentification suivantes comme méthode principale :
- Un code numérique
- Un mot de passe alphanumérique
- Un schéma de balayage sur une grille de 3 x 3 points
Notez que les méthodes d'authentification ci-dessus sont appelées méthodes d'authentification principales recommandées dans ce document.
[C-0-1] MUST limit the number of failed primary authentication attempts.
[C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter une limite supérieure de 20 tentatives d'authentification principale infructueuses et, si les utilisateurs y consentent et activent la fonctionnalité, d'effectuer une "réinitialisation des données d'usine" après avoir dépassé la limite de tentatives d'authentification principale infructueuses.

Si les implémentations d'appareils définissent un code PIN numérique comme méthode d'authentification principale recommandée :

[C-SR-6] Il est FORTEMENT RECOMMANDÉ qu'un code comporte au moins six chiffres, soit une entropie de 20 bits.
[C-SR-7] Il est FORTEMENT DÉCONSEILLÉ d'autoriser la saisie automatique d'un code à moins de six chiffres sans interaction de l'utilisateur, afin d'éviter de révéler la longueur du code.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principale recommandées et utilisent une nouvelle méthode d'authentification comme moyen sécurisé de verrouiller l'écran, la nouvelle méthode d'authentification :

[C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans Exiger l'authentification de l'utilisateur pour l'utilisation des clés.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage si elles sont basées sur un secret connu et utilisent une nouvelle méthode d'authentification pour être traitées comme un moyen sécurisé de verrouiller l'écran :

[C-3-1] L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
[C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
[C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer les méthodes d'authentification principales recommandées (c'est-à-dire le code, le schéma ou le mot de passe) implémentées et fournies dans AOSP.
[C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application outil de contrôle des règles relatives aux appareils (DPC) a défini la règle relative aux exigences de mot de passe via DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive que PASSWORD_COMPLEXITY_NONE ou via la méthode DevicePolicyManager.setPasswordQuality() avec une constante plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-3-5] Les nouvelles méthodes d'authentification DOIVENT revenir aux méthodes d'authentification principales recommandées (c'est-à-dire code, schéma ou mot de passe) au moins une fois toutes les 72 heures OU indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de ses données.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principale recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie pour être traitée comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode :

[C-4-1] DOIT répondre à toutes les exigences décrites dans la section 7.3.10 pour la classe 1 (anciennement Praticité).
[C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées, basée sur un secret connu.
[C-4-3] DOIT être désactivé et n'autoriser que l'authentification principale recommandée pour déverrouiller l'écran lorsque l'application outil de contrôle des règles relatives aux appareils (DPC) a défini la règle de fonctionnalité keyguard en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(), avec l'un des indicateurs biométriques associés (c'est-à-dire KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences de la classe 3 (anciennement forte) décrites dans la section 7.3.10 :

[C-5-1] Les méthodes DOIVENT être désactivées si l'application outil de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité des exigences relatives au mot de passe via DevicePolicyManager.setRequiredPasswordComplexity() avec un niveau de complexité plus restrictif que PASSWORD_COMPLEXITY_LOW ou à l'aide de la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] L'utilisateur DOIT être invité à utiliser la méthode d'authentification principale recommandée (code, schéma ou mot de passe, par exemple), comme décrit dans [C-1-7] et [C-1-8] de la section 7.3.10.
[C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé et DOIVENT répondre aux exigences commençant par C-8 dans la section ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur la position :

[C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et répond aux exigences pour être considérée comme un écran de verrouillage sécurisé.
[C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser qu'une seule des méthodes d'authentification principale recommandées pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la règle avec l'une des options suivantes :
- La méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS).
- Méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_NONE.
- Méthode DevicePolicyManager.setRequiredPasswordComplexity() avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_NONE.
[C-6-3] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (code, schéma ou mot de passe, par exemple) au moins une fois toutes les quatre heures ou moins. Lorsqu'un jeton physique répond aux exigences des implémentations TrustAgent dans C-X, les restrictions de délai d'expiration définies dans [C-9-5] s'appliquent à la place.
[C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans la section C-8 ci-dessous.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui implémentent l'API système TrustAgentService, elles :

[C-7-1] Une indication claire doit figurer dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou peut être déverrouillé par des agents de confiance. Par exemple, l'AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouillage automatique" et "Verrouillage instantané avec le bouton Marche/Arrêt" dans le menu des paramètres, ainsi qu'une icône distinctive sur l'écran de verrouillage.
[C-7-2] DOIT respecter et implémenter entièrement toutes les API d'agent de confiance dans la classe DevicePolicyManager, telles que la constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NE DOIT PAS implémenter entièrement la fonction TrustAgentService.addEscrowToken() sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil mobile), mais PEUT implémenter entièrement la fonction sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou automobile).
[C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
[C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui où la clé est utilisée. Par exemple, une clé stockée sur un téléphone peut déverrouiller un compte utilisateur sur un téléviseur. Pour les appareils automobiles, il n'est pas autorisé de stocker le jeton de séquestre sur une partie quelconque du véhicule.
[C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'activer le jeton de séquestre pour déchiffrer le stockage de données.
[C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées.
[C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (comme un code, un schéma ou un mot de passe) décrites dans [C-1-7] et [C-1-8] de la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, la distraction du conducteur) est préoccupante.
[C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.
[C-7-11] NE DOIT PAS autoriser les TrustAgents sur les appareils personnels principaux (par exemple, les appareils portables) à déverrouiller l'appareil, et ne peut les utiliser que pour maintenir un appareil déjà déverrouillé dans l'état déverrouillé pendant une durée maximale de quatre heures. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
[C-7-12] DOIT utiliser un canal de communication cryptographiquement sécurisé (par exemple, UKEY2) pour transmettre le jeton de séquestre du périphérique de stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et utilisent une nouvelle méthode d'authentification pour déverrouiller le keyguard :

[C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_NONE ou via la méthode DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive que PASSWORD_COMPLEXITY_NONE.
[C-8-2] Ils NE DOIVENT PAS réinitialiser les minuteurs d'expiration des mots de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Ils NE DOIVENT PAS exposer d'API permettant aux applications tierces de modifier l'état de verrouillage.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et ne sont pas compatibles avec les événements d'entrée associés, par exemple via VirtualDeviceManager, elles :

[C-9-1] DOIT verrouiller ces écrans virtuels secondaires lorsque l'écran par défaut de l'appareil est verrouillé, et les déverrouiller lorsque l'écran par défaut de l'appareil est déverrouillé.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et de prendre en charge les événements d'entrée associés, par exemple via VirtualDeviceManager, elles :

[C-10-1] DOIT prendre en charge des états de verrouillage distincts par appareil virtuel
[C-10-2] Exigence supprimée dans Android 16.
[C-10-3] Exigence supprimée dans Android 16.
[C-10-4] DOIT verrouiller tous les écrans lorsque l'utilisateur lance un verrouillage, y compris via l'affordance utilisateur de verrouillage requise pour les appareils portables (voir la section 2.2.5[9.11/H-1-2]).
[C-10-5] DOIT disposer d'instances d'appareils virtuels distinctes par utilisateur
[C-10-6] DOIT désactiver le streaming d'application comme indiqué par DevicePolicyManager.setNearbyAppStreamingPolicy.
[C-10-7] Exigence supprimée dans Android 16.
[C-10-11] DOIT désactiver l'UI d'authentification sur les appareils virtuels, y compris la saisie du facteur de connaissance et l'invite biométrique
[C-10-12] Exigence supprimée dans Android 16.
[C-10-13] NE DOIT PAS utiliser un état de verrouillage d'appareil virtuel comme autorisation d'authentification de l'utilisateur avec le système Android Keystore. Consultez KeyGenParameterSpec.Builder.setUserAuthentication*.
[C-10-14] DOIT fournir une affordance utilisateur pour activer le partage du presse-papiers entre les appareils avant de partager les données du presse-papiers entre les appareils physiques et virtuels si l'appareil implémente un presse-papiers partagé.
[C-10-15] DOIT afficher des notifications lorsque les données du presse-papiers sont consultées, à la fois sur l'appareil à partir duquel elles ont été consultées et sur l'appareil à partir duquel elles proviennent.

Lorsque les implémentations d'appareils permettent à l'utilisateur de transférer le facteur de connaissance d'authentification principal d'un appareil source vers un appareil cible, par exemple pour la configuration initiale de l'appareil cible, elles :

[C-11-1] DOIT chiffrer le facteur de connaissance avec des garanties de protection semblables à celles décrites dans le livre blanc sur la sécurité du service Google Cloud Key Vault lors du transfert du facteur de connaissance de l'appareil source vers l'appareil cible, de sorte que le facteur de connaissance ne puisse pas être déchiffré à distance ni utilisé pour déverrouiller l'un ou l'autre des appareils à distance.
[C-11-2] DOIT demander à l'utilisateur de confirmer le facteur de connaissance de l'appareil source avant de le transférer vers l'appareil cible.
[C-11-3] DOIT, sur un appareil cible dépourvu de facteur de connaissance pour l'authentification principale, demander à l'utilisateur de confirmer un facteur de connaissance transféré sur l'appareil cible avant de définir ce facteur de connaissance comme facteur de connaissance pour l'authentification principale de l'appareil cible et avant de rendre disponibles les données transférées depuis un appareil source.

[C-12-1] DOIT appeler grantTrust() avec l'indicateur uniquement lorsqu'il est connecté à un appareil physique à proximité disposant de son propre écran de verrouillage et lorsque l'utilisateur a authentifié son identité sur cet écran de verrouillage. Les appareils à proximité peuvent utiliser des mécanismes de détection sur le poignet ou l'appareil porté après un déverrouillage unique par l'utilisateur pour répondre à l'exigence d'authentification de l'utilisateur.
[C-12-2] DOIT placer l'implémentation de l'appareil dans l'état TrustState.TRUSTABLE lorsque l'écran est éteint (par exemple, en appuyant sur un bouton ou en cas de délai d'inactivité de l'écran) et que TrustAgent n'a pas révoqué la confiance. L'AOSP répond à cette exigence.
[C-12-3] NE DOIT déplacer l'appareil de l'état TrustState.TRUSTABLE à l'état TrustState.TRUSTED que si TrustAgent accorde toujours la confiance en fonction des exigences de [C-12-1].

[C-12-4] DOIT appeler TrustManagerService.revokeTrust() si les implémentations n'utilisent pas une mesure de distance cryptographiquement sécurisée et précise, comme défini dans [C-12-5] :
- Au bout de 24 heures maximum après l'octroi de l'accès, ou
- après une période d'inactivité de huit heures ;
- Si les implémentations n'utilisent pas une mesure de distance précise et sécurisée par chiffrement, comme défini dans [C-12-5], lorsque la connexion sous-jacente à l'appareil physique à proximité est perdue.

[C-12-5] Les implémentations qui s'appuient sur une mesure de distance sécurisée et précise pour répondre aux exigences de [C-12-4] DOIVENT utiliser l'une des solutions suivantes :
- Implémentations utilisant l'UWB :
  - DOIT répondre aux exigences de conformité, de certification, de précision et de calibration pour l'UWB décrites dans la section 7.4.9.
  - DOIT utiliser l'un des modes de sécurité P-STS listés dans la section 7.4.9.
- Implémentations utilisant le réseau Wi-Fi Neighborhood Awareness Networking (NAN) :
  - DOIT respecter les exigences de précision décrites dans la section 2.2.1 [7.4.2.5/H-SR-1], utiliser la bande passante de 160 MHz (ou plus) et suivre les étapes de configuration des mesures spécifiées dans Calibration de la présence.
  - DOIT utiliser le LTF sécurisé tel que défini dans IEEE 802.11az.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et acceptent les événements d'entrée associés, par exemple via VirtualDeviceManager, et que les écrans ne sont pas marqués avec VIRTUAL_DISPLAY_FLAG_SECURE, ils :

[C-13-8] DOIT empêcher le démarrage des activités avec l'attribut android:canDisplayOnRemoteDevices ou les métadonnées android.activity.can_display_on_remote_devices définis sur "false" sur l'appareil virtuel.
[C-13-9] DOIT bloquer le démarrage sur l'appareil virtuel des activités qui n'activent pas explicitement le streaming et qui indiquent qu'elles affichent du contenu sensible, y compris via SurfaceView#setSecure et FLAG_SECURE.

Si les implémentations d'appareil sont compatibles avec des états d'alimentation d'écran distincts via DeviceStateManager ET avec des états de verrouillage d'écran distincts via KeyguardDisplayManager, elles :

[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser une méthode d'authentification répondant aux exigences définies dans la section 9.11.1 ou une méthode biométrique répondant au moins aux spécifications de classe 1 définies dans la section 7.3.10 pour permettre le déverrouillage indépendant de l'écran par défaut de l'appareil.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de limiter le déverrouillage de l'écran séparé via un délai d'affichage défini.
[C-SR-4] Il est FORTEMENT RECOMMANDÉ de permettre à l'utilisateur de verrouiller globalement tous les écrans à l'aide du verrouillage depuis l'appareil portable principal.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un processeur sécurisé dédié ainsi que dans l'environnement d'exécution isolé décrit ci-dessus. Ce processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre pour être considéré comme une StrongBox.

Implémentations d'appareils dotés d'un processeur sécurisé dédié :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox. StrongBox deviendra probablement une exigence dans une prochaine version.

Si les implémentations d'appareils sont compatibles avec StrongBox, elles :

[C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DOIT fournir un matériel sécurisé dédié utilisé pour sauvegarder le keystore et l'authentification sécurisée des utilisateurs. Le matériel sécurisé dédié peut également être utilisé à d'autres fins.
[C-1-3] DOIT disposer d'un processeur distinct qui ne partage aucun cache, DRAM, coprocesseur ni autre ressource de base avec le processeur d'application (AP).
[C-1-4] DOIT s'assurer que les périphériques partagés avec le PA ne peuvent en aucun cas modifier le traitement StrongBox ni obtenir d'informations de StrongBox. L'AP PEUT désactiver ou bloquer l'accès à StrongBox.
[C-1-5] DOIT disposer d'une horloge interne d'une précision raisonnable (+/- 10%) qui est à l'abri de toute manipulation par le PA.
[C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit des résultats imprévisibles et uniformément distribués.
[C-1-7] DOIT être inviolable, y compris résistant à la pénétration physique et aux problèmes techniques.
[C-1-8] DOIT être résistant aux canaux auxiliaires, y compris à la fuite d'informations via les canaux auxiliaires de puissance, de synchronisation, de rayonnement électromagnétique et de rayonnement thermique.
[C-1-9] DOIT disposer d'un stockage sécurisé qui garantit la confidentialité, l'intégrité, l'authenticité, la cohérence et la fraîcheur du contenu. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf dans les limites autorisées par les API StrongBox.

Pour valider la conformité avec les sections [C-1-3] à [C-1-9], les implémentations d'appareils doivent :

[C-1-10] DOIT inclure le matériel certifié conforme au profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou BSI-CC-PP-0117-2022, ou évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation de la vulnérabilité à fort potentiel d'attaque conformément à la Application du potentiel d'attaque aux cartes à puce des critères communs.
[C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation des failles à fort potentiel d'attaque conformément aux Critères communs pour l'application du potentiel d'attaque aux cartes à puce.
[C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, d'un niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement obligatoire dans une prochaine version.
[C-SR-3] Il est FORTEMENT RECOMMANDÉ de fournir une résistance aux attaques internes (IAR, insider attack resistance), ce qui signifie qu'un employé ayant accès aux clés de signature du micrologiciel ne peut pas produire un micrologiciel qui provoque la fuite de secrets par StrongBox, contourne les exigences de sécurité fonctionnelle ou permet d'accéder à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fourni via l'IAuthSecret HAL.

9.11.3. Justificatif d'identité

Le système d'identifiants d'identité est défini et obtenu en implémentant toutes les API du package android.security.identity.*. Ces API permettent aux développeurs d'applications de stocker et de récupérer des documents d'identité utilisateur. Implémentations sur les appareils :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le système d'identifiants d'identité.

Si les implémentations d'appareils implémentent le système d'informations d'identité, elles :

[C-1-1] DOIT renvoyer une valeur non nulle pour la méthode IdentityCredentialStore#getInstance().
[C-1-2] DOIT implémenter le système d'identifiants (par exemple, les API android.security.identity.*) avec du code communiquant avec une application de confiance dans une zone isolée de manière sécurisée du code s'exécutant sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur pourrait accéder à l'état interne de l'environnement isolé, y compris le DMA.
[C-1-3] Les opérations de chiffrement nécessaires à l'implémentation du système d'identifiants (par exemple, les API android.security.identity.*) DOIVENT être effectuées entièrement dans l'application de confiance, et le contenu de la clé privée NE DOIT JAMAIS quitter l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par des API de niveau supérieur (par exemple, la méthode createEphemeralKeyPair()).
[C-1-4] L'application de confiance DOIT être implémentée de manière à ce que ses propriétés de sécurité ne soient pas affectées (par exemple, les données d'identification ne sont pas divulguées à moins que les conditions de contrôle des accès ne soient remplies, les MAC ne peuvent pas être produits pour des données arbitraires) même si Android se comporte mal ou est compromis.

Le projet Android Open Source en amont fournit une implémentation de référence d'une application de confiance (libeic) qui peut être utilisée pour implémenter le système d'identifiants d'identité.

9.12. Suppression des données

Toutes les implémentations d'appareils :

[C-0-1] DOIT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine.
[C-0-2] DOIT supprimer toutes les données du système de fichiers userdata lors d'un "rétablissement de la configuration d'usine".
[C-0-3] DOIT supprimer les données de manière à respecter les normes du secteur concernées, telles que NIST SP800-88, lors d'un "rétablissement de la configuration d'usine".
[C-0-4] DOIT déclencher le processus de rétablissement de la configuration d'usine ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'outil de contrôle des règles relatives aux appareils de l'utilisateur principal.
PEUT proposer une option d'effacement rapide des données qui n'effectue qu'un effacement logique des données.

9.13. Mode démarrage sécurisé

Android propose un mode de démarrage sécurisé qui permet aux utilisateurs de démarrer l'appareil dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et où toutes les applications tierces sont désactivées. Ce mode, appelé "mode sans échec", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes :

[C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode Safe Boot, elles :

[C-1-1] DOIT fournir à l'utilisateur une option permettant d'accéder au mode de démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf lorsque l'application tierce est un outil de contrôle des règles relatives aux appareils et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".
[C-1-2] DOIT permettre à l'utilisateur de désinstaller les applications tierces en mode sans échec.
DOIT fournir à l'utilisateur une option permettant d'accéder au mode sans échec à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation du système de véhicule automobile

Les appareils Android Automotive sont censés échanger des données avec les sous-systèmes critiques du véhicule en utilisant la HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule, tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android pour empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Forfaits d'abonnement

Les "forfaits d'abonnement" font référence aux détails du forfait de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils :

[C-0-1] DOIT renvoyer les forfaits d'abonnement uniquement à l'application de l'opérateur mobile qui les a fournis à l'origine.
[C-0-2] NE DOIT PAS sauvegarder ni importer à distance des forfaits.
[C-0-3] DOIT uniquement autoriser les remplacements, tels que SubscriptionManager.setSubscriptionOverrideCongested(), à partir de l'application de l'opérateur mobile qui fournit actuellement des forfaits valides.

9.16. Migration des données d'application

Si les implémentations d'appareils incluent une fonctionnalité permettant de migrer des données d'un appareil vers un autre et ne limitent pas les données d'application qu'elles copient à celles configurées par le développeur d'application dans le fichier manifeste via l'attribut android:fullBackupContent, elles :

[C-1-1] NE DOIT PAS lancer de transfert de données d'application depuis des appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale, comme décrit dans la section 9.11.1 Écran de verrouillage sécurisé et authentification.
[C-1-2] DOIT confirmer de manière sécurisée l'authentification principale sur l'appareil source et confirmer l'intention de l'utilisateur de copier les données sur l'appareil source avant tout transfert de données.
[C-1-3] DOIT utiliser l'attestation de clé de sécurité pour s'assurer que l'appareil source et l'appareil cible de la migration d'appareil à appareil sont des appareils Android légitimes et que leur bootloader est verrouillé.
[C-1-4] DOIT uniquement migrer les données d'application vers la même application sur l'appareil cible, avec le même nom de package ET le même certificat de signature.
[C-1-5] DOIT indiquer dans le menu des paramètres que les données de l'appareil source ont été migrées à l'aide d'une migration de données d'appareil à appareil. Un utilisateur NE DOIT PAS pouvoir supprimer cette indication.

9.17. Framework de virtualisation Android

Les API du Framework de virtualisation Android (AVF) (android.system.virtualmachine.*) permettent aux applications de créer des machines virtuelles (VM) protégées (pVM) et non protégées (non-pVM) sur l'appareil, qui chargent et exécutent des binaires natifs en tant que charges utiles.

Si les implémentations d'appareil définissent FEATURE_VIRTUALIZATION_FRAMEWORK sur true, elles :

[C-1-1] DOIT s'assurer que android.system.virtualmachine.VirtualMachineManager.getCapabilities() renvoie l'un des éléments suivants :
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. Validation du développeur

Implémentations d'appareils déclarant le niveau d'API 36.1 ou supérieur :

PEUT inclure la prise en charge d'un service de validation des développeurs pour certifier que les applications proviennent d'un développeur connu.

Les implémentations d'appareil déclarant le niveau d'API 36.1 ou supérieur et configurant un vérificateur de développeur en définissant config_developerVerificationServiceProviderPackageName dans config.xml :

[9.18/C-1-1] DOIT appeler le android.content.pm.verify.developer.DeveloperVerifierService configuré pour chaque installation de package d'application, y compris les nouvelles installations et les mises à jour des applications existantes.

Implémentations d'appareils déclarant le niveau d'API 36.1 ou supérieur :

MAY peut également configurer un délégué pour définir la règle active en définissant config_developerVerificationPolicyDelegatePackageName dans config.xml.

Si un validateur de développeur est configuré, les implémentations d'appareil :

[9.18/C-2-1] DOIT uniquement autoriser le validateur du développeur ou son délégué configuré à définir la stratégie d'installation telle que définie dans android.content.pm.PackageInstaller.

Si un validateur est appelé dans le cadre d'une session d'installation de package, les implémentations d'appareil :

[9.18/C-3-1] DOIT empêcher l'installation d'un package d'application si :
- L'installation échoue lors de la validation de l'identité du développeur.
- La règle de validation des développeurs pour la session d'installation est définie sur une valeur autre que DEVELOPER_VERIFICATION_POLICY_NONE.
- Sauf si les points 9.18/C-3-2 ou 9.18/C-3-3 s'appliquent.

[9.18/C-3-2] NE DOIT PAS empêcher l'installation d'un package d'application, quel que soit l'état de la règle ou de la validation, lorsque :
- Le package est installé via Android Debug Bridge (ADB).
- Le package correspond au programme de validation du développeur configuré ou à son programme d'installation.

[9.18/C-3-3] NE DOIT PAS empêcher l'installation d'un package d'application lorsque toutes les conditions suivantes sont remplies :
- La règle est définie sur DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN ou DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
- La validation est signalée comme incomplète.
- Le programme d'installation indique que l'utilisateur a explicitement demandé la poursuite de l'installation en signalant DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

PEUT autoriser l'installation d'un package d'application, quel que soit l'état de la règle ou de la validation pour les installations initiées par le propriétaire de l'appareil sur un appareil géré ou par le propriétaire du profil sur un profil géré, mais il est FORTEMENT RECOMMANDÉ d'empêcher les installations comme indiqué dans la section 9.18/C-3-1.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Toutefois, notez qu'aucun package de test logiciel n'est entièrement exhaustif. Pour cette raison, il est FORTEMENT RECOMMANDÉ aux développeurs d'appareils de limiter au maximum les modifications apportées à l'implémentation de référence et préférée d'Android disponible sur le projet Android Open Source. Cela permet de minimiser le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles des appareils.

10.1. Compatibility Test Suite

Implémentations sur les appareils :

[C-0-1] DOIT réussir la suite de tests de compatibilité (CTS) Android disponible sur le projet Android Open Source, en utilisant la version finale du logiciel sur l'appareil.
[C-0-2] DOIT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. La CTS sera versionnée indépendamment de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 17.

Implémentations sur les appareils :

[C-0-3] DOIT réussir la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.
DOIT utiliser l'implémentation de référence dans l'arborescence Android Open Source autant que possible.

10.2. Vérificateur CTS

CTS Verifier est inclus dans la Compatibility Test Suite. Il est conçu pour être exécuté par un opérateur humain afin de tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

Implémentations sur les appareils :

[C-0-1] DOIT exécuter correctement tous les cas applicables dans le CTS Verifier.

Le CTS Verifier comporte des tests pour de nombreux types de matériel, y compris certains matériels optionnels.

Implémentations sur les appareils :

[C-0-2] DOIT réussir tous les tests pour le matériel qu'il possède. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le cas de test de l'accéléromètre dans CTS Verifier.

Les cas de test pour les fonctionnalités indiquées comme facultatives dans le présent document de définition de la compatibilité PEUVENT être ignorés ou omis.

[C-0-2] Chaque appareil et chaque compilation DOIVENT exécuter correctement le CTS Verifier, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les fabricants d'appareils ne sont pas tenus d'exécuter explicitement le CTS Verifier sur les versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le test CTS Verifier uniquement par l'ensemble des paramètres régionaux inclus, la marque, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels pouvant être mis à jour

[C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à jour "en direct", c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répondra à cette exigence :
- Téléchargements "Over-The-Air (OTA)" avec mise à jour hors connexion via le redémarrage.
- Mises à jour "ancrées" via USB depuis un PC hôte.
- Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un support de stockage amovible.
[C-0-2] Le mécanisme de mise à jour utilisé DOIT permettre les mises à jour sans effacer les données utilisateur. En d'autres termes, le mécanisme de mise à jour DOIT préserver les données privées et partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.
[C-0-3] L'intégralité de la mise à jour DOIT être signée, et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.
[C-SR-1] Le mécanisme de signature est FORTEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide d'ECDSA NIST P-256.

Si les implémentations d'appareils incluent la prise en charge d'une connexion de données sans compteur telle que le profil 802.11 ou Bluetooth PAN (Personal Area Network), elles :

[C-1-1] DOIT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Les implémentations d'appareils DOIVENT vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur des blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT prendre en charge les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide du HAL de contrôle du démarrage.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais pendant sa durée de vie raisonnable déterminée en concertation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces :

[C-2-1] L'implémenteur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée selon le mécanisme décrit ci-dessus.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, cela signifie que :

[C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications des documents

À partir d'Android 16, il n'existe plus de journal des modifications distinct. Toutes les modifications apportées par rapport à la version précédente sont mises en évidence dans ce document.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler tout problème qui, selon vous, n'est pas abordé dans le document.

Définition de compatibilité Android 17 [APERÇU] Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

1. Introduction

1.1 Structure du document

1.1.1. Exigences par type d'appareil

1.1.2. ID de l'exigence

1.1.3. ID de l'exigence dans la section 2

2. Types d'appareils

2.1 Configurations de l'appareil

2.2. Exigences concernant les appareils mobiles

2.2.1. Matériel

2.2.2. Multimédia

2.2.3. Logiciel

2.2.3. Logiciel

2.2.4. Performances et puissance

2.2.5. Modèle de sécurité

Paramètres restreints

2.2.6. Compatibilité des outils et options pour les développeurs

2.2.7. Classe de performances multimédias pour les appareils portables

2.2.7.1. Contenus multimédias

2.2.7.2. Appareil photo

2.2.7.3. Matériel

2.2.7.4. Performances

2.2.7.5. Graphiques

2.3. Exigences concernant le téléviseur

2.3.1. Matériel

2.3.2. Multimédia

2.3.3. Logiciel

2.3.4. Performances et puissance

2.3.5. Modèle de sécurité

2.3.6. Compatibilité des outils et options pour les développeurs

2.4. Configuration requise pour la montre

2.4.1. Matériel

2.4.2. Multimédia

2.4.3. Logiciel

2.4.4. Performances et puissance

2.4.5. Modèle de sécurité

2.5. Exigences pour le secteur automobile

2.5.1. Matériel

2.5.2. Multimédia

2.5.3. Logiciel

2.5.4. Performances et puissance

2.5.5. Modèle de sécurité

2.5.6. Compatibilité des outils et options pour les développeurs

2.6. Exigences liées aux tablettes

2.6.1. Matériel

2.6.2. Modèle de sécurité

2.6.2. Logiciel

3. Logiciel

3.1. Compatibilité des API gérées

3.1.1. Extensions Android

3.1.2. Bibliothèque Android

3.2. Compatibilité logicielle avec les API

3.2.1. Autorisations

3.2.2. Créer des paramètres

3.2.3. Compatibilité des intentions

3.2.3.1. Intents d'application courants

3.2.3.2. Résolution des intents

3.2.3.3. Espaces de noms d'intent

3.2.3.4. Intents de diffusion

3.2.3.5. Intents d'application conditionnels

3.2.4. Activités sur des écrans secondaires/multiples

3.3. Compatibilité avec les API natives

3.3.1. Interfaces binaires d'application

3.3.2. Compatibilité du code natif ARM 32 bits

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

3.4.2. Compatibilité du navigateur

3.5. Compatibilité comportementale de l'API

3.5.1. Restriction d'une application

3.5.2. Hibernation des applications

3.6. Espaces de noms de l'API

3.7. Compatibilité de l'environnement d'exécution

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur d'applications (écran d'accueil)

3.8.2. Widgets

3.8.3. Notifications

3.8.3.1. Présentation des notifications

3.8.3.2. Service d'écoute des notifications

3.8.3.3. Mode Ne pas déranger/Prioritaire

3.8.3.4. Protection des notifications sensibles

Définition de compatibilité Android 17 [APERÇU]