Définition de compatibilité Android 13

1. Introduction

Ce document énumère les conditions à remplir pour que les appareils soient compatibles avec Android 13.

L'utilisation des éléments "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRAIT", "NE DEVRAIT PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" est conforme à la norme IETF définie dans la RFC 2119.

Comme utilisé dans ce document, un "outil de mise en œuvre d'appareil" est une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 13. Une "implémentation d'appareil" ou "implémentation" est la solution matérielle/logicielle ainsi développée.

Pour être considérées comme compatibles avec Android 13, les implémentations d'appareils DOIVENT respecter les exigences présentées dans la présente Définition de compatibilité, y compris tout document intégré via une référence.

Lorsque cette définition ou les tests logiciels décrits à la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'équipe chargée de la mise en œuvre de l'appareil de garantir la compatibilité avec les implémentations existantes.

Pour cette raison, le projet Android Open Source est à la fois la référence et l'implémentation préférée d'Android. Il est FORTEMENT RECOMMANDÉ de baser leurs implémentations sur le code source "en amont" disponible dans le projet Android Open Source. Bien que certains composants puissent être remplacés par d'autres implémentations, il est FORTEMENT RECOMMANDÉ de ne pas suivre cette pratique, car il sera considérablement plus difficile de réussir les tests logiciels. Il incombe à l'outil d'implémentation de garantir une compatibilité 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 à ce document sont dérivées 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 ou la suite de tests de compatibilité ne sont pas d'accord avec la documentation du SDK, celle-ci fait autorité. Tous les détails techniques fournis dans les ressources associées à 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 énumérées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le terme "Exigences principales" dans ce document.

1.1.2. Identifiant du prérequis

L'ID du prérequis est attribué pour les exigences DOIT.

• L'identifiant est attribué uniquement pour les exigences DOIT.
• Les exigences FORTEMENT RECOMMANDÉES sont signalées par la mention [SR], mais aucun identifiant n'est attribué.
• L'ID comprend les éléments suivants : ID du type d'appareil, ID de la condition, ID de la condition (par exemple, C-0-1).

Chaque ID est défini comme suit:

• ID du type d'appareil (pour plus d'informations, voir 2. Types d'appareils)
  • C: Core (exigences qui s'appliquent à toutes les implémentations d'appareils Android)
  • H: appareil portable Android
  • T: Un appareil Android Television
  • R: L'implémentation d'Android Automotive
  • W: Implémentation d'Android Watch
  • Onglet: Mise en œuvre des tablettes Android
• ID de la condition
  • Lorsque cette condition est inconditionnelle, cet ID est défini sur 0.
  • Lorsque l'exigence est conditionnelle, la valeur 1 est attribuée à la première condition, et le nombre augmente d'une unité dans la même section et le même type d'appareil.
• ID du prérequis
  • Cet ID commence à partir de 1 et incrémente de 1 dans la même section et la même condition.

1.1.3. Identifiant de l'exigence formulée dans la section 2

Les identifiants des exigences de la section 2 se divisent en 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.

suivi de l'identifiant du prérequis décrit ci-dessus.

• Dans la section 2, l'ID se compose des éléments suivants : ID de section / ID du type d'appareil, ID de la condition, ID de la condition (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 divers types d'appareils et facteurs de forme. Pour assurer la sécurité des appareils, la pile logicielle, y compris tout OS de remplacement ou une autre implémentation de 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 présentent un écosystème de distribution d'applications relativement mieux é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 respecter toutes les exigences des autres sections de cette définition de compatibilité.

2.1 Configurations des appareils

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

2.2. Configuration requise pour les appareils portables

Un appareil portable Android est une implémentation d'appareil Android généralement utilisée en le tenant dans la main, comme un lecteur MP3, un téléphone ou une tablette.

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

• Disposer d'une source d'alimentation qui permet la mobilité, telle qu'une batterie.
• La diagonale de l'écran doit être comprise entre 3,3 pouces (ou 2,5 pouces pour les implémentations d'appareils livrées au niveau d'API 29 ou antérieur) à 8 pouces.

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

2.2.1. Matériel

Implémentations pour les appareils portables:

• [7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible Android qui répond à toutes les exigences décrites dans ce document.

• [7.1.1.3/H-SR-1] SONT FORTEMENT RECOMMANDÉS de fournir aux utilisateurs l' affordance de modifier la taille d'affichage (densité d'écran).

• [7.1.1.1/H-0-2] DOIT prendre en charge la composition GPU de tampons graphiques au moins égale à la résolution la plus élevée de tout écran intégré.

Si les implémentations d'appareils portables prennent en charge la rotation logicielle de l'écran, elles:

• [7.1.1.1/H-1-1]* DOIT mettre l'écran logique mis à la disposition des applications tierces à au moins 2 pouces sur les bords courts et 2,7 pouces sur les bords longs. Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

Si les implémentations d'appareils portables ne sont pas compatibles avec la rotation logicielle de l'écran, elles:

• [7.1.1.1/H-2-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces se trouve à au moins 2,7 pouces sur les bords courts. Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

Si les implémentations d'appareils portables sont compatibles avec les affichages HDR (High Dynamic Range) via Configuration.isScreenHdr() , elles:

• [7.1.4.5/H-1-1] DOIT annoncer la compatibilité avec les 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 pour les appareils portables:

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

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

• [7.1.4.6/H-1-1] DOIT signaler en sortie une trace protobuf conforme au schéma des compteurs de GPU et des étapes de rendu GPU définis dans la documentation de Perfetto.
• [7.1.4.6/H-1-2] DOIT indiquer des valeurs conformes pour les compteurs de GPU de l'appareil en suivant le prototype du paquet de trace du compteur GPU.
• [7.1.4.6/H-1-3] DOIT indiquer des valeurs conformes pour les RenderStages du GPU de l'appareil en suivant le prototype du paquet de trace de l'étape de rendu.
• [7.1.4.6/H-1-4] DOIT signaler un point de trace pour la fréquence du GPU comme spécifié au format power/gpu_frequency.

Implémentations pour les appareils portables:

• [7.1.5/H-0-1] DOIT inclure la prise en charge de l'ancien mode de compatibilité des 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 ou les seuils auxquels le mode de compatibilité est activé, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.
• [7.2.1/H-0-1] DOIT inclure la compatibilité avec les applications tierces de l'éditeur de mode de saisie (IME).
• [7.2.3/H-0-2] DOIT envoyer à la fois l'événement d'appui normal et l'événement d'appui prolongé de la fonction Retour (KEYCODE_BACK) à l'application de premier plan. Ces événements NE DOIVENT PAS être utilisés par le système et PEUVENT être déclenchés par l'extérieur 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 Home sur tous les écrans compatibles 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 "Recents" (Éléments récents) sur au moins un des écrans compatibles avec Android.
• [7.2.4/H-0-1] DOIT être compatible avec la saisie 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 lors de l'appui prolongé sur KEYCODE_MEDIA_PLAY_PAUSE ou KEYCODE_HEADSETHOOK si l'activité au 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 à 3 axes.

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

• [7.3.1/H-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 100 Hz.

Si les implémentations d'appareils portables incluent un récepteur GPS/GNSS et signalent cette fonctionnalité aux applications via l'indicateur de fonctionnalité android.hardware.location.gps, celles-ci:

• [7.3.3/H-2-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/H-2-2] DOIT indiquer les pseudo-plages GNSS et les taux de pseudo-plages GNSS, qui, en conditions de ciel ouvert après avoir déterminé la position, sont suffisants pour calculer la position à 20 mètres carrés et la vitesse à 0, 2 mètre par seconde au moins, tout en se déplaçant à moins de 0, 2 mètre par seconde carré d'accélération.

Si les appareils portables sont équipés d'un gyroscope à trois axes:

• [7.3.4/H-3-1] DOIT pouvoir signaler des événements avec 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 indiquer toute valeur autre que PHONE_TYPE_NONE dans getPhoneType:

• [7,3,8/H] DEVRAIT inclure un capteur de proximité.

Implémentations pour les appareils portables:

• [7.3.11/H-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge le capteur de position avec six degrés de liberté.
• [7.4.3/H] DEVRAIT inclure la prise en charge du Bluetooth et de la technologie Bluetooth LE.

Si les appareils sont compatibles avec le protocole NAN (Wi-Fi Neighbor Awareness Networking) en déclarant PackageManager.FEATURE_WIFI_AWARE et la localisation Wi-Fi (délai aller-retour Wi-Fi, DAR) en déclarant PackageManager.FEATURE_WIFI_RTT, ils:

• [7.4.2.5/H-1-1] DOIT indiquer la plage avec précision à +/-1 mètre à 160 MHz/160 MHz au 68e centile (calculé avec la fonction de distribution cumulative), +/-2 mètres à 80 MHz au 68e centile, +/-4 mètres à 40 MHz/8 centiles au 68e centile et au 68e centile.

• [7.4.2.5/H-SR-1] Il est FORTEMENT RECOMMANDÉ de signaler la plage avec précision à +/-1 mètre pour une bande passante de 160 MHz au 90e centile (calculé avec la fonction de distribution cumulative), à +/-2 mètres à la bande de 80 MHz au 90e centile et au 90e centile de la bande de fréquences,

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans Étalonnage de présence.

Si les implémentations d'appareils portables incluent une caméra logique qui répertorie 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 95 degrés.

Implémentations pour 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 des applications (également appelée partition "/data").
• [7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsque moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

Si les implémentations d'appareils portables déclarent ne prendre en charge qu'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 allant jusqu'au 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'en 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'en 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'affichage par défaut utilise des résolutions de tampon d'image allant jusqu'au QHD (par exemple, QWXGA).

Si les implémentations d'appareils portables déclarent la prise en charge de toute 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 tampon de trames allant jusqu'au format 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 tampon d'images 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 tampon d'images jusqu'en 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 tampon de trames jusqu'en 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 contrôlés par le noyau sur les implémentations d'appareils.

Si les implémentations d'appareils portables incluent moins de 1 Go de mémoire 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 des applications (également appelée 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 d'espace de stockage non volatile disponible pour les données privées de l'application (également appelée partition "/data").
• DEVRAIT déclarer le flag de fonctionnalité android.hardware.ram.normal.

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

• [7.6.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge uniquement un 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 prendre en charge uniquement des ABI 32 bits.

Implémentations pour les appareils portables:

• [7.6.2/H-0-1] NE DOIT PAS fournir d'espace de stockage partagé pour l'application inférieur à 1 Gio.
• [7.7.1/H] DEVRAIT inclure un port USB compatible avec le mode périphérique.

Si les implémentations d'appareils portables incluent un port USB compatible avec le mode périphérique, ils:

• [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 pour 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 en mesure de répondre à toutes les exigences de performances pour la compatibilité avec le mode RV et incluent la prise en charge de celui-ci, 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 mettant en œuvre android.service.vr.VrListenerService pouvant être activée par les applications de réalité virtuelle 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:

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

Fonction	Mappages	Le contexte	Comportement
R	Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0CD Clé du noyau: KEY_PLAYPAUSE Clé Android: KEYCODE_MEDIA_PLAY_PAUSE	Lecture de contenus multimédias	Entrée: appui court Sortie: Lecture ou mise en pause
			Entrée: appui de manière prolongée Sortie: lancer la commande vocale Envoie : android.speech.action.VOICE_SEARCH_HANDS_FREE si l'appareil est verrouillé ou si son écran est éteint. Envoie android.speech.RecognizerIntent.ACTION_WEB_SEARCH dans le cas contraire.
		Appel entrant	Entrée: appui court Sortie: accepter l'appel
			Entrée: appui de manière prolongée Sortie: refuser l'appel
		Appel en cours	Entrée: appui court Sortie: Mettre fin à l'appel
			Entrée: appui de manière prolongée Sortie: couper ou réactiver le micro
Mrds	Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0E9 Clé du noyau: KEY_VOLUMEUP Clé Android: VOLUME_UP	Lecture de contenus multimédias, appel en cours	Entrée: appui court ou long Sortie: augmente le volume du système ou du casque
C	Page d'utilisation de HID: 0x0C Utilisation de HID: 0x0EA Clé de noyau: KEY_VOLUMEDOWN Clé Android: VOLUME_DOWN	Lecture de contenus multimédias, appel en cours	Entrée: appuyez brièvement ou de manière prolongée Sortie: diminue le volume du système ou du casque
D	Page d'utilisation des HID: 0x0C Utilisation du 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 court ou long Sortie: lancer la commande vocale

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

Lorsque des terminaux audio USB de type 0x0302 sont détectés, ils:

• [7.8.2.2/H-2-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec "micro" défini sur 0.

Lorsque des terminaux audio USB de type 0x0402 sont détectés, ils:

• [7.8.2.2/H-3-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec "micro" supplémentaire 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 indiquer un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSink() si le champ de type de terminal audio USB est 0x0302.

• [7.8.2.2/H-4-2] DOIT indiquer un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et rôle isSink() si le champ de type de terminal audio USB est 0x0402.

• [7.8.2.2/H-4-3] DOIT indiquer un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et rôle isSource() si le champ de type de terminal audio USB est 0x0402.

• [7.8.2.2/H-4-4] DOIT indiquer un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et rôle isSink() si le champ de type de terminal audio USB est 0x603.

• [7.8.2.2/H-4-5] DOIT indiquer un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et rôle isSource() si le champ de type de terminal audio USB est 0x604.

• [7.8.2.2/H-4-6] DOIT répertorier un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et role isSink() si le champ du type de terminal audio USB correspond à 0x400.

• [7.8.2.2/H-4-7] DOIT indiquer un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et rôle isSource() si le champ de type de terminal audio USB est 0x400.

• [7.8.2.2/H-SR-1] SONT FORTEMENT RECOMMANDÉS lors de la connexion d'un périphérique audio USB-C pour effectuer l'énumération des descripteurs USB, identifier les types de terminaux et diffuser l'intent ACTION_HEADSET_PLUG en moins de 1 000 millisecondes.

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

• [5.6/H-1-1] DOIT avoir une latence moyenne aller-retour continue de 500 millisecondes ou moins sur 5 mesures, avec une écart absolue moyenne inférieure à 50 ms, sur les chemins de données suivants: "haut-parleur vers micro", adaptateur de bouclage 3,5 mm (si compatible), rebouclage USB (si compatible).

• [5.6/H-1-2] DOIT avoir une latence moyenne de 500 millisecondes ou moins sur au moins cinq mesures sur le chemin de données entre le haut-parleur et le micro.

Si les implémentations d'appareils portables incluent au moins un actionneur haptique:

• [7.10/H]* NE DOIT PAS utiliser d'actionneur haptique (vibreur) à masse rotative excentrique.
• [7.10/H]* DEVRAIT positionner l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
• [7.10/H]* DEVRAIT implémenter toutes les constantes publiques pour les retours haptiques clairs dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_Release, KEYBOARD_TAP, CONFIRM_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_MOVE, VIRTUREAL_START).
• [7.10/H]* DEVRAIT implémenter toutes les constantes publiques pour les résultats haptiques clairs dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques PRIMITIVE_* possibles pour nameTICKly, EffectK,VibrationEffect, android_LOWTIK,VibrationEffect, android_LOWTICK. Certaines de ces primitives, telles que LOW_TICK et SPIN, ne sont possibles que si le vibreur peut prendre en charge des fréquences relativement basses.

• [7.10/H]* DEVRAIT suivre les conseils pour mapper des constantes publiques dans android.view.HapticFeedbackConstants aux constantes android.os.VibrationEffect recommandées, avec les relations d'amplitude correspondantes.

• [7,10/H]* DEVRAIT suivre l'évaluation de la qualité pour les API createOneShot() et createWaveform().

• [7.10/H]* DEVRAIT vérifier que le résultat de l'API publique android.os.Vibrator.hasAmplitudeControl() reflète correctement les capacités de son vibreur.

Un actionneur à résonateur linéaire (LRA, Linear Resonant Actionator) est un système à ressorts à masse unique dont la fréquence de résonance dominante est celle où la masse se traduit dans la direction du mouvement souhaité.

Si les implémentations d'appareils portables incluent au moins un actionneur à résonateur linéaire, elles:

• [7,10/H]* DEVRAIT déplacer l'actionneur haptique sur l'axe X (gauche-droite) en mode portrait.

Si les implémentations d'appareils portables disposent d'un actionneur haptique (actionneur à résonance linéaire sur l'axe X), ils:

• [7,10/H]* DEVRAIT faire en sorte que la fréquence de résonance de l'LRA de l'axe X soit inférieure à 200 Hz.

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

• [7.10/H]* DEVRAIT 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]* DEVRAIT effectuer une évaluation de la qualité des constantes haptiques.

• [7.10/H]* DEVRAIT vérifier et mettre à jour si nécessaire la configuration de remplacement pour les primitives non compatibles, comme décrit dans les instructions d'implémentation pour les constantes.

2.2.2. Multimédia

Les implémentations d'appareils portables DOIVENT prendre en charge 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 MPEG-4 AAC (AAC LC)
• [5.1/H-0-4] Profil MPEG-4 HE AAC (AAC+)
• [5.1/H-0-5] AAC ELD (AAC à faible délai améliorés)

Les implémentations d'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

Les implémentations d'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] HEVC H.265
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

2.2.3. Logiciels

Implémentations pour 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 comme décrit dans les documents du SDK, et fournir à l'utilisateur l'autorisation 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 au moins une application ou un composant de service avec un gestionnaire d'intent pour tous les modèles de filtre d'intent public définis par les intents d'application suivants, listés ici.
• [3.2.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une application de messagerie 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 de l'utilisateur standard.
• [3.8.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut compatible avec l'épinglage des raccourcis, widgets et widgetFeatures dans l'application.
• [3.8.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par des applications tierces via l'API ShortcutManager.
• [3.8.1/H-SR-3] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lanceur par défaut qui affiche les badges des icônes d'application.
• [3.8.2/H-SR-1] EST VIVEMENT RECOMMANDÉ pour prendre en charge les widgets d'application tiers.
• [3.8.3/H-0-1] DOIT autoriser les applications tierces à avertir les utilisateurs d'événements importants 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 prioritaires.
• [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, répéter, ignorer ou bloquer) les notifications via les affordances de l'utilisateur telles que les boutons d'action ou le panneau de configuration, comme implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications.
• [3.8.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via RemoteInput.Builder setChoices() dans le volet des notifications sans intervention supplémentaire de l'utilisateur.
• [3.8.3/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans ce volet.
• [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 dans la ligne des 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 d'assistance.

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 à partir de l'UI du système qui permet aux utilisateurs de basculer entre les routes multimédias disponibles appropriées (par exemple, les appareils Bluetooth et les routes fournies à MediaRouter2Manager) lorsqu'une application publie une notification MediaStyle avec un jeton MediaSession.

Si les implémentations d'appareils portables sont compatibles avec l'action d'assistance, celles-ci:

• [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é qui gère l'intent ACTION_ASSIST.

Si les implémentations d'appareils portables sont compatibles avec conversation notifications et les regroupent dans une section distincte de celle des alertes et des notifications silencieuses sans conversation, elles:

• [3.8.4/H-1-1]* DOIT afficher les notifications de conversation avant les notifications de non-conversation, à l'exception des notifications de service de premier plan en cours et des notifications importance:high.

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

• [3.8.10/H-1-1] DOIT afficher les notifications sur 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é, celles-ci:

• [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 sont compatibles avec les API ControlsProviderService et Control, et autorisent les applications tierces à publier des commandes de contrôle des appareils, elles:

• [3.8.16/H-1-1] DOIT déclarer l'indicateur de fonctionnalité android.software.controls et le définir sur true.
• [3.8.16/H-1-2] DOIT fournir à un utilisateur la possibilité d'ajouter, de modifier, de sélectionner et d'utiliser les commandes de ses appareils favoris à 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 de l'utilisateur dans trois interactions à partir d'un lanceur d'applications par défaut.

• [3.8.16/H-1-4] DOIT afficher avec précision dans cette affordance utilisateur 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 affordance aux utilisateurs pour qu'ils puissent désactiver les commandes d'appareils désignées comme triviales pour l'application, à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control Control.isAuthRequired.

À l'inverse, si les implémentations d'appareils portables ne mettent pas en œuvre de tels contrôles:

• [3.8.16/H-2-1] DOIT indiquer null pour les API ControlsProviderService et Control.
• [3.8.16/H-2-2] DOIT déclarer l'indicateur 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 le contenu est copié dans le presse-papiers:

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

Implémentations pour les appareils portables:

• [3.10/H-0-1] DOIT prendre en charge 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 allant au-delà des services d'accessibilité Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) fournis dans le projet Open Source TalkBack.
• [3.11/H-0-1] DOIT être compatible avec l'installation de moteurs de synthèse vocale tiers.
• [3.11/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.
• [3.13/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'interface utilisateur "Quick Settings" (Réglages 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 à l'écran basée sur un geste:

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

Si les implémentations d'appareils portables fournissent une fonction de navigation sous forme de geste depuis n'importe où 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 être inférieure à 40 dp de largeur 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 prennent en charge 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 les intents android.media.action.STILL_IMAGE_CAMERA et android.media.action.STILL_IMAGE_CAMERA_SECURE et lancer l'appareil photo en mode Image fixe, comme décrit dans le SDK.
• [7.5.4/H-1-2] DOIT respecter l'intent android.media.action.VIDEO_CAMERA pour lancer l'appareil photo en mode vidéo, comme décrit dans le SDK.

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

• [3.2.3.1/ H-1-1] DOIT avoir 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.

Performances et puissance

• [8.1/H-0-1] Latence cohérente des frames. Une latence de trame incohérente ou un délai d'affichage des cadres NE DOIT PAS se produire plus souvent que cinq images par seconde et DOIT être inférieures à une image 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 telles que définies par la suite de tests de compatibilité Android (CTS) en moins de 36 secondes.
• [8.1/H-0-3] Changement de tâches Lorsque plusieurs applications ont été lancées, le redémarrage d'une application déjà en cours d'exécution DOIT prendre moins d'une seconde.

Implémentations pour 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 des performances de lecture séquentielle d'au moins 15 Mo/s.
• [8.2/H-0-4] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations d'appareils portables incluent des fonctionnalités visant à améliorer la gestion de l'alimentation des appareils incluses dans AOSP ou à étendre les fonctionnalités incluses dans AOSP, elles:

• [8.3/H-1-1] DOIT fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.
• [8.3/H-1-2] DOIT fournir une affordance utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Mise en veille des applications.

Implémentations pour les appareils portables:

• [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [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 indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [8.4/H-0-4] DOIT rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats au développeur de l'application.
• [8.4/H] DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à 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'intent android.intent.action.POWER_USAGE_SUMMARY et afficher un menu de paramètres qui indique cette consommation d'énergie.

Implémentations pour les appareils portables:

• [8.5/H-0-1] DOIT fournir une affordance utilisateur dans le menu "Paramètres" avec la possibilité d'arrêter une application qui exécute un service de premier plan et d'afficher toutes les applications avec des services de premier plan actifs, ainsi que la durée de chacun de ces services depuis son lancement, comme décrit dans le document du SDK.
  • Certaines applications PEUVENT être exemptées d'être arrêtées ou répertoriées dans une telle affordance utilisateur, comme décrit dans le document relatif au SDK.

Modèle de sécurité

Implémentations pour les appareils portables:

• [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 à l'utilisateur pour accorder ou révoquer l'accès à ces applications en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

Implémentations pour les appareils portables:

• [9.11/H-0-2] DOIT sauvegarder la mise en œuvre du keystore dans un environnement d'exécution isolé.
• [9.11/H-0-3] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que de fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. 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 vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [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 réussite. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/H-0-5] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareil. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente peut être utilisée pour chaque tranche de 100 000 unités.
• [9/H-0-1] DOIT déclarer la fonctionnalité "android.hardware.security.model.compatible".

Notez que si l'implémentation d'un appareil est déjà lancée sur une version antérieure d'Android, cet appareil n'est pas tenu de disposer d'un keystore sauvegardé par un environnement d'exécution isolé et de prendre en charge l'attestation des clés, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore reposant sur 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 entre l'état déverrouillé et l'état verrouillé, de 15 secondes ou moins.
• [9.11/H-1-2] DOIT fournir une affordance à l'utilisateur pour masquer les notifications et désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans la section 9.11.1 Sécuriser l'écran de verrouillage. L’AOSP répond à l’exigence du mode verrouillé.

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 prendre en charge les profils restreints, une fonctionnalité qui permet aux propriétaires d'un appareil de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs pourront travailler, tout en ayant la possibilité de 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 être compatible avec les profils restreints, mais DOIT s'aligner sur la mise en œuvre AOSP des contrôles permettant d'autoriser ou de désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

Android, via l'API système, VoiceInteractionService prend en charge un mécanisme de détection sécurisée et permanente des mots clés sans indication d'accès au micro.

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 mots clés ne peut transmettre des données qu'au service System ou ContentCaptureService
• [9.8/H-1-2] DOIT s'assurer que le service de détection de mots clés ne peut transmettre que des données audio du micro ou des données dérivées de celui-ci au serveur système via l'API HotwordDetectionService, ou à ContentCaptureService via l'API ContentCaptureManager.
• [9.8/H-1-3] NE DOIT PAS fournir un contenu audio de plus de 30 secondes au micro pour une requête individuelle déclenchée par le matériel au service de détection de mots clés.
• [9.8/H-1-4] NE DOIT PAS fournir de micro mis en mémoire tampon de plus de huit secondes pour une requête individuelle adressée au service de détection de mots clés.
• [9.8/H-1-5] NE DOIT PAS fournir de micro en mémoire tampon de plus de 30 secondes au service d'interaction vocale ou à une entité similaire.
• [9.8/H-1-6] NE DOIT PAS autoriser la transmission de plus de 100 octets de données non audio depuis le service de détection de mots clés pour chaque résultat de mot clé réussi.
• [9.8/H-1-7] NE DOIT PAS permettre la transmission de plus de cinq bits de données en dehors du service de détection de mots clés pour chaque résultat de mot clé négatif.
• [9.8/H-1-8] NE DOIT autoriser la transmission de données en dehors du service de détection de mots clés que lors d'une requête de validation de mot clé envoyée par le serveur système.
• [9.8/H-1-9] NE DOIT PAS permettre à une application installable par l'utilisateur de fournir le service de détection de mots clés.
• [9.8/H-1-10] NE DOIT PAS faire apparaître dans les données quantitatives de l'interface utilisateur des données quantitatives sur l'utilisation du micro par le service de détection de mots clés.
• [9.8/H-1-11] DOIT consigner le nombre d'octets inclus dans chaque transmission par le service de détection de mots clés afin de permettre aux chercheurs en sécurité de l'inspecter.
• [9.8/H-1-12] DOIT être compatible avec un mode de débogage qui enregistre le contenu brut de chaque transmission provenant du service de détection de mots clés afin de 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-SR-1] Il est FORTEMENT RECOMMANDÉ d'avertir les utilisateurs avant de définir une application comme fournisseur du service de détection de mots clés.
• [9.8/H-SR-2] Sont FORTEMENT RECOMMANDÉS pour interdire la transmission de données non structurées en dehors du service de détection de mots clés.
• [9.8/H-SR-3] Il est FORTEMENT RECOMMANDÉ de redémarrer le processus hébergeant le service de détection de mots clés au moins une fois par heure ou tous les 30 événements déclenchés par le matériel, selon la première échéance atteinte.

Si les implémentations d'appareils incluent une application qui utilise l'API système HotwordDetectionService ou un mécanisme similaire de détection de mot clé sans indication d'utilisation du micro, l'application:

• [9.8/H-2-1] DOIT fournir une notification explicite à l'utilisateur pour chaque expression composée de mots clés acceptée.
• [9.8/H-2-2] NE DOIT PAS préserver les données audio brutes, ni les données qui en sont dérivées, via le service de détection de mots clés.
• [9.8/H-2-3] NE DOIT PAS transmettre à partir du service de détection de mots clés, de données audio, de données pouvant être utilisées pour reconstruire (entièrement ou partiellement) l'audio ou les contenus audio sans rapport avec le mot clé lui-même, à l'exception du ContentCaptureService.

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

• [9.8.2/H-4-1] DOIT afficher l'indicateur de micro lorsqu'une application accède aux données audio du micro, mais pas lorsqu'il n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD ou ContentCaptureService,ou par des applications détenant les rôles décrits 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 que renvoyée par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont 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'appareil photo lorsqu'une application accède aux données en direct de l'appareil photo, mais pas lorsqu'elle n'est accessible que par une ou plusieurs applications détenant les rôles décrits 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 comme renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.

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

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

• [6.1/H-0-1]* DOIT prendre en charge la commande shell cmd testharness.

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

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

2.2.7. Classe de performance des médias portables

Consultez la section 7.11 pour la définition de la classe de performance multimédia.

Contenus multimédias

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• DOIT respecter les exigences multimédias répertoriées dans la section 2.2.7.1 du CDD Android 12.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matérielle pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
• [5.1/H-1-3] DOIT annoncer 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().
• [5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à une résolution de 1080p à 30 FPS.
• [5.1/H-1-5] DOIT annoncer le nombre maximal de sessions d'encodeur et 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().
• [5.1/H-1-6] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle et de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
• [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session d'encodage vidéo de 1080p ou moins pour tous les encodeurs vidéo matériels en charge. Ici, la charge désigne une session simultanée de transcodage vidéo de 1080p à 720p qui utilise des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
• [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session d'encodage audio de 128 kbit/s ou un débit inférieur pour tous les encodeurs audio en charge. La charge ici est définie comme une session simultanée de transcodage vidéo 1080p à 720p en utilisant des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p.
• [5.1/H-1-9] DOIT prendre en charge deux instances de sessions de décodeur vidéo matérielle sécurisées (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
• [5.1/H-1-10] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel non sécurisées avec une instance de session de décodeur vidéo matérielle sécurisée (4 instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à une résolution de 1080p à 30 FPS.
• [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 de l'appareil.
• [5.1/H-1-12] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session de décodage vidéo de 1080p ou moins pour tous les décodeurs vidéo matériels en charge. La charge ici est définie comme une session simultanée de transcodage vidéo de 1080p à 720p effectuée à l'aide de codecs vidéo matériels et de l'initialisation de la lecture audio/vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.
• [5.1/H-1-13] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session de décodage audio de 128 kbit/s ou un débit inférieur pour tous les décodeurs audio en charge. Cette charge désigne une session simultanée de transcodage vidéo de 1080p à 720p utilisant des codecs vidéo matériels et l'initialisation de la lecture audio/vidéo 1080p.
• [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Main 10, niveau 4.1.
• [5.1/H-SR-1] Il est VIVEMENT RECOMMANDÉ de prendre en charge Film Grain pour le décodeur matériel AV1.
• [5.1/H-1-15] DOIT disposer d'au moins un décodeur vidéo matériel compatible avec la résolution 4K60.
• [5.1/H-1-16] DOIT disposer d'au moins un encodeur vidéo matériel compatible avec la résolution 4K60.
• [5.3/H-1-1] NE DOIT PAS supprimer plus d'une image en 10 secondes (c'est-à-dire une perte de frames inférieure à 0,167 %) pour une session vidéo 1080p à 60 FPS en charge. La charge désigne une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC de 128 kbit/s.
• [5.3/H-1-2] NE DOIT PAS supprimer plus d'une image en 10 secondes lors d'un changement de résolution vidéo au cours d'une session vidéo de 60 FPS soumise à une charge élevée. La charge correspond à une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels et à une lecture audio AAC à 128 kbit/s.
• [5.6/H-1-1] DOIT avoir une latence tap-to-ton de 80 millisecondes ou moins à l'aide du test tap-to-tone OboeTester ou CTS Verifier.
• [5.6/H-1-2] DOIT avoir une latence audio aller-retour de 80 millisecondes ou moins sur au moins un chemin de données compatible.
• [5.6/H-1-3] DOIT prendre en charge l'audio >=24 bits pour une sortie stéréo sur des connecteurs audio 3,5 mm si elle est présente, et via l'audio USB si elle est prise en charge via l'intégralité du chemin de données pour une faible latence et des configurations de streaming. Pour la configuration à faible latence, AAudio doit être utilisé par l'application en mode de rappel à faible latence. Pour la configuration du streaming, une piste audio Java doit être utilisée par l'application. Dans les configurations à faible latence et en streaming, le récepteur de sortie HAL doit accepter AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT pour son format de sortie cible.
• [5.6/H-1-4] DOIT prendre en charge les appareils audio USB à 4 canaux ou plus (utilisé par les manettes de DJ pour la prévisualisation des titres).
• [5.6/H-1-5] DOIT prendre en charge les appareils MIDI conformes aux classes et déclarer l'indicateur de fonctionnalité MIDI.
• [5.7/H-1-2] DOIT prendre en charge MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL avec les fonctionnalités de déchiffrement de contenu ci-dessous.

Taille d'échantillon minimale	4 Mio
Nombre minimal de sous-échantillons – H264 ou HEVC	32
Nombre minimal de sous-échantillons – VP9	9
Nombre minimal de sous-échantillons – AV1	288
Taille minimale de la mémoire tampon du sous-échantillon	1 Mio
Taille minimale de la mémoire tampon cryptographique générique	500 Kio
Nombre minimal de sessions simultanées	30
Nombre minimal de clés par session	20
Nombre total minimal de clés (toutes les sessions)	80
Minimum Total Number of DRM Keys (toutes les sessions)	6
Taille du message	16 Kio
Frames déchiffrés par seconde	60 FPS

2.2.7.2. Appareil photo

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• DOIT respecter les exigences concernant l'appareil photo indiquées dans la section 2.2.7.2 du CDD Android 12.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution d'au moins 12 mégapixels permettant la capture vidéo à 4K à 30 images par seconde. La caméra arrière principale est celle qui possède l'ID d'appareil photo le plus bas.
• [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution d'au moins 5 mégapixels et prendre en charge la capture vidéo à 1080p à 30 images par seconde. La caméra frontale principale est celle qui possède l'ID d'appareil photo le plus bas.
• [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel avec une valeur FULL ou supérieure pour la caméra principale arrière et LIMITED ou supérieure pour la caméra principale avant.
• [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux caméras principales.
• [7.5/H-1-5] DOIT avoir une latence de capture JPEG de "camera2" inférieure à 1 000 ms pour une résolution de 1080p telle que mesurée par le test PerformanceTest de la caméra CTS dans des conditions d'éclairage SIT (3 000 K) pour les deux caméras principales.
• [7.5/H-1-6] DOIT avoir une latence de démarrage de l'appareil photo 2 (ouvrir la caméra à la première image d'aperçu) inférieure à 500 ms, telle que mesurée par le test PerformanceTest de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
• [7.5/H-1-8] DOIT prendre en charge CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW et android.graphics.ImageFormat.RAW_SENSOR pour la caméra arrière principale.
• [7.5/H-1-9] DOIT disposer d'une caméra principale arrière compatible avec les résolutions 720p ou 1080p à 240 FPS.
• [7.5/H-1-10] DOIT avoir une valeur ZOOM_RATIO inférieure à 1,0 pour les caméras principales si une caméra RVB ultra grand angle orientée dans la même direction.
• [7.5/H-1-11] DOIT implémenter une diffusion simultanée de flux avant arrière sur les caméras principales.
• [7.5/H-1-12] DOIT prendre en charge CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION pour la caméra arrière principale.
• [7.5/H-1-13] DOIT prendre en charge la fonctionnalité LOGICAL_MULTI_CAMERA pour la caméra arrière principale s'il existe plusieurs caméras RVB à l'arrière.
• [7.5/H-1-14] DOIT prendre en charge la fonctionnalité STREAM_USE_CASE pour la caméra avant principale et la caméra arrière principale.

Matériel

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• DOIT respecter la configuration matérielle requise indiquée dans la section 2.2.7.3 du CDD Android 12.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• [7.1.1.1/H-2-1] DOIT avoir une résolution d'écran d'au moins 1080p.
• [7.1.1.3/H-2-1] DOIT avoir une densité d'écran d'au moins 400 ppp.
• [7.6.1/H-2-1] DOIT disposer d'au moins 8 Go de mémoire physique.

Performances

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• DOIT répondre aux exigences de performances indiquées dans la section 2.2.7.4 du CDD Android 12.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• [8.2/H-1-1] DOIT garantir des performances d'écriture séquentielle d'au moins 125 Mo/s.
• [8.2/H-1-2] DOIT garantir des performances d'écriture aléatoire d'au moins 10 Mo/s.
• [8.2/H-1-3] DOIT garantir des performances de lecture séquentielle d'au moins 250 Mo/s.
• [8.2/H-1-4] DOIT garantir des performances de lecture aléatoire d'au moins 40 Mo/s.

2.3. Configuration requise pour la télévision

Un appareil de télévision Android fait référence à une implémentation d'appareil Android qui est une interface de divertissement permettant de lire des contenus multimédias numériques, des films, des jeux, des applications et/ou la télévision en direct pour des utilisateurs assis à environ trois mètres de distance (interface utilisateur de trois mètres).

Les implémentations d'appareils Android sont classées dans la catégorie "Téléviseur" 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, pouvant se trouver à trois mètres de l'utilisateur
• Disposer d'un écran intégré dont la diagonale est 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 décrites dans le reste de cette section sont spécifiques aux implémentations d'appareils Android Television.

Matériel

Implémentations pour les téléviseurs:

• [7.2.2/T-0-1] DOIT prendre en charge le pavé directionnel.
• [7.2.3/T-0-1] DOIT fournir les fonctions Accueil et Retour.
• [7.2.3/T-0-2] DOIT envoyer à la fois l'événement d'appui normal et l'événement d'appui prolongé de la fonction Retour (KEYCODE_BACK) à l'application de premier plan.
• [7.2.6.1/T-0-1] DOIT inclure la prise en charge des manettes de jeu et déclarer l'indicateur de fonctionnalité android.hardware.gamepad.
• [7.2.7/T] DEVRAIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder aux entrées de la navigation non tactile et des touches de navigation principales.

Si les téléviseurs sont équipés d'un gyroscope à trois axes:

• [7.3.4/T-1-1] DOIT pouvoir signaler des événements avec 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 pour les téléviseurs:

• [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 des applications (également appelée partition "/data").

Si les implémentations de téléviseurs incluent un port USB compatible avec le mode hôte, ils:

• [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 connectée.

Pour les téléviseurs 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 ppp ou plus sur les écrans de petite taille
  • xhdpi ou supérieur sur les grands écrans
  • tvdpi ou supérieur sur les très grands écrans

Pour les téléviseurs 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 ppp ou plus sur les écrans de petite taille
  • xhdpi ou supérieur sur les grands écrans
  • tvdpi ou supérieur sur les très grands écrans

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 contrôlés par le noyau sur les implémentations d'appareils.

Implémentations pour les téléviseurs:

• [7.8.1/T] DEVRAIT 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 de téléviseurs DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants et les mettre à la disposition d'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 à faible délai améliorés)

Les implémentations d'appareils de télévision DOIVENT accepter 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

Implémentations pour les téléviseurs:

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

Les implémentations de téléviseurs DOIVENT être compatibles avec 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] HEVC H.265
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

Les installations de télévision DOIVENT être compatibles avec le décodage MPEG-2, comme détaillé dans la section 5.3.1, pour des fréquences d'images et des résolutions vidéo standards allant jusqu'à:

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

Les installations de téléviseurs DOIVENT prendre en charge le décodage H.264, comme détaillé dans la section 5.3.4, pour les fréquences d'images et les résolutions vidéo standards jusqu'à:

• [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 le profil principal
• [5.3.4/T-1-3] HD 1080p à 60 images par seconde avec High Profile de 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 détaillé dans la section 5.3.5, avec des fréquences d'images et des résolutions vidéo standards allant jusqu'à:

• [5.3.5/T-1-1] HD 1080p à 60 images par seconde avec le 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 prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil de niveau principal "Main10" de niveau 5

Les téléviseurs DOIVENT être compatibles avec le décodage VP8, comme détaillé dans la section 5.3.6, pour des fréquences d'images et des résolutions vidéo standards allant jusqu'à:

• [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 détaillé dans la section 5.3.7, avec des fréquences d'images et des résolutions vidéo standards allant jusqu'à:

• [5.3.7/T-1-1] HD 1080p à 60 images par seconde avec 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 prendre en charge 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 pour les téléviseurs:

• [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 sortie audio numérique sur les sorties compatibles, à l'exception de la sortie audio compressée passthrough (où aucun décodage audio n'est effectué sur l'appareil).

Si les téléviseurs n'ont pas d'écran intégré, mais sont compatibles avec un écran externe connecté via HDMI, ils:

• [5.8/T-0-1] DOIT définir le mode de sortie HDMI de manière à sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou de 60 Hz.
• [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] DEVRAIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation de la vidéo pour la région dans laquelle l'appareil est vendu.

Si les téléviseurs n'ont pas d'écran intégré, mais sont compatibles avec un écran externe connecté via HDMI, ils:

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

Si les implémentations de téléviseurs ne prennent pas en charge le décodage UHD, mais acceptent un écran externe connecté via HDMI, elles:

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

Logiciels

Implémentations pour les téléviseurs:

• [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 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.
• [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 Television sont compatibles avec un écran de verrouillage,elles:

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

Implémentations pour les téléviseurs:

• [3.8.14/T-SR-1] EST VIVEMENT RECOMMANDÉ pour la compatibilité avec le mode 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 les services d'accessibilité sur l'appareil avec des fonctionnalités comparables ou supérieures aux services d'accessibilité Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) fournis dans le projet Open Source TalkBack.

Si les implémentations de téléviseurs signalent la fonctionnalité android.hardware.audio.output, elles:

• [3.11/T-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.
• [3.11/T-1-1] DOIT être compatible avec l'installation de moteurs de synthèse vocale tiers.

Implémentations pour les téléviseurs:

• [3.12/T-0-1] DOIT être compatible avec le framework d'entrée TV.

Performances et puissance

• [8.1/T-0-1] Latence cohérente des frames. Une latence de trame incohérente ou un délai d'affichage des cadres NE DOIT PAS se produire plus souvent que cinq images par seconde et DOIT être inférieures à une image par seconde.
• [8.2/T-0-1] DOIT garantir des performances 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 des performances de lecture séquentielle d'au moins 15 Mo/s.
• [8.2/T-0-4] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

Si les implémentations de téléviseurs incluent des fonctionnalités visant à améliorer la gestion de l'alimentation des appareils qui sont incluses dans AOSP ou à étendre les fonctionnalités incluses dans AOSP, elles:

• [8.3/T-1-1] DOIT fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.

Si les téléviseurs ne sont pas équipés d'une batterie:

• [8.3/T-1-2] DOIT enregistrer l'appareil en tant qu'appareil sans batterie, comme décrit dans la section Compatibilité avec les appareils sans batterie.

Si les téléviseurs sont équipés d'une batterie:

• [8.3/T-1-3] DOIT fournir une affordance utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Mise en veille des applications.

Implémentations pour les téléviseurs:

• [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie 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 indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [8.4/T] DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
• [8.4/T-0-4] DOIT rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats au développeur de l'application.

Modèle de sécurité

Implémentations pour les téléviseurs:

• [9.11/T-0-1] DOIT sauvegarder la mise en œuvre du keystore dans un environnement d'exécution isolé.
• [9.11/T-0-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. 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 vérifiée par un tiers d'une isolation appropriée basée sur l'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 réussite. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/T-0-4] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareil. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente peut être utilisée pour chaque tranche de 100 000 unités.
• [9/T-0-1] DOIT déclarer la fonctionnalité "android.hardware.security.model.compatible".

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

Si les téléviseurs sont compatibles avec un écran de verrouillage sécurisé, ils:

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

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

• [9.5/T-2-1] DOIT prendre en charge les profils restreints, une fonctionnalité qui permet aux propriétaires d'un appareil de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs pourront travailler, tout en ayant la possibilité de gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations de téléviseurs incluent plusieurs utilisateurs et déclarent le flag de fonctionnalité android.hardware.telephony, elles:

• [9.5/T-3-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur la mise en œuvre AOSP des contrôles permettant d'autoriser ou d'empêcher d'autres utilisateurs d'accéder aux appels vocaux et aux SMS.

Si les implémentations de téléviseurs 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 lorsqu'il n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou par des applications détenant les rôles décrits 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 ayant des interfaces utilisateur visibles ou une interaction directe de l'utilisateur.

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

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

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

Implémentations pour les téléviseurs:

• Perfetto
  • [6.1/T-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur de shell dont la cmdline est conforme à la documentation de Perfetto.
  • [6.1/T-0-2] Le binaire Perfetto DOIT accepter en entrée une configuration de tampon de protocole conforme au schéma défini dans la documentation de Perfetto.
  • [6.1/T-0-3] Le binaire Perfetto DOIT écrire en sortie une trace de tampon de protocole conforme au schéma défini dans la documentation de Perfetto.
  • [6.1/T-0-4] DOIT fournir, via le binaire Perfetto, au moins les sources de données décrites dans la documentation de Perfetto.

2.4. Configuration requise pour la montre

Une Android Watch est une implémentation d'appareil Android destinée à être portée sur le corps, éventuellement sur le poignet.

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

• La longueur de la diagonale physique doit être comprise entre 1,1 et 2,5 pouces.
• Prévoir un mécanisme pouvant être porté sur le corps.

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

Matériel

Implémentations sur les montres:

• [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 avoir la fonction Accueil et la fonction Retour, sauf si elle se trouve dans UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] DOIT être compatible avec la saisie tactile.

• [7.3.1/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à 3 axes.

Si les implémentations de montres incluent un récepteur GPS/GNSS et signalent la capacité aux applications via l'indicateur 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 une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/W-1-2] DOIT indiquer les pseudo-plages GNSS et les taux de pseudo-plages GNSS, qui, dans des conditions de ciel ouvert après avoir déterminé la position, sont suffisants pour calculer la position à 20 mètres par seconde au carré, tout en se déplaçant à moins de 0,2 mètre par seconde au carré d'accélération, et à 0,2 mètre par seconde au moins à 9,5% du temps dans des conditions de ciel ouvert.

Si les implémentations de montres incluent un gyroscope à 3 axes, elles:

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

Implémentations sur les montres:

• [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 des applications (également appelée 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.

Multimédia

Aucune exigence supplémentaire.

Logiciels

Implémentations sur les montres:

• [3/W-0-1] DOIT déclarer la fonctionnalité android.hardware.type.watch.
• [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] DOIT précharger au moins une application ou un composant de service avec un gestionnaire d'intent pour tous les modèles de filtre d'intent public définis par les intents d'application suivants, listés ici.

Implémentations sur les montres:

• [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.

Les implémentations d'appareils qui déclarent l'indicateur de fonctionnalité android.hardware.audio.output:

• [3.10/W-1-1] DOIT prendre en charge 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 dépassant les fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source TalkBack.

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

• [3.11/W-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur TTS compatible avec les langues disponibles sur l'appareil.

• [3.11/W-0-1] DOIT être compatible avec l'installation de moteurs de synthèse vocale tiers.

Performances et puissance

Si les implémentations d'appareils de la montre incluent des fonctionnalités visant à améliorer la gestion de l'alimentation de l'appareil incluses dans AOSP ou à étendre les fonctionnalités incluses dans AOSP, elles:

• [8.3/W-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes d'économie d'énergie et de mise en veille des applications.
• [8.3/W-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir à l'utilisateur l' affordance d'activer et de désactiver l'économiseur de batterie.

Implémentations sur les montres:

• [8.4/W-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [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 indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [8.4/W-0-4] DOIT rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats au développeur de l'application.
• [8.4/W] DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.

Modèle de sécurité

Implémentations sur les montres:

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

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

• [9.5/W-1-1] DOIT être compatible avec les profils restreints, une fonctionnalité qui permet aux propriétaires d'un appareil de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs pourront travailler, tout en ayant la possibilité de gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

Si les implémentations d'appareils de la montre incluent plusieurs utilisateurs et déclarent le flag 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 la mise en œuvre AOSP des contrôles permettant d'autoriser ou de désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

2.5. Exigences concernant l'automobile

L'implémentation Android Automotive fait référence à l'unité principale d'un véhicule exécutant Android en tant que système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'infoloisirs.

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

• s'intègrent dans un véhicule automobile ou peuvent y être branchés ;
• utilisent un écran situé sur le 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.

Matériel

Implémentations pour les appareils automobiles:

• [7.1.1.1/A-0-1] DOIT avoir un écran d'au moins 6 pouces en 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.2.3/A-0-1] DOIT fournir la fonction Home et PEUT fournir les fonctions "Retour" et "Récents".

• [7.2.3/A-0-2] DOIT envoyer à la fois l'événement d'appui normal et l'événement d'appui prolongé de la fonction Retour (KEYCODE_BACK) à l'application de 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 de l'indicateur 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 un champ d'informations supplémentaires sur le capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.

• [7.3/A-SR1] PEUT reconnaître la localisation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la localisation est désactivée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs correspondants et/ou les ID de propriété de véhicule utilisés.

• [7.3/A-0-4] L'élément Location demandé via LocationManager#requestLocationUpdates() NE DOIT PAS être mis en correspondance sur la carte.

• [7.3.1/A-0-4] DOIT se conformer au système de coordonnées du capteur de voiture d'Android.

• [7.3/A-SR-1] Doivent considérablement inclure un accéléromètre à 3 axes et un gyroscope à 3 axes.

• [7.3/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_HEADING.

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 prendre en charge 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 un accéléromètre:

• [7.3.1/A-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 100 Hz.

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

• [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 à 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 Automotive incluent un gyroscope:

• [7.3.4/A-2-1] DOIT pouvoir signaler des événements avec 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 d'optimiser la résolution possible.

Si les implémentations d'appareils Automotive incluent un gyroscope à trois axes:

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

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

• [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 la connectivité de données basée sur le réseau mobile, celles-ci:

• [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 au moins quatre jours en 60 secondes.
• [7.3.3/A-3-2] DOIT respecter les critères de délai de première correction décrits dans les sections 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 effectuées depuis toujours ou après plus de quatre jours). La condition 7.3.3/C-1-2 est généralement remplie dans les véhicules sans connectivité de données basée sur le réseau cellulaire, à l'aide des prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule avec la possibilité de compter au moins 60 secondes avec une précision de position conforme à 7.3.3/C-1-3, ou une combinaison des deux.

Si les implémentations d'appareils automobiles incluent un capteur TYPE_HEADING, celles-ci:

• [7.3.4/A-4-3] DOIT pouvoir signaler des événements avec une fréquence d'au moins 1 Hz.
• [7.3.4/A-SR-3] StrongLY_RECOMMENDED pour signaler les événements avec une fréquence d'au moins 10 Hz.
• DEVRAIT faire référence au nord géographique.
• DEVRAIT être disponible même lorsque le véhicule est immobile.
• DEVRAIT avoir une résolution d'au moins 1 degré.

Implémentations pour les appareils automobiles:

• [7.4.3/A-0-1] DOIT être compatible avec Bluetooth et Bluetooth LE.
• [7.4.3/A-0-2] Les implémentations d'Android Automotive DOIVENT prendre en charge les profils Bluetooth suivants :
  • Appels téléphoniques via un profil mains libres (HFP).
  • Lecture de contenus multimédias via un profil de distribution audio (A2DP).
  • Contrôle de la lecture multimédia via le profil de contrôle à distance (AVRCP).
  • Partage des contacts à l'aide du profil d'accès au répertoire téléphonique (PBAP)

• [7.4.3/A-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge le profil d'accès aux messages (MAP).

• [7.4.5/A] DEVRAIT inclure la prise en charge de la connectivité de 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 système pour les réseaux qui devraient être disponibles pour les applications système.

Une caméra de l'extérieur est une caméra qui capture les scènes en dehors de l'implémentation de l'appareil, comme la caméra de recul.

Implémentations pour les appareils automobiles:

• DEVRAIT inclure une ou plusieurs caméras de vue extérieure.

Si les implémentations d'appareils automobiles incluent une caméra offrant une vue extérieure, celles-ci:

• [7.5/A-1-1] NE DOIT PAS avoir de caméras extérieures accessibles via les API Android Camera, sauf si elles respectent les exigences principales relatives aux caméras.

• [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter l'aperçu de l'appareil photo ni le mettre en miroir horizontalement.

• [7.5/A-SR-2] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'au moins 1,3 mégapixel.

• DEVRAIT être équipé d'un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).

• Un autofocus matériel ou logiciel peut être implémenté dans le pilote de l'appareil photo.

Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras offrant une vue extérieure et chargent le service EVS (Exterior View System), alors pour ce type de caméra:

• [7.5/A-2-1] NE DOIT PAS pivoter ni dupliquer horizontalement l'aperçu de l'appareil photo.

Implémentations pour les appareils automobiles:

• PEUT inclure une ou plusieurs caméras disponibles pour des applications tierces.

Si les implémentations d'appareils automobiles incluent au moins une caméra et la mettent à la disposition des applications tierces:

• [7.5/A-3-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any.
• [7.5/A-3-2] NE DOIT PAS déclarer la caméra en tant que caméra système.
• PEUVENT être compatibles avec les caméras externes décrites dans la section 7.5.3.
• PEUT inclure des fonctionnalités (telles que l'autofocus, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Implémentations pour les 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 des applications (également appelée partition "/data").

• [7.6.1/A] DEVRAIT formater la partition de données pour améliorer les performances et la longévité sur le stockage Flash, par exemple en utilisant le système de fichiers f2fs.

Si les implémentations d'appareils Android Automotive fournissent un espace de stockage externe partagé via une partie de la mémoire de stockage interne non amovible:

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

Si les implémentations d'appareils Automotive sont 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 si l'une des densités suivantes est utilisée:

  • 280 ppp ou moins sur les écrans de petite taille
  • ldpi ou inférieur sur les très grands écrans
  • mdpi ou inférieur 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 si l'une des densités suivantes est utilisée:

  • xhdpi ou supérieur sur les écrans de petite taille/normal
  • hdpi ou supérieur sur les grands écrans
  • mdpi ou supérieur sur les très grands écrans

• [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 si l'une des densités suivantes est utilisée:

  • 400 ppp ou plus sur les écrans de petite taille
  • xhdpi ou supérieur sur les grands écrans
  • tvdpi ou supérieur sur les très grands écrans

• [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 si l'une des densités suivantes est utilisée:

  • 560 ppp ou plus sur les écrans de petite taille ou de taille normale
  • 400 ppp ou plus sur les grands écrans
  • xhdpi ou supérieur sur les très grands écrans

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 contrôlés par le noyau sur les implémentations d'appareils.

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

2.5.2. Multimédia

Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants et les mettre à la disposition d'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 à faible délai améliorés)

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

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

Les implémentations d'appareils automobiles DOIVENT prendre en charge les formats de décodage vidéo suivants et les mettre à la disposition d'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

Les implémentations d'appareils automobiles sont FORTEMENT RECOMMANDÉES pour permettre le décodage vidéo suivant:

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

Logiciels

Implémentations pour les appareils automobiles:

• [3/A-0-1] DOIT déclarer la fonctionnalité android.hardware.type.automotive.

• [3/A-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_CAR.

• [3/A-0-3] DOIT prendre en charge toutes les API publiques de l'espace de noms android.car.*.

Si les implémentations d'appareils Automotive fournissent une API propriétaire utilisant android.car.CarPropertyManager avec android.car.VehiclePropertyIds, elles:

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

Implémentations pour les appareils automobiles:

• [3.2.1/A-0-1] DOIT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence des autorisations automobiles.

• [3.2.3.1/A-0-1] 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.

• [3.4.1/A-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

• [3.8.3/A-0-1] DOIT afficher des 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 afin de gérer l'action d'assistance.

Si les implémentations d'appareils automobiles incluent un bouton Appuyer pour parler:

• [3.8.4/A-1-1] DOIT utiliser un appui court 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 pour les 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 "PLAY" et "MUTE" pour les actions de notification à la place de celles fournies via Notification.Builder.addAction()
• [3.8.3.1/A] DEVRAIT limiter l'utilisation de tâches de gestion enrichies telles que les commandes par canal de notification. PEUT utiliser l' 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 HAL de l'utilisateur, elles:

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

Implémentations pour les appareils automobiles:

• [3.14/A-0-1] DOIT inclure un framework d'interface utilisateur pour prendre en charge les applications tierces utilisant les API multimédias, 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 DOIT l'activer uniquement lorsque les restrictions liées à l'expérience utilisateur pour les voitures 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 extras facultatifs ERROR_RESOLUTION_ACTION_LABEL et ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DOIT prendre en charge une affordance de recherche dans l'application pour les applications compatibles.
• [3.14/A-0-7] DOIT respecter les définitions CONTENT_STYLE_BROWSABLE_HINT et CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de la hiérarchie MediaBrowser.

Si les implémentations d'appareils Automotive incluent un lanceur d'applications par défaut, celles-ci:

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

Implémentations pour les appareils automobiles:

• [3.8/A] PEUT restreindre 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 restreindre les requêtes de l'application concernant la modification des couleurs derrière les éléments de l'interface utilisateur du système, afin de s'assurer que ces éléments sont clairement visibles à tout moment.

Performances et puissance

Implémentations pour les appareils automobiles:

• [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans un espace de stockage non volatile pour chaque UID de chaque processus, afin que les statistiques soient accessibles aux développeurs via l'API System android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence via le module de noyau uid_sys_stats.
• [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 dans les cas suivants :
  • 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 d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [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 indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [8.4/A] DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
• [8.4/A-0-4] DOIT rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats au développeur de l'application.

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 permettre aux utilisateurs d'interagir avec l'utilisateur système sans adresse IP de cluster ni de passer à l'utilisateur système headless, sauf pour le provisionnement des appareils.
• [9.5/A-1-2] DOIT passer en utilisateur secondaire avant BOOT_COMPLETED.
• [9.5/A-1-3] DOIT prendre en charge la création d'un utilisateur invité, même lorsque le nombre maximal d'utilisateurs sur un appareil a été atteint.

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

• [9.8.2/A-2-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'une application accède aux données en direct de l'appareil photo, mais pas lorsqu'elle n'est accessible que par une ou plusieurs applications détenant les rôles décrits dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
• [9.8.2/A-2-2] NE DOIT pas masquer l'indicateur d'appareil photo pour les applications système ayant des interfaces utilisateur visibles ou une interaction directe de l'utilisateur.

Implémentations pour les appareils automobiles:

• [9.11/A-0-1] DOIT sauvegarder la mise en œuvre du keystore dans un environnement d'exécution isolé.
• [9.11/A-0-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que de fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. 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 vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [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 réussite. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/A-0-4] DOIT prendre en charge l'attestation des clés lorsque celle-ci est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareil. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente peut être utilisée pour chaque tranche de 100 000 unités.
• [9/A-0-1] DOIT déclarer la fonctionnalité "android.hardware.security.model.compatible".

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

Implémentations pour les appareils automobiles:

• [9.14/A-0-1] DOIT contrôler les messages provenant de sous-systèmes de véhicule du framework Android, par exemple, listes d'autorisation des types et sources de messages autorisés.
• [9.14/A-0-2] DOIT surveiller une surveillance contre les attaques par déni de service à partir du framework Android ou d'applications tierces. Cela protège 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 des véhicules.

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

Implémentations pour les appareils automobiles:

• Perfetto
  • [6.1/A-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur de shell dont la cmdline est conforme à la documentation de Perfetto.
  • [6.1/A-0-2] Le binaire Perfetto DOIT accepter en entrée une configuration de tampon de protocole conforme au schéma défini dans la documentation de Perfetto.
  • [6.1/A-0-3] Le binaire Perfetto DOIT écrire en sortie une trace de tampon de protocole conforme au schéma défini dans la documentation de Perfetto.
  • [6.1/A-0-4] DOIT fournir, via le binaire Perfetto, au moins les sources de données décrites dans la documentation de Perfetto.

2.6. Configuration requise pour les tablettes

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

• Utilisé en tenant l'appareil dans les deux mains.
• Elle ne dispose pas d'un ordinateur à clapet ni d'une configuration convertible.
• Les implémentations de clavier physique utilisées avec l'appareil se connectent à l'aide d'une connexion standard (par exemple, USB ou Bluetooth).
• dispose d'une source d'alimentation qui permet de la mobilité, telle qu'une batterie ;
• La taille de l'écran est supérieure à 7 pouces et inférieure à 18 pouces en diagonale.

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

Matériel

Gyroscope

Si les implémentations de tablettes comprennent un gyroscope à 3 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 minimaux (section 7.6.1)

Les densités d'écran indiquées pour les écrans de petite taille ou de taille normale dans les exigences concernant les appareils portables ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

Si les implémentations de tablettes incluent un port USB compatible avec le mode périphérique, celles-ci:

• [7.7.1/Tab] PEUT implémenter l'API Android Open Accessory (AOA).

Mode de réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences concernant la 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 des tablettes incluent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony, elles:

• [9.5/T-1-1] DOIT être compatible avec les profils restreints, une fonctionnalité qui permet aux propriétaires d'un appareil de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs pourront travailler, tout en ayant la possibilité de gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

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

• [9.5/T-2-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur la mise en œuvre AOSP des contrôles permettant d'autoriser ou d'empêcher d'autres utilisateurs d'accéder aux appels vocaux et aux SMS.

2.6.2. Logiciels

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

3. Logiciels

3.1. Compatibilité des API gérées

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

Implémentations pour 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 du marqueur "@SystemApi" dans le code source Android en amont.

• [C-0-2] DOIT prendre en charge et préserver l'ensemble des 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 des API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par la présente définition de compatibilité.

• [C-0-4] DOIT maintenir les API présentes et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. Consultez la section 7 pour connaître les exigences spécifiques à ce scénario.

• [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 classpath de démarrage d'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 des classes privées et package-private.

• [C-0-6] DOIT être envoyé avec chaque interface non SDK sur les mêmes listes limitées que celles fournies via les indicateurs provisoires et de liste de blocage dans le chemin prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche de niveau d'API appropriée dans l'AOSP.

• [C-0-7] DOIT prendre en charge 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.

  Cependant, ils:

  • PEUT-ÊTRE, si une API masquée est absente ou implémentée différemment sur l'appareil, déplacez-la dans la liste de blocage ou omettez-la de toutes les listes restreintes.
  • PEUT-ÊTRE, si une API masquée n'existe pas déjà dans l'AOSP, ajoutez-la à l'une des listes restreintes.

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 d'extension du apiLevel fourni, s'il existe des extensions pour ce niveau d'API.

Implémentations pour les appareils Android:

• [C-0-1] DOIT précharger la mise en œuvre AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales au nombre minimal de versions autorisé pour chaque niveau d'API. Par exemple, pour les implémentations d'appareils Android 7.0, l'exécution du niveau d'API 24 DOIT inclure au moins la version 1.

• [C-0-2] DOIT renvoyer uniquement un numéro de version d'extension valide qui a été défini par l'AOSP.

• [C-0-3] DOIT prendre en charge 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 paramètre bootclasspath.
• [C-0-2] DOIT ajouter la bibliothèque org.apache.http.legacy au chemin de classe 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'il a besoin de la bibliothèque en définissant l'attribut android:name de <uses-library> sur org.apache.http.legacy.

La mise en œuvre d'AOSP répond à ces exigences.

3.2. Compatibilité avec les API soft

En plus des API gérées de la section 3.1, Android inclut également une API "soft" significative uniquement à l'environnement d'exécution, sous la forme d'éléments tels que des intents, des autorisations et des 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 responsables de la mise en œuvre d'appareils DOIVENT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence des autorisations. Notez que la section 9 répertorie les exigences supplémentaires liées au modèle de sécurité Android.

3.2.2. Paramètres de compilation

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

• [C-0-1] Pour fournir des valeurs cohérentes et significatives entre les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs que les implémentations d'appareils DOIVENT respecter.

Paramètre	Détails
VERSION.VERSION	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 13.
VERSION.SDK	Version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 13, ce champ DOIT contenir la valeur entière 13_INT.
VERSION.SDK_INT	Version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 13, ce champ DOIT contenir la valeur entière 13_INT.
VERSION SUPPLÉMENTAIRE	Valeur choisie par l'outil d'implémentation de l'appareil qui désigne le build spécifique du système Android en cours d'exécution, dans un format lisible par l'humain. Cette valeur NE DOIT PAS être réutilisée pour différentes compilations mises à la disposition des utilisateurs finaux. Ce champ est généralement utilisé pour indiquer le numéro de build ou l'identifiant de modification de contrôle de source utilisé pour générer la compilation. La valeur de ce champ DOIT être encodable au format ASCII 7 bits imprimable et correspondre à l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ	Valeur choisie par l'outil de mise en œuvre de l'appareil identifiant le matériel interne spécifique utilisé par l'appareil, dans un format lisible par l'humain. Ce champ peut éventuellement servir à indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE	Valeur reflétant la marque associée à l'appareil, telle que connue des utilisateurs finaux. DOIT être dans un format lisible et 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 être encodable au format 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 d'ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives
ABI_PRIS EN CHARGE_32_BIT	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives
SUPPORTED_64_BIT_ABIS	Nom du deuxième ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité des API natives
ABI_CPU	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité avec les API natives
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité des API natives
APPAREIL	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du 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 être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom d'appareil NE DOIT PAS changer pendant la durée de vie du produit.
Empreinte	Chaîne qui identifie cette compilation de manière unique. Il DOIT être raisonnablement lisible par l'humain. Il DOIT suivre ce modèle: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Par exemple : acme/myproduct/ mydevice:13/LMYXX/3359:userdebug/test-keys L'empreinte NE DOIT PAS inclure d'espaces blancs. La valeur de ce champ DOIT être encodable au format ASCII 7 bits.
MATÉRIEL	Nom du matériel (depuis la ligne de commande du noyau ou /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
HÉBERGEUR	Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans un format lisible par l'humain. Il n'existe 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 le responsable de la mise en œuvre de l'appareil pour faire référence à une version spécifique, dans un format lisible. 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 au format 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'existe aucune exigence concernant le format spécifique de ce champ, sauf 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.
FABRICANT_DE_SOC	Nom commercial du fabricant du système sur puce (SOC) principal utilisé dans le produit. Les appareils appartenant au même fabricant de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant de votre SOC la constante à utiliser. La valeur de ce champ DOIT être encodable au format 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 à "inconnu". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE SOC	Nom de modèle du système principal sur une puce (SOC) utilisé dans le produit. Les appareils ayant le même modèle de SOC doivent utiliser la même valeur constante. Demandez au fabricant de votre SOC la constante à utiliser. La valeur de ce champ DOIT être encodable en tant que code ASCII 7 bits et 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 à "inconnu". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom de l'appareil connu de l'utilisateur final. Ce nom DOIT être identique au nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf 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.
PRODUIT	Valeur choisie par l'outil de mise en œuvre 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 l'humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom de produit NE DOIT PAS changer pendant sa durée de vie.
SKU_ODM	Valeur facultative choisie par le responsable de la mise en œuvre de l'appareil qui contient le SKU (Stock Keeping Unit, unité de gestion des stocks) utilisée pour suivre des configurations spécifiques de l'appareil (par exemple, tous les périphériques inclus avec l'appareil lorsqu'il est vendu). La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "[0-9A-Za-z.,_-])
SÉRIE	DOIT renvoyer la valeur "UNKNOWN".
TAGS	Liste de tags séparés par une virgule, choisis par l'outil de mise en œuvre de l'appareil, qui permettent de distinguer davantage le build. Les tags DOIVENT être encodables au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+" et DOIVENT comporter l'une des valeurs correspondant aux trois configurations de signature typiques de la plate-forme Android : "release-keys", "dev-keys" et "test-keys".
DURÉE	Valeur représentant l'horodatage du moment où la compilation s'est produite.
MACH	Valeur choisie par l'outil de mise en œuvre de l'appareil spécifiant la configuration d'exécution de la compilation. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'environnement d'exécution Android types: user, userdebug ou eng.
UTILISATEUR	Nom ou ID de l'utilisateur (ou de l'utilisateur automatisé) qui a généré la compilation. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
SÉCURITÉ_PATCH	Valeur indiquant le niveau du correctif de sécurité d'un build. Cela DOIT signifier que le build n'est aucunement vulnérable à l'un des problèmes décrits dans le bulletin de sécurité publique d'Android désigné. Il DOIT être au format [AAAA-MM-JJ] et correspondre à 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".
OS DE BASE	Valeur représentant le paramètre FINGERPRINT pour le build, qui est par ailleurs identique à celle-ci, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte et, si une telle compilation n'existe pas, signaler une chaîne vide ("").
CHARGEUR DE CHARGEMENT	Valeur choisie par l'équipe chargée de la mise en œuvre de l'appareil identifiant la version spécifique du bootloader interne utilisée dans l'appareil, dans un format lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DOIT (être ou renvoyer) une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l'appareil, dans un format lisible par l'humain. Si un appareil ne possède pas de radio/modem interne, il DOIT renvoyer la valeur NULL. La valeur de ce champ DOIT être encodable au format 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 sur tous les appareils ayant le même MODEL et le même MANUFACTURER. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9]+$".

Compatibilité des intents

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 pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent pour tous les modèles de filtre d'intent public définis par les intents d'application suivants, listés ici, et de fournir un traitement (c'est-à-dire répondre aux attentes du développeur 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.

Résolution d'intent

• [C-0-1] Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT permettre à chaque modèle d'intent référencé dans la section 3.2.3.1, à l'exception des paramètres, d'être remplacé par des applications tierces. L'implémentation Open Source d'Android en amont le permet par défaut.

• [C-0-2] Les responsables de la mise en œuvre d'appareils NE DOIVENT PAS accorder de droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de créer des liaisons avec ces modèles et d'en prendre le contrôle. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur du sélecteur, qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même schéma 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 des intents.

• Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des formats 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 schéma 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 d'association d'applications 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'appareils:

• [C-0-4] DOIT tenter de valider les filtres d'intent en effectuant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'elles ont été 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 avec succès en tant que gestionnaires d'application par défaut pour leurs URI.
• PEUT définir des filtres d'intent d'URI spécifiques en tant que gestionnaires d'application par défaut pour leurs URI s'ils ont été validés, mais que la validation d'autres filtres d'URI candidats échoue. Si une implémentation d'un appareil effectue cette opération, elle DOIT fournir les forçages de modèle par URI appropriés dans le menu des paramètres.
• DOIT fournir à l'utilisateur les commandes de liens vers une application par application dans les paramètres, comme suit :
  • [C-0-6] L'utilisateur DOIT pouvoir ignorer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours ouverte ou toujours ouverte, ce qui doit s'appliquer de la même manière à tous les filtres d'intent d'URI candidats.
  • [C-0-7] L'utilisateur DOIT pouvoir afficher la liste des filtres d'intent d'URI candidats.
  • L'implémentation de l'appareil PEUT donner à l'utilisateur la possibilité de remplacer des filtres d'intent d'URI candidats spécifiques qui ont été validés avec succès, pour chaque 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 vérification, tandis que d'autres peuvent échouer.

Espaces de noms des intents

• [C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte de nouveaux intents ou modèles d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORY ou d'une autre chaîne de 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 intents ou modèles d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORY ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation.
• [C-0-3] Les responsables de la mise en œuvre 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 utilisant des espaces de noms clairement et évidemment associés à leur propre organisation. Cette interdiction est semblable à celle spécifiée pour les classes de langage Java dans la section 3.6.

Intents de diffusion

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

Implémentations pour les appareils:

• [C-0-1] DOIT diffuser les intents de diffusion publique répertorié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 applicables aux applications en arrière-plan sont également décrites dans la documentation du SDK. En outre, certains intents de diffusion sont conditionnés à la compatibilité matérielle. Si l'appareil prend en charge le matériel nécessaire, il DOIT diffuser les intents et fournir le comportement conformément à la documentation du SDK.

Intents d'application conditionnels

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

Le cas échéant, 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écrits dans la documentation du SDK, comme ci-dessous.

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

• [C-1-1] DOIT respecter l'intent android.settings.HOME_SETTINGS pour 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 appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application SMS par défaut.

• [C-2-2] DOIT respecter l'intent android.telecom.action.CHANGE_DEFAULT_DIALER pour 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 utiliseront l'application Téléphone préinstallée.

• [C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour fournir une affordance à l'utilisateur afin de configurer l'ConnectionServices associé à PhoneAccounts, ainsi qu'un compte PhoneAccount par défaut que le fournisseur de services de télécommunications utilisera pour passer des appels sortants. L'implémentation d'AOSP répond à cette exigence en incluant un menu "Calling Accounts option" (Options de comptes téléphoniques) dans le menu des paramètres "Calls" (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 fournir à l'utilisateur l' affordance 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é permettant d'envoyer ou d'afficher des SMS.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de respecter 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 téléphonie préchargée capable de gérer ces intents et d'assurer le traitement.

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

• [C-3-1] DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS pour afficher un menu de paramètres par défaut de l'application 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 afin de demander à l'utilisateur de modifier le service d'émulation de carte par défaut pour une catégorie spécifique, 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 visible.

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

• [C-6-1] DOIT implémenter une activité qui répond à l'intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS. Pour les implémentations avec UI_MODE_TYPE_NORMAL, il DOIT s'agir d'une activité où l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de règles Ne pas déranger.

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

• [C-7-1] DOIT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des méthodes d'entrée tierces en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

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

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

Si les implémentations d'appareils sont compatibles avec Wi-Fi Easy Connect et exposent la fonctionnalité à des applications tierces, celles-ci:

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

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

• [C-10-1] DOIT fournir dans les paramètres une interface utilisateur qui gère l'intent 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 proposent pas le mode Économiseur de données:

• [C-11-1] DOIT avoir 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'appareils déclarent la prise en charge de la caméra via android.hardware.camera.any, elles:

• [C-12-3] DOIT gérer et NE DOIT autoriser que les applications Android préinstallées pour gérer les intents suivants : MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE et MediaStore.ACTION_VIDEO_CAPTURE, comme décrit dans le document du SDK.

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

• [C-13-1] DOIT respecter l'intent android.app.action.ADD_DEVICE_ADMIN pour appeler une interface utilisateur afin d'amener l'utilisateur à ajouter l'administrateur de l'appareil au système (ou à lui permettre de le rejeter).

• [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.STARTici_ENCRYPTION, et disposer d'une activité permettant de traiter ces intents dans le SDK.

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

• [C-14-1] DOIT implémenter intégralement les API AutofillService et AutofillManager, et respecter l'intent android.settings.REQUEST_SET_AUTOFILL_SERVICE afin d'afficher un menu de paramètres par défaut de l'application afin 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 si vous souhaitez autoriser des applications tierces à accéder aux statistiques d'utilisation:

• Les [C-SR-2] sont FORTEMENT RECOMMANDÉS fournissent un mécanisme accessible à l'utilisateur pour accorder ou révoquer l'accès aux statistiques 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 visent à empêcher des applications, y compris celles préinstallées, d'accéder aux statistiques d'utilisation:

• [C-15-1] DOIT toujours avoir 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 no-op, afin d'avoir un comportement équivalent à celui d'un refus d'accès de 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 un mécanisme similaire, les actions suivantes sont effectuées:

• [C-16-1] DOIT faire apparaître ces liens pour tous les services de saisie automatique installés.

• [C-17-1] [Déplacé vers la version 2.2.3]

Si les implémentations d'appareils sont compatibles avec VoiceInteractionService et que plusieurs applications utilisant cette API sont installées à la fois, elles:

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

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

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de respecter android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et android.speech.tts.engine.GET_ présente_TEXT une activité permettant de les exécuter, comme décrit dans le SDK.

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

• DEVRAIT inclure la prise en charge des économiseurs d'écran et fournir aux utilisateurs une option de paramétrage leur permettant de les configurer en réponse à l'intent android.settings.DREAM_SETTINGS.

Activités sur des écrans secondaires ou 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 l'indicateur 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é exécutée sur l'écran principal.
• [C-1-3] DOIT envoyer 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 l'indicateur 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'application active l'affichage en haut de l'écran de verrouillage à l'aide de l'API Activity#setShowWhenLocked().
• DEVRAIT avoir android.content.res.Configuration qui correspond à cet écran pour s'afficher, fonctionner correctement et maintenir la compatibilité si une activité est lancée sur l'écran secondaire.

Si les implémentations d'appareils autorisent le lancement d'activités Android normales sur des écrans secondaires et que celui-ci 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 qui y figurent DOIT pouvoir y être lancés. Tout le monde peut lancer un écran doté de l'indicateur android.view.Display.FLAG_PUBLIC.

3.3. Compatibilité avec les API natives

La compatibilité avec le code natif est complexe. Pour cette raison, les responsables de la mise en œuvre d'appareils sont les suivants:

• [C-SR-1] FORTEMENT RECOMMANDÉ d'utiliser les implémentations des bibliothèques listées ci-dessous 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 de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android.

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec une ou plusieurs ABI du NDK Android définies.
• [C-0-2] DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, à l'aide de la sémantique JNI (Java Native Interface) standard.
• [C-0-3] DOIT être compatible avec la source (c'est-à-dire avec les en-têtes) et 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 compatible avec 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, chacune sous la forme d'une liste d'ABI séparées par une virgule, classées de la plus à la moins préférée.

• [C-0-6] DOIT signaler, via les paramètres ci-dessus, un sous-ensemble de la liste d'ABI ci-dessous et NE DOIT PAS signaler d'ABI ne figurant pas sur cette liste.

  • armeabi (n'est plus pris en charge en tant que cible par le NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] DOIT mettre à la disposition des applications qui incluent du code natif toutes les bibliothèques suivantes, fournissant des API natives:

  • libaaudio.so (compatibilité native avec 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 (lien dynamique)
  • libEGL.so (gestion de la surface OpenGL native)
  • 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 de médias natifs)
  • libm (bibliothèque de mathématiques)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (compatible 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 de fonctions publiques pour les bibliothèques natives répertoriées ci-dessus.

• [C-0-9] DOIT répertorier des bibliothèques supplémentaires non-AOSP exposées directement à des 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, à des 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 Android Extension Pack, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que bien que tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit plus en détail les exigences liées à 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.0 principaux, 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 bien que tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences liées à l'implémentation complète de chaque fonction correspondante.

• DEVRAIT être créé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Android Open Source en amont.

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

3.3.2. Compatibilité avec le code natif ARM 32 bits

Si les implémentations d'appareils indiquent la prise en charge de l'ABI armeabi, elles:

• [C-3-1] DOIT également prendre en charge armeabi-v7a et signaler sa prise en charge, car armeabi n'est destiné qu'à la rétrocompatibilité avec les applications plus anciennes.

Si les implémentations d'appareils indiquent la prise en charge de l'ABI armeabi-v7a, les applications qui l'utilisent:

• [C-2-1] DOIT inclure les lignes suivantes dans /proc/cpuinfo et NE DEVRAIT PAS modifier les valeurs sur le même appareil, même lorsqu'elles sont lues par d'autres ABI.

  • Features:, suivi de la liste de toutes les fonctionnalités facultatives du processeur ARMv7 compatibles avec l'appareil.
  • CPU architecture:, suivi d'un entier décrivant l'architecture ARM la plus élevée compatible avec l'appareil (par exemple, "8" pour les appareils ARMv8).

• [C-2-2] DOIT toujours garder les opérations suivantes disponibles, même dans le cas où l'ABI est implémentée sur une architecture ARMv8, que ce soit via la compatibilité native du processeur ou via l'émulation logicielle:

  • Instructions SWP et SWPB
  • Opérations de barrières CP15ISB, CP15DSB et CP15DMB

• [C-2-3] DOIT inclure la compatibilité avec l'extension Advanced SIMD (également appelée NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

Si les implémentations d'appareils 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 version du projet Chromium du projet Android Open Source en amont sur la branche Android 13 pour l'implémentation de l'API android.webkit.WebView.

• [C-1-3] La chaîne user-agent signalée par la WebView 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 d'android.os.Build.VERSION.Release.
  • La chaîne $(MODEL) PEUT être vide, mais si elle n'est pas vide, elle DOIT avoir la même valeur qu'android.os.Build.MODEL.
  • "Build/$(Build)" PEUT être omis, mais si elle est présente, la chaîne $(Build) DOIT être identique à la valeur d'android.os.Build.ID.
  • La valeur de la chaîne $(CHROMIUM_VER) DOIT être la version de Chromium du projet Android Open Source en amont.
  • Il est possible que les implémentations d'appareils omettent "Mobile" dans la chaîne de l'agent utilisateur.

• Le composant WebView DOIT inclure un maximum de fonctionnalités HTML5 et, s'il est compatible, 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 moteur de rendu distinct DOIT détenir des privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, n'avoir aucun accès au répertoire de données de l'application, n'avoir aucun accès direct au réseau et n'avoir accès qu'aux services système minimaux requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

Notez que si les implémentations d'appareils sont 32 bits ou déclarent l'indicateur de fonctionnalité android.hardware.ram.low, elles sont exemptées de l'autorisation C-1-3.

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 suivantes associées à HTML5 :
  • Cache d'application/opération hors connexion
  • Balise <video>
  • géolocalisation
• [C-1-2] DOIT être compatible avec l'API WebStorage HTML5/W3C et l'API IndexedDB HTML5/W3C. Notez qu'à mesure que les organismes de normalisation pour le développement Web s'orientent vers le stockage Web, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.
• PEUT envoyer une chaîne user-agent personnalisée dans l'application de navigateur autonome.
• DEVRAIT mettre en œuvre la compatibilité avec un maximum de HTML5 sur l'application de navigateur autonome (que ce soit basé sur l'application de navigateur WebKit en amont ou sur un outil de remplacement tiers).

Toutefois, si les implémentations sur les appareils n'incluent pas d'application de navigateur autonome, celles-ci:

• [C-2-1] DOIT toujours prendre en charge les modèles d'intent public décrits dans la section 3.2.3.1.

3.5. Compatibilité comportementale de l'API

Implémentations pour les appareils:

• [C-0-9] DOIT s'assurer que la compatibilité de l'API est appliquée pour toutes les applications installées, sauf si celles-ci sont limitées comme décrit dans la section 3.5.1.
• [C-0-10] NE DOIT PAS implémenter l'approche d'ajout à la liste d'autorisation qui garantit la compatibilité comportementale de l'API uniquement pour les applications sélectionnées par les outils de mise en œuvre de l'appareil.

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 domaines de compatibilité spécifiques:

• [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
• [C-0-2] Les appareils NE DOIVENT PAS modifier la sémantique du cycle de vie ou du cycle de vie d'un type particulier de composant système (tel qu'un service, une activité, un 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 appliquées aux applications en arrière-plan. Plus précisément, pour les applications en arrière-plan :
  • [C-0-4], ils DOIVENT cesser d'exécuter des 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 broadcast receivers pour les diffusions implicites d'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 sur la liste d'exception.
  • [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT arrêter ses services en arrière-plan, comme si l'application avait appelé la méthode stopSelf() des services, sauf si l'application était 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 contient.
• [C-0-11] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants comme les sept premières valeurs de tableau de la méthode Security.getProviders(), dans l'ordre donné et avec les noms et classes 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 en fonction de la liste 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. AndroidKeyStoreBCSolution : 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 la compatibilité comportementale de parties importantes de la plate-forme, mais pas de toutes. Il est de la responsabilité de l'outil de mise en œuvre de veiller à la compatibilité du comportement avec le projet Android Open Source. Pour cette raison, dans la mesure du possible, les responsables de la mise en œuvre d'appareils DOIVENT utiliser le code source disponible via le projet Android Open Source plutôt que de réimplémenter des parties importantes du système.

3.5.1. Restriction d'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 limitées, elles:

• [C-1-1] DOIT autoriser l'utilisateur à voir la liste des applications soumises à restriction.
• [C-1-2] DOIT fournir une affordance à l'utilisateur pour 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 mauvais comportement en termes d'état du système, mais PEUT appliquer les restrictions des applications lors de la détection d'un mauvais comportement de l'état du système, comme les wakelocks figés, les services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les personnes chargées de la mise en œuvre des 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 uniquement 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 aux applications lorsqu'un utilisateur désactive 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 au cours de la période de 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 à partir d'une application.

• [C-1-7] NE DOIT PAS limiter l'application au premier plan qui est 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 la meilleure application de premier plan.

• [C-1-10] DOIT fournir un document ou un site Web public et clair décrivant la façon dont les restrictions propriétaires sont appliquées. Ce document ou ce site Web DOIT inclure les éléments suivants:

  • Conditions de déclenchement des restrictions propriétaires
  • les types de restrictions qui peuvent être appliqués à une application et de quelle manière ;
  • Les modalités d'exemption de ces restrictions pour une application
  • Manière dont une application peut demander une exemption des restrictions propriétaires si elle accepte ce type d'exception pour les applications que l'utilisateur peut installer.

Si une application est préinstallée sur l'appareil et qu'elle n'a jamais été explicitement utilisée par un utilisateur depuis plus de 30 jours, le [C-1-3] [C-1-5] en est exempté.

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

• [C-2-1]DOIT suivre la procédure d'implémentation décrite dans ce document.

3.5.2. Hibernation des applications

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

• [C-1-1] DOIT respecter toutes les exigences de la section 3.5.1, à l'exception de [C-1-6] et [C-1-3].
• [C-1-2] NE DOIT appliquer la restriction sur l'application à un utilisateur que s'il est évident que celui-ci ne s'est pas servi de l'application depuis un certain temps. Cette durée est FORTEMENT RECOMMANDÉE : elle est d'un mois ou plus. L'utilisation DOIT être définie par une interaction explicite de l'utilisateur via l'API UsageStats#getLastTimeVisible() ou par tout élément qui entraînerait un arrêt forcé d'une application, 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] NE DOIT appliquer des restrictions affectant tous les utilisateurs de l'appareil que s'il est avéré que le package n'a pas été utilisé par AUCUN utilisateur depuis un certain temps. Il est FORTEMENT RECOMMANDÉ de choisir une durée d'au moins un mois.
• [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 fournisseurs de contenu ou aux annonces explicites.

L'hibernation 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 des packages et des classes définies par le langage de programmation Java. Pour assurer la compatibilité avec les applications tierces, les développeurs d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) aux espaces de noms de ces packages:

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

En d'autres termes, ils:

• [C-0-1] NE DOIT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant des signatures de méthode ou de classe, 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 interfaces, ou des champs ou 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 repère "@hide" tel qu'il est utilisé dans le code source Android en amont.

Les responsables de la mise en œuvre d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications:

• [C-0-3] NE DOIT PAS affecter le comportement ni la signature en langage Java indiqués pour les API exposées publiquement.
• [C-0-4] NE DOIT PAS être promus ni présentés aux développeurs d'une autre manière.

Toutefois, les responsables de la mise en œuvre 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 la mise en œuvre des appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou similaire: seul Google est autorisé à 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'utilisation accrue de la mémoire de ces API.

Les responsables de l'implémentation d'appareils PEUVENT ajouter des API personnalisées dans des langues natives, en dehors des API du NDK, mais les API personnalisées:

• [C-1-1] NE DOIT PAS faire partie d'une bibliothèque NDK ou d'une bibliothèque appartenant à une autre organisation, comme décrit ici.

Si un responsable de la mise en œuvre d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant de nouvelles fonctionnalités utiles à une API existante ou en ajoutant une nouvelle API), il DOIT accéder à source.android.com et commencer le processus de modification et de code, en fonction des informations fournies sur ce site.

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

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

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec le format complet Dalvik Executable (DEX), ainsi que la spécification et la sémantique du bytecode Dalvik.

• [C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire en fonction de 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.)

• DEVRAIT utiliser Android RunTime (ART), l'implémentation de référence en amont du format exécutable Dalvik et le système de gestion de packages de l'implémentation de référence.

• DEVRAIT exécuter des tests à données aléatoires dans différents modes d'exécution et architectures cibles pour assurer la stabilité de l'environnement d'exécution. Reportez-vous à 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 ppp (140 ppp)
	160 ppp (mdpi)
	180 ppp (180 ppp)
	200 ppp (200 ppp)
	213 ppp (tvdpi)
	220 ppp (220 ppp)	36 Mo
	240 ppp (hdpi)
	280 ppp (280 ppp)
	320 ppp (xhdpi)	48 Mo
	360 ppp (360 ppp)
	400 ppp (400 ppp)	56 Mo
	420 ppp (420 ppp)	64 Mo
	480 ppp (xxhdpi)	88 Mo
	560 ppp (560 ppp)	112 Mo
	640 ppp (xxxhdpi)	154 Mo
petite/normale	120 ppp (ldpi)	32 Mo
	140 ppp (140 ppp)
	160 ppp (mdpi)
	180 ppp (180 ppp)	48 Mo
	200 ppp (200 ppp)
	213 ppp (tvdpi)
	220 ppp (220 ppp)
	240 ppp (hdpi)
	280 ppp (280 ppp)
	320 ppp (xhdpi)	80 Mo
	360 ppp (360 ppp)
	400 ppp (400 ppp)	96 Mo
	420 ppp (420 ppp)	112 Mo
	480 ppp (xxhdpi)	128 Mo
	560 ppp (560 ppp)	192 Mo
	640 ppp (xxxhdpi)	256 Mo
grand	120 ppp (ldpi)	32 Mo
	140 ppp (140 ppp)	48 Mo
	160 ppp (mdpi)
	180 ppp (180 ppp)	80 Mo
	200 ppp (200 ppp)
	213 ppp (tvdpi)
	220 ppp (220 ppp)
	240 ppp (hdpi)
	280 ppp (280 ppp)	96 Mo
	320 ppp (xhdpi)	128 Mo
	360 ppp (360 ppp)	160 Mo
	400 ppp (400 ppp)	192 Mo
	420 ppp (420 ppp)	228 Mo
	480 ppp (xxhdpi)	256 Mo
	560 ppp (560 ppp)	384 Mo
	640 ppp (xxxhdpi)	512 Mo
xlarge	120 ppp (ldpi)	48 Mo
	140 ppp (140 ppp)	80 Mo
	160 ppp (mdpi)
	180 ppp (180 ppp)	96 Mo
	200 ppp (200 ppp)
	213 ppp (tvdpi)
	220 ppp (220 ppp)
	240 ppp (hdpi)
	280 ppp (280 ppp)	144 Mo
	320 ppp (xhdpi)	192 Mo
	360 ppp (360 ppp)	240 Mo
	400 ppp (400 ppp)	288 Mo
	420 ppp (420 ppp)	336 Mo
	480 ppp (xxhdpi)	384 Mo
	560 ppp (560 ppp)	576 Mo
	640 ppp (xxxhdpi)	768 Mo

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

Android inclut une application de lancement (écran d'accueil) et la prise en charge d'applications tierces pour remplacer le lanceur d'appareils (écran d'accueil).

Si les implémentations d'appareils permettent à des applications tierces de 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 pour récupérer les icônes sont appelées.

Si les implémentations d'appareils incluent un lanceur d'applications par défaut compatible avec l'épinglage des raccourcis dans l'application, elles:

• [C-2-1] DOIT signaler true pour ShortcutManager.isRequestPinShortcutSupported().
• [C-2-2] DOIT disposer d'une affordance de l'utilisateur qui demande à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode API ShortcutManager.requestPinShortcut().
• [C-2-3] DOIT prendre en charge les raccourcis épinglés et les raccourcis dynamiques et statiques, comme indiqué sur la page Raccourcis d'application.

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

• [C-3-1] DOIT signaler false pour ShortcutManager.isRequestPinShortcutSupported().

Si les implémentations d'appareils implémentent un lanceur d'applications par défaut qui fournit un accès rapide aux raccourcis supplémentaires fournis par des applications tierces via l'API ShortcutManager, celles-ci:

• [C-4-1] DOIT prendre en charge toutes les fonctionnalités de raccourci documentées (par exemple, les raccourcis statiques et dynamiques, épingler les raccourcis) et implémenter intégralement 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 API NotificationChannel.setShowBadge(). En d'autres termes, affichez une affordance visuelle associée à l'icône d'application si la valeur est définie sur true, et n'affichez aucun schéma 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 leur schéma propriétaire de badges lorsque des applications tierces indiquent la prise en charge du schéma de badges propriétaires via l'utilisation d'API propriétaires. Toutefois, DEVEZ utiliser les ressources et les valeurs fournies via les API de badges de notification décrites dans le SDK, comme Notification.Builder.setNumber() et l'API Notification.Builder.setBadgeIconType().

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

• [C-6-1] DOIT être utilisé uniquement lorsqu'un utilisateur les active explicitement (par exemple, via les paramètres ou le menu de sélection du fond d'écran).

Widgets

Android prend en charge les widgets d'application tiers 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'application tiers:

• [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
• [C-1-2] DOIT inclure la compatibilité intégrée avec AppWidgets et exposer les affordances d'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets.
• [C-1-3] DOIT être capable d'afficher des widgets de 4 x 4 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.
• 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'application tiers et l'épinglage de raccourcis dans l'application, elles:

• [C-2-1] DOIT signaler true pour AppWidgetManager.html.isRequestPinAppWidgetSupported().
• [C-2-2] DOIT disposer d'une affordance de l'utilisateur qui demande à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode 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 notables et d'attirer leur attention à l'aide des composants matériels (son, vibration et lumière, par exemple) et des fonctionnalités logicielles (volet des notifications, barre système, par exemple) de l'appareil.

Présentation des notifications

Si les implémentations sur les appareils permettent aux applications tierces d'avertir les utilisateurs en cas d'événements notables, 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 l'implémentation d'un appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si l'implémentation d'un appareil manque de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est détaillé 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. Toutefois, elles PEUVENT offrir une expérience utilisateur différente de celle fournie par l'implémentation Android Open Source de référence.
• [C-1-3] DOIT respecter et mettre en œuvre correctement les comportements décrits pour les API afin 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 affordance à l'utilisateur pour bloquer et modifier une notification d'application tierce spécifique pour chaque canal et niveau de package d'application.
• [C-1-6] DOIT également fournir une affordance utilisateur pour afficher les canaux de notification supprimés.
• [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies via Notification.MessagingStyle en plus du texte de la notification, sans intervention supplémentaire de l'utilisateur. Par exemple, DOIT afficher toutes les ressources, y compris les icônes fournies via android.app.Person, dans une conversation de groupe définie via setGroupConversation.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance à l'utilisateur pour lui permettre de contrôler les notifications exposées aux applications auxquelles l'autorisation "Écouteur de notifications" a été accordée. La précision DOIT être définie de sorte que l'utilisateur puisse contrôler pour chaque écouteur de notifications les types de notifications qui lui sont associés. Les types DOIVENT inclure les notifications "conversations", "alertes", "silencieux" et "importantes en cours".
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de fournir aux utilisateurs une affordance de spécifier les applications à exclure de la notification d'un écouteur de notification spécifique.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de faire apparaître automatiquement une affordance de l'utilisateur afin de bloquer la notification d'une certaine application tierce pour chaque canal et niveau de package d'application après que l'utilisateur a ignoré cette notification plusieurs fois.
• DEVRAIT prendre en charge les notifications enrichies.
• DEVRAIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
• DEVRAIT avoir une affordance utilisateur pour mettre en attente les notifications.
• PEUVENT gérer uniquement la visibilité et le moment où les applications tierces peuvent avertir les utilisateurs d'événements importants afin d'atténuer les problèmes de sécurité tels que la distraction au volant.

Android 11 prend en charge les notifications de conversation, qui utilisent MessagingStyle et fournissent un ID de raccourci People (Personnes) publié.

Implémentations pour les appareils:

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de regrouper et d'afficher conversation notifications avant les notifications de non-conversation, à 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 d'AOSP répond à ces exigences avec l'UI système, les paramètres et le lanceur d'applications par défaut.

Si les implémentations d'appareils prennent en charge les notifications enrichies, celles-ci:

• [C-2-1] DOIT utiliser les ressources exactes fournies via la classe d'API Notification.Style et ses sous-classes pour les éléments de ressources présentés.
• DEVRAIT 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 prennent en charge les notifications prioritaires:

• [C-3-1] DOIT utiliser la vue de notification prioritaire et les ressources 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 via Notification.Builder.addAction() avec le contenu de la notification sans interaction supplémentaire de l'utilisateur, comme décrit dans le SDK.

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 pour les appareils:

• [C-0-1] DOIT mettre à jour correctement et rapidement les notifications dans leur intégralité sur 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(), ignorer la notification et effectuer un rappel après la durée de mise en attente définie dans l'appel d'API.

Si les implémentations d'appareils ont une affordance utilisateur pour mettre en attente les notifications, elles:

• [C-1-1] DOIT refléter correctement l'état des notifications mises en attente via les API standards telles que NotificationListenerService.getSnoozedNotifications().
• [C-1-2] DOIT mettre cette affordance utilisateur disponible pour mettre en attente les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.

Mode Ne pas déranger/Ne pas déranger

Si les implémentations d'appareils sont compatibles avec la fonctionnalité Ne pas déranger (également appelée "mode Priorité"), les actions suivantes doivent se dérouler:

• [C-1-1] DOIT, lorsque l'implémentation de l'appareil a fourni à l'utilisateur un moyen d'autoriser ou de refuser l'accès des applications tierces à la configuration des règles Ne pas déranger, afficher les règles Ne pas déranger automatiques 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 via 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 Ne pas déranger.

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 prennent en charge l'action d'assistance, celles-ci:

• [C-2-1] DOIT indiquer clairement à l'utilisateur final lorsque le contexte est partagé :
  • Chaque fois que l'application d'assistance accède au contexte, un voyant blanc s'affiche autour des bords de l'écran pour atteindre ou dépasser la durée et la luminosité de l'implémentation du projet Android Open Source.
  • Pour l'application d'assistance préinstallée, fournissez à l'utilisateur une affordance de moins de deux navigations depuis le menu des paramètres de la saisie vocale et de l'application d'assistance par défaut, et ne partage le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via une saisie par mot clé ou via la touche de navigation d'assistance.
• [C-2-2] L'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, en d'autres termes l'application qui implémente VoiceInteractionService ou une activité gérant l'intent ACTION_ASSIST.

Alertes et toasts

Les applications peuvent utiliser l'API Toast pour présenter à l'utilisateur final de courtes chaînes non modales qui disparaissent après un bref délai, 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, ils:

• [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 d'AOSP répond à cette exigence grâce à 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" qui permettent 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" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent s'adapter à l'apparence du thème Holo, telle que définie par le SDK Android.

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

• [C-1-1] NE DOIT PAS modifier les attributs de 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 éléments exposés aux applications.

• [C-1-3] DOIT soit définir la famille de polices "sans-serif" sur Roboto version 2.x pour les langues prises en charge par Roboto, soit fournir une affordance utilisateur pour remplacer la police utilisée pour la famille de polices "sans-serif" par la version Roboto 2.x pour les langues prises en charge par Roboto.

• [C-1-4] DOIT générer des palettes de tonalités 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 de tonalités dynamiques à l'aide de 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.

  "Couleur source" utilisée pour générer des palettes de tons dynamiques lorsqu'elles sont envoyées avec android.theme.customization.system_palette (comme indiqué dans Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

• [C-1-6] DOIT avoir une valeur de chrominance CAM16 supérieure ou égale à 5.

  • DEVRAIT être dérivé du fond d'écran via com.android.systemui.monet.ColorScheme#getSeedColors, qui fournit plusieurs couleurs sources valides parmi lesquelles choisir.

  • DEVRAIT utiliser la valeur 0xFF1B6EF3 si aucune des couleurs fournies ne répond aux exigences de couleur source ci-dessus.

Android inclut également une famille de thèmes "Device Default" (par défaut de l'appareil) sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent s'adapter à l'apparence du thème de l'appareil, tel que défini par le responsable de la mise en œuvre de l'appareil.

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

Android prend en charge un thème de variantes 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 cohérente aux développeurs dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé dans les différentes implémentations d'appareils.

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

• [C-2-1] DOIT utiliser du blanc pour les icônes d'état système (telles que l'intensité du signal et le niveau de la 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 lumineuse à l'aide de l'indicateur WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] Les implémentations d'appareils Android DOIVENT modifier la couleur des icônes d'état système en noir (pour en savoir plus, reportez-vous à R.style) lorsqu'une application demande une barre d'état lumineuse.

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 aux capacités d'entrée limitées et 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 diffuser tous les fonds d'écran animés, sans limitation de fonctionnalité, à une fréquence d'images raisonnable sans affecter les autres applications. Si les limitations du matériel entraînent le plantage, le dysfonctionnement des fonds d'écran et/ou des applications, une utilisation excessive du processeur ou de la batterie, ou une fréquence d'images trop faible, 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 s'exécutera pas de manière fiable sur du matériel non compatible avec plusieurs contextes OpenGL, car l'utilisation d'un fond d'écran animé avec un contexte OpenGL 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:

• [C-1-1] DOIT signaler l'indicateur de fonctionnalité de 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 permettant de changer de tâche et d'afficher les activités et les tâches récemment consultées à l'aide d'une vignette de l'état graphique de l'application au moment où l'utilisateur la quitte pour la dernière fois.

Les implémentations d'appareils, y compris la touche de navigation des fonctions récentes, comme détaillé dans la section 7.2.3, PEUVENT modifier l'interface.

Si les implémentations d'appareils incluant la touche de navigation des fonctions récentes 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.
• DEVRAIT afficher au moins le titre de quatre activités à la fois.
• [C-1-2] DOIT implémenter le comportement d'épinglage d'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
• DEVRAIT afficher la couleur de mise en surbrillance, l'icône et le titre de l'écran dans les éléments récents.
• DEVRAIT afficher une affordance de fermeture ("x"), mais PEUT la retarder jusqu'à ce que l'utilisateur interagit avec les écrans.
• DEVRAIT implémenter un raccourci pour revenir facilement à l'activité précédente.
• DEVRAIT déclencher l'action de basculement rapide entre les deux dernières applications utilisées lorsque l'utilisateur appuie deux fois sur la touche de fonction "Recents".
• DEVRAIT déclencher le mode multifenêtre de l'écran partagé, s'il est compatible, lorsque vous appuyez de manière prolongée sur la touche des fonctions récentes.
• PEUT afficher les récents affiliés en tant que groupe qui bougent ensemble.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface similaire basée sur des vignettes) pour l'écran d'aperçu.

3.8.9. Gestion des entrées

Android est compatible avec la gestion des entrées et les éditeurs de mode de saisie tiers.

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

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

3.8.10. Commandes multimédias pour l'écran de verrouillage

L'API cliente Remote Control a été abandonnée dans la version 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 Dreams)

Consultez la section 3.2.3.5 pour en savoir plus sur l'intention de configurer les économiseurs d'écran.

3.8.12. Position

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

• [C-1-2] DOIT afficher l'état actuel de l'emplacement dans le menu "Emplacement" des paramètres.
• [C-1-3] NE DOIT PAS afficher les modes de localisation dans le menu "Localisation" 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, ils:

• [C-1-1] DOIT pouvoir afficher ces caractères emoji avec un glyphe de couleur.
• [C-1-2] DOIT inclure la prise en charge des éléments suivants :
  • Police Roboto 2 avec des épaisseurs différentes : 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.
  • Compatibilité Unicode 7.0 complète en termes de caractères latins, grecs et cyrilliques, y compris les plages de caractères latins étendus 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 le fichier NotoColorEmoji.tff dans l'image système. (Il est possible d'ajouter une nouvelle police d'emoji pour remplacer les emoji dans le fichier NotoColorEmoji.tff.)
• DEVRAIT prendre en charge la carnation et les différents emoji familiaux, comme spécifié dans le rapport technique Unicode 51.

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

• DEVRAIT fournir un mode de saisie à l'utilisateur pour ces caractères emoji.

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

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

• [C-2-1] DOIT afficher le texte avec une police compatible Unicode par défaut. 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 prendre en charge une police Unicode et une police non compatible avec Unicode si l'appareil l'accepte. Une police non compatible avec Unicode NE DOIT PAS supprimer ni remplacer la police Unicode.
• [C-2-3] DOIT afficher le texte avec une police non compatible avec Unicode UNIQUEMENT SI un code de langue comportant le code de script Qaag est spécifié (par exemple, my-Qaag). Aucun autre code de langue ou de région ISO (attribué, non attribué ou réservé) ne peut être utilisé pour faire référence à une police non compatible avec 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. Multifenêtre

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

• [C-1-1] DOIT implémenter ce ou ces modes multifenêtres conformément aux comportements d'application et aux API décrits dans la documentation de prise en charge du mode multifenêtre du SDK Android, et respecter les exigences suivantes:
• [C-1-2] DOIT respecter android:resizeableActivity défini par une application dans le fichier AndroidManifest.xml, comme décrit dans ce SDK.
• [C-1-3] NE DOIT PAS proposer le mode Écran partagé ou Format libre si la hauteur de l'écran est inférieure à 440 dp et sa largeur 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être autres que Picture-in-picture.
• Les implémentations d'appareils avec une taille d'écran xlarge DEVRAIT prendre en charge le mode Format libre.

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

• [C-2-2] DOIT recadrer l'activité ancrée d'un écran partagé multifenêtre, mais DEVRAIT afficher un contenu de celui-ci si l'application de lancement 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 lancement tierce, et ne pas remplacer ces valeurs lorsqu'une partie du contenu de l'activité ancrée s'affiche.

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

• [C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque l'application : * cible le niveau d'API 26 ou supérieur et déclare android:supportsPictureInPicture ; * cible le niveau d'API 25 ou inférieur, et déclare à la fois android:resizeableActivity et android:supportsPictureInPicture.
• [C-3-2] DOIT exposer les actions dans leur SystemUI, comme spécifié par l'activité PIP en cours via l'API setActions().
• [C-3-3] DOIT prendre en charge des 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é de premier plan.
• [C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher en mode PIP. L'implémentation d'AOSP répond à cette exigence en disposant de commandes dans le volet des notifications.

• [C-3-6] DOIT allouer la largeur et la hauteur minimales suivantes pour la fenêtre PIP lorsqu'une application ne déclare aucune valeur pour AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight:

  • Les appareils dont le paramètre Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur et une hauteur minimales de 108 dp.
  • Les appareils dont le paramètre Configuration.uiMode est défini sur UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

3.8.15. Découpe de l'écran

Android prend en charge une découpe d'affichage comme décrit dans le document du SDK. L'API DisplayCutout définit une zone sur le bord de l'écran qui peut ne pas fonctionner pour une application en raison d'une encoche ou d'un écran incurvé sur les bords.

Si les implémentations d'appareils incluent une ou plusieurs encoches, celles-ci:

• [C-1-5] NE DOIT PAS comporter d'encoches 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 indiquer des valeurs correctes pour toutes les métriques d'encoche définies dans l'API DisplayCutout.

3.8.16. Commandes de contrôle des appareils

Android inclut les API ControlsProviderService et Control qui permettent aux applications tierces de publier des commandes de contrôle des appareils pour offrir un état et une action rapides aux utilisateurs.

Consultez la section 2_2_3 pour connaître les exigences spécifiques à chaque appareil.

3.8.17. Presse-papiers

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS envoyer de données de presse-papiers à un composant, une activité, un service ni via une connexion réseau, sans action explicite de l'utilisateur (par exemple, en appuyant sur un bouton en superposition), sauf pour les services mentionnés à la section 9.8.6 Capture de contenu et Recherche d'applications.

Si les implémentations d'appareils génèrent un aperçu visible par l'utilisateur lorsque le 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 aux exigences du presse-papiers.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications sensibles de la sécurité 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 l'API Android Device Administration.

Si les implémentations d'appareils implémentent l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android, elles:

• [C-1-1] DOIT déclarer android.software.device_admin.
• [C-1-2] DOIT prendre en charge le provisionnement par le propriétaire de l'appareil, comme décrit dans les sections 3.9.1 et 3.9.1.1.

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

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

• [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application de propriétaire d'appareil, comme décrit ci-dessous :
  • Lorsque ni utilisateurs ni données utilisateur n'ont été configurés dans l'implémentation de l'appareil, elle :
    • [C-1-5] DOIT enregistrer l'application DPC en tant qu'application Propriétaire de l'appareil ou permettre à l'application de choisir de devenir propriétaire d'appareil ou propriétaire de profil, si l'appareil déclare la compatibilité NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de 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 de profil, en fonction des valeurs de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, sauf si le contexte indique qu'il n'y a 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 d'appareil est établi lors du provisionnement, quelle que soit la méthode de provisionnement utilisée. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que l'application Propriétaire de l'appareil n'a pas terminé.
  • Lorsque l'implémentation de l'appareil contient des utilisateurs ou des données utilisateur, elle :
    • [C-1-7] NE DOIT plus enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil.
• [C-1-2] DOIT afficher un avis de divulgation approprié (comme référencé dans l'AOSP) et obtenir le consentement explicite de l'utilisateur final avant qu'une application ne soit définie comme propriétaire de l'appareil, sauf si l'appareil est configuré de manière programmatique pour le mode démo en magasin avant l'interaction utilisateur final à l'écran.

Si les implémentations d'appareils déclarent android.software.device_admin, mais incluent également une solution propriétaire de gestion des appareils et fournissent un mécanisme permettant de promouvoir une application configurée dans la solution en tant que "Propriétaire de l'appareil équivalent" au "Propriétaire de l'appareil" standard tel qu'il est reconnu par les API DevicePolicyManager Android standards, elles:

• [C-2-1] DOIT mettre en place un processus permettant de vérifier que l'application faisant l'objet de la promotion appartient à une solution d'entreprise légitime de gestion des appareils et qu'elle a été configurée dans la solution propriétaire pour disposer des droits équivalents en tant que "Propriétaire de l'appareil".
• [C-2-2] DOIT afficher la même mention de consentement pour le propriétaire de l'appareil AOSP que celle initiée par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
• [C-2-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'applications appartenant à d'autres propriétaires de l'appareil.

3.9.1.2 Provisionnement des profils gérés

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

• [C-1-1] DOIT implémenter les API permettant à une application DPC (Device Policy Controller) de devenir le propriétaire d'un nouveau profil géré.

• [C-1-2] Le processus de provisionnement du profil géré (le flux lancé par le DPC à l'aide de android.app.action.PROVISION_MANAGED_PROFILE) ou par la plate-forme), l'écran de consentement et l'expérience utilisateur DOIVENT correspondre à l'implémentation AOSP.

• [C-1-3] DOIT indiquer les affordances suivantes dans les paramètres pour indiquer à l'utilisateur qu'une fonction système particulière a été désactivée par l'outil de contrôle des règles relatives aux appareils (DPC):

  • Icône cohérente ou autre affordance de l'utilisateur (par exemple, l'icône d'informations AOSP en amont) pour indiquer quand un paramètre particulier est limité par un administrateur d'appareil.
  • Un bref message d'explication, fourni par l'administrateur de l'appareil via setShortSupportMessage.
  • Icône de l'application DPC.

• [C-1-4] DOIT lancer le gestionnaire de l'intent ACTION_PROVISIONING_SuccessFUL dans le profil professionnel si un propriétaire de profil est établi lorsque le provisionnement est lancé par l'intent android.app.action.PROVISION_MANAGED_PROFILE et que l'outil 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 lancé 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 de profil, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] DOIT envoyer l'intent 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 celui-ci est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que l'application Propriétaire de profil n'a pas terminé.

• [C-1-8] DOIT envoyer une 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 Prise en charge des profils gérés

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

• [C-1-1] DOIT prendre en charge 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 dotés d'un badge tels que les applications récentes et les notifications.
• [C-1-4] DOIT afficher une icône de notification (semblable au badge professionnel en amont AOSP) pour indiquer que 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é si et quand l'appareil se met en marche (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, DOIT afficher une affordance visuelle dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré à l'utilisateur principal, ou inversement, s'il est activé par le contrôleur Device Policy.
• [C-1-7] Lorsqu'un profil géré existe, DOIT exposer les ressources utilisateur suivantes pour l'utilisateur principal et le profil géré :
  • Séparation de l'utilisation de la batterie, de l'emplacement, 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 le profil géré.
  • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré.
  • Gestion indépendante des comptes dans l'utilisateur principal ou le profil géré.
• [C-1-8] DOIT s'assurer que le clavier, les contacts et les applications de messagerie préinstallés peuvent rechercher et consulter des informations sur l'appelant dans le profil géré (le cas échéant) en plus de celles du profil principal, si le contrôleur de règles relatives aux appareils le permet.
• [C-1-9] DOIT s'assurer qu'il répond à 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.

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

• [C-2-1] DOIT prendre en charge la possibilité de spécifier un écran de verrouillage distinct répondant aux exigences suivantes, afin de n'accorder l'accès qu'aux applications s'exécutant dans un profil géré.
  • Les implémentations d'appareils DOIVENT respecter l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer des identifiants d'écran de verrouillage distincts 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 de mot de passe DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si l'instance DevicePolicyManager renvoyée par getParentProfileInstance est appelée.
• Lorsque les contacts du profil géré sont affichés dans le journal d'appels préinstallé, l'UI de l'appel en cours, les notifications d'appels en cours et manqués, les contacts et les applications de chat, ils DOIVENT porter le même badge que celui utilisé pour indiquer les applications de profil géré.

3.9.3 Assistance aux utilisateurs gérés

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

• [C-1-1] DOIT fournir une affordance d'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 de l'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 de l'utilisateur sur l'appareil pour ajouter des utilisateurs secondaires, elles:

• [C-SR-1] VIVEMENT RECOMMANDÉ affichent les mêmes déclarations de consentement AOSP pour les propriétaires d'appareils que celles indiqué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 relatives aux rôles de gestion des règles relatives aux appareils

Si les implémentations d'appareils signalent android.software.device_admin ou android.software.managed_users, alors:

• [C-1-1] DOIT prendre en charge 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 relatives aux appareils PEUT être définie en définissant config_devicePolicyManagement sur le nom du package. Le nom du package DOIT être suivi de : 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 prendre en charge le provisionnement sans application de titulaire de rôle de gestion des règles relatives aux appareils (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 relatives aux appareils 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.10. Accessibilité

Android fournit une couche d'accessibilité qui aide les utilisateurs ayant un handicap à naviguer plus facilement sur leurs appareils. En outre, 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 rétroaction, 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:

• [C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android, comme décrit dans la documentation du SDK sur les 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 d'utilisateur pour contrôler les services d'accessibilité qui déclarent l'élément AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BOUTON. Notez que pour les implémentations d'appareils avec une barre de navigation système, elles DOIVENT permettre à l'utilisateur d'avoir la possibilité d'utiliser 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:

• [C-2-1] DOIT implémenter ces services d'accessibilité préinstallés en tant qu'applications compatibles avec le démarrage direct lorsque le stockage de données est chiffré à l'aide du chiffrement basé sur les fichiers (FBE).
• DEVRAIT 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 de la police, la taille d'affichage et les gestes d'agrandissement.

3.11. Synthèse vocale

Android inclut des API qui permettent aux applications d'utiliser des services de synthèse vocale et aux fournisseurs de services de proposer des implémentations de services de synthèse vocale.

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

• [C-1-1] DOIT prendre en charge les API du framework de synthèse vocale Android.

Si les implémentations d'appareils sont compatibles avec l'installation de moteurs de synthèse vocale tiers, ceux-ci:

• [C-2-1] DOIT fournir une affordance à l'utilisateur pour lui permettre de sélectionner un moteur de synthèse vocale à utiliser au niveau du système.

3.12. Framework d'entrée TV

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

Si les implémentations d'appareils sont compatibles avec le TIF:

• [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.live_tv.
• [C-1-2] DOIT être compatible avec toutes les API TIF de sorte qu'une application qui utilise ces API et le service d'entrées tiers basé sur TIF puissent être installés et utilisés sur l'appareil.

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 nécessaires en urgence.

Si les implémentations d'appareils incluent un composant d'interface utilisateur Réglages rapides et sont compatibles avec les Réglages rapides tiers, elles:

• [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les cartes fournies via les API quicksettings à partir d'une application tierce.
• [C-1-2] NE DOIT PAS ajouter automatiquement une carte depuis une application tierce directement aux Réglages rapides.
• [C-1-3] DOIT afficher toutes les vignettes ajoutées par l'utilisateur depuis des applications tierces à côté des tuiles de Réglages rapides fournies par le système.

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent des applications non à commande vocale (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 le fichier MediaDescription. Peut raccourcir les titres afin de respecter les réglementations de sécurité (par exemple, les distractions au volant).

• [C-1-3] DOIT afficher l'icône de l'application tierce lors de l'affichage 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 restreindre l'accès à une partie de la hiérarchie afin de respecter les réglementations 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 fait d'appuyer deux fois sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme étant KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

Si les implémentations d'appareils sont compatibles avec les applis instantanées, ils DOIVENT respecter les exigences suivantes:

• [C-1-1] Les applis instantanées DOIVENT disposer uniquement d'autorisations dont l'élément 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 format 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 applis instantanées NE DOIVENT PAS voir d'informations sur les applis instantanées sur l'appareil, sauf si elles se connectent 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 système, les paramètres et le lanceur d'applications par défaut. Implémentations pour les appareils:

  • [C-1-5] DOIT fournir une affordance utilisateur pour afficher et supprimer les applis instantanées mises en cache localement pour chaque package d'application.
  • [C-1-6] DOIT fournir une notification utilisateur persistante pouvant être réduite lorsqu'une appli instantanée est exécutée au premier plan. Cette notification utilisateur DOIT inclure que les applis instantanées ne nécessitent pas d'installation et fournir une affordance de l'utilisateur qui redirige l'utilisateur vers l'écran d'informations de l'application dans les paramètres. Pour les applis instantanées lancées via des intents Web, comme défini à l'aide d'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'appli 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 applis 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 un ou plusieurs composants d'application ou de service avec un gestionnaire d'intents pour les intents répertoriés dans le SDK, et rendre ces intents visibles pour les applis instantanées.

3.16. Association d'un appareil associé

Android prend en charge l'association d'appareils associés pour gérer plus efficacement cette association, 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:

• [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 à l'utilisateur pour sélectionner/confirmer qu'un appareil associé est présent et opérationnel.

3.17. Applications lourdes

Si les implémentations d'appareils déclarent la fonctionnalité FEATURE_CANT_SAVE_STATE, alors:

• [C-1-1] DOIT disposer d'une seule application installée spécifiant cantSaveState à la fois dans le système. Si l'utilisateur quitte une application sans la quitter explicitement (par exemple, en appuyant sur la touche d'accueil tout en laissant une activité active dans le système, au lieu de revenir en arrière sans aucune activité active restante dans le système), les implémentations d'appareils DOIVENT donner la priorité à cette application dans la RAM comme elles le font pour les autres éléments censés rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une application de ce type est exécutée en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, telles que 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/de 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 de stratégie aux applications qui spécifient cantSaveState, telles que la modification des performances du processeur ou de la priorisation de la planification.

Si les implémentations d'appareils 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 qui permettent aux applications de gérer les coordonnées 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 il est possible que ces données ne résident que localement sur l'appareil. Les contacts qui ne sont stockés que sur l'appareil sont appelés contacts locaux.

Les RawContacts sont "associés" ou "stockés" dans un Account lorsque les colonnes ACCOUNT_NAME et ACCOUNT_TYPE des contacts bruts correspondent aux champs Account.name et Account.type correspondants 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. Ces contacts 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, qui sont créés avec au moins une valeur non nulle pour les colonnes ACCOUNT_NAME et ACCOUNT_TYPE.

Implémentations pour 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 champ 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 avec le compte local par défaut (c'est-à-dire en définissant des valeurs nulles pour ACCOUNT_NAME et ACCOUNT_TYPE) DOIVENT être insérés dans le compte local personnalisé.
• [C-1-4] Les contacts bruts insérés dans un compte local personnalisé NE DOIVENT pas être supprimés lors de l'ajout ou de la suppression de comptes.
• [C-1-5] Les opérations de suppression effectuées sur le compte local personnalisé DOIVENT entraîner la suppression immédiate et définitive 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 n'était pas spécifié.

4. Compatibilité avec les packages d'applications

Implémentations pour les appareils:

• [C-0-1] DOIT être capable d'installer et d'exécuter des fichiers Android ".apk" tels qu'ils sont générés par l'outil "aapt" inclus dans le SDK Android officiel.

  • Comme l'exigence ci-dessus peut s'avérer difficile, les implémentations d'appareils sont RECOMMANDÉES d'utiliser le système de gestion des packages de l'implémentation de référence AOSP.

• [C-0-2] DOIT prendre en charge la validation des fichiers ".apk" à l'aide des fichiers APK Signature Scheme v3.1, APK Signature Scheme v3, APK Signature Scheme v2 et JAR.

• [C-0-3] NE DOIT PAS étendre les formats de bytecode .apk, manifest Android, Dalvik bytecode ou RenderScript d'une manière qui empêcherait ces fichiers de s'installer et de s'exécuter correctement sur d'autres appareils compatibles.

• [C-0-4] NE DOIT PAS autoriser les applications autres que le "programme d'installation officiel" actuel du package à désinstaller l'application en mode silencieux sans 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 de gestionnaire d'espace de stockage qui gère l'intent ACTION_MANAGE_STORAGE.

• [C-0-5] DOIT avoir une activité qui gère l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

• [C-0-6] NE DOIT PAS installer de packages d'applications 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 été autorisé à installer des applications provenant de sources inconnues.

• DEVRAIT fournir à un utilisateur l'autorisation d'accorder ou de révoquer l'autorisation d'installer des applications provenant de sources inconnues par application, mais PEUT choisir de l'implémenter en tant qu'opération no-op et renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas que les utilisateurs aient ce choix. Toutefois, même dans de tels cas, elles DOIVENT indiquer à l'utilisateur pourquoi une telle décision n'est pas proposée.

• [C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie via l'API système PackageManager.setHarmfulAppWarning à l'utilisateur avant de lancer une activité dans une application marquée comme potentiellement dangereuse par la même API système PackageManager.setHarmfulAppWarning.

• DEVRAIT permettre à l'utilisateur de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.

• [C-0-8] DOIT mettre en œuvre la prise en charge du système de fichiers incrémentiel comme indiqué ici.

• [C-0-9] DOIT prendre en charge la vérification des fichiers .apk à l'aide des APK Signature Scheme v4 et APK Signature Scheme v4.1.

5. Compatibilité multimédia

Implémentations pour 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 compatibilité avec les encodeurs et décodeurs disponibles pour les applications tierces via MediaCodecList.
• [C-0-3] DOIT être capable de décoder correctement et de mettre à la disposition des applications tierces tous les formats qu'elles peuvent encoder. Cela inclut tous les flux de bits générés par ses encodeurs et les profils signalés dans son fichier CamcorderProfile.

Implémentations pour les appareils:

• DEVRAIT avoir une latence minimale du codec. En d'autres termes, il doit :
  • NE DEVRAIT PAS consommer ni stocker les tampons d'entrée, et ne renvoyer les tampons d'entrée qu'une fois traités.
  • NE DEVRAIT PAS conserver sur les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
  • NE DEVRAIT PAS conserver sur les tampons encodés plus longtemps que requis par la structure GOP.

Tous les codecs répertorié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 prétendent que l'absence de brevets tiers pour ces codecs. Ceux qui ont l'intention d'utiliser ce code source dans des produits matériels ou logiciels sont informés que les implémentations de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevet des titulaires des brevets concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

Pour plus d'informations, 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

Tous les encodeurs audio DOIVENT prendre en charge:

• [C-3-1] Trames audio PCM natives ordonnées par ordre des octets 16 bits via l'API android.media.MediaCodec.

5.1.2. Décodage audio

Pour plus d'informations, consultez la section 5.1.3. Détails des codecs audio.

Si les implémentations d'appareils déclarent être compatibles avec la fonctionnalité android.hardware.audio.output, elles doivent accepter le décodage des formats audio suivants:

• [C-1-1] Profil MPEG-4 AAC (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 décalage amélioré)
• [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 plage dynamique ISO/IEC 23003-4)
• [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, un taux 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 à réduire le mixage pendant la phase de lecture.
• [C-1-10] Opus

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) vers le format PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être acceptés:

• [C-2-1] Le décodage DOIT être effectué sans sous-mélange (par exemple, un flux 5.0 AAC doit être décodé en cinq canaux PCM, et un flux 5.1 AAC doit être décodé sur six canaux PCM).
• [C-2-2] Les métadonnées de plage dynamique DOIVENT être telles que définies dans la section "Dynamic Range Control (DRC)" de la norme ISO/IEC 14496-3, et les clés DRC android.media.MediaFormat 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 des fichiers audio USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Les métadonnées "Loudness" et "DRC" DOIVENT être interprétées et appliquées conformément au profil MPEG-D DRC Dynamic Range Control Profile 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:

• PEUT prendre en charge le volume et le contrôle de la plage dynamique à l'aide du profil de contrôle de plage dynamique ISO/IEC 23003-4.

Si la norme ISO/IEC 23003-4 est acceptée et que les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont toutes deux présentes dans un flux de bits décodé, procédez comme suit:

• Les métadonnées ISO/IEC 23003-4 ONT la priorité.

Tous les décodeurs audio DOIVENT prendre en charge la sortie:

• [C-6-1] Trames audio PCM natives ordonnées par ordre des octets 16 bits via l'API android.media.MediaCodec.

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) vers le format PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être acceptés:

• [C-7-1] DOIT être configuré par l'application à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est réduit en stéréo (si vous utilisez une valeur de 2) ou si la sortie est effectuée à l'aide du nombre natif de canaux (lorsque vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour qu'il produise six canaux lorsqu'il est alimenté en contenu 5.1.
• [C-7-2] Lors du décodage, le décodeur DOIT annoncer le masque de canal utilisé sur le format de sortie à l'aide de la clé KEY_CHANNEL_MASK, à l'aide des constantes android.media.AudioFormat (exemple : 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 qu'elles peuvent produire du contenu audio multicanal (c'est-à-dire plus de deux canaux) lorsqu'ils fournissent du contenu multicanal compressé, procédez comme suit:

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de pouvoir configurer le décodeur pour pouvoir être configuré par l'application à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT afin de contrôler si le contenu est réduit en stéréo (si vous utilisez une valeur de 2) ou si la sortie utilise le nombre natif de canaux (si vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour qu'il produise six canaux lorsqu'il est alimenté en contenu 5.1.
• [C-SR-3] Lors du décodage, il est FORTEMENT RECOMMANDÉ d'annoncer le masque de canal utilisé sur le format de sortie avec la clé KEY_CHANNEL_MASK, à l'aide des constantes android.media.AudioFormat (exemple : CHANNEL_OUT_5POINT1).

5.1.3. Détails des codecs audio

Format/Codec	Détails	Types de fichiers/Formats de conteneur compatibles
Profil MPEG-4 AAC (AAC LC)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (0,3gp) MPEG-4 (.mp4, .m4a) ADTS AAC bruts (.aac, ADIF non compatibles) MPEG-TS (.ts, impossible de rechercher, décodage uniquement) Matroska (.mkv, décodage uniquement)
Profil MPEG-4 HE AAC (AAC+)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (0,3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 Profil (AAC+ amélioré)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (0,3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC à faible délai amélioré)	Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (0,3gp) MPEG-4 (.mp4, .m4a)
USAC	Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 7,35 à 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (0,3gp)
AMR-WB	9 débits allant de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz, tels que définis dans le AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec	3GPP (0,3gp)
FLAC	Pour l'encodeur comme le décodeur, au moins les modes Mono et Stéréo DOIVENT être acceptés. Des taux d'échantillonnage jusqu'à 192 kHz DOIVENT être acceptés. Les résolutions 16 bits et 24 bits DOIVENT être acceptées. Le traitement des données audio FLAC 24 bits DOIT être disponible avec une configuration audio à virgule flottante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MP3	Constante CBR (Mono/Stéréo) de 8 à 320 kbit/s ou débit variable (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MIDI	Type MIDI 0 et 1. DLS version 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		Ogg (.ogg) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv) WebM (.webm)
PCM/WAVE	Le codec PCM DOIT être compatible avec la PCM linéaire 16 bits et le float 16 bits. L'extracteur WAVE doit être compatible avec les mesures PCM linéaires 16, 24 bits et 32 bits, et les valeurs à virgule flottante 32 bits (débits allant jusqu'à la limite du matériel). Les taux d'échantillonnage DOIVENT être acceptés de 8 kHz à 192 kHz.	WAVE (.wav)
Opus	Décodage: compatibilité avec les 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: compatibilité avec les contenus mono et stéréo avec des taux d'échantillonnage de 8 000, 12 000 et 4 Hz	Ogg (.ogg) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv) WebM (.webm)

5.1.4. Encodage d'image

Pour plus d'informations, consultez la section 5.1.6. Détails des codecs image.

Les implémentations d'appareils DOIVENT prendre en charge l'encodage d'image suivant:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

Si les implémentations d'appareils sont compatibles avec l'encodage HEIC via android.media.MediaCodec pour le type de contenu MIMETYPE_IMAGE_ANDROID_HEIC, elles:

• [C-1-1] DOIT fournir un codec encodeur HEVC avec accélération matérielle, compatible avec le mode de contrôle de débit BITRATE_MODE_CQ, le profil HEVCProfileMainStill et une taille de trame de 512 x 512 pixels.

5.1.5. Décodage d'images

Pour plus d'informations, consultez la section 5.1.6. Détails des codecs image.

Les implémentations d'appareils DOIVENT prendre en charge 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

Si les implémentations d'appareils sont compatibles avec le décodage vidéo HEVC, elles : * [C-1-1] DOIT être compatible avec le décodage d'image HEIF (HEIC).

Décodeurs d'images compatibles avec un format à forte profondeur de bits (plus de 9 bits par canal):

• [C-2-1] DOIT prendre en charge 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 des codecs image

Format/Codec	Détails	Types de fichiers/formats de conteneur acceptés
JPEG	Base+progressive	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Brute		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)

Encodeur et décodeurs d'images exposés via l'API MediaCodec

• [C-1-1] DOIT prendre en charge le format de couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) à CodecCapabilities.

• [C-SR-1] FORTEMENT RECOMMANDÉ pour prendre en charge le format de couleurs RGB888 pour le mode Surface d'entrée.

• [C-1-3] DOIT prendre en charge au moins un format de couleur YUV420 8:8:8 planaire ou semi-plan: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de prendre en charge les deux.

5.1.7. Codecs vidéo

• Pour garantir une qualité acceptable pour les services de streaming vidéo sur le Web et de vidéoconférence, les implémentations d'appareils DOIVENT utiliser un codec matériel VP8 conforme 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 prendre en charge des tailles de tampon d'octets de sortie et d'entrée qui s'adaptent à la plus grande trame compressée et non compressée possible, conformément aux exigences de la norme et de la configuration, mais sans surallouer.

• [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge les formats de couleurs flexibles YUV420 8:8:8 (COLOR_FormatYUV420Flexible) à CodecCapabilities.

• [C-1-3] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec au moins l'un des formats de couleurs YUV420 8:8:8 planaires ou semi-planaires: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de les accepter.

• [C-SR-1] Les encodeurs et décodeurs vidéo sont FORTEMENT RECOMMANDÉS pour être compatibles avec au moins l'un des formats de couleurs 8:8:8 YUV420 planaires ou semi-planaires optimisés pour le matériel (YV12, NV12, NV21 ou un format équivalent optimisé par un fournisseur).

• [C-1-5] Les décodeurs vidéo compatibles avec un format à forte profondeur de bits (plus de 9 bits par canal) DOIVENT prendre en charge la sortie d'un format équivalent à 8 bits si l'application les demande. Cela DOIT être reflété par la compatibilité avec un format de couleur YUV420 8:8:8 via android.media.MediaCodecInfo.

Si les implémentations d'appareils annoncent la prise en charge des profils 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'appareils annoncent la prise en charge des actualisations d'intra-actualisation via FEATURE_IntraRefresh dans la classe MediaCodecInfo.CodecCapabilities, elles:

• [C-3-1] DOIT accepter des périodes d'actualisation comprises entre 10 et 60 images et fonctionner avec précision à 20% de la période d'actualisation configurée.

Sauf indication contraire de l'application avec 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é avec une sortie en surface.
• [C-4-2] DOIT utiliser par défaut un format de couleurs YUV420 8:8:8 optimisé pour la lecture du processeur s'il est configuré pour ne pas utiliser la sortie de surface.

5.1.8. Liste des codecs vidéo

Format/Codec	Détails	Types de fichiers/Formats de conteneur compatibles
H.263		3GPP (0,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 (0,3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, impossible de rechercher) Matroska (.mkv, décodage uniquement)
HEVC H.265	Pour en savoir plus, consultez la section 5.3.	MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
MPEG-2	Main Profile	MPEG2-TS (.ts, impossible de rechercher) MPEG-4 (.mp4, décodage uniquement) Matroska (.mkv, décodage uniquement)
MPEG-4 SP		3GPP (0,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)

5.1.9. Sécurité du codec multimédia

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du codec multimédia, 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 peu coûteuse.

Si les implémentations d'appareils prennent en charge le contenu multimédia, elles:

• [C-1-1] DOIT assurer la prise en charge des 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 ou contourner les protections de sécurité. Plus précisément, cela ne signifie pas que chaque codec DOIT utiliser l'API OMX ou Codec 2.0, mais que la prise en charge d'au moins une de ces API DOIT être disponible, et 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 prise en charge de l'API Codec 2.0.

Si les implémentations d'appareils ne sont pas compatibles avec l'API Codec 2.0, celles-ci:

• [C-2-1] DOIT inclure le codec logiciel OMX correspondant du projet Open Source Android (s'il est disponible) pour chaque format et type de média (encodeur ou décodeur) compatible avec l'appareil.
• [C-2-2] Les codecs dont le nom commence par "OMX.google". DOIT être basé sur le code source de leur 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 accès à aucun pilote matériel autre que les mappeurs de mémoire.

Si les implémentations d'appareils sont compatibles avec l'API Codec 2.0, ils:

• [C-3-1] DOIT inclure le codec logiciel Codec 2.0 correspondant du projet Open Source Android (s'il est disponible) pour chaque format et type de média (encodeur ou décodeur) pris en charge par l'appareil.
• [C-3-2] DOIT héberger les codecs logiciels du Codec 2.0 dans le processus de codec logiciel fourni dans le projet Open Source Android, afin de permettre un accès plus restreint aux codecs logiciels.
• [C-3-3] Les codecs dont le nom commence par "c2.android". DOIT être basé sur le code source de leur projet Android Open Source.

5.1.10. Caractérisation du codec multimédia

Si les implémentations d'appareils sont compatibles avec les codecs multimédias, ils:

• [C-1-1] DOIT renvoyer des valeurs correctes de caractérisation du codec multimé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 d'attribution de noms 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 d'attribution de noms de 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é par un fournisseur ou une accélération matérielle.
• [C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) ayant accès à des pilotes matériels autres que les outils d'allocation de mémoire et les mappeurs NE DOIVENT PAS être considérés comme exclusivement logiciels.
• [C-1-6] Les codecs qui ne figurent pas dans le projet Android Open Source ou qui ne sont pas basés sur le code source de ce projet DOIVENT être définis comme des fournisseurs.
• [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés par une accélération matérielle.
• [C-1-8] Les noms de codec 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 les noms contiennent des formats multimédias DOIVENT être compatibles avec 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 de fréquence d'images atteignables pour les tailles suivantes, si elles sont compatibles avec le codec:

	SD (basse qualité)	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)	1408 x 1152 px (H263) 1 280 x 720 px (autre)	1 920 x 1 080 px (autres que MPEG4)	3840 x 2160 px (HEVC, VP9)

• [C-2-2] Les codecs vidéo caractérisés par une accélération matérielle DOIVENT publier des informations sur les points de performance. Ils DOIVENT répertorier tous les points de performances standards compatibles (répertoriés dans l'API PerformancePoint), sauf s'ils sont couverts par un autre point de performances standard accepté.
• De plus, ils DOIVENT publier des points de performance étendus s'ils permettent des performances vidéo durables autres que les performances standards listées.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le rendent disponible pour des applications tierces, celles-ci:

• NE DOIT PAS être, sur deux fenêtres glissantes, plus de 15% du débit entre les intervalles intraframe (I-frame).
• NE DEVRAIT PAS dépasser 100% du débit sur une fenêtre glissante d'une seconde.

Si les implémentations d'appareils incluent un écran intégré d'une longueur en diagonale d'au moins 2,5 pouces, incluent un port de sortie vidéo ou déclarent la prise en charge d'une caméra via l'indicateur de fonctionnalité android.hardware.camera.any:

• [C-1-1] DOIT être compatible avec au moins l'un des encodeurs vidéo VP8 ou H.264 et le rendre disponible pour les applications tierces.
• DEVRAIT être compatible avec les encodeurs vidéo VP8 et H.264, et le rendre disponible pour des applications tierces.

Si les implémentations d'appareils sont compatibles avec les encodeurs vidéo H.264, VP8, VP9 ou HEVC et les mettent à la disposition d'applications tierces, elles:

• [C-2-1] DOIT être compatible avec les débits configurables dynamiquement.
• DEVRAIT prendre en charge des fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des frames en fonction des horodatages des tampons d'entrée et allouer son bucket de bits 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 rendent disponible pour les applications tierces, celles-ci:

• DEVRAIT prendre en charge des débits configurables dynamiquement pour l'encodeur pris en charge.

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image avec accélération matérielle, et acceptent une ou plusieurs caméras matérielles connectées ou branchées exposées via les API android.camera:

• [C-4-1] Tous les encodeurs vidéo et d'image avec accélération matérielle DOIVENT prendre en charge l'encodage des trames provenant des caméras matérielles.
• DEVRAIT prendre en charge l'encodage des images de la ou des caméras matérielles via tous les encodeurs vidéo ou d'image.

Si les implémentations d'appareils proposent un encodage HDR, celles-ci:

• Il est FORTEMENT RECOMMANDÉ de fournir un plug-in [C-SR-1] pour permettre à l'API de transcodage fluide de passer du format HDR au 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, celles-ci:

• [C-1-1] DOIT prendre en charge le profil de référence de niveau 45.
• DEVRAIT prendre en charge des débits configurables dynamiquement pour l'encodeur pris en charge.

5.2.2. H.264

Si les implémentations d'appareils sont compatibles avec le codec H.264:

• [C-1-1] DOIT prendre en charge le profil de référence de niveau 3. Toutefois, la prise en charge des types ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (Redondant Slices) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ de ne pas utiliser ASO, FMO et RS pour le profil de référence par les encodeurs.
• [C-1-2] DOIT être compatible avec les profils d'encodage vidéo SD (définition standard) indiqués dans le tableau suivant.
• DEVRAIT prendre en charge le profil principal de niveau 4.
• DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) comme indiqué dans le tableau suivant.

Si les implémentations d'appareils indiquent la compatibilité de l'encodage H.264 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:

• [C-2-1] DOIT être compatible avec les profils d'encodage indiqués dans le tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images 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:

• [C-1-1] DOIT être compatible avec les profils d'encodage vidéo SD.
• DEVRAIT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.
• [C-1-2] DOIT prendre en charge l'écriture de fichiers Matroska WebM.
• DEVRAIT fournir un codec matériel VP8 conforme aux exigences de codage matériel RTC des projets WebM, afin de garantir une qualité acceptable pour les services de streaming vidéo Web et de visioconférence.

Si les implémentations d'appareils indiquent la compatibilité de l'encodage VP8 pour les vidéos en résolution 720p ou 1080p via les API multimédias, elles:

• [C-2-1] DOIT être compatible avec les profils d'encodage indiqués dans le tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images 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:

• [C-1-2] DOIT prendre en charge le profil 0 de niveau 3.
• [C-1-1] DOIT prendre en charge l'écriture de fichiers Matroska WebM.
• [C-1-3] DOIT générer des données CodecPrivate.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.
• [C-SR-1] est VIVEMENT RECOMMANDÉ pour prendre en charge les profils de décodage HD, comme indiqué 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	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images 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 prétendent être compatibles avec Profil 2 ou Profil 3 via les API Media:

• La prise en charge du format 12 bits est FACULTATIVE.

5.2.5. H265

Si les implémentations d'appareils sont compatibles avec le codec H.265:

• [C-1-1] DOIT prendre en charge le profil principal de niveau 3.
• DEVRAIT prendre en charge les profils d'encodage HD, comme indiqué dans le tableau suivant.
• [C-SR-1] est VIVEMENT RECOMMANDÉ pour prendre en charge les profils d'encodage HD, comme indiqué 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	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images 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.3. Décodage vidéo

Si les implémentations d'appareils sont compatibles avec les codecs VP8, VP9, H.264 ou H.265:

• [C-1-1] DOIT prendre en charge le changement de résolution vidéo et de fréquence d'images dynamiques via les API Android standards dans le même flux pour tous les codecs VP8, VP9, H.264 et H.265 en temps réel et jusqu'à la résolution maximale acceptée 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, ils:

• [C-1-1] DOIT prendre en charge le niveau supérieur du profil principal.

5.3.2. H.263

Si les implémentations d'appareils sont compatibles avec les décodeurs H.263:

• [C-1-1] DOIT être compatible avec les profils de référence de niveaux 30 et 45.

5.3.3. MPEG-4

Si les appareils sont implémentés avec des décodeurs MPEG-4:

• [C-1-1] DOIT prendre en charge le niveau de profil simple 3.

5.3.4. H.264

Si les implémentations d'appareils sont compatibles avec les décodeurs H.264:

• [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), de FMO (Flexible Macroblock Ordering) et de RS (segments redondants) est FACULTATIVE.
• [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (définition standard) répertoriées dans le tableau suivant, et encodées avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
• DOIT être capable de décoder des vidéos avec les profils HD (haute définition), comme indiqué dans le tableau suivant.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo, les implémentations d'appareils:

• [C-2-1] DOIT être compatible avec les profils de décodage vidéo HD 720p indiqués dans le tableau suivant.
• [C-2-2] DOIT être compatible avec les profils de décodage vidéo HD 1080p présentés dans le tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	60 FPS	30 FPS (60 FPS pour la 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:

• [C-1-1] DOIT prendre en charge le niveau principal du profil principal de niveau 3 et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué 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 indiqué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 prendre en charge au moins l'un des décodages H.265 ou VP9 des profils 720, 1080 et UHD.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30/60 FPS (60 FPS, téléviseur 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 déclarent ê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, et permettre l'extraction et la sortie des métadonnées HDR requises à partir du flux de bits 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:

• [C-1-1] DOIT être compatible avec les profils de décodage SD indiqués dans le tableau suivant.
• DEVRAIT utiliser un codec matériel VP8 répondant aux exigences.
• DEVRAIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

Si la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution de la vidéo:

• [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge les profils 720p indiqués dans le tableau suivant.
• [C-2-2] Les implémentations d'appareils DOIVENT prendre en charge les profils 1080p indiqués dans le tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	30 FPS (60 FPS pour la télévision)	30 (60 FPS pour la 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:

• [C-1-1] DOIT être compatible avec les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué 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 indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo:

• [C-3-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des décodages VP9 ou H.265 des profils 720, 1080 et UHD.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 FPS (téléviseur 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 déclarent ê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 déclarent être compatibles avec un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API multimédias:

• [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) de l'application. Ils DOIVENT également être compatibles avec l'extraction et la sortie des métadonnées HDR requises à partir du flux de bits 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 être compatibles avec le 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 port de sortie vidéo standard (par exemple, HDMI).
• [C-1-3] DOIT définir l'ID de piste des couches de base rétrocompatibles (le cas échéant) de sorte qu'ils soient identiques à 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:

• [C-1-1] DOIT prendre en charge le profil 0, y compris le contenu 10 bits.

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient énumérées comme DEVRAIT depuis Android 4.3, il est prévu que la définition de compatibilité pour les versions futures les remplace par OBLIGATOIRE. Les appareils Android nouveaux et existants sont VIVEMENT RECOMMANDÉS de répondre à ces exigences, qui sont énumérées comme DEVRAIT. Dans le cas contraire, ils ne pourront pas assurer la compatibilité Android lors d'une mise à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

Si les implémentations d'appareils 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 correctement. Les caractéristiques suivantes DOIVENT être acceptées:

  • Format:PCM linéaire 16 bits
  • Taux d'échantillonnage:8 000, 11 025, 16 000, 44 100 et 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.

• DEVRAIT permettre la capture d'un 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 le nombre de micros sur l'appareil.

• [C-1-2] DOIT enregistrer à des taux d'échantillonnage supérieurs sans suréchantillonnage.

• [C-1-3] DOIT inclure un filtre d'anticrénelage approprié lorsque les taux d'échantillonnage indiqués ci-dessus sont capturés avec un sous-échantillonnage.

• DEVRAIT autoriser la capture radio AM et DVD de qualité audio brute, c'est-à-dire les caractéristiques suivantes:

  • Format: PCM linéaire 16 bits
  • Taux d'échantillonnage: 22 050, 48 000 Hz
  • Canaux: stéréo

• [C-1-4] DOIT respecter l'API MicrophoneInfo et renseigner correctement les informations concernant les micros disponibles sur l'appareil accessible aux applications tierces via l'API AudioManager.getMicrophones(), pour les enregistrements audio actifs 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 en qualité radio et DVD en qualité AM, ils:

• [C-2-1] DOIT effectuer une capture sans suréchantillonnage à un ratio supérieur à 16 000:22050 ou 44 100:48 000.
• [C-2-2] DOIT inclure un filtre d'anticrénelage approprié pour tout échantillonnage à la hausse ou à la baisse.

5.4.2. Capturer pour la reconnaissance vocale

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

• [C-1-1] DOIT capturer android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION source audio à l'un des taux d'échantillonnage : 44 100 et 48 000.
• [C-1-2] DOIT désactiver par défaut tout traitement audio de réduction de bruit lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.

• [C-1-3] DOIT désactiver par défaut tout contrôle de gain automatique lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.

• DEVRAIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: ±3 dB de 100 Hz à 4 000 Hz pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR-1] pour présenter des niveaux d'amplitude dans la plage de basses fréquences, en particulier de ±20 dB de 30 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR-2] pour présenter des niveaux d'amplitude dans la plage des hautes fréquences: de ±30 dB de 4 000 Hz à 22 KHz par rapport à la bande de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

• DEVRAIT définir la sensibilité de l'entrée audio de sorte qu'une source à tonalités sinusoïdales de 1 000 Hz lue à 90 dB d'un niveau de pression acoustique (SPL) de 90 dB (mesurée à côté du micro) produise une réponse idéale de RMS 2 500 dans une plage de 1 770 et 3 530 pour une source audio de 16 bits ou -22.3

• DEVRAIT enregistrer le flux audio de reconnaissance vocale pour que les niveaux d'amplitude PCM suivent de manière linéaire le SPL d'entrée sur une plage d'au moins 30 dB, de -18 dB à +12 dB avec 90 dB SPL au niveau du micro.

• DEVRAIT enregistrer le flux audio de reconnaissance vocale avec une distorsion harmonique totale (THD) inférieure à 1% pour 1 kHz avec un niveau d'entrée SPL de 90 dB au niveau du micro.

Si les implémentations d'appareils déclarent android.hardware.microphone et que les technologies de suppression du bruit (réduction) sont adaptées pour 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 via le champ AudioEffect.Descriptor.uuid.

5.4.3. Capturer pour réacheminer la lecture

La classe android.media.MediaRecorder.AudioSource inclut la source audio REMOTE_SUBMIX.

Si les implémentations d'appareils déclarent à la fois android.hardware.audio.output et android.hardware.microphone, elles:

• [C-1-1] DOIT implémenter correctement la source audio REMOTE_SUBMIX de sorte que lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle capture un mélange de tous les flux audio, à l'exception des suivants:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. Annulateur d'écho acoustique

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

• DEVRAIT implémenter une technologie d'annulation de l'écho acoustique (AEC) adaptée pour 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 annulant d'écho acoustique qui est inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION est sélectionné, ils:

• Les [C-SR-1] doivent pouvoir déclarer cet accès via AcousticEchoCanceler méthode API AcousticEchoCanceler.isAvailable().
• [C-SR-2] sont STRONGLY_RECOMMENDED pour permettre le contrôle de cet effet audio avec l'API AcousticEchoCanceler.
• [C-SR-3] sont STRONGLY_RECOMMENDED 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'appareils déclarent android.hardware.microphone,elles DOIVENT implémenter la capture simultanée comme décrit dans ce document. Plus spécifiquement :

• [C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité qui capture avec AudioSource.VOICE_RECOGNITION et au moins une application capturant un élément AudioSource.
• [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée détenant un rôle Assistant et au moins une application capturant n'importe quel AudioSource, à l'exception de AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] DOIT couper le son de la capture audio pour toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application capture avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application capture 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 plusieurs applications sont capturées simultanément et qu'aucune n'est dotée d'une interface utilisateur, celle qui a commencé à capturer la plus récemment reçoit du contenu audio.

5.4.6. Niveaux de gain du micro [Déplacé vers 5.4.2]

5.5. Lecture audio

Android permet d'autoriser les applications à 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'appareils déclarent android.hardware.audio.output, elles:

• [C-1-1] DOIT autoriser la lecture de contenu audio brut présentant les caractéristiques suivantes:

  • Formats sources: PCM linéaire, 16 bits, 8 bits, float
  • Canaux: configurations mono, stéréo et 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 et 48 000, selon les configurations de canaux indiquées ci-dessus
    • 96 000 en mono et stéréo

5.5.2. Effets audio

Android fournit une API pour les effets audio pour les implémentations sur les appareils.

Si les implémentations d'appareils 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 prendre en charge l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer.
• [C-1-3] DOIT prendre en charge l'implémentation de EFFECT_TYPE_DYNAMICS_PROCESSING contrôlable via la sous-classe AudioEffect DynamicsProcessing.
• DOIT prendre en charge les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlables via les sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
• [C-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge les effets en virgule flottante et multicanal.

5.5.3. Volume de sortie audio

Implémentations pour les appareils automobiles:

• DEVRAIT permettre d'ajuster le volume audio séparément pour chaque flux audio en utilisant le type ou l'utilisation de contenu 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 appareils sont compatibles avec la lecture de déchargement audio, ils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de couper le contenu audio lu entre deux clips de même format, si spécifié par l'API AudioTrack sans intervalles et le conteneur multimédia pour MediaPlayer.

5.6. Latence audio

La latence audio correspond au délai pendant lequel un signal audio traverse un système. De nombreuses classes d'applications reposent sur des latences courtes pour obtenir des effets sonores en temps réel.

Pour les besoins 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 par un transducteur sur l'appareil ou le moment où le signal quitte l'appareil via un port et peut être observé en externe.
• latence de sortie à froid. Délai entre le démarrage d'un flux de sortie et le temps de présentation de la première trame en fonction des horodatages, lorsque le système de sortie audio a été inactif et mis hors tension avant la requête.
• latence de sortie continue. Latence de sortie des trames suivantes, après que l'appareil lit du contenu audio.
• la latence d'entrée. Intervalle entre le moment où un son est présenté par l'environnement à l'appareil via un transducteur ou un signal sur l'appareil via un port et lorsqu'une application lit la trame correspondante de données codées PCM.
• perd input. Partie initiale d'un signal d'entrée qui est inutilisable ou indisponible.
• latence d'entrée à froid. Délai entre le démarrage du flux et la réception de la première trame valide, lorsque le système d'entrée audio a été inactif et mis hors tension avant la requête.
• latence d'entrée continue. Latence d'entrée des trames suivantes, pendant que l'appareil capture du contenu audio.
• la latence aller-retour continue. Somme de la latence d'entrée continue et de la latence de sortie continue plus une période de tampon. La période de mise en mémoire tampon laisse le temps à l'application de traiter le signal et le temps nécessaire à l'application pour atténuer la différence de phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon OpenSL ES PCM Ensemble des API OpenSL ES liées au PCM dans le NDK Android.
• API audio native AAudio : Ensemble d'API AAudio dans le NDK Android.
• Code temporel : Paire composée d'une position relative de trame dans un flux et du temps estimé où cette trame entre dans le pipeline de traitement audio ou en part sur le point de terminaison associé. Consultez également AudioTimestamp.
• glitch. Une interruption temporaire ou une valeur d'échantillon incorrecte dans le signal audio, généralement causée par une sous-utilisation de la mémoire tampon en sortie, un dépassement de la mémoire tampon en entrée ou toute autre source de bruit numérique ou analogique.
• écart absolu moyen. Moyenne de la valeur absolue des écarts par rapport à la moyenne pour un ensemble de valeurs.
• latence "appuyer sur ton". Délai entre le moment où l'utilisateur appuie sur l'écran et le moment où un son est généré à la suite de cette pression sur l'enceinte.

Si les implémentations d'appareils déclarent android.hardware.audio.output, ils DOIVENT respecter ou dépasser les exigences suivantes:

• [C-1-1] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/-2 ms.

• [C-1-2] Latence de sortie à 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.

Si les implémentations d'appareils déclarent android.hardware.audio.output, il est VIVEMENT RECOMMANDÉ de respecter ou de dépasser les exigences suivantes:

• [C-SR-1] Latence de sortie à froid de 100 millisecondes ou moins sur le chemin de données du locuteur.

• [C-SR-2] Latence maximale de 80 millisecondes au maximum.

• [C-SR-4] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 1 ms.

Si les implémentations d'appareils répondent aux exigences ci-dessus, après tout calibrage initial, lors de l'utilisation de l'API audio native AAudio, pour assurer la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, les deux valeurs sont les suivantes:

• [C-SR-5] VIVEMENT RECOMMANDÉ de signaler les contenus audio à faible latence en déclarant l'indicateur de fonctionnalité android.hardware.audio.low_latency.
• [C-SR-6] VIVEMENT RECOMMANDÉ pour répondre aux exigences d'un contenu audio à faible latence via l'API AAudio.
• [C-SR-7] VIVEMENT RECOMMANDÉ pour s'assurer que pour les flux qui renvoient AAUDIO_PERFORMANCE_MODE_LOW_LATENCY à partir de AAudioStream_getPerformanceMode(), la valeur renvoyée par AAudioStream_getFramesPerBurst() est inférieure ou égale à la valeur renvoyée par android.media.AudioManager.getProperty(String) pour la clé de propriété AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

Si les implémentations d'appareils ne répondent pas aux exigences de l'audio à faible latence via l'API audio native AAudio, elles:

• [C-2-1] NE DOIT PAS indiquer que l'audio à faible latence est pris en charge.

Si les implémentations d'appareils incluent android.hardware.microphone, ils DOIVENT répondre aux exigences suivantes pour l'audio d'entrée:

• [C-3-1] Limitez l'erreur dans les horodatages d'entrée, tels qu'ils sont renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 2 ms. "Erreur" désigne ici l'écart par rapport à la valeur correcte.

• [C-3-2] Latence d'entrée à froid inférieure ou égale à 500 millisecondes

• [C-3-3] L'ouverture d'un flux d'entrée à l'aide de AAudioStreamBuilder_openStream() DOIT prendre moins de 1 000 millisecondes.

Si les implémentations d'appareils incluent android.hardware.microphone, il est FORTEMENT RECOMMANDÉ de répondre à ces exigences audio d'entrée:

• [C-SR-8] Latence d'entrée froide de 100 millisecondes ou moins sur le chemin de données du micro.

• [C-SR-11] Limite l'erreur dans les horodatages d'entrée renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp à +/- 1 ms.

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

• [C-SR-12] Il est FORTEMENT RECOMMANDÉ d'avoir une latence aller-retour continue moyenne de 50 millisecondes ou moins sur 5 mesures, avec une déviation absolue moyenne inférieure à 10 ms sur au moins un chemin pris en charge.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT prendre en charge les protocoles réseau multimédias 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 de l'appareil:

• [C-1-1] DOIT prendre en charge ce codec ou ce conteneur via HTTP et HTTPS.

• [C-1-2] DOIT prendre en charge les formats de segment multimédia correspondants, tels qu'indiqués dans le tableau des formats de segment multimédia ci-dessous via le protocole brouillon de streaming en direct HTTP, version 7.

• [C-1-3] DOIT prendre en charge les formats de charge utile RTSP correspondants, comme indiqué dans le tableau RTSP ci-dessous. Pour les exceptions, veuillez consulter les notes de bas de tableau de la section 5.1.

Formats des segments média

Formats de segment	Référence(s)	Compatibilité avec le codec requise
Flux de transport MPEG-2	ISO 13818	Codecs vidéo : H264 AVC MPEG-4 SP MPEG-2 Consultez la section 5.1.8 pour en savoir plus sur H264 AVC, MPEG2-4 SP et MPEG-2. Codecs audio: AAC Consultez la section 5.1.3 pour en savoir plus sur AAC et ses variantes.
AAC avec encadrement ADTS et balises ID3	ISO 13818-7	Consultez la section 5.1.1 pour en savoir plus sur AAC et ses variantes.
WebVTT	WebVTT

RTSP (RTP, SDP)

Nom du profil	Référence(s)	Compatibilité avec le codec requise
H264 AVC	RFC 6184	Pour en savoir plus sur H264 AVC, consultez la section 5.1.8.
MP4A-LATM	RFC 6416	Consultez la section 5.1.3 pour en savoir plus sur AAC et ses variantes.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Pour en savoir plus sur le code H263, consultez la section 5.1.8.
H263-2000	RFC 4629	Pour en savoir plus sur le code 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 générique	RFC 3640	Consultez la section 5.1.3 pour en savoir plus sur AAC et ses variantes.
MP2T	RFC 2250	Pour en savoir plus, consultez la section Flux de transport MPEG-2 sous la diffusion HTTP en direct.

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec la sortie vidéo sécurisée et des 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 prendre en charge Display.FLAG_SECURE et le protocole d'affichage sans fil:

• [C-2-1] DOIT sécuriser la liaison à l'aide d'un mécanisme cryptographiquement 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 être compatibles avec Display.FLAG_SECURE et les écrans externes filaires, elles:

• [C-3-1] DOIT prendre en charge HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible à l'utilisateur.

5.9. Interface numérique pour instruments de musique (MIDI)

Si les implémentations d'appareils indiquent la compatibilité avec la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager, elles:

• [C-1-1] DOIT prendre en charge MIDI sur tous les transports matériels compatibles 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 via Bluetooth LE agissant en tant que rôle central, section 7.4.3

• [C-1-2] DOIT prendre en charge le transport logiciel MIDI entre applications (appareils MIDI virtuels)

• [C-1-3] DOIT inclure libamidi.so (compatibilité MIDI native)

• DEVRAIT prendre en charge le mode périphérique MIDI via USB, section 7.7

5.10. Audio professionnel

Si les implémentations d'appareils indiquent la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles:

• [C-1-1] DOIT signaler la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
• [C-1-2] DOIT présenter une latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, de 25 millisecondes ou moins sur au moins un chemin pris en charge.
• [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec les modes hôte USB et périphérique USB.
• [C-1-4] DOIT signaler la prise en charge de la fonctionnalité android.software.midi.
• [C-1-5] DOIT respecter les latences et les exigences audio USB à l'aide de l'API AAudio native audio et de AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
• [C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
• [C-1-7] DOIT avoir une latence d'entrée à froid de 200 millisecondes ou moins.
• [C-1-8] DOIT avoir une latence moyenne "Tap-to-tone" de 80 millisecondes ou moins sur au moins cinq mesures sur le chemin de données entre le haut-parleur et le micro.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de respecter les latences telles que définies dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur 5 mesures avec une écart absolue moyenne inférieure à 5 millisecondes sur le chemin entre le haut-parleur et le micro.
• [C-SR-2] Sont FORTEMENT RECOMMANDÉS pour répondre aux exigences de Pro Audio pour la latence audio aller-retour continue, la latence d'entrée à froid et la latence de sortie à froid, et les exigences audio USB en utilisant l'API audio natif AAudio sur le chemin MMAP.

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de fournir un niveau de performances constant du processeur lorsque l'audio est actif et que la charge du processeur varie. Vous devez tester cette fonctionnalité à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel s'exécutant sur un framework audio simulé qui mesure les performances du système. Pour en savoir plus sur les analyses comparatives, consultez la documentation SynthMark. L'application SynthMark doit être exécutée à l'aide de l'option "Test automatisé" et obtenir les résultats suivants:

  • voicemark.90 >= 32 voix
  • latencemark.Fix.little <= 15 ms
  • latencemark.dynamic.little <= 50 ms

• DOIT minimiser les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.

• DEVRAIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.

• DEVRAIT minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil.

• DEVRAIT minimiser la latence audio sur l'audio numérique USB.

• DEVRAIT documenter les mesures de latence audio sur tous les chemins.

• DOIT réduire la gigue dans les temps d'entrée du rappel de fin de tampon audio, car cela affecte le pourcentage utilisable de la bande passante complète du processeur par le rappel.

• DEVRAIT ne fournir aucun problème audio dans des conditions d'utilisation normale et avec une latence signalée.

• DEVRAIT ne fournir aucune différence de latence entre les canaux.

• DEVRAIT minimiser la latence moyenne MIDI sur tous les transports.

• DEVRAIT minimiser la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.

• DEVRAIT fournir des horodatages MIDI précis pour tous les transports.

• DOIT minimiser le bruit du signal audio sur les transducteurs de l'appareil, y compris la période qui suit le démarrage à froid.

• DEVRAIT ne fournir aucune différence d'horloge audio entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Les points de terminaison correspondants incluent le micro et le haut-parleur de l'appareil, ou les entrées et sorties du connecteur audio.

• DEVRAIT gérer les rappels d'achèvement du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et saisir le rappel de sortie immédiatement après le retour du rappel d'entrée. S'il n'est pas possible de gérer les rappels sur le même thread, saisissez le rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à l'application d'avoir une synchronisation cohérente des côtés d'entrée et de sortie.

• DEVRAIT minimiser la différence de phase entre la mise en mémoire tampon audio HAL pour les côtés entrée et sortie des points de terminaison correspondants.

• DEVRAIT minimiser la latence tactile.

• DEVRAIT minimiser la variabilité de la latence tactile en cas de charge (gigue).

Si les implémentations d'appareils répondent à toutes les exigences ci-dessus, elles:

• [C-SR-4] FORTEMENT RECOMMANDÉ de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs, ils:

• [C-2-1] DOIT avoir une latence audio aller-retour continue moyenne, telle que définie dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur 5 mesures avec un écart absolu inférieur à 5 millisecondes sur le chemin du connecteur audio à l'aide d'un dongle de bouclage audio.
• [C-SR-5] FORTEMENT RECOMMANDÉ de respecter la section Caractéristiques des appareils mobiles (connecteurs) de la page Caractéristiques du casque audio filaire (v1.1).

Si les implémentations d'appareils omettent de fournir un connecteur audio 3, 5 mm à 4 conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB:

• [C-3-1] DOIT implémenter la classe audio USB.
• [C-3-2] DOIT avoir une latence audio aller-retour continue moyenne de 25 millisecondes ou moins, supérieure à 5 mesures avec une écart absolue moyenne inférieure à 5 millisecondes sur le port en mode hôte USB utilisant la classe audio USB. (cela peut être mesuré à l'aide d'un adaptateur USB-3,5 mm et d'un dongle de bouclage audio, ou à l'aide d'une interface audio USB avec des câbles de raccordement reliant les entrées aux sorties).
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à 8 canaux par direction, un taux d'échantillonnage de 96 kHz et une profondeur de 24 bits ou 32 bits, en cas d'utilisation avec des périphériques audio USB qui répondent également à ces exigences.
• [C-SR-7] Il est FORTEMENT RECOMMANDÉ de répondre à ce groupe d'exigences en utilisant l'API audio native AAudio sur le chemin MMAP.

Si les appareils incluent un port HDMI, ils:

• DEVRAIT prendre en charge une sortie en stéréo et 8 canaux à une profondeur de 20 ou 24 bits et à 192 kHz sans perte de profondeur de bits ni rééchantillonnage, dans au moins une configuration.

5.11. Capturer pour les éléments non traités

Android prend en charge l'enregistrement de contenu audio non traité via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, vous pouvez y accéder à l'aide du préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si les implémentations d'appareils ont l'intention de prendre en charge une source audio non traitée et de la mettre à la disposition des applications tierces:

• [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 amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-3] DOIT présenter des niveaux d'amplitude dans la plage des basses fréquences, plus précisément de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-4] DOIT présenter des niveaux d'amplitude dans la plage des hautes fréquences, spécifiquement de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-5] DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalités sinusoïdales de 1 000 Hz lue à un niveau de pression sonore (SPL) de 94 dB génère une réponse avec un RMS de 520 pour les échantillons de 16 bits (ou une échelle complète de -36 dB pour les échantillons audio non précis/à virgule flottante) pour chaque micro utilisé pour enregistrer la source audio non précisée.

• [C-1-6] DOIT avoir un rapport signal sur bruit (SNR) de 60 dB ou plus pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que le rapport SNR correspond à la différence entre une valeur SPL de 94 dB et une valeur SPL équivalente de bruit propre, pondérée A).

• [C-1-7] DOIT avoir une distorsion harmonique totale (THD) inférieure à 1% pour 1 kHZ à un niveau d'entrée SPL de 90 dB sur chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-8] NE DOIT PAS comporter d'autre traitement de signal (contrôle automatique du gain, filtre passe-haut ou annulation de l'écho, par exemple) dans le chemin autre qu'un multiplicateur de niveau pour régler le niveau dans la plage souhaitée. Autrement dit :

  • [C-1-9] Si l'architecture comporte un traitement de signal pour une raison quelconque, il DOIT être désactivé et introduire zéro délai ou une latence supplémentaire dans le chemin du signal.
  • [C-1-10] Le multiplicateur de niveau, bien qu'il soit autorisé à se trouver sur le chemin, NE DOIT PAS introduire de délai ni de latence dans le chemin du signal.

Toutes les mesures SPL sont effectuées directement à côté du micro testé. Si plusieurs micros sont configurés, ces exigences s'appliquent à chaque micro.

Si les implémentations d'appareils déclarent android.hardware.microphone, mais que la source audio non traitée n'est pas compatible:

• [C-2-1] DOIT renvoyer null pour la méthode API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) afin d'indiquer correctement l'absence de compatibilité.
• [C-SR-1] est toujours VIVEMENT RECOMMANDÉ pour répondre à autant d'exigences concernant le chemin de 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 de pixel

Si un décodeur vidéo annonce la prise en charge du format COLOR_FormatYUVP010, alors:

• [C-1-1] DOIT prendre en charge le format P010 pour la lecture par processeur (ImageReader, MediaImage, ByteBuffer). Dans Android 13, P010 est assoupli pour permettre un pas arbitraire pour les plans Y et UV.

• [C-1-2] Le tampon de sortie P010 DOIT pouvoir être échantillonné par le GPU (lorsqu'il est alloué avec l'utilisation de GPU_SAMPLING). Cela permet la composition GPU et le mappage des tons personnalisé par les applications.

Si un décodeur vidéo annonce la prise en charge du format COLOR_Format32bitABGR2101010, il:

• [C-2-1] DOIT être compatible avec le format RGBA_1010102 pour la surface de sortie et lisible par le processeur (sortie ByteBuffer).

Si un encodeur vidéo annonce la prise en charge du format COLOR_FormatYUVP010, il:

• [C-3-1] DOIT être compatible avec le format P010 pour la surface d'entrée et l'entrée en écriture sur le processeur (ImageWriter, MediaImage, ByteBuffer).

Si un encodeur vidéo annonce la prise en charge du format COLOR_Format32bitABGR2101010, il:

• [C-4-1] DOIT prendre en charge le format RGBA_1010102 pour la surface d'entrée et l'entrée avec écriture sur le processeur (ImageWriter, ByteBuffer). Remarque: la conversion entre différentes courbes de transfert n'est PAS nécessaire pour les encodeurs.

Conditions requises pour la capture HDR

Pour tous les encodeurs vidéo compatibles avec les profils HDR, les implémentations d'appareils suivantes:

• [C-5-1] NE DOIT PAS supposer que les métadonnées HDR sont précises. Par exemple, la trame encodée peut comporter des pixels au-delà du niveau de luminance maximale, ou l'histogramme peut ne pas être représentatif de la trame.

• DEVRAIT 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 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:

• [C-6-1] DOIT être également compatible avec la capture HDR via les API Camera2.

• [C-6-2] DOIT être compatible avec au moins un encodeur vidéo avec accélération matérielle pour chaque technologie HDR compatible.

• [C-6-3] DOIT prendre en charge (au minimum) la capture HLG.

• [C-6-4] DOIT être compatible avec l'écriture des métadonnées HDR (le cas échéant) dans le fichier vidéo capturé. Pour AV1, HEVC et DolbyVision, cela implique d'inclure les métadonnées dans le flux de bits encodé.

• [C-6-5] DOIT prendre en charge P010 et COLOR_FormatYUVP010.

• [C-6-6] DOIT prendre en charge le mappage des tons HDR vers SDR dans le décodeur avec accélération matérielle par défaut pour le profil capturé. En d'autres termes, si un appareil peut capturer des images HEVC HDR10+, le décodeur HEVC par défaut DOIT pouvoir décoder le flux capturé en SDR.

Conditions requises pour la retouche HDR

Si les implémentations d'appareils incluent des encodeurs vidéo compatibles avec le montage HDR, ils:

• DEVRAIT utiliser une latence minimale pour générer les métadonnées HDR lorsqu'elles ne sont pas présentes, et DEVRAIT gérer correctement les cas où les métadonnées sont présentes pour certaines images et pas pour d'autres. Ces métadonnées DOIVENT être précises (elles doivent par exemple représenter la luminance maximale réelle et l'histogramme de la trame).

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 prendre en charge la fonctionnalité FEATURE_HdrEditing pour tous les profils HDR promus par ce codec. En d'autres termes, ils DOIVENT prendre en charge la génération de métadonnées HDR lorsqu'ils ne sont pas disponibles pour tous les profils HDR compatibles qui utilisent ces métadonnées.

• [C-7-3] DOIT être compatible avec les formats d'entrée suivants de l'encodeur vidéo, qui conservent entièrement le signal décodé HDR:

  • RGBA_1010102 (déjà dans la courbe de transfert cible) pour la surface d'entrée et pour ByteBuffer et DOIT annoncer la prise en charge de COLOR_Format32bitABGR2101010.

Si l'implémentation de l'appareil inclut des codecs compatibles avec FEATURE_HdrEditing, l'appareil:

• [C-7-4] DOIT indiquer la compatibilité avec l'extension OpenGL EXT_YUV_target.

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

6.1. Outils pour les développeurs

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans le SDK Android.

• Android Debug Bridge (adb)

  • [C-0-2] DOIT prendre en charge adb, comme indiqué dans le SDK Android et les commandes shell fournies dans AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys. cmd stats
  • [C-0-11] DOIT prendre en charge 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 l'autorisation 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, charts, netstats, notification, procstats) enregistrés via 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 System StatsManager.
    • État de premier plan de l'activité modifié
    • Anomalie détectée
    • Fil d'Ariane signalé
    • AppCrashOccured
    • AppStartOccurred (Démarrage de l'application)
    • Niveau de batterie modifié
    • État du mode d'économie de batterie modifié
    • BleScanResultReceived (Résultat reçu)
    • BleScanStateChanged
    • État de facturation modifié
    • DeviceIdleModeStateChanged
    • État du service de premier plan modifié
    • GpsScanStateChanged
    • État du job modifié
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • État de l'écran modifié
    • SyncStateChanged (État de synchronisation modifié)
    • SystèmeElapsedRealtime
    • UidProcessStateChanged
    • État du wakelock modifié
    • Alarme du réveilSure
    • État du verrouillage du Wi-Fi modifié
    • État du verrouillage WifiMulticast modifié
    • État du Wi-Fi modifié
  • [C-0-4] DOIT avoir le daemon adb côté appareil inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer le pont de débogage Android.
  • [C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Le service adb sécurisé active adb sur des hôtes authentifiés connus.
  • [C-0-6] DOIT fournir un mécanisme permettant à adb d'être connecté à partir d'une machine hôte. Plus spécifiquement :

  Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, celles-ci:

  • [C-3-1] DOIT implémenter adb via un réseau local (par exemple, Ethernet ou 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 faire en sorte que la méthode AdbManager#isAdbWifiSupported() renvoie true.

  Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi ou Ethernet et incluent au moins une caméra, ils:

  • [C-5-1] DOIT faire en sorte que la méthode AdbManager#isAdbWifiQrSupported() renvoie true.

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android. Étant donné que 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 ci-dessus.

• SysTrace

  • [C-0-9] DOIT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir 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 de shell dont la ligne de commande est conforme à la documentation de Perfetto.
  • [C-SR-2] Il est VIVEMENT RECOMMANDÉ d'accepter comme entrée une configuration protobuf conforme au schéma défini dans la documentation de Perfetto pour le binaire Perfetto.
  • [C-SR-3] Il est VIVEMENT RECOMMANDÉ d'écrire le binaire Perfetto pour écrire en sortie une trace de tampon de protocole conforme au schéma défini dans la documentation de 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 de Perfetto.

• Tueur de mémoire faible

  • [C-0-12] DOIT écrire un élément Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le tueur de mémoire faible.

• Mode Harness de test Si les implémentations d'appareils acceptent 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 faisceau de test comme décrit dans la documentation sur le mode faisceau de test.

• Informations sur les GPU

  Implémentations pour les appareils:

  • [C-0-13] DOIT implémenter la commande shell dumpsys gpu --gpuwork pour afficher les données de travail agrégées 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 prise en charge de Vulkan 1.0 ou version ultérieure via les flags de fonctionnalité android.hardware.vulkan.version, elles:

• [C-1-1] DOIT fournir une affordance au développeur de l'application pour activer/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 des bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie du package de plate-forme ou d'application) qui se trouvent dans le répertoire de base des applications débogables afin de prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties et vkCreateInstance().

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:

• [C-0-1] DOIT respecter l'intent 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 "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 (7) fois sur Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version).
• [C-0-2] DOIT masquer les options pour les développeurs par défaut.
• [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas un traitement préférentiel à une application tierce plutôt qu'à une autre afin d'activer les Options pour les développeurs. DOIT fournir un document ou un site Web visible par le public expliquant comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible via un lien depuis les documents du SDK Android.
• DEVRAIT afficher une notification visuelle en continu à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
• PEUT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant ou en le désactivant visuellement, afin d'éviter toute distraction dans les cas où la sécurité de l'utilisateur est préoccupante.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier 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ésigné 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 des composants DOIVENT toujours être présentées.
• [C-0-3] Les comportements de l'API DOIVENT être implémentés en tant que no-ops de manière raisonnable.
• [C-0-4] Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK le permet.
• [C-0-5] Les méthodes API DOIVENT renvoyer des implémentations no-op de classes dans lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• [C-0-6] Les méthodes 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 indiquer de manière cohérente des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte de build.

L'API de téléphonie est un exemple type de scénario dans lequel ces exigences s'appliquent. Même sur des appareils autres que des téléphones, ces API doivent être implémentées de manière à être implémentées de manière raisonnable.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et la mise en page de l'interface utilisateur en fonction de l'appareil afin de garantir que les applications tierces s'exécutent correctement sur différentes configurations matérielles. Sur les écrans compatibles Android sur lesquels toutes les applications tierces compatibles Android peuvent s'exécuter, les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme détaillé dans cette section.

Les unités référencées par les exigences de cette section sont définies comme suit:

• taille physique en diagonale. Distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
• points par pouce (PPP). Nombre de pixels englobés par une étendue linéaire (horizontale ou verticale) de 1". Lorsque les valeurs dpi sont répertoriées, les dpi horizontal et vertical doivent être compris dans la plage.
• format. Rapport entre le nombre de pixels de la dimension la plus longue et la dimension la plus courte de l'écran. Par exemple, un affichage de 480 x 854 pixels serait 854/480 = 1,779, soit approximativement "16:9".
• pixel indépendant de la densité (dp). Unité de pixel virtuel normalisée sur un écran de 160 ppp, calculée comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

Taille et forme de l'écran

Le framework d'UI Android est compatible avec différentes tailles logiques de mise en page d'écran et permet aux applications d'interroger la taille de mise en page de la configuration actuelle via Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK et Configuration.smallestScreenWidthDp.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer 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 d'écran en pixels indépendants de la densité (dp) correctes, comme indiqué ci-dessous:

  • Les appareils dont le Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_WATCH et qui signalent une taille small pour Configuration.screenLayout DOIVENT avoir au moins 426 dp x 320 dp.
  • Les appareils indiquant une taille normal pour Configuration.screenLayout DOIVENT avoir au moins 480 dp x 320 dp.
  • Les appareils indiquant une taille large pour Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
  • Les appareils indiquant une taille xlarge pour Configuration.screenLayout DOIVENT avoir au moins 960 dp x 720 dp.

• [C-0-2] DOIT respecter correctement la prise en charge déclarée des tailles d'écran par les applications via l'attribut <supports-screens> du fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.

• PEUVENT disposer d'un ou plusieurs écrans compatibles avec Android aux angles arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent un ou plusieurs écrans compatibles avec Android aux angles arrondis, ils:

• [C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est satisfaite:

  • Le rayon des angles arrondis est inférieur ou égal à 38 dp.
  • Lorsqu'une zone de 15 dp par 15 dp est ancrée à chaque coin de l'affichage logique, au moins un pixel de chaque zone est visible à l'écran.

• DEVRAIT inclure l' affordance de l'utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou qui incluent une charnière pliable entre plusieurs écrans et permettent à ces écrans d'afficher des applications tierces:

• [C-2-1] DOIT implémenter la dernière version stable disponible de l'API Extensions ou de la version stable de l'API side-car qui sera utilisée par la bibliothèque Window Manager Jetpack.

Si les implémentations d'appareils incluent un écran pliable compatible avec Android ou une charnière pliable entre plusieurs écrans, et si la charnière ou le pli traverse une fenêtre d'application en plein écran, ils:

• [C-3-1] DOIT indiquer à l'application la position, les limites et l'état de la charnière ou du pli par l'intermédiaire d'extensions ou d'API side-car.

Pour savoir comment implémenter correctement les API side-car ou d'extension, consultez la documentation publique de Window Manager Jetpack.

Format de l'écran

Bien qu'il n'existe aucune restriction concernant le format de l'écran physique pour les écrans compatibles avec Android, le format de l'écran logique sur lequel les applications tierces sont affichées, qui peuvent être dérivés des valeurs de hauteur et de largeur transmises par les API view.Display et les API Configuration, DOIT répondre aux exigences suivantes:

• [C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format inférieur ou égal à 1,86 (environ 16:9), sauf si l'application remplit l'une des conditions suivantes:

  • L'application a déclaré qu'elle était compatible avec un format d'écran plus grand via la valeur de métadonnées android.max_aspect.
  • L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
  • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de android:maxAspectRatio qui limiterait le format autorisé.

• [C-0-3] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_WATCH DOIVENT avoir un format de 1.0 (1:1).

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.

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT indiquer une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE. Cette valeur NE DOIT PAS changer à aucun moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications apportées à la configuration d'affichage par l'utilisateur (par exemple, la taille d'affichage) définies après le démarrage initial.

• Les implémentations d'appareils DOIVENT définir la densité standard du framework Android la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique pousse la taille d'écran indiquée en dessous de la taille minimale acceptée. Si la densité du framework Android standard la plus proche numériquement de la densité physique se traduit par une taille d'écran inférieure à la plus petite taille d'écran compatible compatible (largeur de 320 dp), les implémentations d'appareils DOIVENT indiquer la deuxième densité de framework standard Android la plus basse.

S'il existe une affordance pour modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle au-delà de 1,5 fois la densité native ou produire une dimension minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
• [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle en dessous de 0,85 fois la densité native.
• Pour garantir une bonne facilité d'utilisation et la cohérence des tailles de police, 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).
  • S: x 0,85
  • Par défaut: 1x (échelle d'affichage natif)
  • Grande: x 1,15
  • Plus grande: x1,3
  • Plus grande x 1,45

Métriques sur le Réseau Display

Si les implémentations d'appareils incluent un ou plusieurs écrans ou sorties vidéo compatibles avec Android sur un ou plusieurs écrans compatibles, elles:

• [C-1-1] DOIT indiquer des 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 ou de sortie vidéo intégrés, ils:

• [C-2-1] DOIT indiquer les valeurs correctes de l'affichage compatible avec Android, tel que défini dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation compatible. Par exemple, un appareil avec un écran à orientation fixe en mode paysage, tel qu'un téléviseur ou un ordinateur portable, DOIT signaler uniquement android.hardware.screen.landscape.
• [C-0-2] DOIT indiquer la valeur correcte pour l'orientation actuelle de l'appareil chaque fois qu'elle est interrogée via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Si les implémentations d'appareils sont compatibles avec les deux orientations d'écran:

• [C-1-1] DOIT prendre en charge l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la requête de l'application pour une orientation d'écran spécifique.
• [C-1-2] NE DOIT PAS modifier la taille ni la densité d'écran indiquées lors du changement d'orientation.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations pour les appareils:

• [C-0-1] DOIT identifier correctement les versions d'OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (telles que la méthode GLES10.getString()) et les API natives.
• [C-0-2] DOIT inclure la compatibilité avec toutes les API gérées et API natives correspondantes pour chaque version d'OpenGL ES qu'elles ont identifiée comme compatible.

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué dans la documentation du SDK Android.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
• DEVRAIT prendre en charge OpenGL ES 3.2.

Les tests dEQP d'OpenGL ES sont partitionnés en plusieurs listes de tests, chacune étant associée à une date/un numéro de version. Ils se trouvent dans l'arborescence source Android sur external/deqp/android/cts/main/glesXX-main-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 test à partir de ce niveau.

Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

• [C-2-1] DOIT signaler via les API gérées et les API natives OpenGL ES toute autre extension OpenGL ES mise en œuvre, et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.
• [C-2-2] DOIT prendre en charge 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 indiquer la version maximale des tests dEQP d'OpenGL ES compatibles avec le flag de fonctionnalité android.software.opengles.deqp.level.
• [C-2-4] DOIT être au moins compatible avec la version 132383489 (à partir du 1er mars 2020), comme indiqué 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 l'indicateur de fonctionnalité android.software.opengles.deqp.level, pour chaque version OpenGL ES compatible.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
• DEVRAIT enregistrer avec précision via la méthode getString(), tout format de compression de texture compatible, qui est généralement spécifique au fournisseur.
• DEVRAIT prendre en charge les extensions EGL_IMG_context_priority et EGL_EXT_protected_content.

Si les implémentations d'appareils déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles:

• [C-3-1] DOIT exporter les symboles de fonction correspondants à cette version en plus des symboles de fonction OpenGL ES 2.0 de la bibliothèque libGLESv2.so.
• [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour la compatibilité avec l'extension OES_EGL_image_external_essl3.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.2, celles-ci:

• [C-4-1] DOIT prendre en charge le pack d'extensions Android OpenGL ES dans son intégralité.

Si les implémentations d'appareils sont compatibles avec le pack d'extensions Android OpenGL ES dans son intégralité, celles-ci:

• [C-5-1] DOIT identifier la compatibilité via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils sont compatibles 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 pour des graphismes 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, celles-ci:

• [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 de variante Vulkan (autrement dit, la partie variante de la version principale de Vulkan DOIT être nulle).

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

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.3.

Les tests dEQP de Vulkan sont partitionnés en plusieurs listes de test, chacune avec une date/une version associée. Ils se trouvent dans l'arborescence source Android sur external/deqp/android/cts/main/vk-main-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 test de ce niveau et des versions antérieures.

Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, 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 élément VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] DOIT mettre en œuvre complètement les API Vulkan 1.0 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 de bibliothèque native du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties().
• [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de traçage ou d'interception de l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
• [C-1-6] DOIT indiquer toutes les chaînes d'extension compatibles avec les API natives Vulkan et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'ils ne prennent pas correctement en charge.
• [C-1-7] DOIT prendre en charge les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
• [C-1-8] DOIT indiquer la version maximale des tests dEQP Vulkan compatibles avec l'indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-9] DOIT être compatible avec la version 132317953 au moins (à partir du 1er mars 2019), comme indiqué 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 l'indicateur 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 VK_KHR_driver_properties et VK_GOOGLE_display_timing.
• DEVRAIT prendre en charge VkPhysicalDeviceProtectedMemoryFeatures et VK_EXT_global_priority.
• [C-1-12] NE DOIT PAS énumérer la compatibilité avec l'extension VK_KHR_performance_query.
• [C-SR-4] Sont FORTEMENT RECOMMANDÉS pour répondre aux exigences spécifiées par le profil Android Baseline 2021.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer d'indicateur de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level ou 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 sont compatibles avec Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan:

• [C-3-1] DOIT exposer la prise en charge des types de sémaphore et de handle externes SYNC_FD ainsi que l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT prendre en charge 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 des graphismes 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue via l'utilisation d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations pour les appareils:

• [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT désactiver l'accélération matérielle si le développeur le 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 cohérent avec la documentation du SDK Android concernant l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans larges

Si les implémentations d'appareils sont compatibles avec les écrans larges via Configuration.isScreenWideColorGamut() , elles:

• [C-1-1] DOIT disposer d'un écran calibré pour les couleurs.
• [C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
• [C-1-3] DOIT disposer d'un écran dont la gamme présente une aire d'au moins 90% de la DCI-P3 dans l'espace xyY CIE 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et les signaler correctement.
• [C-1-5] DOIT faire la promotion 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] EST VIVEMENT RECOMMANDÉ d'utiliser GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans larges, ils:

• [C-2-1] DOIT couvrir 100% ou plus du sRVB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

Mode de compatibilité des anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" (largeur 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android qui sont antérieures à la taille d'écran indépendante.

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 prendre en charge toutes ces API telles que définies par le SDK Android, sauf si elles sont spécifiquement autorisées 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 images en couleurs 16 bits.
• DEVRAIT prendre en charge les écrans compatibles avec des graphismes en couleurs 24 bits.
• [C-0-2] DOIT être capable d'afficher des animations.
• [C-0-3] DOIT avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le rapport hauteur/largeur des pixels DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

Écrans secondaires

Android prend en charge les écrans secondaires compatibles avec Android afin d'activer les fonctionnalités de partage multimédia et les API de développement permettant d'accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou d'un écran supplémentaire intégré, ils:

• [C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un mécanisme d'entrée, tel qu'un écran tactile ou une navigation non tactile, pour naviguer entre les éléments de l'interface utilisateur.

7.2.1. Clavier

Si les implémentations d'appareils sont compatibles avec les applications tierces de l'éditeur de mode de saisie (IME, Input Method Editor), elles:

• [C-1-1] DOIT déclarer l'indicateur de fonctionnalité android.software.input_methods.
• [C-1-2] DOIT implémenter intégralement Input Management Framework
• [C-1-3] DOIT disposer d'un clavier virtuel préinstallé.

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.Keyboard (QWERTY ou 12 touches).
• DEVRAIT inclure des implémentations de clavier virtuel supplémentaires.
• PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android prend en charge le pavé directionnel, le trackball et la molette en tant que mécanismes de navigation non tactile.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

• [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du 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 d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour généralement fournies via 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 des applications installées dont l'activité <intent-filter> est définie avec ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations de télévision. La fonction Accueil DOIT être le mécanisme de cette affordance utilisateur.
• DEVRAIT 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 (appuyer, double-cliquer ou faire un geste, par exemple) si l'un de ces éléments est accessible.
• [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Il peut s'agir, par exemple, d'une icône visible imprimée sur le bouton, d'une icône de logiciel dans la partie de la barre de navigation de l'écran ou d'une procédure de démonstration guidée par étapes lors de la configuration prête à l'emploi.

Implémentations pour les appareils:

• [C-SR-1] est VIVEMENT RECOMMANDÉ de ne pas fournir le mécanisme d'entrée pour la fonction de menu, car elle est abandonnée au profit de la barre d'action depuis Android 4.0.

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir toutes les fonctions de navigation comme annulables. L'option "Annulable" est définie comme la capacité de l'utilisateur à empêcher l'exécution de la fonction de navigation (par exemple, revenir à l'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 intègrent la fonction Menu, celles-ci:

• [C-2-1] DOIT afficher le bouton à développer d'actions chaque fois que le pop-up du menu à développer d'actions n'est pas vide et que la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position du pop-up de dépassement d'action affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher le pop-up de dépassement d'action à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils ne fournissent pas la fonction Menu, pour assurer la rétrocompatibilité, elles : * [C-3-1] DOIT mettre la fonction Menu à disposition des applications lorsque la valeur de targetSdkVersion est inférieure à 10, que ce soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction Menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils fournissent la fonction d'assistance, elles:

• [C-4-1] DOIT rendre la fonction Assist accessible en une seule action (appui, double-clic ou geste, par exemple) lorsque d'autres touches de navigation sont accessibles.
• [C-SR-3] FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction HOME pour cette 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 accessible aux applications, et NE DOIVENT PAS obscurcir ni interférer avec la partie de l'écran accessible aux 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 API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (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 à l'écran basée sur un geste:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() NE DOIT être utilisé que pour signaler la zone de reconnaissance de gestes d'accueil.
• [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion tel que fourni par l'application au 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, comme spécifié dans la documentation pour View#setSystemGestureExclusionRects().
• [C-6-3] DOIT envoyer à l'application de premier plan un événement MotionEvent.ACTION_CANCEL une fois que les gestes commencent à être interceptés pour un geste système par l'application au premier plan, si l'application au premier plan a déjà envoyé un événement MotionEvent.ACTION_DOWN.
• [C-6-4] DOIT fournir une affordance à l'utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
• DEVRAIT fournir la fonction d'accueil sous la forme d'un balayage vers le haut à partir du bord inférieur de l'orientation actuelle de l'écran.
• DEVRAIT fournir la fonctionnalité "Récents" : balayez l'écran vers le haut et maintenez la pression avant de relâcher, depuis la même zone que le geste d'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 depuis n'importe où sur les bords gauche et droit de l'orientation actuelle de l'écran:

• [C-7-1] La fonction de navigation DOIT être "Retour" et être fournie sous forme de balayage à partir des bords gauche et droit de l'orientation actuelle de l'écran.
• [C-7-2] Si des panneaux système à faire glisser personnalisés 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 que le fait de faire glisser l'écran appellera les panneaux mentionnés ci-dessus, et non "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se retrouve sous le tiers supérieur du ou des bords de l'écran, mais il NE DOIT PAS utiliser plus d'un tiers des bords.
• [C-7-3] Lorsque l'application au premier plan dispose des options View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BAHAVIOR_SHOW_TRANSIENT_BAHAVIOR_SHOW_TRANSIENT_BAHAVIOR_SHOW_TRANSIENT_BAPRS_SWIPE.
• [C-7-4] Lorsque l'application au premier plan comporte soit View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT.

Si la fonction de navigation vers l'arrière est fournie et que l'utilisateur annule le geste de 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 envoyé.

Si la fonction de navigation vers l'arrière est fournie, mais que l'application de premier plan n'a PAS de OnBackInvokedCallback enregistré, procédez comme suit:

• 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'appareils prennent en charge 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 barre de navigation, alors:

• [C-9-1] DOIT prendre en charge les icônes adaptées aux enfants ou la navigation basée sur des boutons, comme indiqué dans le code AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée de 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 ait 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 affordance supplémentaire pour indiquer les objets manipulés.

Implémentations pour les appareils:

• DEVRAIT disposer d'un système d'entrée de pointeur (de type souris ou tactile).
• DEVRAIT prendre en charge les pointeurs suivis de manière totalement indépendante.

Si les implémentations d'appareils incluent un écran tactile (simple ou mieux) sur un écran principal compatible avec Android:

• [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
• [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 permettant de suivre plusieurs pressions sur un écran principal compatible avec Android, celles-ci:

• [C-2-1] DOIT signaler les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand, qui correspondent au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils dépendent d'un périphérique d'entrée externe tel qu'une souris ou un trackball (c'est-à-dire qu'ils ne touchent pas directement l'écran) pour la saisie sur un écran principal compatible avec Android et répondent aux exigences concernant les gestes tactiles simulés de la section 7.2.5, ils:

• [C-3-1] NE DOIT PAS signaler d'indicateur de fonctionnalité commençant par android.hardware.touchscreen.
• [C-3-2] DOIT signaler uniquement android.hardware.faketouch.
• [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

Saisie tactile simulée

L'interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités de l'écran tactile. Par exemple, une souris ou une télécommande qui pilote un curseur à l'écran se rapproche d'un geste tactile, mais nécessite que l'utilisateur pointe d'abord ou sélectionne un élément, puis clique. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris aérienne à gyroscope, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles fictives. Android inclut la constante android.hardware.faketouch, qui correspond à un périphérique d'entrée haute fidélité non tactile (basé sur un pointeur), tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie 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 tactiles.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie de pointeur qu'ils souhaitent proposer, ils:

• DEVRAIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch, elles:

• [C-1-1] DOIT indiquer les positions X et Y absolues 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 sur le pointeur descendant ou vers le haut de l'écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le haut et le bas 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 pointeurs vers le bas, vers le haut, vers le bas, puis vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler le double appui sur un objet à l'écran.
• [C-1-5] DOIT prendre en charge le pointeur vers un point arbitraire de l'écran, qui se déplace vers n'importe quel autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un déplacement tactile.
• [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de le pointer vers le haut, ce qui permet aux utilisateurs de faire glisser un objet sur l'écran.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.distinct, elles:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT prendre en charge le suivi distinct d'au moins deux entrées de pointeur indépendantes.

Si les implémentations d'appareils déclarent prendre en charge 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 un suivi distinct de 5 (suivi d'une main des doigts) ou plus d'entrées de pointeur de manière entièrement indépendante.

Compatibilité avec les manettes de jeu

Mappages de boutons

Implémentations pour 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 une manette ou sont livrées avec une manette distincte dans la boîte permettant 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 HID2	Bouton Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0 x 09, 0 x 0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
O1	0x09 0x0005	KEYCODE_BOUTON_Y (100)
Pavé directionnel vers le haut1 Pavé directionnel descendant1	0x01 0x00393	AXIS_HAT_Y4
Pavé directionnel gauche1 Pavé directionnel droit1	0x01 0x00393	AXIS_HAT_X4
Bouton de l'épaule gauche1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1	0x09 0x0008	KEYCODE_BOUTON_R1 (103)
Clic gauche1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Effectuer un clic avec le stick droit1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Retour1	0x0c 0x0224	KEYCODE_BACK (4)

1 Événement clé

2 Les utilisations HID ci-dessus doivent être déclarées dans une manette de jeu CA (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, une unité en degrés et une taille de rapport de 4. La valeur logique correspond à une rotation dans le sens des aiguilles d'une montre en dehors de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et le bouton "Haut" en cours d'appui, tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et une pression sur les touches haut et gauche.

4 MotionEvent

Commandes analogiques1	Utilisation HID	Bouton Android
Gâchette gauche	0x02, 0x00C5	AXIS_LTRIGGER
Déclencheur 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

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier avec 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 pour les appareils:

• [C-0-1] DOIT indiquer avec précision la présence ou l'absence de capteurs conformément à 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 selon les cas, lorsque les applications tentent d'enregistrer des écouteurs, et non en appelant les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier doté d'une API correspondante pour les développeurs tiers, celles-ci:

• [C-1-1] DOIT indiquer toutes les mesures de capteurs en utilisant les valeurs métriques (système international d'unités) pertinentes pour chaque type de capteur, tel que défini dans la documentation du SDK Android.
• [C-1-2] DOIT indiquer les données de capteurs avec une latence maximale de 100 millisecondes + 2 * échantillon_time dans le cas d'un flux de capteurs dont la latence maximale demandée est de 0 ms lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT indiquer le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time du capteur en cours d'activation. La justesse de cet échantillon peut être 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%, la gigue étant définie comme l'écart type de la différence des valeurs d'horodatage signalées entre des é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 à l'état "suspendu" ou de sortir de l'état "suspendu".
• [C-1-6] DOIT signaler l'heure de l'événement en nanosecondes, telle que définie dans la documentation du SDK Android, représentant l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano().
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir une erreur de synchronisation de l'horodatage inférieure à 100 millisecondes, et DOIT présenter une erreur de synchronisation de l'horodatage inférieure à 1 milliseconde.
• Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie rapportée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et la documentation Open Source Android concernant les capteurs doivent être considérés comme faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier doté d'une API correspondante pour les développeurs tiers, celles-ci:

• [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler cette valeur via la méthode 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 pour les appareils:

• DEVRAIT mettre en œuvre ces types de capteurs lorsqu'ils incluent des capteurs physiques préalables, comme décrit dans la section Types de capteurs.

Si les implémentations d'appareils incluent un capteur composite, celles-ci:

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Open Source d'Android sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'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 cette valeur via la méthode 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, celles-ci:

• [C-4-1] NE DOIT PAS inclure de paramètres d'étalonnage fixes définis en usine dans les données fournies.

Si les implémentations d'appareils comprennent une combinaison d'accéléromètre à 3 axes, de gyroscope à 3 axes ou de magnétomètre, les deux sont:

• [C-SR-2] VIVEMENT RECOMMANDÉ pour garantir que l'accéléromètre, le gyroscope et l'magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes du capteur restent alignés et cohérents avec le système de coordonnées du capteur tout au long de tous les états de transformation possibles de l'appareil.

7.3.1. Accéléromètre

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre à 3 axes.

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

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-3] DOIT se conformer au système de coordonnées du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT être capable de mesurer de la chute libre jusqu'à quatre fois la gravité(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 au taux d'échantillonnage le plus rapide.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DEVRAIT avoir une résolution d'au moins 16 bits.
• DEVRAIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et compensées, et conservez les paramètres de compensation entre les redémarrages de l'appareil.
• DEVRAIT être compensé en température.

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

• [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É de répondre à cette exigence pour les appareils Android afin de pouvoir effectuer une mise à niveau vers la prochaine version de la plate-forme, qui pourrait devenir OBLIGATOIRE.
• DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document 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] Sont STRONGLY_RECOMMENDED pour implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils incluent un accéléromètre à 3 axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER est implémenté:

• [C-4-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DOIT être inférieure à 2 mW et à 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les implémentations d'appareils incluent un accéléromètre à 3 axes et un capteur de gyroscope à 3 axes, ils:

• [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 à 3 axes, un gyroscope à 3 axes et un magnétomètre, ils:

• [C-6-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à 3 axes.

Si les implémentations d'appareils incluent un magnétomètre à 3 axes, ils:

• [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
• [C-1-2] DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DOIT rapporter des événements dont la fréquence est d'au moins 50 Hz.
• [C-1-3] DOIT être conforme au système de coordonnées du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT être capable de mesurer entre -900 μT et +900 μT sur chaque axe avant la saturation.
• [C-1-5] DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et une valeur inférieure à 200 μT, en plaçant le magnétomètre éloigné 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 l'étalonnage et la compensation en ligne du biais du fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] DOIT appliquer la compensation du fer doux. L'étalonnage peut être effectué en cours d'utilisation ou pendant 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 3 secondes au taux d'échantillonnage le plus rapide, ne dépassant pas 1,5 μT ; DOIT avoir un écart type inférieur à 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 à 3 axes, un capteur d'accéléromètre et un gyroscope à 3 axes, ils:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils comprennent un magnétomètre à 3 axes (un accéléromètre), ils:

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à 3 axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, ils:

• [C-3-1] DOIT consommer moins de 10 mW.
• DEVRAIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode de traitement par lot à 10 Hz.

7.3.3. GPS

Implémentations pour 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 cette fonctionnalité aux applications via le flag de fonctionnalité android.hardware.location.gps, celles-ci:

• [C-1-1] DOIT prendre en charge les sorties de localisation à un taux d'au moins 1 Hz lorsqu'il est demandé via LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être en mesure de déterminer la position en ciel ouvert (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (temps nécessaire pour la première correction), lorsqu'il est connecté à une connexion Internet dont le débit est de 0,5 Mbit/s ou plus. Cette exigence est généralement satisfaite en utilisant une technique de GPS/GNSS assisté ou prévu pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, le lieu de référence et les éphémères du satellite/l'horloge).
  • [C-1-6] Une fois ce calcul de localisation effectué, la mise en œuvre des appareils DOIT déterminer sa position, en ciel ouvert, dans un délai de cinq secondes lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de localisation initial, même si la requête suivante est effectuée sans connexion de données et/ou après un redémarrage.

• En ciel ouvert, après avoir déterminé la position, lorsque vous êtes à l'arrêt ou que vous vous déplacez avec un carré d'accélération inférieur à 1 mètre par seconde:

  • [C-1-3] DOIT être capable de déterminer la position dans un rayon de 20 mètres et la vitesse dans un rayon de 0, 5 mètre par seconde, au moins 95% du temps.
  • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une constellation.
  • DEVRAIT pouvoir suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, le GPS et au moins un satellite de Glonass, Beidou ou Galileo).

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des sorties de localisation GPS/GNSS normales via l'API de fournisseur de localisation GNSS 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 des SBAS.

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler les erreurs AGC et la fréquence des mesures GNSS.

• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de transmettre toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.

• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de transmettre les mesures GNSS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-plages GNSS et les taux de pseudo-orange qui, dans des conditions de ciel ouvert après avoir déterminé la position, tout en restant immobile ou en se déplaçant avec moins de 0,2 mètre par seconde au carré d'accélération, suffisent pour calculer la position à 20 mètres et la vitesse à 0, 2 mètre par seconde au moins, à moins de 9% du temps.

7.3.4. Gyroscope

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscope.

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

• [C-1-1] DOIT pouvoir signaler des événements avec 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é en cours d'utilisation, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier avec le taux d'échantillonnage, mais DOIT être contrainte par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à un taux d'échantillonnage de 1 Hz, il DOIT ne pas être supérieur à 1e-7 rad^2/s^2.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution de 16 bits ou plus.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

Si les implémentations d'appareils comprennent un gyroscope à 3 axes, ils:

• [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:

• [C-3-1] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES.
• [C-SR-5] Sont STRONGLY_RECOMMENDED pour implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

Si les implémentations d'appareils comprennent un gyroscope à trois axes, un capteur d'accéléromètre et un capteur 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 à 3 axes et un gyroscope à 3 axes, ils:

• [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.

Baromètre

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression de l'air ambiant).

Si les implémentations d'appareils comprennent un baromètre, celles-ci:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT pouvoir diffuser des événements avec une fréquence de 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [C-SR-2] FORTEMENT RECOMMANDÉ de pouvoir signaler les mesures de pression comprises entre 300 hPa et 1 100 hPa.
• DEVRAIT avoir une précision absolue de 1 hPa.
• DEVRAIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalant à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les appareils sont équipés d'un thermomètre ambiant (capteur de température), ils:

• [C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température ambiante, et celui-ci DOIT mesurer la température ambiante (de la pièce/l'habitacle du véhicule) à partir de l'endroit où l'utilisateur interagit avec l'appareil, en degrés Celsius.

Si les appareils incluent un capteur thermomètre qui mesure une température autre que la température ambiante, telle que la température du processeur, ils:

• [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, ils:

• [C-SR-1] Sont vivement RECOMMANDÉS pour la compatibilité avec 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 de type "proche" ou "éloignée", 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é pour 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'appareils incluent un capteur de proximité avec une autre orientation, celui-ci 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 pour la lecture proche et 5 centimètres pour la lecture éloignée.
• [C-1-4] DOIT indiquer une plage maximale et une résolution de 5.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité (comme défini dans cette section) et les mettent à la disposition des applications tierces, elles:

• [C-1-1] DOIT identifier la capacité via l'indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareils 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 comprise entre -8 g et +8 g, et il est FORTEMENT RECOMMANDÉ d'avoir une plage de mesure comprise entre -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 ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme non activée 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 inférieure ou égale à 3 mW.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et d'un spectre de bruit blanc dans cette bande.
  • DEVRAIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg/°C.
  • DOIT présenter une non-linéarité ≤ 0,5 % de la courbe la plus adaptée et une variation de la sensibilité par rapport à la température de ≤ 0,03%/C°.
  • DEVRAIT avoir une sensibilité transversale inférieure à 2,5 % et une variation de la sensibilité de l'axe transversal < 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.
  • 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 ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et du spectre de bruit blanc dans cette bande passante.
  • DEVRAIT avoir un taux de marche aléatoire inférieur à 0,001 °/s √Hz testé à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
  • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
  • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
  • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
  • L'erreur d'étalonnage DOIT être inférieure à 0,002 rad/s dans une plage de températures de 10 à 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité g DOIT être inférieure à 0,1°/s/g.
  • DEVRAIT avoir une sensibilité transversale inférieure à 4,0 % et une variation de sensibilité transversale inférieure à 0,3% dans la plage de températures 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.
  • 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 présenter un bruit de mesure inférieur à 0,5 uT.

• [C-2-6] DOIT comporter un élément TYPE_MAGNETIC_FIELD_UNCALIBRATED présentant les mêmes exigences de qualité que l'élément TYPE_GEOMAGNETIC_FIELD, ainsi que les éléments suivants:

  • DOIT implémenter une forme non activée 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'utiliser un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence de signalement est supérieure ou égale à 50 Hz.

• [C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui:

  • La plage de mesure DOIT être 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 enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non activée 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 inférieure ou égale à 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 activée 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] L'horodatage du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT se situer à une distance de moins de 2, 5 millisecondes l'un de l'autre. L'horodatage du même événement physique signalé par l'accéléromètre et le gyroscope DOIT se situer à une distance de 0,25 milliseconde l'un de l'autre.

• [C-2-14] DOIT disposer d'horodatages des événements du capteur du gyroscope sur la même base temporelle que le sous-système de l'appareil photo et dans un délai d'une milliseconde d'erreur.

• [C-2-15] DOIT fournir des échantillons aux applications dans un délai de 5 millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus à l'application.

• [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsqu'il est en mouvement lorsqu'une combinaison des capteurs suivants 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 indiquées dans 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 : le capteur, les circuits de soutien, les systèmes de traitement de capteurs dédiés, etc.

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, celles-ci:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du taux de signalement direct via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
• [C-3-2] DOIT accepter au moins l'un des deux types de canaux directs des capteurs pour tous les capteurs déclarant être compatibles avec le canal direct du capteur.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVRAIT accepter la création de rapports d'événements via le canal direct du capteur pour les capteurs principaux (variantes 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 comprennent un écran de verrouillage sécurisé:

• DEVRAIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés en tant que classe 3 (anciennement Strong), classe 2 (anciennement Faible) ou classe 1 (anciennement Convenience) en fonction de leurs taux d'acceptation de spoofing et d'imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique pour interagir avec la plate-forme et les applications tierces. Les capteurs doivent répondre aux exigences supplémentaires décrites ci-dessous s'ils souhaitent être classés dans la classe 1, la classe 2 ou la classe 3. Les méthodes 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 à 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 biométriques de classe 3 ou 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 en tant que constante dans la classe Authenticators et toute combinaison de ces noms. Inversement, il NE DOIT PAS respecter ni reconnaître des 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 ces constantes.
• [C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils utilisant la biométrie de classe 3 ou de classe 2. Cette action DOIT présenter uniquement les points d'entrée d'enregistrement pour la biométrie des classes 3 ou 2.

Si les implémentations d'appareils prennent en charge la biométrie passive, elles:

• [C-5-1] DOIT nécessiter par défaut une étape de confirmation supplémentaire (par exemple, une pression sur un bouton).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et de toujours exiger une étape de confirmation.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation de sorte qu'aucun système d'exploitation ou noyau ne puisse en usurper l'identité. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée uniquement) d'un élément sécurisé (SE) qui ne peut être pilotée par aucun autre moyen qu'une pression sur un bouton physique.
• [C-5-2] DOIT également mettre en œuvre 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 appareils disposent de plusieurs capteurs biométriques, ils:

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule confirmation biométrique par authentification (par exemple, si des capteurs d'empreinte digitale et faciale sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé une fois que l'un d'entre eux est confirmé).

Pour que les implémentations d'appareils autorisent l'accès aux clés de keystore à des applications tierces, ils doivent:

• [C-6-1] DOIT respecter les exigences de la classe 3, telles que définies dans la présente 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 que l'authentification est appelée avec un CryptoObject.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 1 (anciennement commodité), procédez comme suit:

• [C-1-1] DOIT avoir un taux de faux acceptations 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 sécurisés, et énumérer clairement les risques liés à son activation si les taux d'acceptation de l'usurpation et de l'imposteur sont supérieurs à 7 %, tels que mesurés par les protocoles de test biométrique Android.
• [C-1-9] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (code, schéma ou mot de passe, par exemple) après vingt faux essais au maximum et un intervalle de 90 secondes maximum pour la vérification biométrique, c'est-à-dire un essai avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une biométrie enregistrée.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de réduire le nombre total de faux essais pour la validation biométrique spécifié dans [C-1-9] si les taux d'acceptation de spoofing et d'imposteurs sont supérieurs à 7 %, tel que mesuré par les protocoles de test biométrique Android.
• [C-1-3] DOIT limiter le débit des tentatives de validation biométrique, c'est-à-dire qu'un faux essai doit présenter une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter le débit des tentatives pendant au moins 30 secondes après cinq faux essais de vérification biométrique pour le nombre maximal de faux essais par [C-1-9], lorsqu'un faux essai est un essai dont la qualité de capture (BIOMETRIC_ACQUIRED_GOOD) ne correspond pas à une biométrie enregistrée.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'intégrer toute la logique de limitation du débit dans le TEE.
• [C-1-10] DOIT désactiver la biométrie une fois l'intervalle d'authentification principal déclenché, comme décrit dans la section [C-0-2] de la section 9.11.
• [C-1-11] DOIT avoir un taux d'acceptation de spoof et d'imposteurs ne dépassant pas 30%, avec (1) un taux d'acceptation de parodie et d'imposteur pour les espèces d'instruments d'attaque de présentation de niveau A (PAI) de niveau A ne dépassant pas 30%, et (2) un taux de spoofing et d'acceptation d'acceptation des espèces PAI de niveau B ne dépassant pas 40 % par les métriques de test d'Android.
• [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer des identifiants existants ou d'ajouter un nouvel identifiant d'appareil (code/modèle/mot de passe) sécurisé par le TEE. L'implémentation du projet Open Source Android fournit le mécanisme dans le framework pour le faire.
• [C-1-5] DOIT supprimer complètement toutes les données biométriques permettant d'identifier un utilisateur lorsque son compte est supprimé (y compris en rétablissant la configuration d'usine).
• [C-1-6] DOIT respecter l'indicateur individuel de cette biométrie (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (code, schéma, mot de passe, etc.) toutes les 24 heures au maximum. Remarque: La mise à niveau des appareils lancés sous Android 9 ou version antérieure DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) toutes les 72 heures ou moins.
• [C-1-8] DOIT demander à l'utilisateur de procéder à l'authentification principale recommandée (par exemple, à l'aide d'un code, d'un schéma ou d'un mot de passe) ou de données biométriques de classe 3 (Strong) après l'un des éléments suivants :
  • un délai d'inactivité de quatre heures, OU
  • 3 tentatives d'authentification biométrique ayant échoué.
  • Le délai d'inactivité et le nombre d'authentifications ayant échoué sont réinitialisés après toute confirmation réussie des identifiants de l'appareil. Remarque: La mise à niveau des appareils lancés avec Android 9 ou une version antérieure PEUT être exemptée de l'autorisation C-1-8.
• [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source afin d'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É de définir un taux de faux refus inférieur à 10%, tel que mesuré sur l'appareil.
• [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'avoir une latence inférieure à une seconde, mesurée entre le moment où la biométrie est détectée et le moment où l'écran est déverrouillé, pour chaque biométrie enregistrée.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 2 (anciennement Faible), procédez comme suit:

• [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.

• [C-2-2] DOIT avoir un taux d'acceptation de spoof et d'imposteurs ne dépassant pas 20%, avec (1) un taux d'acceptation de parodie et d'imposteur pour les espèces d'instruments d'attaque de présentation (PAI) de niveau A ne dépassant pas 20%, et (2) un taux de spoof et d'acceptation d'imposteur des espèces PAI de niveau B ne pas supérieur à 30 %

• [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), ou sur une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé.

• [C-2-4] DOIT faire en sorte que toutes les données identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source.

• [C-2-5] Pour la biométrie basée sur l'appareil photo, alors que l'authentification ou l'enregistrement biométrique sont en cours:

  • DOIT utiliser la caméra dans un mode qui empêche la lecture ou la modification des trames de caméra en dehors de l'environnement d'exécution isolé, ou d'une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé.
  • Pour les solutions RVB à caméra unique, les images de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour permettre des opérations telles que l'aperçu pour l'enregistrement, mais elles NE DOIVENT EN AUCUN CAS ê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 un accès non chiffré à des données biométriques permettant d'identifier l'utilisateur ou à toute donnée qui en est dérivée (comme les représentations vectorielles continues) au processeur d'applications en dehors du contexte du TEE. Les appareils de mise à niveau lancés sous Android 9 ou une version antérieure ne sont pas exemptés de C-2-7.

• [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'un piratage du système d'exploitation ou du noyau ne permette pas l'injection directe de données pour s'authentifier à tort en tant qu'utilisateur. Remarque: Si les implémentations d'appareils sont déjà lancées sur Android version 9 ou antérieure et ne peuvent pas répondre à l'exigence C-2-8 via une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence.

• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de l'activité pour toutes les modalités biométriques et la détection de l'attention pour la biométrie du visage.

• [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 en tant que classe 3 (anciennement Strong), elles:

• [C-3-1] DOIT respecter 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 de spoof et d'imposteurs d'au moins 7%, avec (1) un taux d'acceptation de spoof et d'imposteurs pour les espèces d'instruments d'attaque de présentation de niveau A (PAI) ne dépassant pas 7%, et (2) un taux d'acceptation de spoofing et d'imposteurs pour les espèces PAI de niveau B dont les métriques ne dépassent pas 20 %
• [C-3-4] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) toutes les 72 heures au maximum.
• [C-3-5] DOIT générer à nouveau l'ID d'authentificateur pour toutes les données biométriques de classe 3 prises en charge sur l'appareil si l'un d'entre eux est réenregistré.
• [C-3-6] Vous devez activer des clés de keystore reposant sur la biométrie pour les applications tierces.

Si les implémentations d'appareils contiennent un lecteur d'empreinte digitale sous l'écran (UDFPS), ils:

• [C-SR-11] Il est FORTEMENT RECOMMANDÉ d'éviter que la zone tactile de l'UDFPS (lecteur d'empreinte digitale sous l'écran) interfère avec la navigation à trois boutons (ce qui peut être nécessaire pour certains utilisateurs à des fins d'accessibilité).

7.3.11. Capteur de postures

Implémentations pour les appareils:

• PEUT prendre en charge les capteurs de position avec 6 degrés de liberté.

Si les implémentations d'appareils prennent en charge les capteurs de position à 6 degrés de liberté, ils:

• [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 appareils sont compatibles avec un capteur d'angle de charnière:

• [C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
• [C-1-2] DOIT prendre en charge au moins deux mesures comprises entre 0 et 360 degrés (inclus, c'est-à-dire inclure 0 et 360 degrés).
• [C-1-3] DOIT renvoyer un capteur de réveil pour getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.3.13. IEEE 802.1.15.4 [Transféré vers la version 7.4.9]

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 permettant de passer des appels vocaux et d'envoyer des SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés de paquets, ils sont destinés aux besoins d'Android et sont considérés comme étant indépendants de toute connectivité de données pouvant être mise en œuvre à l'aide du même réseau. En d'autres termes, la fonctionnalité de téléphonie et les API Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir des SMS ne sont pas considérées comme des appareils de téléphonie, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

• Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel téléphonique. 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, ils:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony et les autres indicateurs de sous-fonctionnalité en fonction de la technologie.
• [C-1-2] DOIT mettre en œuvre la compatibilité totale de l'API avec cette technologie.
• DEVRAIT autoriser tous les types de services mobiles disponibles (2G, 3G, 4G, 5G, etc.) pendant les appels d'urgence (quels que soient les types de réseaux définis par SetAllowedNetworkTypeBitmap()).

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie:

• [C-2-1] DOIT implémenter les API complètes en tant que no-ops.

Si les implémentations d'appareils sont compatibles avec les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant aux développeurs tiers d'accéder à la fonctionnalité eSIM, celles-ci:

• [C-3-1] DOIT déclarer l'indicateur 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" :

• [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 acceptent un enregistrement unique de sous-système multimédia IP (IMS) pour les fonctionnalités du service de téléphonie multimédia (MMTEL) et des services de communication enrichis (RCS), et qu'elles doivent respecter les exigences des opérateurs mobiles concernant l'utilisation d'un enregistrement IMS unique pour tout le trafic de signaux IMS, elles:

• [C-5-1] DOIT déclarer l'indicateur 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 l'indicateur de fonctionnalité android.hardware.telephony.ims.singlereg et fournir une implémentation complète de l'API SipTransport, de l'API GbaService, des indications de support dédiées à l'aide de la couche HAL IRadio 1.6 et du provisionnement via le serveur de configuration automatique (ACS) ou tout autre mécanisme de provisionnement propriétaire à l'aide de l'API IMS Configuration.

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony:

• [C-6-1] Les éléments 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 lors de l'envoi et de la réception de SMS et de 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 prendre en charge la saisie de codes de numéroteur 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 visuelle des messages vocaux aux utilisateurs si elle prend en charge les transcriptions visuelles des messages vocaux.
• [C-6-5] DOIT représenter tous les éléments SubscriptionInfo avec des UUID de groupe équivalents en tant qu'abonnement unique dans toutes les affordances visibles par l'utilisateur qui affichent et contrôlent les informations de la carte SIM. Les interfaces de paramètres qui correspondent à Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS sont des exemples de ces affordances.
• [C-6-6] NE DOIT PAS afficher ni autoriser le contrôle d'une SubscriptionInfo avec un UUID de groupe et un bit opportuniste non nuls dans les affordances visibles par l'utilisateur qui autorisent la configuration ou le contrôle des paramètres de la carte SIM.

Si les implémentations de l'appareil signalent la fonctionnalité android.hardware.telephony et fournissent une barre d'état système:

• [C-7-1] DOIT sélectionner un abonnement actif représentatif pour un UUID de groupe donné afin de l'afficher à l'utilisateur dans toutes les affordances qui fournissent des informations sur l'état de la carte SIM. Il peut s'agir, par exemple, de l'icône de signal mobile de la barre d'état ou du bloc Réglages rapides.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de choisir l'abonnement représentatif comme abonnement aux données actives, sauf si l'appareil fait l'objet d'un appel vocal, au cours duquel il est FORTEMENT RECOMMANDÉ que l'abonnement représentatif soit l'abonnement vocal actif.

Si les implémentations d'appareils signalent la fonctionnalité android.hardware.telephony:

• [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 à l'ETSI TS 102 221.
• [C-6-8] NE DOIT PAS appliquer l'un des comportements suivants aux applications d'opérateurs actives (telles que désignées par TelephonyManager#getCarrierServicePackageName) automatiquement ou sans confirmation explicite de l'utilisateur :
  • Révoquer ou limiter l'accès au réseau
  • Révoquer les autorisations
  • Limitez l'exécution d'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'appareils signalent la fonctionnalité android.hardware.telephony et que tous les abonnements actifs non opportunistes qui partagent un UUID de groupe sont désactivés, supprimés physiquement de l'appareil ou marqués comme opportunistes, l'appareil:

• [C-8-1] DOIT désactiver automatiquement tous les abonnements opportunistes actifs restants dans le même groupe.

Si les implémentations d'appareils incluent la téléphonie GSM, mais pas la téléphonie CDMA, ils:

• [C-9-1] NE DOIT PAS déclarer PackageManager#FEATURE_TELEPHONY_CDMA.
• [C-9-2] DOIT générer une exception IllegalArgumentException lors des tentatives de définition de n'importe quel type de réseau 3GPP2 dans des masques de bits de type de réseau préférés ou autorisés.
• [C-9-3] DOIT renvoyer une chaîne vide à partir de TelephonyManager#getMeid.

Si les implémentations d'appareils prennent en charge les eUICC avec plusieurs ports et profils, elles:

• [C-10-1] DOIT déclarer l'indicateur de fonctionnalité android.hardware.telephony.euicc.mep.

Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure une fonctionnalité de blocage de numéros
• [C-1-2] DOIT implémenter complètement 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. Seule exception : le blocage des 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 en dehors de la vue du journal d'appels par défaut dans l'application de téléphonie 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 interface utilisateur de gestion des nombres bloqués, qui est ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().

• [C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à afficher ou 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. Toutes les interfaces utilisateur liées au blocage DOIVENT être masquées pour les utilisateurs secondaires, et la liste bloquée DOIT tout de même être respectée.

• DEVRAIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil sera mis à jour vers Android 7.0.

• DEVRAIT fournir une affordance utilisateur pour afficher les appels bloqués dans l'application d'appel préinstallée.

API Telecom

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

• [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir une affordance à l'utilisateur pour accepter ou rejeter l'appel entrant lorsque l'utilisateur est en cours d'appel effectué par une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
• [C-1-3] DOIT disposer d'une application mettant en œuvre InCallService.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que le fait de répondre à un appel entrant mettra fin à un appel en cours.

  L'implémentation d'AOSP répond à ces exigences par une notification prioritaire qui indique à l'utilisateur que le fait de 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éphonie par défaut qui affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels lorsque l'application tierce définit la clé supplémentaire EXTRA_LOG_SELF_MANAGED_CALLS sur son PhoneAccount sur true.

• [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 indiqué ci-dessous:

  • Appelez Connection.onDisconnect() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel en cours.
  • Appelez Connection.onAnswer() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel entrant.
  • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté pendant un appel entrant.
  • Activer/Désactiver le son de CallAudioState.

Déchargement cellulaire NAT-T Keepalive

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du déchargement du message keepalive cellulaire.

Si les implémentations d'appareils prennent en charge le déchargement des messages keepalive cellulaire et les expose à des applications tierces, elles:

• [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
• [C-1-2] DOIT prendre en charge au moins un emplacement keepalive simultané sur le réseau mobile.
• [C-1-3] DOIT prendre en charge autant d'emplacements de message keepalive cellulaires simultanés que ceux acceptés par la HAL de radio cellulaire.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge au moins trois emplacements de message keepalive cellulaire par instance radio.

Si les implémentations d'appareils ne prennent pas en charge le déchargement des messages keepalive cellulaire:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils sont compatibles 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 prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de l'opération, y compris dans les cas suivants :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android Television, même en mode veille.
• [C-1-5] NE DOIT PAS traiter l'appel de méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif 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 que le réseau Wi-Fi fournit l'accès à Internet.
• [C-1-6] Il est FORTEMENT RECOMMANDÉ, lorsque la méthode API ConnectivityManager.reportNetworkConnectivity() est appelée, de réévaluer l'accès à Internet sur le Network et, une fois que l'évaluation détermine que le Network actuel ne fournit plus d'accès à Internet, de passer à un autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
• [C-1-7] DOIT appliquer de manière aléatoire l'adresse MAC source et le numéro de séquence des trames de requêtes de vérification, une fois au début de chaque analyse, tandis que la STA est déconnectée.
• [C-1-8] DOIT utiliser une seule adresse MAC cohérente (NE DEVRAIT PAS randomiser l'adresse MAC à la moitié de l'analyse).
• [C-1-9] DOIT itérer le numéro de séquence des requêtes de vérification comme d'habitude (de manière séquentielle) entre les requêtes de vérification d'une analyse.
• [C-1-10] DOIT attribuer de manière aléatoire le numéro de séquence de la requête de vérification 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 (PA) lors de l'association et de l'association.
  • L'appareil DOIT utiliser une adresse MAC aléatoire différente pour chaque SSID avec lequel il communique.
  • L'appareil DOIT permettre à l'utilisateur de contrôler la randomisation par SSID (nom de domaine complet pour Passpoint) avec des options non aléatoires et aléatoires, et DOIT définir le mode par défaut pour que les nouvelles configurations Wi-Fi soient aléatoires.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser un BSSID aléatoire pour tout point d'accès créé.
  • L'adresse MAC DOIT être aléatoire et conservée selon le SSID utilisé par le point d'accès.
  • L'APPAREIL PEUT Donner à 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, les appareils suivants:

• DEVRAIT désactiver le mode Économie d'énergie Wi-Fi chaque fois qu'une application acquiert un verrou WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire(), et que le verrou 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 de verrouillage Wi-Fi à faible latence (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 verrou à 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 rechercher la position, ils:

• [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API WifiManager.isScanAlwaysAvailable.

Wi-Fi Direct

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les appareils sont compatibles avec le Wi-Fi Direct, ils:

• [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 être compatible avec le fonctionnement Wi-Fi standard.
• [C-1-4] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Direct simultanément.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source pour toutes les nouvelles connexions Wi-Fi Direct.

7.4.2.2. Configuration du lien direct par tunneling en Wi-Fi

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la configuration TDLS (Wi-Fi Tunneled Direct Link Setup), comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils sont compatibles avec le TDLS et que le TDLS est activé par l'API WiFiManager, celles-ci:

• [C-1-1] DOIT déclarer la prise en charge du TDLS via WifiManager.isTdlsSupported.
• DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
• DEVRAIT utiliser une méthode heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pires que de passer par le point d'accès Wi-Fi.

Wi-Fi Aware

Implémentations pour les appareils:

• DEVRAIT inclure la compatibilité avec Wi-Fi Aware.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité à des applications tierces, celles-ci:

• [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 prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
• [C-1-4] DOIT appliquer de manière aléatoire l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure des distances Aware est en cours ou qu'un chemin de données Aware est actif (la randomisation n'est pas attendue tant que le chemin de données est actif).

Si les implémentations d'appareils incluent la prise en charge du Wi-Fi Aware et de la localisation via le Wi-Fi comme décrit dans la section 7.4.2.5 et expose ces fonctionnalités à des applications tierces, les conditions suivantes doivent être réunies:

• [C-2-1] DOIT implémenter les API de découverte avec détection de la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Si les appareils sont compatibles avec la norme 802.11 (Wi-Fi), ils:

• [C-1-1] DOIT inclure la compatibilité avec Wi-Fi Passpoint.
• [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, spécifiquement liée à la découverte et à la sélection de réseaux, comme le service publicitaire générique (GAS) et le protocole de requête réseau d'accès (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, mettre en correspondance et associer des réseaux Passpoint.
• [C-1-6] DOIT être compatible avec au moins les sous-ensembles de protocoles de provisionnement d'appareils suivants, tels que définis dans Wi-Fi Alliance Passpoint R2: l'authentification EAP-TTLS et SAP-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 prendre en charge le contrôle utilisateur du provisionnement via le sélecteur Wi-Fi.
• [C-1-9] DOIT garder les configurations Passpoint persistantes lors des redémarrages.
• [C-SR-1] Sont VIVEMENT RECOMMANDÉS de prendre en charge la fonctionnalité d'acceptation des conditions d'utilisation.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge la fonctionnalité d'informations sur le lieu.

Si un bouton de désactivation global des commandes utilisateur pour Passpoint est fourni, les implémentations suivantes:

• [C-3-1] DOIT activer Passpoint par défaut.

Emplacement du Wi-Fi (délai aller-retour Wi-Fi - DAR)

Implémentations pour les appareils:

• DEVRAIT 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é à des applications tierces, celles-ci:

• [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 attribuer de manière aléatoire l'adresse MAC source pour chaque rafale de DAR exécutée alors que l'interface Wi-Fi sur laquelle le DAR est exécuté n'est pas associée à un point d'accès.
• [C-1-4] DOIT être précis à 2 mètres près pour une bande passante de 80 MHz au 68e centile (calculé avec la fonction de distribution cumulative).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de créer un rapport précis à 1,5 mètre pour une bande passante de 80 MHz au 68e centile (calculé à l'aide de la fonction de distribution cumulative).

7.4.2.6. Déchargement Wi-Fi Keepalive

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du déchargement Wi-Fi keepalive.

Si les implémentations d'appareils prennent en charge le déchargement du message keepalive Wi-Fi et exposent cette fonctionnalité à des applications tierces, elles:

• [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
• [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés sur le Wi-Fi.

Si les implémentations d'appareils ne prennent pas en charge le déchargement du message keepalive Wi-Fi, elles:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement des appareils)

Implémentations pour les appareils:

• DEVRAIT être compatible avec Wi-Fi Easy Connect (DPP).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Easy Connect et exposent la fonctionnalité à des applications tierces, celles-ci:

• [C-1-1] DOIT faire en sorte que la méthode WifiManager#isEasyConnectSupported() renvoie true.

7.4.2.8. Validation du certificat du serveur Wi-Fi d'entreprise

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 permettre à l'utilisateur d'ajouter manuellement le réseau Wi-Fi d'entreprise dans l'application Paramètres.

7.4.2.9. Confiance lors de la première utilisation (TOFU)

Si les implémentations d'appareils sont compatibles avec TOFU (Trust on First Usage) et permettent à l'utilisateur de définir des configurations WPA/WPA2/WPA3-Enterprise, elles:

• [C-4-1] DOIT fournir à l'utilisateur l'option de choisir d'utiliser TOFU.

7.4.3. Bluetooth

Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

• DOIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (LDAC, par exemple) avec A2DP.

Si les implémentations d'appareils sont compatibles avec les protocoles HFP, A2DP et AVRCP:

• DEVRAIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareils déclarent la fonctionnalité android.hardware.vr.high_performance, elles:

• [C-1-1] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations d'appareils sont compatibles avec les technologies Bluetooth et Bluetooth à basse consommation, elles:

• [C-2-1] DOIT déclarer les fonctionnalités pertinentes de la plate-forme (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de la plate-forme.
• DEVRAIT implémenter les profils Bluetooth appropriés, tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations d'appareils sont compatibles avec la technologie BLE (Bluetooth basse consommation), elles:

• [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 un profil d'attribut générique (GATT), comme décrit dans la documentation du SDK et dans android.bluetooth.
• [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() pour indiquer si la logique de filtrage des classes d'API ScanFilter est mise en œuvre.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() pour indiquer si la publicité à basse consommation est prise en charge.
• [C-3-5] DOIT mettre en œuvre un délai avant expiration de l'adresse privée pouvant être résolue (RPA, Resolvable Private Address, RPA) ne dépassant pas 15 minutes et effectuer une rotation de l'adresse après expiration du délai afin de protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement la technologie BLE pour l'analyse ou la publicité. Pour éviter les attaques temporelles, les intervalles d'expiration DOIVENT également être aléatoires entre 5 et 15 minutes.
• DEVRAIT accepter le déchargement de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
• DEVRAIT permettre le déchargement de la recherche par lot sur le chipset Bluetooth.
• DEVRAIT prendre en charge les annonces multiples comportant au moins 4 emplacements.

Si les implémentations d'appareils sont compatibles avec la technologie Bluetooth LE et utilisent cette technologie pour la recherche de position, elles:

• [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via le BluetoothAdapter.isBleScanAlwaysAvailable() de l'API système.

Si les implémentations d'appareils prennent en charge la technologie Bluetooth LE et le profil d'appareils auditifs, comme décrit dans la section Compatibilité de l'audio pour les appareils auditifs avec la technologie Bluetooth LE, elles:

• [C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, Listen, BluetoothProfile.HEARING_AID).

Si les implémentations d'appareils sont compatibles avec le Bluetooth ou le Bluetooth à basse consommation:

• [C-6-1] DOIT restreindre l'accès à toutes les métadonnées Bluetooth (telles que les résultats d'analyse) qui pourraient être utilisées pour déterminer la position de l'appareil, sauf si l'application à l'origine de la demande réussit une vérification d'autorisation android.permission.ACCESS_FINE_LOCATION basée sur son état actuel de premier plan/arrière-plan.

Si les implémentations d'appareils sont compatibles 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 que la localisation ne provient pas du Bluetooth, il:

• [C-6-2] DOIT activer l'accès Bluetooth derrière le android.permission.ACCESS_FINE_LOCATION.

Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioSupported(), elles:

• [C-7-1] DOIT prendre en charge le client monodiffusion.
• [C-7-2] DOIT prendre en charge 2M PHY.
• [C-7-3] DOIT prendre en charge la publicité LE Extended.
• [C-7-4] DOIT prendre en charge au moins deux connexions CIS dans un pipeline CIG.
• [C-7-5] DOIT activer simultanément le client de monodiffusion BAP, le coordinateur de définition CSIP, le serveur MCP, le contrôleur VCP et le serveur CCP.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'activer le client monodiffusion HAP.

Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elles:

• [C-8-1] DOIT prendre en charge au moins 2 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 prendre en charge la publicité LE Periodic.

Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elles:

• [C-9-1] DOIT être compatible avec PAST (Periodic Advertising Sync Transfer).
• [C-9-2] DOIT prendre en charge la publicité LE Periodic.

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

• [C-10-1] DOIT que les mesures de l'RSSI soient comprises dans une plage de +/-9 dB pour 95% des mesures à 1 m d'un appareil de référence émettant dans un environnement de ligne de vue ADVERTISE_TX_POWER_HIGH.
• [C-10-2] DOIT inclure les corrections Rx/Tx pour réduire les écarts par canal, de sorte que les mesures sur chacun des trois canaux, sur chacune des antennes (si plusieurs sont utilisées), se situent à plus ou moins -3 dB les unes des autres pour 95% des mesures.
• [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 de distance d'un appareil de référence transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -60 dBm à +/-10 dB lors de la recherche depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.

Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans Étalonnage de présence.

Si les implémentations d'appareils sont compatibles avec la version Bluetooth 5.0, ils:

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de fournir une assistance dans les domaines suivants :
  • LE 2M PHY
  • LE Codec PHY
  • Extension LE Advertising Extension
  • Publicité périodique
  • Au moins 10 ensembles d'annonces
  • Au moins huit connexions LE simultanées. Chaque connexion peut appartenir à l'un ou l'autre des rôles de topologie de connexion.
  • Confidentialité de la couche de liaison LE
  • Une "liste de résolution" d'au moins huit entrées

7.4.4. Communication en champ proche

Implémentations pour les appareils:

• DEVRAIT inclure un émetteur-récepteur et le matériel associé pour la technologie NFC (communication en champ proche).
• [C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord même si elles n'incluent pas la compatibilité NFC ou si elles ne déclarent pas la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation de données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le rendre disponible pour les applications tierces:

• [C-1-1] DOIT signaler la caractéristique 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/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • ISO Dep (ISO 14443-4)
  • Types de tags du forum NFC 1, 2, 3, 4, 5 (définis par le forum NFC)

• [C-SR-1] VIVEMENT RECOMMANDÉ pour pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que bien que les normes NFC soient indiquées comme étant VIVEMENT RECOMMANDÉES, il est prévu qu'elles soient remplacées par une OBLIGATION dans la définition de compatibilité d'une prochaine version. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les futures versions. Les appareils nouveaux et existants qui exécutent cette version d'Android sont vivement encouragés à répondre à 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 de détection NFC lorsque l'appareil est activé, avec l'écran actif et l'écran de verrouillage déverrouillé.

• DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) des produits Thinfilm NFC Barcode.

Notez que les liens accessibles au public ne sont pas disponibles pour les spécifications du forum JIS, ISO et NFC citées ci-dessus.

Android est compatible avec le mode HCE (émulation de carte hôte 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 des ID d'application (AID), elles:

• [C-2-1] DOIT indiquer la constante de caractéristique 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 cette fonctionnalité pour des applications tierces:

• [C-3-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de cartes NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent une compatibilité NFC générale comme décrit dans cette section et sont compatibles avec les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/rédacteur, elles:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué par 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 et qu'elle n'apparaît donc pas comme une constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles de mise en réseau et API

Capacité réseau minimale

Implémentations pour les appareils:

• [C-0-1] DOIT inclure la compatibilité avec une ou plusieurs formes de mise en réseau de données. Plus précisément, les mises en œuvre d'appareils DOIVENT être compatibles avec au moins une norme de données pouvant atteindre 200 kbit/s ou plus. Les technologies EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth sont des exemples de technologies répondant à cette exigence.
• DEVRAIT également prendre en charge 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 mettre en œuvre plusieurs formes de connectivité de données.

IPv6

Implémentations pour les appareils:

• [C-0-2] DOIT inclure une pile réseau IPv6 et accepter 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 Sommeil.
    • [C-0-5] La limitation du débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur tout 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 effectuée localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort et 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 sur les serveurs Web (Web).

Le niveau requis de compatibilité IPv6 dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les appareils sont compatibles avec le Wi-Fi, ils:

• [C-1-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, ils:

• [C-2-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur Ethernet.

Si les appareils sont compatibles avec les données mobiles, ils:

• [C-3-1] DOIT prendre en charge les opérations 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.

Portails captifs

Un portail captif est un réseau qui nécessite une connexion pour obtenir un accès à Internet.

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

• [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif, en envoyant cet intent, lors d'un 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é à n'importe quel type de réseau, y compris les réseaux mobiles/cellulaires, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide d'un DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode DNS strict privé.
• [C-1-4] DOIT utiliser un 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 de mise en réseau Java telles que java.net.Socket, ainsi que les API natives telles que connect()) correspond à tout autre réseau disponible qui fournit un accès à Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations pour les appareils:

• [C-0-1] DOIT activer le paramètre de synchronisation automatique du maître par défaut pour que la méthode getMasterSyncAutomatically() renvoie la valeur "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, voici les types de connexions:

• [C-SR-1] FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

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

• [C-1-1] DOIT prendre en charge toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.

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

• [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. Éléments sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés compatibles avec l'API Open Mobile 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 flags de fonctionnalité appropriés via android.hardware.se.omapi.uicc pour l'appareil doté d'éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil doté d'é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 la SD.

7.4.9. UWB

Si les implémentations d'appareils sont compatibles avec la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, celles-ci:

• [C-1-1] DOIT implémenter l'API Android correspondante dans android.uwb.
• [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.uwb.
• [C-1-3] DOIT prendre en charge tous les profils UWB pertinents définis dans l'implémentation Android.
• [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver la radio UWB.
• [C-1-5] DOIT faire en sorte que les applications qui utilisent la radio UWB détiennent l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICE).

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organisations standards, y compris FIRA, CCC et CSA.

  • [C-1-6] DOIT s'assurer que les mesures de distance se situent à moins de +/-15 cm pour 95 % des mesures dans l'environnement de vision à une distance d'un mètre dans une chambre non réfléchissante.
  • [C-1-7] DOIT s'assurer que la médiane des mesures de distance à 1 m de l'appareil de référence se situe dans les limites de [0,75 m, 1,25 m], où la distance de vérité terrain est mesurée à partir du bord supérieur de l'appareil testé, face vers le haut et incliné à 45 degrés.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans Étalonnage de présence.

7.5. Appareils photo

Si les implémentations d'appareils incluent au moins une caméra:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
• [C-1-2] DOIT être possible pour qu'une application puisse allouer simultanément trois bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur photo ayant la plus grande résolution de l'appareil, alors que l'appareil photo est ouvert à des fins d'aperçu de base et de capture.
• [C-1-3] DOIT s'assurer que les intents de gestion de l'application d'appareil photo par défaut préinstallés MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE sont responsables de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application réceptrice lorsque celle-ci n'a pas ACCESS_FINE_LOCATION.

Si les implémentations d'appareils sont compatibles avec la capacité de sortie HDR 10 bits, les conditions suivantes s'appliquent:

• [C-2-1] DOIT prendre en charge au moins le profil HDR HLG pour chaque appareil photo compatible avec une sortie 10 bits.
• [C-2-2] DOIT prendre en charge une sortie 10 bits pour la caméra arrière principale ou la caméra avant principale.
• [C-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge une sortie 10 bits pour les deux caméras principales.
• [C-2-3] DOIT prendre en charge les mêmes profils HDR pour toutes les sous-caméras physiques compatibles BACKWARD_COMPATIBLE d'une caméra logique et pour l'appareil photo logique lui-même.

Pour les appareils photo logiques compatibles avec la technologie HDR 10 bits et qui implémentent l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

• [C-3-1] DOIT prendre en charge le basculement entre toutes les caméras physiques rétrocompatibles via la commande CONTROL_ZOOM_RATIO de la caméra logique.

7.5.1. Caméra arrière

Une caméra arrière est une caméra située sur le côté de l'appareil, en face de l'écran, c'est-à-dire des scènes à l'arrière de l'appareil, comme un appareil photo traditionnel.

Implémentations pour les appareils:

• DEVRAIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière:

• [C-1-1] DOIT signaler les indicateurs 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 intégrer un autofocus matériel ou logiciel dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
• PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• PEUT inclure un flash.

Si la caméra dispose d'un flash:

• [C-2-1] La lampe du 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 l'appareil photo, 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 à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil que l'écran, c'est-à-dire une caméra généralement utilisée pour créer une image de l'utilisateur, par exemple pour la visioconférence et des applications similaires.

Implémentations pour les appareils:

• PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra avant:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• [C-1-2] DOIT avoir une résolution VGA d'au moins (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra frontale 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 l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque celle-ci a explicitement demandé la rotation de l'écran de l'appareil photo 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'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NE DOIT PAS mettre en miroir l'image fixe ou les flux vidéo finaux renvoyés aux rappels d'application ou validés dans le stockage multimédia.
• [C-1-6] DOIT mettre en miroir l'image affichée par la vue post-vue de la même manière que le flux d'image d'aperçu de l'appareil photo.
• PEUT inclure des fonctionnalités (telles que l'autofocus, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils 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 mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations pour les appareils:

• PEUT inclure la prise en charge d'une caméra externe qui n'est pas toujours connectée.

Si les implémentations d'appareils prennent en charge une caméra externe, celles-ci:

• [C-1-1] DOIT déclarer les indicateurs de fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any.
• [C-1-2] DOIT être compatible avec la classe vidéo USB (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 lorsqu'une caméra externe physique est connectée. Pour en savoir plus sur le test CTS de la caméra, consultez source.android.com.
• DEVRAIT accepter les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
• PEUT prendre en charge plusieurs appareils photo.
• PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est compatible:

• [C-2-1] Un flux simultané non encodé / MJPEG (QVGA ou résolution 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 permettant d'accéder à l'appareil photo. La nouvelle API android.hardware.camera2 offre un contrôle de niveau inférieur de l'appareil photo à l'application, y compris des flux efficaces en rafale et en streaming sans copie, et des commandes par image pour l'exposition, le gain, les gains de balance des blancs, la conversion des couleurs, la suppression du bruit, l'accentuation, 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 compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe obsolète android.hardware.Camera et le package android.hardware.camera2 plus récent DOIVENT présenter des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être identique. Il n'est pas nécessaire que les caractéristiques qui dépendent de la sémantique différente des deux API aient une vitesse ou une qualité identiques, mais DOIVENT être aussi proches que possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux caméras, pour toutes les caméras disponibles. Implémentations pour 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 être davantage au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback, que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données de l'élément "byte[]" transmises à onPreviewFrame(). Autrement dit, 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 l'appareil photo des caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT être compatible avec 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'API Camera complète incluse dans la documentation du SDK Android, que l'appareil intègre l'autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo sans mise au point automatique DOIVENT appeler toutes les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si elles ne sont pas pertinentes pour un appareil photo sans mise au point automatique). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec l'autofocus, les rappels de l'API doivent toujours être "faussés", comme décrit dans la description.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que 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 des constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel le permet, et NE DOIVENT PAS être compatibles avec les types de paramètres de l'appareil photo personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'image à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo 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 signaler les indicateurs de fonctionnalité du framework appropriés.
• [C-0-8] DOIT également déclarer ses capacités de caméra individuelles android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir le flag de fonctionnalité si l'une des caméras associées est compatible avec cette fonctionnalité.
• [C-0-9] DOIT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par la caméra et que l'entrée de cette image a été ajoutée au Media Store.
• [C-0-10] DOIT diffuser l'intent 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] DOIT disposer de toutes les caméras accessibles via l'API android.hardware.Camera obsolète également accessible 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, en modifiant la géométrie du visage, la carnation ou le lissage de la peau pour une API android.hardware.camera2 ou android.hardware.Camera.
• [C-SR-1] Pour les appareils équipés de plusieurs caméras RVB orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui répertorie les fonctionnalités CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, qui se composent de toutes les caméras RVB orientées dans cette direction comme des sous-appareils physiques.

Si les implémentations d'appareils fournissent une API d'appareil photo propriétaire à des applications tierces, celles-ci:

• [C-1-1] DOIT implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
• PEUT fournir des balises et/ou des extensions de fournisseur à l'API android.hardware.camera2.

7.5.5. Orientation de l'appareil photo

Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

• [C-1-1] DOIT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil. Autrement dit, elle s'applique aux appareils principaux en mode paysage ainsi qu'aux appareils principaux en mode portrait.

Les appareils qui répondent à tous les critères suivants sont exemptés de l'exigence ci-dessus:

• L'appareil implémente des écrans à géométrie variable, tels que des écrans pliables ou à charnière.
• Lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe du mode portrait principal à l'orientation paysage principal (ou inversement).

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

Implémentations pour 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'une taille minimale de 100 Mo vers l'emplacement de "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations pour les appareils:

• [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "stockage externe partagé", "stockage partagé d'application" ou par le chemin Linux "/sdcard" sur lequel il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, en d'autres termes, "prêt à l'emploi", qu'il soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un emplacement de carte numérique sécurisée).
• [C-0-3] DOIT installer le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux entre sdcard et le point d'installation 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 les cas suivants :
  • 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 balises GPS Exif, stockées dans des fichiers multimédias lorsque ces fichiers sont accessibles 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 à l'aide de l'une des méthodes suivantes:

• Stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital).
• Une partie de la mémoire de stockage interne (non amovible) mise en œuvre dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un espace de stockage amovible pour répondre aux exigences ci-dessus, celles-ci:

• [C-1-1] DOIT implémenter une interface utilisateur toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans l'emplacement.
• [C-1-2] DOIT inclure un support de stockage au format FAT (une carte SD, par exemple) ou montrer sur la boîte et tout autre matériel disponible au moment de l'achat que ce 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:

• DEVRAIT utiliser l'implémentation AOSP du stockage partagé de l'application interne.
• 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, ils:

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données de l'espace de stockage partagé de l'application à partir d'un ordinateur hôte.
• DEVRAIT exposer le contenu des deux chemins de stockage de manière transparente via le service d'analyse multimédia d'Android et android.provider.MediaStore.
• PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole Media Transfer Protocol pour satisfaire à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et compatible avec le protocole Media Transfer Protocol, ils:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DEVRAIT signaler une classe de périphérique USB de 0x00.
• DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Si l'appareil doit être de nature mobile, contrairement à la télévision, les implémentations d'appareils sont les suivantes:

• [C-SR-1] FORTEMENT RECOMMANDÉ de mettre en œuvre le stockage adoptable dans un emplacement stable à long terme, car toute déconnexion accidentelle peut entraîner une perte/corruption de données.

Si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, par exemple dans le compartiment à piles ou un autre couvercle de protection, les implémentations d'appareil sont les suivantes:

• [C-SR-2] VIVEMENT RECOMMANDÉ d'implémenter un stockage adoptable.

7.7. USB

Si les appareils disposent d'un port USB, ils:

• DEVRAIT prendre en charge le mode périphérique USB et le mode hôte USB.
• DEVRAIT prendre en charge la désactivation du signal de données via USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils comprennent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT ê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 USB standard via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs 1,5 A et 3 A conformément à la norme de résistance de type C, et DOIT détecter les changements dans l'annonce si ceux-ci sont compatibles avec un câble USB Type-C.
• [C-SR-1] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Les appareils Android nouveaux et existants sont VIVEMENT RECOMMANDÉS de répondre à ces exigences afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• [C-SR-2] Le port DOIT être situé en bas de l'appareil (en fonction de l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement lorsque l'appareil est orienté avec le port situé en bas. Les appareils Android nouveaux et existants sont VIVEMENT RECOMMANDÉS de répondre à ces exigences afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• [C-SR-3] DEVRAIT prendre en charge la prise en charge d'un courant de 1,5 A pendant le bip et le trafic du haut-parleur, comme spécifié dans la révision 1.2 des spécifications de recharge de la batterie USB. Les appareils Android nouveaux et existants sont VIVEMENT RECOMMANDÉS de répondre à ces exigences afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• [C-SR-4] 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 du récepteur ou de la source, 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 considéré comme "VENTEMENT RECOMMANDÉ", dans les futures versions d'Android, nous EXIGERons tous les appareils de type C pour assurer une interopérabilité totale avec les chargeurs de type C standards.
• [C-SR-5] FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour les données et l'échange de rôle d'alimentation lorsqu'ils sont compatibles avec les modes USB de type C et hôte USB.
• DEVRAIT prendre en charge l'alimentation électrique pour la recharge haute tension et la prise en charge des autres modes tels que l'affichage.
• DEVRAIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, ils:

• [C-2-1] DOIT déclarer la prise en charge de 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 iInterface de la description de l'interface de la mémoire de stockage de masse USB.
• NE DEVRAIT PAS implémenter l'audio AOAv2 documenté dans la documentation du protocole Android Open Accessory 2.0. L'audio AOAv2 est obsolète depuis la version 8.0 d'Android (niveau d'API 26).

7.7.2. Mode hôte USB

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

• [C-1-1] DOIT implémenter l'API hôte USB Android comme indiqué 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. En d'autres termes, ils DOIVENT :
  • Disposer d'un port de type C intégré à l'appareil ou expédier vos produits avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB Type-C standard (appareil USB Type-C).
  • disposer d'un appareil de type A ou l'expédier avec un ou plusieurs câbles adaptant un port propriétaire de l'appareil à un port USB Type-A standard ;
  • disposer d'un port micro-AB intégré, qui DOIT être livré avec un câble adapté à un port standard de type A ;
• [C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant un port USB de type A ou micro-AB vers un port de type C (réceptacle).
• [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 le chargement du périphérique USB connecté lorsqu'il est en mode hôte.Il doit indiquer un courant source d'au moins 1,5 A, comme indiqué dans la section sur les paramètres de terminaison de la révision 1.2 des spécifications du connecteur USB Type-C et du connecteur 1.2 pour les connecteurs USB Type-C, ou à l'aide du port de recharge en aval(CDP) comme spécifié dans les spécifications des connecteurs de recharge USB-AB.
• DEVRAIT 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, ils:

• [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 requête d'utilisation de commandes vocales avec les constantes KeyEvent, comme indiqué ci-dessous :
  • ID d'utilisation (0x0CD) de la page d'utilisation (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID d'utilisation (0x0E9) de la page d'utilisation (0xC): KEYCODE_VOLUME_UP
  • ID d'utilisation de la page d'utilisation (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID d'utilisation (0x0CF) de la page d'utilisation (0xC): KEYCODE_VOICE_ASSIST

Si les mises en œuvre 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 tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leur 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, ils:

• [C-4-1] DOIT implémenter la fonctionnalité de port double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3). Pour les ports double rôle, sur les appareils équipés d'un connecteur audio 3,5 mm, la détection du récepteur USB (mode hôte) PEUT être désactivée par défaut, mais il DOIT être possible pour l'utilisateur de l'activer.
• [C-SR-2] FORTEMENT RECOMMANDÉ pour prendre en charge DisplayPort, DEVRAIT prendre en charge les débits de données USB SuperSpeed, et est VIVEMENT RECOMMANDÉ pour prendre en charge Power Delivery pour l'échange de données et de rôle de puissance.
• [C-SR-3] FORTEMENT RECOMMANDÉ DE NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la révision 1.2 des spécifications relatives au câble et au connecteur USB Type-C.
• DEVRAIT implémenter le modèle try.* le plus approprié pour le facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter le modèle try.SNK.

7.8. Son

Micro

Si les implémentations d'appareils incluent un micro, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio décrites dans la section 5.4.
• [C-1-3] DOIT répondre aux exigences de latence audio décrites dans la section 5.6.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement par ultrasons, comme décrit dans la section 7.8.3.

Si l'intégration d'un appareil n'inclut pas de micro:

• [C-2-1] NE DOIT PAS signaler la constante de caractéristique android.hardware.microphone.
• [C-2-2] DOIT implémenter l'API d'enregistrement audio au moins comme no-ops, conformément à la section 7.

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'un connecteur audio 3,5 mm à 4 conducteurs ou un port en mode hôte USB utilisant la classe audio USB, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.audio.output.
• [C-1-2] DOIT respecter les exigences concernant la lecture audio décrites dans la section 5.5.
• [C-1-3] DOIT répondre aux exigences de latence audio décrites dans la section 5.6.
• [C-SR-1] FORTEMENT RECOMMANDÉ pour prendre en charge la lecture par ultrasons, comme décrit dans la section 7.8.3.

Si les appareils ne comprennent pas de haut-parleur ni de port de sortie audio:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] DOIT implémenter les API liées à la sortie audio au moins comme no-ops.

Pour les besoins de cette section, un "port de sortie" est une interface physique, telle qu'un connecteur audio 3,5 mm, ou un port en mode hôte HDMI ou USB avec classe audio USB. La prise en charge de la sortie audio sur des protocoles basés sur la radio, tels que le Bluetooth, le Wi-Fi ou les réseaux mobiles, ne signifie pas qu'un "port de sortie" est inclus.

Ports audio analogiques

Pour être compatibles avec les casques audio et autres accessoires audio utilisant la prise audio 3, 5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins l'un des ports audio de sorte qu'il s'agisse d'un connecteur audio de 3,5 mm à 4 conducteurs.

Si les appareils sont équipés d'un connecteur audio 3, 5 mm à quatre conducteurs:

• [C-1-1] DOIT prendre en charge la lecture audio sur des casques stéréo et stéréo dotés d'un micro.
• [C-1-2] DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA.
• [C-1-3] DOIT prendre en charge la détection et la mise en correspondance des codes de clavier pour les trois plages suivantes d'impédance équivalente entre le micro et les conducteurs de terre sur la fiche audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une fiche, mais uniquement une fois que tous les contacts de la fiche touchent les segments correspondants sur le connecteur.
• [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 ohms.
• [C-1-6] DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper le code de clavier pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la fiche audio :
  • 110-180 ohm:KEYCODE_VOICE_ASSIST
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio dans l'ordre de brochement OMTP.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir d'un casque stéréo doté d'un micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à 4 conducteurs, sont compatibles avec un micro et diffusent le android.intent.action.HEADSET_PLUG avec le micro de valeur supplémentaire défini sur 1, ils:

• [C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

Ports audio numériques

Consultez la section 2.2.1 pour connaître les exigences spécifiques à chaque appareil.

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz.

Implémentations pour les appareils:

• DOIT indiquer correctement la prise en charge de la fonctionnalité audio de proche 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 respecter les exigences suivantes:

• [C-1-1] La réponse de puissance moyenne du micro dans la bande de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
• [C-1-2] Le rapport signal/bruit non pondéré du micro sur une plage de 18,5 kHz à 20 kHz pour un ton de 19 kHz à -26 dBFS DOIT ne pas être inférieur à 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true" (vrai) :

• [C-2-1] La réponse moyenne du haut-parleur sur la plage de 18,5 kHz à 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations pour les appareils:

• DEVRAIT fournir un chemin de signal audio sans faille 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. Effectuez un test avec l'outil de test de Glitch automatisé d'OboeTester.

Le test nécessite un dongle de bouclage audio, utilisé directement dans un connecteur 3,5 mm et/ou associé à un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester prend actuellement en charge les chemins AAudio. Par conséquent, les combinaisons suivantes DOIVENT être testées pour détecter des problèmes avec AAudio:

Mode Performances	Partage	Taux d'échantillonnage sortant	En chan	Chans.
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	1	2
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	2	1
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	1	2
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	2	1
AUCUN	PARTAGÉ	48000	1	2
AUCUN	PARTAGÉ	48000	2	1
AUCUN	PARTAGÉ	44100	1	2
AUCUN	PARTAGÉ	44100	2	1
AUCUN	PARTAGÉ	16000	1	2
AUCUN	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants pour le rapport signal sur bruit (SNR) et la distorsion harmonique totale (THD) pour le sinus de 2 000 Hz.

Transducteur	THD	Numéro SNR
haut-parleur intégré principal, mesuré à l'aide d'un micro 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 avec l'adaptateur de rebouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés avec l'adaptateur de rebouclage	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de réalité virtuelle (RV), y compris des expériences de RV mobiles de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme détaillé dans cette section.

7.9.1. Mode Réalité virtuelle

Android prend en charge le mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est axée sur l'utilisateur.

7.9.2. Mode Réalité virtuelle - Hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, ils:

• [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 prendre en charge le mode Performances soutenues.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.2.
• [C-1-5] DOIT accepter android.hardware.vulkan.level 0.
• DEVRAIT prendre en charge 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, EGL_EXT_image_gl_colorspace et exposer les extensions GL disponibles dans la liste des extensions GL 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 et GL_OVR_multiview_multisampled_render_to_texture, et d'exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS 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 les 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 dans laquelle flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et queueCount est au moins égal à 2.
• [C-1-7] Le GPU et l'écran DOIVENT être capables de synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu alterné des contenus de réalité virtuelle à 60 images par seconde avec deux contextes de rendu s'affiche sans artefacts de déchirure visibles.
• [C-1-9] DOIT implémenter la prise en charge des options 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 toute combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants : AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM et AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'allocation de AHardwareBuffer avec plusieurs couches et indicateurs et 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 Mbit/s à 6 Mbit/s).
• [C-1-12] DOIT être compatible avec les formats HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressés à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS et 20 Mbit/s à 30 FPS à 0 Mbit/s d'instances 1 à 0 FPS2.
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs de température cutanée précises.
• [C-1-14] DOIT disposer d'un écran intégré et sa résolution DOIT être au moins de 1 920 x 1 080.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'utiliser une résolution d'écran d'au moins 2 560 x 1 440 pixels.
• [C-1-15] L'écran DOIT mettre à jour une fréquence d'au moins 60 Hz en mode RV.
• [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance inférieure ou égale à 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 les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension section 7.4.3.
• [C-1-19] DOIT accepter et signaler correctement le type de canal direct 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 respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors, comme spécifié dans la section 7.3.9.
• [C-SR-8] Sont vivement RECOMMANDÉS pour la compatibilité avec la fonctionnalité android.hardware.sensor.hifi_sensors.
• [C-1-22] DOIT présenter une latence du mouvement de bout en bout au photon qui ne doit pas dépasser 28 millisecondes.
• [C-SR-9] Il est FORTEMENT RECOMMANDÉ que la latence du mouvement de bout en bout ne dépasse pas 20 millisecondes.
• [C-1-23] DOIT avoir un ratio de première image, c'est-à-dire le ratio entre la luminosité des pixels sur la première image après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable, d'au moins 85%.
• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de première image d'au moins 90%.
• PEUT fournir un cœur exclusif à l'application de premier plan et prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application de premier plan.

Si un cœur exclusif est pris en charge, le noyau:

• [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur sur celui-ci (à 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. Technologies haptiques

Consultez la section 2.2.1 pour connaître les exigences spécifiques à chaque appareil.

7.11. Classe Media Performance

La classe de performance multimédia de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Les exigences concernant la classe de performances multimédias sont définies pour chaque version d'Android à partir de R (version 30). La valeur spéciale de 0 indique que l'appareil n'appartient pas à une classe de performance multimédia.

Si les implémentations d'appareils 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 respecter toutes les exigences de la "classe de performance multimédia" décrites dans la section 2.2.7.

En d'autres termes, la classe de performance multimédia dans Android T n'est définie que pour les appareils portables de version T, S ou R.

Consultez la section 2.2.7 pour connaître les exigences spécifiques à chaque appareil.

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 lorsqu'ils développent 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 s'appliquent afin de 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, en fonction du type d'appareil, peuvent présenter des exigences mesurables en termes de latence de l'interface utilisateur et de changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes sur le stockage de données privé de l'application (partition /data) permet aux développeurs d'applications de définir une attente appropriée qui facilitera la conception de leur logiciel. Les implémentations d'appareils, selon leur type, PEUVENT présenter certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes:

• Performances d'écriture séquentielle. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec un tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire. Mesure effectuée par l'écriture d'un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 Ko.
• Performances de lecture séquentielle. Mesure effectuée par la lecture d'un fichier de 256 Mo à l'aide d'un tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire. Mesure effectuée par la lecture d'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 visant à améliorer la gestion de l'alimentation des appareils qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, Sommeil) ou qui étendent ces fonctionnalités pour appliquer des restrictions plus strictes que le bucket de mise en veille des applications LIMITÉ, elles:

• [C-1-1] NE DOIT PAS déroger à l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de wakeup, ni pour l'utilisation de paramètres système globaux ou de DeviceConfig des modes d'économie d'énergie et de mise en veille des applications.
• [C-1-2] NE DOIT PAS déroger à l'implémentation AOSP pour l'utilisation de paramètres globaux 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 Mise en veille des applications.
• [C-1-3] NE DOIT PAS dévier de la mise en œuvre 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 mettre en œuvre les buckets de mise en veille des applications et la fonctionnalité Sommeil comme décrit dans la section 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 une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Sommeil des applications, ou des optimisations de batterie, et DOIT implémenter l'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS pour demander à l'utilisateur d'autoriser une application à ignorer les optimisations de batterie.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir à l'utilisateur des affordances pour l'activation et la désactivation de l'économiseur de batterie.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Mise en veille des applications.

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 rares, reportez-vous à la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou la totalité des quatre états d'alimentation en veille définis par l'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] NE DOIT entrer dans cet état qu'une fois que l'utilisateur a effectué une action explicite pour mettre l'appareil dans un état inactif (par exemple, en fermant un capot qui fait partie physiquement de l'appareil, ou en éteignant un véhicule ou une télévision) et avant que l'utilisateur ne le réactive (par exemple, en ouvrant le capot ou en rallumant le véhicule ou la télévision).

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 respecter le code 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 ou le processeur).

  À l'inverse, vous DEVEZ quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

  Par exemple, bien que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur fonctionnant 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 rendre l'appareil inactif. À l'inverse, lorsqu'une tâche implémentée par des applications tierces via JobScheduler est déclenchée ou que Firebase Cloud Messaging est distribué à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur l'a désactivé. Ces exemples ne sont pas exhaustifs. AOSP met en œuvre de nombreux signaux de wakeup qui déclenchent un wakeup à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilité et des rapports plus précis sur la consommation d'énergie offrent au développeur d'applications les avantages et les outils nécessaires pour optimiser le modèle de consommation d'énergie de l'application.

Implémentations pour les appareils:

• [C-SR-1] FORTEMENT RECOMMANDÉ de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [C-SR-2] VIVEMENT RECOMMANDÉ de signaler toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
• [C-SR-3] VIVEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [C-SR-4] VIVEMENT RECOMMANDÉ de mettre cette consommation d'énergie à la disposition du développeur de l'application via la commande shell adb shell dumpsys batterystats.
• DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée hautes performances, soit à cause des autres applications s'exécutant en arrière-plan, soit à cause de la limitation du processeur en raison des limites de température. Android inclut des interfaces de programmation de sorte que, lorsque l'appareil le permet, l'application au premier plan supérieure puisse demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode API PowerManager.isSustainedPerformanceModeSupported().

• DEVRAIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils sont compatibles avec le mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan supérieure 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 au moins deux cœurs de processeur:

• DEVRAIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan.

Si les implémentations d'appareils permettent de réserver un cœur exclusif à l'application de premier plan, elles:

• [C-2-1] DOIT indiquer via la méthode d'API Process.getExclusiveCores() les numéros d'identification des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
• [C-2-2] NE DOIT PAS autoriser l'exécution d'aucun processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application, sur les cœurs exclusifs. Toutefois, certains processus du noyau PEUVENT s'exécuter si nécessaire.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, celles-ci:

• [C-3-1] DOIT renvoyer une liste vide via la méthode API Process.getExclusiveCores().

9. Compatibilité des modèles de sécurité

Implémentations pour 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 de la documentation pour les développeurs Android.

• [C-0-2] DOIT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers ou d'autorités.

Si les implémentations d'appareils déclarent la fonctionnalité android.hardware.security.model.compatible, elles:

• [C-1-1] DOIT respecter les exigences indiquées dans les sous-sections suivantes.

9.1. Autorisations

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge 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 ou ignorés.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne figurent pas dans l'espace de noms android.\*.

• [C-0-2] Les autorisations dont l'protectionLevel est 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 que des fichiers APEX) et faire partie du sous-ensemble des autorisations explicitement ajoutées à la liste d'autorisation pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations de chaque application à partir des fichiers du chemin privilégié etc/permissions/ et en utilisant le chemin system/priv-app.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec une targetSdkVersion supérieure à 22 les demandent au moment de l'exécution.

Implémentations pour les appareils:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider s'il doit accorder les autorisations d'exécution demandées et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] DOIT comporter une seule et unique implémentation des deux interfaces utilisateur. Si l'implémentation de l'appareil est compatible avec un appareil associé, celui-ci PEUT fournir une interface supplémentaire.

• [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications, sauf dans les cas suivants:

  • Ils sont installés au moment de l'expédition de l'appareil, ET

  • Vous pouvez obtenir le consentement de l'utilisateur avant que l'application n'utilise l'autorisation.

    OU

  • Les autorisations d'exécution sont accordées par la stratégie d'attribution d'autorisations par défaut ou disposent d'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 espace de stockage distant hors appareil. Il est équipé d'un matériel sécurisé dont la protection est é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 connaissances de l'écran de verrouillage.

Implémentations pour les appareils:

• [C-0-7] DOIT respecter les propriétés d'autorisation d'accès à la position Android lorsqu'une application demande des données de localisation ou d'activité physique via l'API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter:

  • La position de l'appareil (latitude et longitude, par exemple), comme décrit dans la section 9.8.8.
  • Informations pouvant être utilisées pour déterminer ou estimer la position de l'appareil (par exemple, SSID, BSSID, ID de cellule ou emplacement 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] DOIT obtenir le consentement de l'utilisateur pour permettre à une application d'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 des autorisations suffisantes, 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ès à la position Android ci-dessus concernent les applications qui n'accèdent pas à la position pour déterminer ou identifier la position de l'utilisateur:

• Lorsque les applis détiennent l'autorisation RADIO_SCAN_WITHOUT_LOCATION.
• À des fins de configuration de l'appareil, lorsque 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 comportant l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si:

  • Un fichier APK d'application se trouve dans la partition du système.
  • L'utilisateur attribue un rôle associé aux autorisations hardRestricted à une application.
  • Le programme d'installation accorde le hardRestricted à une application.
  • Une application se voit attribuer le 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ù un accès complet et limité est défini pour chaque autorisation softRestricted (par exemple, READ_EXTERNAL_STORAGE).

• [C-0-12] NE DOIT PAS fournir de fonctions ni d'API personnalisées permettant de 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 provenant des activités et services Android.

• [C-0-14] NE DOIT attribuer des rôles qu'aux applications disposant de fonctionnalités répondant aux exigences de ce rôle.

• [C-0-15] NE DOIT PAS définir de rôles correspondant à des doublons ou à des fonctionnalités sur-ensemble de rôles définis par la plate-forme.

Si les appareils signalent android.software.managed_users:

• [C-1-1] NE DOIT PAS disposer des autorisations suivantes accordées silencieusement par l'administrateur :
  • Emplacement (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION et ACCESS_FINE_LOCATION)
  • Caméra (CAMERA)
  • Micro (RECORD_AUDIO)
  • Capteur corporel (BODY_SENSORS)
  • Activité physique (ACTIVITÉ_RECOGNITION)

Si les implémentations d'appareils permettent à l'utilisateur de choisir les applications qui peuvent se superposer aux 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'interface utilisateur, quelles que soient l'application de lancement ou les informations qu'elle fournit.

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

• [C-3-1] DOIT afficher une clause de non-responsabilité lors de la configuration entièrement gérée de l'appareil (configuration par le 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 localisation, avec des options permettant à l'utilisateur de poursuivre la configuration ou de quitter la configuration SAUF si l'administrateur a désactivé les autorisations sur l'appareil.

Si les implémentations d'appareils préinstallent les packages qui possèdent 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 respecter toutes les exigences décrites dans la section "9.8.6 Capture de contenu" pour les mises en œuvre d'appareils.
• [C-4-2] NE DOIT PAS disposer de l'autorisation android.permission.INTERNET. Cette valeur est plus stricte que les recommandations FORTEMENT RECOMMANDÉES figurant dans la section 9.8.6.
• [C-4-3] NE DOIT PAS être associé à d'autres applications, à l'exception des applications système suivantes: Bluetooth, Contacts, Multimédia, Téléphonie, SystemUI et composants fournissant des API Internet.Cette option est plus stricte que les recommandations FORTEMENT RECOMMANDÉES figurant dans la section 9.8.6.

9.2. UID et isolation de processus

Implémentations pour 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 unique de style Unix et dans un processus distinct.
• [C-0-2] DOIT prendre en charge 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 pour les appareils:

• [C-0-1] DOIT prendre en charge 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 logiciel ou d'une technologie autre que le format exécutable Dalvik ou du code natif. Autrement dit :

• [C-0-1] Les environnements d'exécution alternatifs DOIVENT être des applications Android et respecter le modèle de sécurité Android standard, tel que décrit ailleurs dans la section 9.

• [C-0-2] Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution 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 des autorisations Android limitées aux applications système.

• [C-0-4] Les autres environnements d'exécution DOIVENT respecter le modèle de bac à sable Android, et les applications installées qui utilisent un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards de partage de l'ID utilisateur et du certificat de signature.

• [C-0-5] Les autres environnements d'exécution NE DOIVENT PAS être lancés avec les bacs à sable correspondant à d'autres applications Android, ni leur accorder l'accès, ni y être autorisés.

• [C-0-6] Les autres environnements d'exécution NE DOIVENT PAS être lancés avec d'autres applications, ni accordés, ni accordés à d'autres applications.

• [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses dans les implémentations d'appareils.

• [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 d'appareil pour laquelle il existe une autorisation Android correspondante (telle que 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 fonctionnalités des applications de cette manière, il DOIT répertorier 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.

• D'autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

• Les autres environnements d'exécution PEUVENT fournir un seul bac à sable Android partagé par toutes les applications qui les utilisent.

9.5. Compatibilité multi-utilisateur

Android permet la prise en charge de plusieurs utilisateurs, l'isolation complète des utilisateurs et le clonage de 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 s'ils utilisent des supports amovibles pour le stockage externe principal.

Si les implémentations d'appareils sont compatibles avec 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 des API.
• [C-1-3] DOIT disposer d'un répertoire de stockage d'application partagé séparé et isolé (également appelé /sdcard) pour chaque instance d'utilisateur.
• [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées pour celui-ci ne peuvent pas répertorier, lire ou é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 des supports amovibles pour les API de stockage externe. Comme cela rend le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel.

Si les implémentations d'appareils prennent en charge plusieurs utilisateurs, les mesures suivantes sont appliquées pour tous les utilisateurs, à l'exception de ceux créés spécifiquement pour exécuter des instances en double de la même application:

• [C-2-1] DOIT disposer d'un répertoire de stockage d'application partagé séparé et isolé (également appelé /sdcard) pour chaque instance d'utilisateur.
• [C-2-2] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées pour celui-ci ne peuvent pas répertorier, lire ou é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 seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE pour l'utilisateur principal (et uniquement pour l'utilisateur principal) dans le but d'exécuter des instances doubles de la même application. Ces instances doubles partagent un espace de stockage partiellement isolé, sont présentées simultanément à l'utilisateur final dans le lanceur d'applications et apparaissent dans la même vue "Recents". Par exemple, cela peut permettre à l'utilisateur d'installer deux instances distinctes d'une même application sur un appareil avec double carte SIM.

Si les implémentations d'appareils créent le profil utilisateur supplémentaire décrit ci-dessus, ils:

• [C-3-1] DOIT ne fournir un accès qu'à un espace de stockage ou à des données déjà accessibles par le profil utilisateur parent ou appartenant directement à ce profil utilisateur supplémentaire.
• [C-3-2] NE DOIT PAS avoir ceci comme profil professionnel.
• [C-3-3] DOIT avoir isolé des répertoires de données d'application privé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 d'appareil est provisionné (voir la section 3.9.1) ni autoriser le provisionnement d'un propriétaire d'appareil sans supprimer d'abord le profil utilisateur supplémentaire.

9.6. Avertissement relatif aux SMS premium

Android permet d'avertir les utilisateurs de tout SMS premium sortant. Les SMS premium sont des SMS envoyés à un service enregistré auprès d'un opérateur qui peut entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.telephony, elles:

• [C-1-1] DOIT avertir les utilisateurs avant d'envoyer un 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 garantir 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) de Security-Enhanced Linux (SELinux), le système de bac à sable seccomp et d'autres fonctionnalités de sécurité dans le noyau Linux. Implémentations pour les appareils:

• [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité est implémenté en dessous du framework Android.
• [C-0-2] NE DOIT PAS avoir d'interface utilisateur visible lorsqu'une violation de sécurité est détectée et bloquée avec succès par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT avoir une interface utilisateur visible en cas de violation de sécurité débloquée entraînant une exploitation réussie.
• [C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée en dessous du framework Android configurable pour l'utilisateur ou le développeur de l'application.
• [C-0-4] NE DOIT PAS permettre à une application pouvant affecter une autre application via une API (telle qu'une API Device Administration) de configurer une règle rompant la compatibilité.
• [C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin qu'il soit possible d'accorder un accès plus restreint pour chaque processus, comme décrit sur le site du projet Android Open Source.
• [C-0-6] DOIT mettre en œuvre un mécanisme de bac à sable pour l'application du noyau permettant de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Open Source Android en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation des groupes de threads (TSYNC), comme décrit dans la section "Configuration du noyau" de source.android.com.

Les fonctionnalités d'intégrité du noyau et d'autoprotection font partie intégrante de la sécurité d'Android. Implémentations pour les appareils:

• [C-0-7] DOIT implémenter des mécanismes de protection contre le débordement de la mémoire tampon de la pile du noyau. CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG sont des exemples de mécanismes de ce type.
• [C-0-8] DOIT mettre en œuvre des protections strictes de la mémoire du noyau où le code exécutable est en lecture seule, les données en lecture seule ne sont pas exécutables ni en écriture, et les données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DOIT implémenter la vérification des limites de taille d'objet statique et dynamique des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec le niveau d'API 28 ou supérieur.
• [C-0-10] NE DOIT PAS exécuter la mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, PXN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur des appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire de l'espace utilisateur dans le noyau en dehors des API d'accès à la copie utilisateur normales (par exemple, le PAN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-12] DOIT mettre en œuvre l'isolation des tables de pages du noyau si le matériel est vulnérable à la faille CVE-2017-5754 sur tous les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] DOIT mettre en œuvre le renforcement de la prédiction de branche si le matériel est vulnérable à la faille CVE-2017-5715 sur tous les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau afin d'empêcher 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 paramètres locaux.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation marquées en lecture seule après l'initialisation (par exemple, __ro_after_init).

• [C-SR-3] EST FORTEMENT RECOMMANDÉ pour randomiser la mise en page du code et de la mémoire du noyau, et pour éviter toute exposition qui pourrait compromettre 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-4] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau afin de fournir une protection supplémentaire contre les attaques de réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver Control-Flow Integrity (CFI), Shadow Call Stack (SCS) ou Integer Overflow Sanitization (IntSan) sur les composants pour lesquels ils sont activés.

• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tous les composants d'espace utilisateur supplémentaires sensibles à la sécurité, comme expliqué dans CFI et IntSan.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau afin d'empêcher 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 paramètres locaux.

• [C-SR-8] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau afin d'empêcher l'utilisation d'allocations de segments de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Il NE DOIT PAS 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 global.
• [C-1-3] DOIT configurer tous les domaines en mode "Enforcing". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/fournisseur.
• [C-1-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le dossier "system/sepolicy" fourni dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT être compilée avec toutes les règles "Neverallow" présentes, à la fois pour les domaines AOSP SELinux et pour les domaines spécifiques à l'appareil ou au fournisseur.
• [C-1-5] DOIT exécuter des 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é de chaque application.
• DEVRAIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et n'ajouter à cette règle que pour leur propre configuration spécifique à l'appareil.

Si les implémentations d'appareils utilisent un noyau autre que Linux ou Linux sans SELinux:

• [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 la loi sur les marchés numériques, ils:

• [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'isoler chaque appareil d'E/S compatible avec la loi sur les marchés numériques à l'aide d'un IOMMU (par exemple, le SMMU ARM).

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils. En outre, Android s'efforce de réduire les classes clés de bugs courants qui contribuent à la mauvaise qualité et à la sécurité.

Afin de réduire les bugs de mémoire, les implémentations d'appareils:

• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'être testé à 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 et versions ultérieures ou ASan pour les autres types d'appareils.
• [C-SR-11] Il est FORTEMENT RECOMMANDÉ d'être testé à 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, tels que 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 le framework du micrologiciel Arm pour Armv8-A (FF-A).
• [C-SR-14] Il est FORTEMENT RECOMMANDÉ de limiter les applications approuvées à la mémoire qui a été explicitement partagée avec elles via le protocole ci-dessus. Si l'appareil prend en charge le niveau d'exception S-EL2 Arm, celui-ci doit être appliqué par le gestionnaire de partitions sécurisé. Sinon, cela doit être appliqué par le TEE OS.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et gère cet historique via UsageStatsManager.

Implémentations pour les appareils:

• [C-0-1] DOIT conserver une durée de conservation raisonnable de cet historique utilisateur.
• [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 d'AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via StatsManager et l'API système IncidentManager.

Implémentations pour les appareils:

• [C-0-2] DOIT inclure uniquement les champs marqués d'un DEST_AUTOMATIC dans le rapport 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 les documents du SDK StatsLog. Si d'autres événements système sont enregistrés, ils PEUVENT utiliser un identifiant atomique différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient des informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran ou le rapport de bug) depuis l'appareil sans le consentement de l'utilisateur ou des notifications claires en cours.
• [C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur permettant de capturer toute information sensible affichée sur son écran chaque fois que la diffusion ou l'enregistrement d'écran sont activés via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs une affordance de désactiver l'affichage futur du consentement de l'utilisateur.
• [C-0-3] DOIT recevoir une notification d'activité en cours à 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 en cours dans la barre d'état.

Si les implémentations d'appareils incluent une fonctionnalité dans le système qui capture le contenu affiché à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou par d'autres moyens propriétaires décrits dans la section 9.8.6 Capture de contenu, elles:

• [C-1-1] DOIT recevoir une notification d'activité en continu à l'utilisateur chaque fois que cette fonctionnalité est activée et qu'elle capture ou enregistre activement.

Si les implémentations sur l'appareil incluent un composant prêt à l'emploi, capable d'enregistrer le son ambiant et/ou d'enregistrer le contenu 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 depuis l'appareil le contenu audio brut enregistré ou tout format pouvant être reconverti en contenu audio d'origine ou sous forme de télécopie, sauf avec le consentement explicite de l'utilisateur.

Un "indicateur de micro" fait référence à une vue à l'écran, qui est constamment visible par l'utilisateur et ne peut pas être masquée, et que les utilisateurs comprennent qu'un micro est utilisé(par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Un "indicateur d'appareil photo" désigne une vue à l'écran, qui est constamment visible par l'utilisateur et ne peut pas être masquée, et que les utilisateurs comprennent 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 uniques).

Après l'affichage de la première seconde, un indicateur peut changer visuellement, par exemple en devenant plus petit. Il n'est donc pas nécessaire de s'afficher tel qu'il était présenté et compris à l'origine.

L'indicateur du micro peut être fusionné avec un indicateur de caméra affiché en cours, à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que l'utilisation du micro a commencé.

L'indicateur d'appareil photo peut être fusionné avec un indicateur de micro affiché activement, à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que l'utilisation de l'appareil photo a commencé.

Si les implémentations d'appareils 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 une ou plusieurs applications détenant les rôles décrits dans la section 9.1 Autorisations avec 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, tel que renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de micro pour les applications système ayant des interfaces utilisateur visibles ou une interaction directe avec l'utilisateur.

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

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur de l'appareil photo lorsqu'une application accède aux données en direct de l'appareil photo, mais pas lorsque seules les applications détenant les rôles décrits dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X] y accèdent.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher les applications récentes et actives à l'aide de l'appareil photo (comme renvoyé par PermissionManager.getIndicatorAppOpUsageData()), ainsi que tous les messages d'attribution qui leur sont associés.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur d'appareil photo des applications système dont les interfaces utilisateur sont visibles ou qui interagissent directement avec l'utilisateur.

9.8.3. Connectivité

Si les implémentations d'appareils disposent d'un port USB compatible avec le mode périphérique USB, ils:

• [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu de l'espace de stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations pour les appareils:

• [C-0-1] DOIT préinstaller pour le magasin de l'autorité de certification approuvé par le système les mêmes certificats racine que ceux fournis en amont dans le projet Android Open Source en amont.
• [C-0-2] DOIT être livré avec un magasin d'autorités de certification racine d'utilisateur vide.
• [C-0-3] DOIT afficher un avertissement indiquant à l'utilisateur que le trafic réseau peut être surveillé, lorsqu'une autorité de certification racine est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations d'appareils:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
  • 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é automatiquement par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, le préchargement d'un service VPN avec l'autorisation android.permission.CONTROL_VPN), elles:

• [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par le contrôleur de règles relatives aux appareils via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas, l'utilisateur n'a pas besoin de fournir un consentement distinct, mais il DOIT seulement être notifié.

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 affordance utilisateur pour les applications qui ne sont pas compatibles avec 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 pour les appareils:

• [C-0-1] DOIT empêcher une application d'accéder 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é IMSI (International Mobile Subscriber Identity) depuis une application, sauf si elle répond à l'une des exigences suivantes :
  • est une application d'opérateur signée qui est validée par les fabricants d'appareils.
  • L'autorisation READ_PRIVILEGED_PHONE_STATE a été accordée.
  • dispose de privilèges d'opérateur tels que définis dans les droits d'opérateur de l'UICC.
  • est un propriétaire d'appareil ou de profil disposant de l'autorisation READ_PHONE_STATE.
  • (Pour le numéro de série de la carte SIM et l'ICCID uniquement) Conformément aux réglementations locales, l'application doit détecter les modifications apportées à l'identité de l'abonné.

9.8.6. Capture de contenu et recherche d'applications

Android, via l'API System ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou par d'autres moyens propriétaires, est compatible avec un mécanisme d'implémentation d'appareils permettant de capturer les interactions de données d'application suivantes entre les applications et l'utilisateur:

• Texte et images affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure.
• Données multimédias, telles que du contenu audio ou vidéo, enregistrées ou lues par l'appareil.
• Événements d'entrée (par exemple, touche, souris, geste, voix, vidéo et accessibilité)
• Tous les autres événements qu'une application fournit au système via l'API Content Capture ou l'API AppSearchManager, une API Android et propriétaire aux fonctionnalités similaires.
• Texte ou autres données envoyés via TextClassifier API au TextClassifier du système, c'est-à-dire au service système pour comprendre la signification du texte et générer les prochaines actions prédites en fonction de celui-ci.
• Données indexées par l'implémentation de la plate-forme AppSearch, y compris, mais sans s'y limiter, le texte, les graphiques, les données multimédias ou d'autres données similaires.

Si les implémentations d'appareils collectent les données ci-dessus, elles:

• [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées sur l'appareil. Ce chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android ou de l'un des algorithmes de chiffrement listés dans la version 26 ou ultérieure de l'API, comme décrit dans le SDK de chiffrement.
• [C-1-2] NE DOIT PAS sauvegarder de données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ou de toute autre méthode de sauvegarde.
• [C-1-3] DOIT envoyer uniquement l'ensemble de ces données et le journal de l'appareil à l'aide d'un mécanisme protégeant la confidentialité. Le mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale 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'éviter que les données utilisateur soient introspectives (par exemple, mises en œuvre à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
• [C-1-4] NE DOIT PAS associer ces données à une identité d'utilisateur (telle que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont associées.
• [C-1-5] NE DOIT PAS partager ces données avec d'autres composants de l'OS qui ne respectent pas les exigences de la section actuelle (9.8.6 Capture de contenu), sauf en cas de partage explicite de ces données avec l'utilisateur.
• [C-1-6] DOIT fournir une affordance à l'utilisateur pour effacer les données collectées par l'ContentCaptureService ou le moyen propriétaire si les données sont stockées sur l'appareil sous quelque forme que ce soit.
• [C-1-7] DOIT fournir une affordance à l'utilisateur pour qu'il puisse refuser l'affichage des données collectées via AppSearch ou des moyens propriétaires sur la plate-forme Android (par exemple, Lanceur d'applications).
• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de NE PAS demander l'autorisation INTERNET.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de n'accéder à Internet que via des API structurées reposant sur des implémentations Open Source publiques.

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService, AppSearchManager.index 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 qu'ils peuvent installer, et DOIT autoriser uniquement les services préinstallés à capturer de telles données.
• [C-2-2] NE DOIT PAS permettre à des applications autres que le mécanisme des services préinstallés de capturer de telles données.
• [C-2-3] DOIT fournir une affordance à l'utilisateur pour désactiver les services.
• [C-2-4] NE DOIT PAS omettre les affordances de l'utilisateur pour gérer les autorisations Android détenues par les services et qui suivent 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, sans lier le service ou partager des ID de processus), sauf dans les cas suivants:

  • Téléphonie, contacts, UI du système et médias

Android, via SpeechRecognizer#onDeviceSpeechRecognizer(), permet d'effectuer une reconnaissance vocale sur l'appareil sans impliquer le réseau. Toute implémentation de la reconnaissance vocale sur l'appareil DOIT respecter les règles décrites dans cette section.

9.8.7. Accès au presse-papiers

Implémentations pour 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 ciblée.
• [C-0-2] DOIT effacer les données du presse-papiers au plus tard 60 minutes après leur dernier placement dans le presse-papiers ou sa dernière lecture.

9.8.8. Position

La localisation inclut des informations dans la classe de localisation Android( telles que la latitude, la longitude et l'altitude), ainsi que des identifiants pouvant être convertis en localisation. La localisation peut être aussi précise que le système DGPS (Differential Global Positioning System) ou plus approximative que la localisation au niveau du pays (par exemple, l'emplacement du code pays - MCC - Mobile Country Code).

Vous trouverez ci-dessous une liste de types de zones géographiques qui déterminent directement la position de l'utilisateur ou qui peuvent être converties en fonction de celle-ci. Cette liste n'est pas exhaustive, mais elle doit être utilisée comme exemple des éléments suivants:

• GPS/GNSS/DGPS/PPP
  • Solution de positionnement global, système de navigation mondiale par satellite ou solution de positionnement global différentiel
  • Cela inclut également les mesures GNSS brutes et l'état GNSS.
    • La position précise peut être obtenue à partir des mesures GNSS brutes
• Technologies sans fil avec des identifiants uniques tels que :
  • Points d'accès Wi-Fi (MAC, BSSID, nom ou SSID)
  • Bluetooth/BLE (MAC, BSSID, nom ou SSID)
  • UWB (MAC, BSSID, nom ou SSID)
  • Identifiant de la tour de téléphonie mobile (3G, 4G, 5G, etc., y compris toutes les futures technologies de modem cellulaire dotées d'identifiants uniques)

Comme point de référence principal, consultez les API Android qui nécessitent les autorisations ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS activer/désactiver le paramètre de localisation de l'appareil ni les paramètres de recherche Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ni à l'initiative de celui-ci.
• [C-0-2] DOIT fournir à l'utilisateur les autorisations d'accès aux informations de localisation, y compris les requêtes de localisation récentes, les autorisations au niveau de l'application et l'utilisation de la recherche Wi-Fi/Bluetooth pour déterminer la position.
• [C-0-3] DOIT s'assurer que l'application qui utilise l'API de contournement de la localisation d'urgence [LocationRequest.setLocationSettingsIgnored()] est une session d'urgence lancée par l'utilisateur (par exemple, appeler le 112 ou envoyer un SMS au 112). Toutefois, pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction de l'utilisateur actif si un accident ou un accident est détecté (par exemple, pour répondre aux exigences d'appel électronique).
• [C-0-4] DOIT préserver la capacité de l'API de contournement de la localisation d'urgence à contourner les paramètres de localisation de l'appareil sans les modifier.
• [C-0-5] DOIT programmer 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].

9.8.9. Applications installées

Par défaut, les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas afficher d'informations sur les autres applications installées (voir Visibilité des packages dans la documentation du SDK Android).

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou supérieur des détails d'une autre application installée, sauf si l'application est déjà en mesure de voir les détails de 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'outil de mise en œuvre 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 d'un répertoire dédié et spécifique à une application d'une autre application dans un espace de stockage externe. Les seules exceptions sont les suivantes :
  • Autorité du fournisseur de stockage externe (par exemple, des applications telles que DocumentsUI).
  • Fournisseur de téléchargement qui utilise l'autorité de fournisseur "téléchargements" pour télécharger des fichiers dans l'espace de stockage des applications.
  • Applications MTP (Media Transfer Protocol) 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" afin de gérer les fichiers d'extension pour APK.

9.8.10. Rapport de bug de connectivité

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

• [C-1-1] DOIT prendre en charge la génération de rapports de bugs de connectivité via BUGREPORT_MODE_TELEPHONY avec BugreportManager.
• [C-1-2] DOIT obtenir le consentement de l'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 requêtes de l'application.
• [C-1-3] NE DOIT PAS renvoyer le rapport généré à l'application à l'origine de la demande sans le consentement explicite de l'utilisateur.
• [C-1-4] Les rapports générés avec BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes :
  • Fichier de dump TelephonyDebugService
  • Fichier de dump TelephonyRegistry
  • Fichier de dump WifiService
  • Fichier de dump ConnectivityService
  • Un vidage de l'instance CarrierService du package appelant (si lié)
  • Tampon journal radio
• [C-1-5] NE DOIT PAS inclure les éléments suivants dans les rapports générés :
  • Toute information qui n'est pas directement liée au débogage de la connectivité.
  • Tous types de journaux de trafic des applications installées par l'utilisateur ou de profils détaillés des applications/packages installés par l'utilisateur (les UID sont acceptés, mais pas les noms de packages).
• PEUT inclure des informations supplémentaires qui ne sont associées à aucune identité d'utilisateur. (par exemple, les journaux des fournisseurs).

Si les implémentations d'appareils incluent des informations supplémentaires (telles que 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É de définir un paramètre de développeur désactivé par défaut. L'implémentation de la référence AOSP répond à ce besoin en fournissant l'option Enable verbose vendor logging dans les paramètres pour les développeurs afin d'inclure des journaux de fournisseurs supplémentaires 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 transmettre des blobs de données au système à partager avec un ensemble d'applications sélectionné.

Si les implémentations d'appareils sont compatibles avec les blobs de données partagées, comme décrit dans la documentation du SDK, elles:

• [C-1-1] NE DOIT PAS partager de blobs de données appartenant à des applications dépassant le cadre prévu (c'est-à-dire le champ d'application de l'accès par défaut et les autres modes d'accès pouvant être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess()) La mise en œuvre de référence AOSP répond à ces exigences.
• [C-1-2] NE DOIT PAS envoyer depuis l'appareil ni partager avec d'autres applications les hachages sécurisés de blobs de données (utilisés pour contrôler l'accès).

9.8.12. Reconnaissance musicale

Android, via MusicRecognitionManager de l'API système, prend en charge 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 qui implémente l'API MusicRecognitionService.

Si les implémentations d'appareils incluent un service qui implémente l'API System MusicRecognitionManager ou tout service propriétaire qui diffuse des données audio comme décrit ci-dessus:

• [C-1-1] DOIT faire en sorte que l'appelant de MusicRecognitionManager détienne l'autorisation MANAGE_MUSIC_RECOGNITION.
• [C-1-2] DOIT faire en sorte qu'une seule application de reconnaissance musicale préinstallée mette MusicRecognitionService en œuvre.
• [C-1-3] NE DOIT PAS autoriser les utilisateurs à remplacer MusicRecognitionManagerService ou MusicRecognitionService par une application ou un service qu'ils peuvent installer.
• [C-1-4] DOIT s'assurer que lorsque MusicRecognitionManagerService accède à l'enregistrement audio et le transfère à l'application mettant en œuvre MusicRecognitionService, l'accès audio est suivi via des appels d'AppOpsManager.noteOp / startOp.

Si les implémentations de MusicRecognitionManagerService ou MusicRecognitionService stockées sur des appareils stockent des données audio capturées, elles:

• [C-2-1] NE DOIT PAS stocker d'empreintes audio ou audio brutes sur le disque du tout, ni en mémoire pendant plus de 14 jours.
• [C-2-2] NE DOIT PAS partager ces données au-delà de MusicRecognitionService, sauf avec le consentement explicite de l'utilisateur chaque fois qu'elles sont partagées.

9.8.13. SensorPrivacyManager

Si les implémentations d'appareils fournissent à l'utilisateur une affordance logicielle permettant 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] DOIT renvoyer précisément la valeur "true" pour la méthode API supportsSensorToggle() concernée.
• [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 qu'il ne peut pas ignorer, qui indique clairement que le capteur est bloqué et nécessite de continuer à bloquer ou débloquer conformément à l'implémentation AOSP qui répond à cette exigence.
• [C-1-3] DOIT transmettre uniquement des données d'appareil photo et audio vides (ou factices) aux applications, et ne pas signaler de code d'erreur, car l'utilisateur n'active pas l'appareil photo ni le micro via l' affordance utilisateur présentée comme indiqué dans le document [C-1-2] ci-dessus.

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT respecter les exigences de la section 9.9.1. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. À la place, ils DOIVENT respecter les exigences de la section 9.9 du document de définition de compatibilité Android correspondant au niveau d'API sur lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations pour les appareils:

• [C-0-1] DOIT mettre en œuvre les API en mode Démarrage direct, 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 des emplacements de stockage chiffrés sur l'appareil (DE) et CE (identifiants chiffrés) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations pour 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) s'il s'agit d'une partie permanente et non amovible de l'appareil.
• [C-0-2] DOIT activer le chiffrement du stockage des données par défaut au moment où l'utilisateur a terminé la configuration initiale.

• [C-0-3] DOIT respecter les exigences de chiffrement du stockage de données ci-dessus en mettant en œuvre l'une des deux méthodes de chiffrement suivantes:

  • Le chiffrement basé sur les fichiers (FBE) et le chiffrement des métadonnées, comme décrit dans la section 9.9.3.1.
  • Chiffrement au niveau du bloc par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareils 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 DE (Device Encrypted) une fois le message ACTION_LOCKED_BOOT_COMPLETED diffusé.
• [C-1-2] NE DOIT autoriser l'accès au stockage CE (identifiants chiffrés) qu'une fois que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, code secret, code, schéma ou empreinte) et que le message ACTION_USER_UNLOCKED est diffusé.
• [C-1-13] NE DOIT PAS proposer de méthode permettant de déverrouiller le stockage protégé par l'API CE sans les identifiants fournis par l'utilisateur, une clé de séquestre enregistrée ou un CV au moment du 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 et métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec chiffrement des métadonnées:

• [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide de l'algorithme AES-256-XTS ou Adiantum. AES-256-XTS fait référence à la norme Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits et fonctionne en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme spécifié à l'adresse https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que la taille des fichiers, leur propriété, les modes et les attributs étendus (xattrs).
• [C-1-6] DOIT chiffrer les noms de fichiers à l'aide de l'algorithme AES-256-CBC-CTS ou Adiantum.
• [C-1-12] Si l'appareil dispose d'instructions AES (Advanced Encryption Standard), telles que les extensions de cryptographie ARMv8 sur les appareils ARM ou AES-NI sur les appareils x86), les options AES ci-dessus pour le nom, le contenu 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é non réversible et sécurisée de manière cryptographique (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. L'expression "solide en termes de chiffrement et non réversible" signifie que la fonction de dérivation de clé a un niveau 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) à des fins de chiffrement différentes (par exemple, pour le chiffrement et la dérivation des clés, ou pour deux algorithmes de chiffrement différents).
• [C-1-15] DOIT s'assurer que tous les blocs de contenu de fichiers chiffrés non supprimés 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 du décalage dans le fichier. En outre, toutes ces combinaisons DOIVENT être distinctes, sauf si le chiffrement est effectué à l'aide de matériel de chiffrement intégré qui n'accepte qu'une longueur de vecteur d'initialisation de 32 bits.
• [C-1-16] DOIT s'assurer que tous les noms de fichiers chiffrés non supprimés du 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 (IV).

• [C-1-17] DOIT s'assurer que tous les blocs de métadonnées chiffrés du système de fichiers 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 matérielle de confiance 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 code secret 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, c'est-à-dire qu'aucune clé CE ou DE d'utilisateur ne correspond aux clés CE ou DE d'un autre utilisateur.
  • [C-1-11] DOIT utiliser les algorithmes de chiffrement, longueurs de clé et modes obligatoires.
  • [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.

• DEVRAIT faire en sorte que les applis essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) soient compatibles avec le démarrage direct.

Le projet Open Source Android en amont fournit une implémentation privilégiée du chiffrement basé sur les fichiers basée 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 du bloc par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau du bloc par utilisateur:

• [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 de volumes logiques.
• [C-1-3] DOIT utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des appareils de stockage en mode bloc sous-jacents.

• [C-1-4] DOIT utiliser l'algorithme AES-256-XTS pour le chiffrement au niveau du bloc des partitions utilisateur.

• Les clés qui protègent les appareils chiffrés au niveau du bloc 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 matérielle de confiance de l'appareil.
  • [C-1-6] DOIT être lié aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau du bloc par utilisateur peut être mis en œuvre à l'aide de la fonctionnalité "dm-crypt" du noyau Linux sur des partitions par utilisateur.

9.9.4. Reprendre au 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 OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

La mise en œuvre de la fonctionnalité de 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 celui-ci de récupérer les données de l'utilisateur chiffrées par CE, même s'il est allumé, que le stockage CE est déverrouillé et que l'utilisateur l'a déverrouillé après avoir reçu une mise à jour OTA. Pour la résistance aux attaques internes, nous supposons également que le pirate informatique parvient à diffuser des clés de signature cryptographique.

Plus spécifiquement :

• [C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour le pirate informatique qui possède physiquement l'appareil, puis présente les capacités et limites suivantes:

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • Ce paramètre peut entraîner la réception d'une mise à jour OTA par l'appareil.
  • Peut modifier le fonctionnement de n'importe quel matériel (point d'accès, flash, etc.), sauf dans les cas indiqués ci-dessous, mais cette modification implique un délai d'au moins une heure et un cycle d'arrêt qui détruit le contenu de la RAM.
  • Ne peut pas modifier le fonctionnement d'un matériel protégé contre les accès non autorisés (Titan M, par exemple).
  • Impossible de lire la RAM de l'appareil actif.
  • ne peut pas obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ni faire en sorte qu'ils soient saisis.

À titre d'exemple, une implémentation d'appareil qui implémente et respecte toutes les descriptions disponibles sur cette page sera conforme à la norme [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent que l'état de l'intégrité de l'appareil est transparent. Implémentations pour les appareils:

• [C-0-1] DOIT indiquer correctement, à l'aide de la méthode PersistentDataBlockManager.getFlashLockState() de l'API système, si l'état du bootloader autorise le flash de l'image système.

• [C-0-2] DOIT être compatible avec le démarrage validé pour assurer l'intégrité de l'appareil.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge le démarrage validé sur une version antérieure d'Android et qu'il n'est pas possible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système, elles PEUVENT être exemptées de l'exigence.

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

• [C-1-1] DOIT déclarer l'indicateur de fonctionnalité de la plate-forme android.software.verified_boot.
• [C-1-2] DOIT effectuer une vérification sur chaque séquence de démarrage.
• [C-1-3] DOIT démarrer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et aller jusqu'à la partition système.
• [C-1-4] DOIT mettre en œuvre chaque étape de vérification 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 vérification aussi performants 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 en cas d'échec de la vérification du système, sauf si l'utilisateur consent à tenter quand même de démarrer. Dans ce cas, les données de blocs de stockage non validé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-SR-1] Si l'appareil comporte plusieurs puces discrètes (par exemple, un processeur radio ou un processeur d'images spécialisé), il est VIVEMENT RECOMMANDÉ de vérifier chaque étape du processus de démarrage de chacune de ces puces pour vérifier chaque étape au démarrage.
• [C-1-8] DOIT utiliser un espace de stockage avec système d'inviolabilité permettant de savoir si le bootloader est déverrouillé. Un stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] DOIT envoyer une invite à l'utilisateur lorsqu'il utilise l'appareil et exiger une confirmation physique avant d'autoriser la transition du mode verrouillé du bootloader vers le mode déverrouillé du bootloader.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (ex. : démarrage, partitions système) et utiliser un espace de stockage inviolable pour stocker les métadonnées servant à 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 version 9.12. suppression des données" (y compris la partition de données utilisateur et les espaces NVRAM).
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance en mode root dans des partitions protégées par le démarrage validé.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de vérifier tous les artefacts exécutables chargés par une application privilégiée en dehors de son fichier APK (comme le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
• DEVRAIT mettre en œuvre une protection contre le rollback pour tout composant doté d'un micrologiciel persistant (modem, appareil photo, par exemple) et utiliser un espace de stockage avec système d'inviolabilité pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge les versions C-1-8 à C-1-11 sur une version antérieure d'Android et qu'une mise à jour logicielle système ne permet pas de répondre à ces exigences, elles PEUVENT être exemptées.

Le projet Open Source Android en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégré au bootloader utilisé pour charger Android.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge la vérification cryptographique du contenu du fichier par rapport à une clé de confiance sans lire l'intégralité du fichier.
• [C-0-4] NE DOIT PAS autoriser la réussite des requêtes de lecture sur un fichier protégé lorsque le contenu en lecture n'est pas vérifié par rapport à une clé approuvée.

Si des implémentations d'appareils sont déjà lancées sans qu'il soit possible de vérifier le contenu d'un fichier par rapport à une clé de confiance sur une version antérieure d'Android et que vous ne pouvez pas ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence. Le projet Open Source Android en amont offre une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations pour les appareils:

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations d'appareils sont compatibles avec l'API Android Protected Confirmation:

• [C-3-1] DOIT indiquer true pour l'API ConfirmationPrompt.isSupported().

• [C-3-2] DOIT s'assurer que le code exécuté dans l'OS Android (y compris son noyau), malveillant ou autre, ne peut pas générer de réponse positive sans interaction de l'utilisateur.

• [C-3-3] DOIT s'assurer que l'utilisateur a pu examiner et approuver le message d'invite, même si l'OS Android, y compris son noyau, est compromis.

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 de chiffrement via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

• [C-0-1] DOIT autoriser l'importation ou la génération d'au moins 8 192 clés.
• [C-0-2] L'authentification de l'écran de verrouillage DOIT implémenter un intervalle de temps entre les tentatives infructueuses. Avec "n" comme 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 au moins 24 heures, la plus petite des deux étant retenue.
• NE DEVRAIT pas limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

• [C-1-1] DOIT sauvegarder la mise en œuvre du keystore dans un environnement d'exécution isolé.
• [C-1-2] DOIT disposer d'implémentations des algorithmes cryptographiques RSA, AES, ECDSA, ECDH (si IKeyMintDevice), 3DES et HMAC, ainsi que des fonctions de hachage de la famille MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes sécurisés pris en charge par le système Android Keystore dans une zone isolée du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. 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 vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [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 réussite. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification sur l'écran de verrouillage. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle Gatekeeper (HAL) et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [C-1-4] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareil. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente peut être utilisée pour chaque tranche de 100 000 unités.

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

• [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal pouvant atteindre 15 secondes. Les appareils automobiles qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur change d'utilisateur, NE peuvent PAS être associés à la configuration du délai de mise en veille.
• [C-1-6] DOIT être compatible avec IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice version 1 ou IKeyMintDevice version 2.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la version 1 d'IKeyMintDevice.

9.11.1. Écran de verrouillage sécurisé, authentification et appareils virtuels

L'implémentation d'AOSP suit un modèle d'authentification à plusieurs niveaux dans lequel une authentification principale basée sur la fabrique de connaissances peut s'appuyer sur une biométrie secondaire forte ou sur des modalités tertiaires plus faibles.

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes suivantes comme méthode d'authentification principale :
  • Un code PIN numérique
  • Un mot de passe alphanumérique
  • Schéma de balayage sur une grille contenant exactement 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont désignées comme méthodes d'authentification principales recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales 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, comme décrit dans la section Exiger l'authentification de l'utilisateur pour l'utilisation des clés.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'ils sont basées sur un secret connu et utilisent une nouvelle méthode d'authentification à considérer comme un moyen sécurisé de verrouiller l'écran:

• [C-3-1] L'entropie de la longueur d'entrées la plus courte 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 aucune des méthodes d'authentification principales recommandées (code, schéma, mot de passe) implémentées et fournies dans l'AOSP.
• [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application DPC (Device Policy Controller) 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_METRICITY.
• [C-3-5] Les nouvelles méthodes d'authentification DOIVENT revenir aux méthodes d'authentification principales recommandées (par code, schéma ou mot de passe) toutes les 72 heures au maximum OU indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver leur confidentialité.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie à considérer comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode:

• [C-4-1] DOIT respecter toutes les exigences décrites dans la section 7.3.10 de la classe 1 (anciennement facilité).
• [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui est basée sur un secret connu.
• [C-4-3] DOIT être désactivé et n'autoriser l'authentification principale recommandée pour déverrouiller l'écran que lorsque l'application DPC (Device Policy Controller) a défini la règle de fonctionnalité de protection du clavier en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(), avec l'un des indicateurs biométriques associés (par exemple, 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 Strong) comme décrit dans la section 7.3.10:

• [C-5-1] Les méthodes DOIVENT être désactivées si l'application DPC (Device Policy Controller) a défini la règle de qualité des exigences de mot de passe via DevicePolicyManager.setRequiredPasswordComplexity() avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_LOW ou 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é à procéder à l'authentification principale recommandée (par code, schéma ou mot de passe, par exemple), comme décrit dans les sections [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 respecter les exigences commençant par C-8 dans la présente section ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient des 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 l'emplacement:

• [C-6-1] Il DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui est basée sur un secret connu et remplir les conditions requises pour être considéré comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser que l'une des méthodes d'authentification principales recommandées pour déverrouiller l'écran lorsque l'application DPC (Device Policy Controller) a défini la règle avec :
  • La méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • La méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_NONE.
  • La méthode DevicePolicyManager.setRequiredPasswordComplexity() avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_NONE.
• [C-6-3] L'utilisateur DOIT être invité à répondre à une question d'authentification principale recommandée (par code, schéma ou mot de passe, par exemple) au moins une fois toutes les quatre heures. Lorsqu'un jeton physique répond aux exigences des implémentations TrustAgent dans C-X, les restrictions de délai avant 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 indiquées dans 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 System TrustAgentService, ils:

• [C-7-1] DOIT avoir une indication claire dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou qu'il peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouiller automatiquement le paramètre" et "Verrouillage instantané" dans le menu des paramètres, ainsi qu'une icône identifiable sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et mettre en œuvre 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, portable), mais PEUT-ÊTRE l'implémenter complètement sur des implémentations d'appareils généralement partagées (par exemple, Android Television ou Automotive).
• [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, le stockage du jeton de séquestre n'est pas autorisé, quelle que soit la partie du véhicule.
• [C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'autoriser le jeton de séquestre à 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 principales recommandées.
• [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par exemple, par code, schéma ou mot de passe) au moins une fois toutes les 72 heures ou moins, sauf si la sécurité de l'utilisateur (par exemple, en cas de distraction au volant) est préoccupante.
• [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par code, schéma ou mot de passe, par exemple), comme décrit dans les sections [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 au volant) est préoccupante.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes indiquées dans l'article C-8 ci-dessous.
• [C-7-11] NE DOIT PAS autoriser les TrustAgents sur des appareils personnels principaux (portables, par exemple) à déverrouiller l'appareil, et ne peuvent les utiliser que pour garder un appareil déjà déverrouillé à 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 de l'appareil de stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient des 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 la protection du clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application DPC (Device Policy Controller) 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 DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive que "PASSWORD_COMPLEXITY_NONE".
• [C-8-2] Il NE DOIT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Ils NE DOIVENT PAS exposer d'API pour que des applications tierces puissent déterminer l'état de verrouillage.

Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et ne prennent pas en charge les événements d'entrée associés, tels que 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] DOIT déconnecter tous les appareils virtuels au terme du délai d'inactivité
• [C-10-3] DOIT disposer d'un délai d'inactivité
• [C-10-4] DOIT verrouiller tous les écrans lorsque l'utilisateur lance un verrouillage, y compris via l' affordance de blocage de l'utilisateur 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 la création d'événements d'entrée associés via VirtualDeviceManager lorsque DevicePolicyManager.setNearbyAppStreamingPolicy l'indique
• [C-10-7] DOIT utiliser un presse-papiers distinct uniquement pour chaque appareil virtuel (ou désactiver le presse-papiers pour les appareils virtuels)
• [C-10-11] DOIT désactiver l'UI d'authentification sur les appareils virtuels, y compris la saisie de facteurs de connaissances et l'invite biométrique
• [C-10-12] DOIT empêcher l'affichage des intents initiés à partir d'un appareil virtuel uniquement sur le même appareil virtuel
• [C-10-13] NE DOIT pas utiliser l'état de verrouillage d'un appareil virtuel comme autorisation d'authentification de l'utilisateur auprès du système Android Keystore. Consultez KeyGenParameterSpec.Builder.setUserAuthentication*.

Lorsque les implémentations d'appareils permettent à l'utilisateur de transférer le facteur de connaissances principal pour l'authentification 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 connaissances 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 connaissances de l'appareil source vers l'appareil cible, de sorte qu'il ne puisse pas être déchiffré à distance ni utilisé pour déverrouiller à distance l'un ou l'autre des appareils.
• [C-11-2] DOIT, sur l'appareil source , demander à l'utilisateur de confirmer le facteur de connaissances de l'appareil source avant de le transférer vers l'appareil cible.
• [C-11-3] DOIT, sur un appareil cible dépourvu de tout facteur de connaissances d'authentification principal défini, demandez à l'utilisateur de confirmer un facteur de connaissances transféré sur l'appareil cible avant de le définir comme facteur de connaissances d'authentification principal pour l'appareil cible et avant de rendre disponibles les données transférées à partir d'un appareil source.

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:

• [C-12-1] DOIT appeler grantTrust() avec l'indicateur uniquement lorsqu'il est connecté à un appareil physique proche doté de son propre écran de verrouillage et lorsque l'utilisateur a authentifié son identité sur cet écran de verrouillage. Pour répondre aux exigences d'authentification de l'utilisateur, les appareils à proximité peuvent utiliser des mécanismes de détection au poignet ou sur le corps après le déverrouillage unique d'un utilisateur.
• [C-12-2] DOIT mettre l'implémentation de l'appareil à l'état TrustState.TRUSTABLE lorsque l'écran est éteint (par exemple, en appuyant sur un bouton ou en cas d'expiration du délai d'affichage) et que TrustAgent n'a pas révoqué l'approbation. L'AOSP satisfait à cette exigence.
• [C-12-3] NE DOIT faire passer l'appareil de l'état TrustState.TRUSTABLE à l'état TrustState.TRUSTED que si le TrustAgent continue d'accorder l'approbation en fonction des exigences de C-12-1.
• [C-12-4] DOIT appeler TrustManagerService.revokeTrust() après un délai maximal de 24 heures à compter de l'octroi de l'approbation, après une période d'inactivité de huit heures, ou en cas de perte de la connexion sous-jacente à l'appareil physique proche.

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 VIRTUAL_DISPLAY_FLAG_SECURE, ils:

• [C-13-8] DOIT empêcher le démarrage sur l'appareil virtuel des activités avec l'attribut android:canDisplayOnRemoteDevices ou les métadonnées android.activity.can_display_on_remote_devices définies sur "false".
• [C-13-9] DOIT empêcher le démarrage des activités qui n'activent pas explicitement le streaming et qui indiquent qu'elles affichent du contenu sensible, y compris via SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, sur l'appareil virtuel.

Si les implémentations d'appareils acceptent des états d'alimentation distincts via DeviceStateManager ET acceptent des états de verrouillage de l'écran distincts via KeyguardDisplayManager, elles:

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser les exigences liées aux identifiants définies dans la section 9.11.1 ou les spécifications biométriques 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 contraindre le déverrouillage de l'écran distinct via un délai d'inactivité défini.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de permettre à l'utilisateur de verrouiller globalement tous les écrans via le blocage de 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 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 qu'un appareil doit remplir pour être considéré comme une StrongBox.

Implémentations d'appareils disposant d'un processeur sécurisé dédié:

• [C-SR-1] EST VIVEMENT RECOMMANDÉ pour la compatibilité avec 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 du matériel sécurisé dédié permettant de sauvegarder le keystore et de sécuriser l'authentification 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, ni aucune mémoire vive (DRAM), coprocesseur ou autre ressource principale avec le processeur d'application (PA).

• [C-1-4] DOIT s'assurer que les périphériques partagés avec le point d'accès ne peuvent en aucun cas modifier le traitement de StrongBox, ni obtenir d'informations à partir de StrongBox. Le point d'accès PEUT désactiver ou bloquer l'accès à StrongBox.

• [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) et immunisée contre la manipulation par le point d'accès.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires produisant une sortie imprévisible et distribuée uniformément.

• [C-1-7] DOIT disposer d'une résistance à la falsification, y compris une résistance à la pénétration physique et aux glitchs.

• [C-1-8] DOIT disposer d'une résistance du canal latéral, y compris la résistance aux informations de fuite via les canaux latéraux de puissance, de temporisation, 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 des contenus. L'espace de stockage NE DOIT PAS être lu ni modifié, sauf dans les cas autorisés par les API StrongBox.

• Pour valider la conformité avec les normes [C-1-3] à [C-1-9], les implémentations d'appareils:

  • [C-1-10] DOIT inclure le matériel certifié conforme au profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essais accrédité au niveau national qui évalue les failles à fort potentiel d'attaque selon la norme commune d'application du potentiel d'attaque aux cartes intelligentes.
  • [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire d'essais accrédité par les États-Unis qui procède à une évaluation des failles à fort potentiel d'attaque, conformément à la norme Common Critères Application of Attack Potential to Smartcards.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement une exigence dans une prochaine version.
  • [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour fournir une résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature de micrologiciel ne peut pas produire de micrologiciel entraînant la fuite de secrets par la StrongBox, le contournement des exigences de sécurité fonctionnelles ou l'accès à 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 le HAL IAuthSecret.

9.11.3. Identifiants d'identité

Le système d'identifiants d'identité est défini et réalisé 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 les documents d'identité des utilisateurs. Implémentations pour les appareils:

• Il est FORTEMENT RECOMMANDÉ d'utiliser [C-SR-1] pour implémenter le système d'identification des identités.

Si les implémentations d'appareils implémentent le système d'identification de l'identité, celles-ci:

• [C-1-1] DOIT renvoyer une valeur non nulle pour la méthode IdentityCredentialStore#getInstance().

• [C-1-2] DOIT mettre en œuvre le système d'identification des identités (par exemple, les API android.security.identity.*) avec du code communiquant avec une application approuvée dans une zone isolée de manière sécurisée du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée.

• [C-1-3] Les opérations cryptographiques nécessaires à la mise en œuvre du système d'identification des identités (par exemple, les API android.security.identity.*) DOIVENT être entièrement effectuées dans l'application approuvée et le matériel de clé privée NE DOIT jamais quitter l'environnement d'exécution isolé, sauf si des API de niveau supérieur l'exigent spécifiquement (par exemple, la méthode createEphemeralKeyPair()).

• [C-1-4] L'application de confiance DOIT être mise en œuvre de manière à ne pas affecter ses propriétés de sécurité (par exemple, les données d'identification ne sont pas publié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 est défaillant ou compromis.

Le projet Open Source Android en amont fournit une implémentation de référence d'une application de confiance (libeic) pouvant être utilisée pour implémenter le système d'identification 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'une "réinitialisation de la configuration d'usine".
• [C-0-3] DOIT supprimer les données de manière à respecter les normes sectorielles pertinentes, telles que NIST SP800-88, lors de la réinitialisation des données 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'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
• PEUT fournir une option d'effacement rapide des données qui n'effectue qu'une effacement logique des données.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", permet à l'utilisateur de désinstaller des applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

• [C-SR-1] VIVEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

• [C-1-1] DOIT fournir à l'utilisateur une option permettant d'activer le mode Démarrage sécurisé de manière ininterrompue par rapport aux applications tierces installées sur l'appareil, sauf si 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 des applications tierces en mode sans échec.

• DEVRAIT donner à l'utilisateur la possibilité d'activer le mode de démarrage sécurisé à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des sous-systèmes critiques de véhicules à l'aide du HAL du véhicule pour envoyer et recevoir des messages sur des réseaux de véhicules 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 afin d'empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits" désignent les 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 abonnements à l'application de l'opérateur mobile qui les a initialement fournis.
• [C-0-2] NE DOIT PAS sauvegarder ni importer de forfaits d'abonnement à distance.
• [C-0-3] NE DOIT autoriser les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), que dans l'application de l'opérateur mobile proposant actuellement des abonnements valides.

9.16. Migration des données d'application

Si les implémentations d'appareils permettent de migrer les 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 de l'application dans le fichier manifeste via l'attribut android:fullBackupContent, elles:

• [C-1-1] NE DOIT PAS lancer de transferts de données d'application à partir d'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 auprès de l'utilisateur l'intention de copier les données sur l'appareil source avant de transférer des données.
• [C-1-3] DOIT utiliser l'attestation des clés de sécurité pour s'assurer que les appareils source et cible lors de la migration d'appareil à appareil sont des appareils Android légitimes et disposent d'un bootloader verrouillé.
• [C-1-4] DOIT migrer uniquement 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 afficher dans le menu des paramètres une indication que des données ont été migrées sur l'appareil source lors d'une migration de données d'appareil à appareil. Un utilisateur NE DEVRAIT PAS être en mesure de supprimer cette indication.

9.17. Framework de virtualisation Android

Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hôte Android:

• [C-1-1] DOIT prendre en charge toutes les API définies par le package android.system.virtualmachine.*.
• [C-1-2] NE DOIT PAS modifier le modèle d'autorisation ni le modèle SELinux Android pour la gestion des machines virtuelles protégées.
• [C-1-3] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy fournis dans le projet Android Open Source (AOSP) en amont. De plus, la stratégie DOIT se compiler avec toutes les règles ne pas autoriser présentes.
• [C-1-4] NE DOIT PAS autoriser du code non approuvé (applications tierces, par exemple) à créer et exécuter une machine virtuelle protégée. Remarque: Cela pourrait changer dans les prochaines versions d'Android.
• [C-1-5] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter du code qui ne fait pas partie de l'image d'usine ou de ses mises à jour. Tout ce qui n'est pas couvert par le démarrage validé Android (par exemple, les fichiers téléchargés sur Internet ou téléchargés indépendamment) NE DOIT PAS être exécuté sur une machine virtuelle protégée.

Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), toute instance de machine virtuelle protégée:

• [C-2-1] DOIT pouvoir exécuter tous les systèmes d'exploitation disponibles dans l'apex de virtualisation au sein d'une machine virtuelle protégée.
• [C-2-2] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter un système d'exploitation qui n'est pas signé par le responsable de l'implémentation de l'appareil ou le fournisseur de l'OS.
• [C-2-3] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter des données en tant que code (par exemple, SELinux n'autorise jamais execmem).
• [C-2-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy/microdroid fournis en amont dans le projet Android Open Source (AOSP).
• [C-2-5] DOIT implémenter des mécanismes de défense en profondeur des machines virtuelles protégées (par exemple, SELinux pour les VM préemptives), même pour les systèmes d'exploitation autres que Microdroid.
• [C-2-6] DOIT s'assurer que le micrologiciel de la VM préemptive refuse de démarrer s'il ne peut pas vérifier l'image initiale.
• [C-2-7] DOIT s'assurer que le micrologiciel de la VM préemptive refuse de démarrer si l'intégrité du fichier instance.img est compromise.

Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hyperviseur:

• [C-3-1] NE DOIT PAS permettre à une pVM d'accéder à une page appartenant à une autre entité (c'est-à-dire une autre pVM ou un hyperviseur), sauf s'il est explicitement partagé par le propriétaire de la page. Cela inclut la VM hôte. Cela s'applique à la fois aux accès au processeur et à la zone de marché désignée.
• [C-3-2] DOIT effacer une page après son utilisation par une VM et avant qu'elle ne soit renvoyée à l'hôte (par exemple, lorsque la pVM est détruite).
• [C-3-3] DOIT s'assurer que le micrologiciel d'une pVM est chargé et exécuté avant tout code dans une pVM.
• [C-3-4] DOIT s'assurer que le Cci et les IDC fournis à une instance de VM préemptive ne peuvent être dérivés que de cette instance particulière.

Si l'appareil est compatible avec les API du framework de virtualisation Android, procédez comme suit dans tous les domaines:

• [C-4-1] NE DOIT PAS fournir à une pVM une fonctionnalité permettant de contourner le modèle de sécurité Android.

Si l'appareil est compatible avec les API du framework de virtualisation Android:

• [C-5-1] DOIT prendre en charge la compilation isolée d'une mise à jour de l'environnement d'exécution ART.

Si l'appareil prend en charge les API du framework de virtualisation Android, procédez comme suit pour la gestion des clés:

• [C-6-1] DOIT utiliser la chaîne DICE racine à un point que l'utilisateur ne peut pas modifier, même sur des appareils déverrouillés. (pour éviter toute usurpation d'identité).
• [C-6-2] DOIT effectuer le processus "DICE" correctement, c'est-à-dire fournir les valeurs correctes.

10. Tests de compatibilité logicielle

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS d'apporter le moins de modifications possible à la référence et à l'implémentation préférée d'Android disponible dans le projet Android Open Source. Cela réduira le risque d'introduire des bugs qui créent des incompatibilités nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations pour les appareils:

• [C-0-1] DOIT réussir la suite de test de compatibilité Android (CTS) disponible dans le projet Open Source Android, en utilisant le logiciel de livraison final de l'appareil.

• [C-0-2] DOIT garantir la compatibilité en cas d'ambiguïté dans CTS et pour toute réimplémentation de parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bogues. La version CTS sera gérée indépendamment de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 13.

Implémentations pour les appareils:

• [C-0-3] DOIT transmettre la dernière version CTS disponible au moment de l'achèvement du logiciel de l'appareil.

• DEVRAIT utiliser autant que possible l'implémentation de référence dans l'arborescence Android Open Source.

10.2. Vérificateur CTS

Le vérificateur CTS est inclus dans la suite de tests de compatibilité et est destiné à être exécuté par un opérateur humain pour tester des 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 pour les appareils:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans l'outil de vérification CTS.

L'outil de vérification CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations pour les appareils:

• [C-0-2] DOIT réussir tous les tests de son matériel. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de l'accéléromètre dans l'outil de vérification CTS.

Les scénarios de test des fonctionnalités indiquées comme facultatives dans ce document de définition de compatibilité PEUVENT être ignorés ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement l'outil de vérification CTS, comme indiqué ci-dessus. Toutefois, étant donné que de nombreux builds sont très similaires, les responsables de la mise en œuvre d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manière mineure. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le vérificateur CTS uniquement par l'ensemble des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à 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 ne doit pas nécessairement effectuer de mises à niveau "en direct", c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. N'importe quelle méthode peut être utilisée, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

  • Téléchargements en mode Over The Air (OTA) avec mise à jour hors connexion via un redémarrage.
  • Mises à jour "partagées" via USB à partir d'un PC hôte.
  • Les mises à jour "hors connexion" se font par un redémarrage et à partir d'un fichier stocké sur un espace de stockage amovible.

• [C-0-2] Le mécanisme de mise à jour utilisé DOIT accepter les mises à jour sans effacer les données utilisateur. Autrement dit, le mécanisme de mise à jour DOIT préserver les données privées de l'application et les données 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] La mise à jour complète 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 VIVEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide de l'ECDSA NIST P-256.

Si les implémentations de l'appareil incluent la prise en charge d'une connexion de données illimitée (telle qu'un profil 802.11 ou un profil de réseau personnel Bluetooth), elles:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Les implémentations d'appareils DOIVENT vérifier que l'image système est identique au résultat attendu après une 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 être compatibles avec les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide de la commande de démarrage HAL.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais dans la durée de vie raisonnable du produit, déterminée en consultation avec l'équipe de compatibilité Android comme pouvant affecter la compatibilité des applications tierces:

• [C-2-1] L'équipe chargée de la mise en œuvre de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme qui vient d'être décrit.

Android inclut des fonctionnalités qui permettent à l'application Device Owner (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, il:

• [C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications du document

Voici un résumé des modifications apportées à la définition de compatibilité dans cette version:

4 octobre 2023

2. Types d'appareils

• 2.2.5. Modèle de sécurité:

  Voir la révision

  • [9.8/H-1-14] DOIT afficher l'indicateur de micro, comme décrit dans la section 9.8.2 [9.8/C-3-1], lorsqu'un résultat de mot clé réussi est transmis à la voix.

• 2.2.7.1 Médias:

  Voir la révision

  • [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session d'encodage vidéo de 1080p ou moins pour tous les encodeurs vidéo matériels en charge. Ici, la charge désigne une session simultanée de transcodage vidéo de 1080p à 720p qui utilise des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.

  • [5.1/H-1-12] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session de décodage vidéo de 1080p ou moins pour tous les décodeurs vidéo matériels en charge. La charge ici est définie comme une session simultanée de transcodage vidéo de 1080p à 720p effectuée à l'aide de codecs vidéo matériels et de l'initialisation de la lecture audio/vidéo 1080p. Pour le codec Dolby Vision, la latence d'initialisation du codec DOIT être inférieure ou égale à 50 ms.

  • [5.1/H-1-13] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session de décodage audio de 128 kbit/s ou un débit inférieur pour tous les décodeurs audio en charge. Cette charge désigne une session simultanée de transcodage vidéo de 1080p à 720p utilisant des codecs vidéo matériels et l'initialisation de la lecture audio/vidéo 1080p.

7.4. Connectivité des données

• 7.4.1.1. Compatibilité avec le blocage des numéros:

  Voir la révision

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

• 7.4.1.2. API Telecom:

  Voir la révision

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

9.11. Clés et identifiants

• 9.11.2. StrongBox:

  Voir la révision

  est fournie via le HAL IAuthSecret.

  Suppression de la règle IAR deviendra une exigence OBLIGATOIRE dans Android 14.

26 juin 2023

2. Types d'appareils

• 2.2.1. Matériel

  • Exigences supprimées : 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7

  • Autre mise à jour:

    Voir la révision

    Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans les exigences pour le calibrage de présence.

• 2.5.1. Matériel

  Voir la révision

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

  • [7.6.1/A-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 512 Mo si l'une des densités suivantes est utilisée:

    • 280 ppp ou moins sur les écrans de petite taille
    • ldpi ou inférieur sur les très grands écrans
    • mdpi ou inférieur sur les grands écrans

  • [7.6.1/A-1-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 608 Mo si l'une des densités suivantes est utilisée:

    • xhdpi ou supérieur sur les écrans de petite taille/normal
    • hdpi ou supérieur sur les grands écrans
    • mdpi ou supérieur sur les très grands écrans

  • [7.6.1/A-1-3] 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 ppp ou plus sur les écrans de petite taille
    • xhdpi ou supérieur sur les grands écrans
    • tvdpi ou supérieur sur les très grands écrans

  • [7.6.1/A-1-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'une des densités suivantes est utilisée:

    • 560 ppp ou plus sur les écrans de petite taille ou de taille normale
    • 400 ppp ou plus sur les grands écrans
    • xhdpi ou supérieur sur les très grands écrans

3. Logiciel

• 3.2.3.5. Intents d'application conditionnels

  Voir la révision

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

7. Compatibilité matérielle

• 7.4. Connectivité des données

  Voir la révision

  Conditions requises pour l'étalonnage de la présence

9. Compatibilité des modèles de sécurité

• 9.1 Autorisations

  Voir la révision

  Implémentations pour les appareils:

  • [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf dans les cas suivants:

    • Ils sont installés au moment de l'expédition de l'appareil, ET
    • Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise l'autorisation.

    OR

    • Les autorisations d'exécution sont accordées par la stratégie d'autorisation par défaut ou pour détenir un rôle de plate-forme. associé à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.

• 9.11. Clés et identifiants

  • Suppression des exigences [C-13-10] et 9.11.4.

20 mars 2023

2. Types d'appareils

• 2.2.3. Logiciel

  Voir la révision

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

  • [C-17-13.2.3.1/ H-1-1] DOIT comporter 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.

  Mettre fin aux nouvelles exigences

• 2.3.2. Multimédia

  Voir la révision

  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-1SR1] Il est VIVEMENT 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).

• 2.5.1. Matériel

  Voir la révision

  Implémentations pour les appareils automobiles:

  • [7.3/A-0-1SR1] PEUT détecter la localisation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la localisation est désactivée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs correspondants et/ou les ID de propriété de véhicule utilisés.

  • [7.3/A-0-20-4] L'élément Location demandé via LocationManager#requestLocationUpdates() NE DOIT PAS être mis en correspondance sur la carte.

3. Logiciel

• 3.18. Contacts

  Voir la révision

  Default account for new contacts (Compte par défaut pour les nouveaux contacts) : Contacts Provider fournit des API permettant de gérer les paramètres du compte par défaut lors de la création d'un contact.

  Si les implémentations de l'appareil préchargent une application de contacts, celle-ci:

  • [C-2-1] DOIT gérer l'intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT pour lancer une UI de sélection de compte et enregistrer le paramètre dans le fournisseur de contacts lorsqu'un compte est sélectionné.

  • [C-2-2] DOIT respecter le paramètre de compte par défaut lors du traitement de Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT pour ContactsContracts.Contacts.CONTENT_TYPE et ContactsContract.RawContacts.CONTENT_TYPE en sélectionnant initialement le compte.

  Mettre fin aux nouvelles exigences

• 3.2.3.5. Intents d'application conditionnels

  Voir la révision

  [Moved to 2.2.3]

  Si l'application 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:

  • [C-17-1] DOIT avoir 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.

  Mettre fin aux nouvelles exigences

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

• 6.1. Outils pour les développeurs

  Voir la révision

  • Singe
    • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.

7. Compatibilité matérielle

• 7.3.13. IEEE 802.1.15.4 (UWB)

  Voir la révision

  [Moved to 7.4.9]

  Si les implémentations d'appareils sont compatibles 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 l'indicateur de fonctionnalité matérielle android.hardware.uwb.
  • [C-1-3] DOIT prendre en charge tous les profils UWB pertinents définis dans l'implémentation Android.
  • [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver la radio UWB.
  • [C-1-5] DOIT faire en sorte que les applications qui utilisent la radio UWB détiennent l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICE).
  • [C-1-6] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organisations standards, y compris FIRA, CCC et CSA.

  Mettre fin aux nouvelles exigences

• 7.4.1. Téléphonie

  Voir la révision

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, signalent la fonctionnalité android.hardware.telephony:

  • [C-6-1] Les éléments 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 lors de l'envoi et de la réception de SMS et de 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 prendre en charge la saisie de codes de numéroteur 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 visuelle des messages vocaux aux utilisateurs si elle prend en charge les transcriptions visuelles des messages vocaux.
  • [C-6-5] DOIT représenter tous les éléments SubscriptionInfo avec des UUID de groupe équivalents en tant qu'abonnement unique dans toutes les affordances visibles par l'utilisateur qui affichent et contrôlent les informations de la carte SIM. Les interfaces de paramètres qui correspondent à Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS sont des exemples de ces affordances.
  • [C-6-6] NE DOIT PAS afficher ni autoriser le contrôle d'une SubscriptionInfo avec un UUID de groupe et un bit opportuniste non nuls dans les affordances visibles par l'utilisateur qui autorisent la configuration ou le contrôle des paramètres de la carte SIM.

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, signalent la fonctionnalité android.hardware.telephony et fournissent une barre d'état système:

  • [C-6-7-1] DOIT sélectionner un abonnement actif représentatif pour un UUID de groupe donné à afficher à l'utilisateur dans toutes les affordances qui fournissent des informations sur l'état de la carte SIM. Il peut s'agir, par exemple, de l'icône de signal mobile de la barre d'état ou du bloc Réglages rapides.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de choisir l'abonnement représentatif comme abonnement aux données actives, sauf si l'appareil fait l'objet d'un appel vocal, au cours duquel il est FORTEMENT RECOMMANDÉ que l'abonnement représentatif soit l'abonnement vocal actif.

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, signalent la fonctionnalité android.hardware.telephony, alors:

  • [C-6-87] DOIT être capable d'ouvrir et d'utiliser simultanément le nombre maximal de canaux logiques (20 au total) pour chaque UICC, conformément à l'ETSI TS 102 221.
  • [C-6-108] NE DOIT PAS appliquer l'un des comportements suivants aux applications d'opérateurs actives (telles que désignées par TelephonyManager#getCarrierServicePackageName) automatiquement ou sans confirmation explicite de l'utilisateur :
    • Révoquer ou limiter l'accès au réseau
    • Révoquer les autorisations
    • Limitez l'exécution d'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'appareils incluent la téléphonie GSM ou CDMA, signalent la fonctionnalité android.hardware.telephony et que tous les abonnements actifs et non opportunistes qui partagent un UUID de groupe sont désactivés, supprimés physiquement de l'appareil ou marqués comme opportunistes, l'appareil:

  • [C-78-1] DOIT désactiver automatiquement tous les abonnements opportunistes restants dans le même groupe.

  Si les implémentations d'appareils incluent la téléphonie GSM, mais pas la téléphonie CDMA, ils:

  • [C-89-1] NE DOIT PAS déclarer PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-89-2] DOIT générer une exception IllegalArgumentException lors des tentatives de définition de n'importe quel type de réseau 3GPP2 dans des masques de bits des types de réseau préférés ou autorisés.
  • [C-89-3] DOIT renvoyer une chaîne vide à partir de TelephonyManager#getMeid.

  Si les implémentations d'appareils prennent en charge les eUICC avec plusieurs ports et profils, elles:

  • [C-1110-1] DOIT déclarer l'indicateur de fonctionnalité android.hardware.telephony.euicc.mep.

• 7.4.9. UWB

  Voir la révision

  Si les implémentations d'appareils indiquent la prise en charge de la fonctionnalité android.hardware.uwb via la classe android.content.pm.PackageManager, Si les implémentations d'appareils sont compatibles avec la norme 802.1.15.4 et exposent la fonctionnalité à une application tierce, qu'elles:

  • [C-1-1] DOIT implémenter l'API Android correspondante dans android.uwb.
  • [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.uwb.
  • [C-1-3] DOIT prendre en charge tous les profils UWB pertinents définis dans l'implémentation Android.
  • [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver la radio UWB.
  • [C-1-5] DOIT faire en sorte que les applications qui utilisent la radio UWB détiennent l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICE).
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organisations standards, y compris FIRA, CCC et CSA.
  • [C-1-16] DOIT s'assurer que les mesures de distance se situent dans un rayon de +/-15 cm pour 95 % des mesures dans l'environnement de vision à une distance d'un mètre dans une chambre non réfléchissante.
  • [C-1-27] DOIT s'assurer que la médiane des mesures de distance à 1 m de l'appareil de référence ne dépasse pas [0,75 m, 1,25 m], où la distance de vérité terrain est mesurée à partir du bord supérieur de l'appareil testé, face vers le haut et incliné à 45 degrés.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans la section Exigences d'étalonnage de présence.

  Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans les Exigences concernant l'étalonnage de présence.

  Mettre fin aux nouvelles exigences

• 7.8.2.2. Ports audio numériques

  Voir la révision

  Afin d'être compatible avec les casques et d'autres accessoires audio utilisant des connecteurs USB-C et d'implémenter (classe audio USB) dans l'écosystème Android, comme défini dans les spécifications des casques USB Android

19 octobre 2022

2. Types d'appareils

• 2.2.3 Logiciel

  Voir la révision

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

  • [3.8.17/H-1-1] DOIT présenter une confirmation à l'utilisateur que les données ont été copiées dans le presse-papiers (par exemple, une vignette ou une alerte indiquant "Contenu copié"). De plus, incluez ici une indication si les données du presse-papiers seront synchronisées sur tous les appareils.

3. Logiciel

• 3.2.3.5. Intents d'application conditionnels

  Voir la révision

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

  • [C-17-1] DOIT avoir 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 sont compatibles avec VoiceInteractionService et que plusieurs applications utilisant cette API sont installées à la fois, elles:

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

• 3.4.1 Compatibilité avec WebView

  Voir la révision

  • [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 moteur de rendu distinct DOIT détenir des privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, n'avoir aucun accès au répertoire de données de l'application, n'avoir aucun accès direct au réseau et n'avoir accès qu'aux services système minimaux requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

7. Compatibilité matérielle

• 7.4.2 IEEE 802.11 (Wi-Fi)

  Voir la révision

  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, les appareils suivants:

  • [C-3-1] DOIT DEVRAIT désactiver le mode Économie d'énergie Wi-Fi chaque fois qu'une application fait l'objet d'un verrouillage WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY via WifiManager.createWifiLock() et WifiManager.WifiLock.acquire()

• 7.4.3 Bluetooth

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec le Bluetooth à basse consommation (BLE), elles:

  • [C-3-5] DOIT mettre en œuvre un délai avant expiration de l'adresse privée pouvant être résolue (RPA, Resolvable Private Address, RPA) ne dépassant pas 15 minutes et effectuer une rotation de l'adresse après expiration du délai afin de protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement la technologie BLE pour l'analyse ou la publicité. Pour éviter les attaques temporelles, les intervalles d'expiration DOIVENT également être aléatoires entre 5 et 15 minutes.

• 7.5.5 Orientation de l'appareil photo

  Voir la révision

  Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

  • [C-1-1] DOIT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil. Autrement dit, elle s'applique aux appareils principaux en mode paysage ainsi qu'aux appareils principaux en mode portrait.

  Les appareils qui répondent à tous les critères suivants sont exemptés de l'exigence ci-dessus:

  • L'appareil implémente des écrans à géométrie variable, tels que des écrans pliables ou à charnière.
  • Lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe du mode portrait principal à l'orientation paysage principal (ou inversement).

  Mettre fin aux nouvelles exigences

9. Compatibilité des modèles de sécurité

• 9.11 Clés et identifiants

  Voir la révision

  Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

  • [C-1-6] DOIT être compatible avec IKeymasterDevice 4.0, IKeymasterDevice 4.1, IKeyMintDevice version 1 ou IKeyMintDevice version 2.

• 9.17 Android Virtualization Framework

  Voir la révision

  Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hôte Android:

  • [C-1-3] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy fournis dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT être compilée avec toutes les règles ne pas autoriser présentes.

  Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), toute instance de machine virtuelle protégée:

  • [C-2-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy/microdroid fournis dans le projet Android Open Source (AOSP) en amont.

  Si l'appareil prend en charge les API du framework de virtualisation Android, procédez comme suit pour la gestion des clés:

  • [C-6-2] DOIT effectuer le processus "DICE" correctement, c'est-à-dire fournir les valeurs correctes. Mais vous n'aurez peut-être pas besoin d'aller dans les moindres détails.

15 août 2022

2. Types d'appareils

• 2.2.1 Matériel: modifications apportées à la configuration matérielle requise comme indiqué ci-dessous.

  • Périphériques d'entrée:

    Voir la révision

    Implémentations pour les appareils portables:

    • [7.2.3/H-0-5] DOIT appeler OnBackInvokedCallback.onBackStarted() sur la fenêtre sélectionnée actuelle lorsque le geste Retour commence ou lorsque le bouton Retour (KEYCODE_BACK) est enfoncé.
    • [7.2.3/H-0-6] DOIT appeler OnBackInvokedCallback.onBackInvoked() lorsque le geste Retour est validé ou lorsque le bouton Retour est relâché (UP).
    • [7.2.3/H-0-7] DOIT appeler OnBackInvokedCallback.onBackCancelled() lorsque le geste Retour n'est pas validé ou que l'événement KEYCODE_BACK est annulé.

    Mettre fin aux nouvelles exigences

    Si les appareils sont compatibles avec le protocole NAN (Wi-Fi Neighbor Awareness Networking) en déclarant PackageManager.FEATURE_WIFI_AWARE et la localisation Wi-Fi (délai aller-retour Wi-Fi, DAR) en déclarant PackageManager.FEATURE_WIFI_RTT, ils:

    • [7.4.2.5/H-1-1] DOIT indiquer la plage avec précision à +/-1 mètre à 160 MHz à 160 MHz au 68e centile (calculé avec la fonction de distribution cumulative), +/-2 mètres à 80 MHz au 68e centile, +/-4 mètres au 68e centile et au 68e centile de bande passante.

    • [7.4.2.5/H-SR] Il est FORTEMENT RECOMMANDÉ de signaler la plage avec précision à +/-1 mètre à 160 MHz au 90e centile (calculé avec la fonction de distribution cumulative), +/-2 mètres à la bande de 80 MHz au 90e centile, +/-4 mètres au 90e centile et à +/-4 mètres au 90e centile de la bande Android.

    Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans les Exigences concernant l'étalonnage de présence.

    Mettre fin aux nouvelles exigences

  • Latence audio:

    Voir la révision

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

    • [5.6/H-1-1] DOIT avoir une latence moyenne aller-retour continue de 500 800 millisecondes ou moins sur 5 mesures, avec un écart absolu moyen inférieur à 50 100 ms sur les chemins de données suivants : boucle compatible du haut-parleur vers le micro ; 3.5 au moins un chemin d'accès compatible.

    • [5.6/H-1-1] DOIT avoir une latence moyenne de 500 millisecondes ou moins sur au moins cinq mesures sur le chemin de données entre le haut-parleur et le micro.

    Mettre fin aux nouvelles exigences

  • Entrées haptiques:

    Voir la révision

    Si les implémentations d'appareils portables incluent au moins un actionneur haptique:

    • [7.10/H]* NE DOIT PAS utiliser d'actionneur haptique (vibreur) à masse rotative excentrique.
    • [7.10/H]* DEVRAIT positionner l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
    • [7.10/H]* DEVRAIT implémenter toutes les constantes publiques pour les retours haptiques clairs dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_Release, KEYBOARD_TAP, CONFIRM_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_MOVE, VIRTUREAL_START).
    • [7.10/H]* DEVRAIT implémenter toutes les constantes publiques pour les résultats haptiques clairs dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques réalisables PRIMITIVE_* pour les constantes haptiques publiques, PRIMITIVE_* pour les composants haptiques enrichis, Certaines de ces primitives, telles que LOW_TICK et SPIN, ne sont possibles que si le vibreur peut prendre en charge des fréquences relativement basses.

    • [7.10/H]* DEVRAIT suivre les conseils pour mapper des constantes publiques dans android.view.HapticFeedbackConstants aux constantes android.os.VibrationEffect recommandées, avec les relations d'amplitude correspondantes.

    Mettre fin aux nouvelles exigences

    • [7.10/H]* DEVRAIT utiliser ces mappages de constantes haptiques associées.

    • [7.10/H]* DEVRAIT vérifier que le résultat de l'API publique android.os.Vibrator.hasAmplitudeControl() reflète correctement les capacités de son vibreur.

    Mettre fin aux nouvelles exigences

    • [7.10/H]* DEVRAIT vérifier les capacités d'évolutivité de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

    Si les implémentations d'appareils portables incluent au moins un actionneur à résonateur linéaire, elles:

    • [7.10/H]* DEVRAIT déplacer l'actionneur haptique sur l'axe X (gauche/droite) en mode portrait.

    • [7.10/H]* DEVRAIT vérifier et mettre à jour, si nécessaire, la configuration de remplacement pour les primitives non compatibles, comme décrit dans les instructions d'implémentation pour les constantes.

    • [7.10/H]* DEVRAIT fournir une assistance de remplacement pour atténuer le risque de défaillance, comme décrit ici.

• 2.2.3 Logiciel:

  • Auth Trivial Device Controls:

    Voir la révision

    • [3.8.16/H-1-5] DOIT fournir une affordance aux utilisateurs pour qu'ils puissent désactiver les commandes d'appareils désignées comme triviales pour l'application, à partir des commandes enregistrées par les applications tierces via ControlsProviderService et l'API Control Control.isAuthRequired.

  • Notifications MediaStyle:

    Voir la révision

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

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

• 2.2.4 Performances et puissance: nouvelle exigence pour les applications qui exécutent des services de premier plan.

  Voir la révision

  Implémentations pour les appareils portables:

  • [8.5/H-0-1] DOIT fournir une affordance utilisateur dans le menu "Paramètres" avec la possibilité d'arrêter une application qui exécute un service de premier plan et d'afficher toutes les applications avec des services de premier plan actifs, ainsi que la durée de chacun de ces services depuis son lancement, comme décrit dans le document du SDK.
    • Certaines applications PEUVENT être exemptées d'être arrêtées ou répertoriées dans une telle affordance utilisateur, comme décrit dans le document relatif au SDK.

  Mettre fin aux nouvelles exigences

• 2.2.7.1 Contenus multimédias: mises à jour de la section "Supports pour appareils portables" comme suit:

  Voir la révision

  Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

  • [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matérielle pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
  • [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
  • [5.1/H-1-3] DOIT annoncer 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().
  • [5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à une résolution de 1080p à 30 FPS.
  • [5.1/H-1-5] DOIT annoncer le nombre maximal de sessions d'encodeur et 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().
  • [5.1/H-1-6] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle et de sessions d'encodeur vidéo matériel (AVC, HEVC, VP9, AV1 ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
  • [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une session d'encodage vidéo de 1080p ou moins pour tous les encodeurs vidéo matériels en charge. Ici, la charge désigne une session simultanée de transcodage vidéo de 1080p à 720p qui utilise des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p.
  • [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 30 ms ou moins pour une session d'encodage audio de 128 kbit/s ou un débit inférieur pour tous les encodeurs audio en charge. La charge ici est définie comme une session simultanée de transcodage vidéo 1080p à 720p en utilisant des codecs vidéo matériels et l'initialisation de l'enregistrement audio-vidéo 1080p.
  • [5.1/H-1-9] DOIT prendre en charge deux instances de sessions de décodeur vidéo matérielle sécurisées (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codecs exécutée simultanément à une résolution de 1080p à 30 FPS.
  • [5.1/H-1-10] DOIT prendre en charge trois instances de sessions de décodeur vidéo matériel non sécurisées avec une instance de session de décodeur vidéo matérielle sécurisée (4 instances au total) (AVC, HEVC, VP9, AV1 ou version ultérieure) dans toute combinaison de codec exécutée simultanément à une résolution de 1080p à 30 FPS.
  • [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 de l'appareil.
  • [5.1/H-1-12] DOIT avoir une latence d'initialisation du décodeur vidéo de 40 ms ou moins.
  • [5.1/H-1-13] DOIT avoir une latence d'initialisation du décodeur audio de 30 ms ou moins.
  • [5.1/H-1-14] DOIT prendre en charge le décodeur matériel AV1 Main 10, niveau 4.1.
  • [5.1/H-SR] Il est fortement recommandé de prendre en charge le grain de film pour le décodeur matériel AV1.
  • [5.1/H-1-15] DOIT disposer d'au moins un décodeur vidéo matériel compatible avec la résolution 4K60.
  • [5.1/H-1-16] DOIT disposer d'au moins un encodeur vidéo matériel compatible avec la résolution 4K60.
  • [5.3/H-1-1] NE DOIT PAS supprimer plus d'une image en 10 secondes (c'est-à-dire une perte de frames inférieure à 0,167 %) pour une session vidéo 1080p à 60 FPS en charge. La charge désigne une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC de 128 kbit/s.
  • [5.3/H-1-2] NE DOIT PAS supprimer plus d'une image en 10 secondes lors d'un changement de résolution vidéo au cours d'une session vidéo de 60 FPS soumise à une charge élevée. La charge correspond à une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels et à une lecture audio AAC à 128 kbit/s.
  • [5.6/H-1-1] DOIT avoir une latence tap-to-ton de 80 millisecondes ou moins à l'aide du test tap-to-tone OboeTester ou CTS Verifier.
  • [5.6/H-1-2] DOIT avoir une latence audio aller-retour de 80 millisecondes ou moins sur au moins un chemin de données compatible.
  • [5.6/H-1-3] DOIT prendre en charge l'audio >=24 bits pour une sortie stéréo sur des connecteurs audio 3,5 mm si elle est présente, et via l'audio USB si elle est prise en charge via l'intégralité du chemin de données pour une faible latence et des configurations de streaming. Pour la configuration à faible latence, AAudio doit être utilisé par l'application en mode de rappel à faible latence. Pour la configuration du streaming, une piste audio Java doit être utilisée par l'application. Dans les configurations à faible latence et en streaming, le récepteur de sortie HAL doit accepter AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT ou AUDIO_FORMAT_PCM_FLOAT pour son format de sortie cible.
  • [5.6/H-1-4] DOIT prendre en charge les appareils audio USB à 4 canaux ou plus (utilisé par les manettes de DJ pour la prévisualisation des titres).
  • [5.6/H-1-5] DOIT prendre en charge les appareils MIDI conformes aux classes et déclarer l'indicateur de fonctionnalité MIDI.
  • [5.7/H-1-2] DOIT prendre en charge MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL avec les fonctionnalités de déchiffrement de contenu ci-dessous.

  Taille d'échantillon minimale	4 Mio
  Nombre minimal de sous-échantillons – H264 ou HEVC	32
  Nombre minimal de sous-échantillons – VP9	9
  Nombre minimal de sous-échantillons – AV1	288
  Taille minimale de la mémoire tampon du sous-échantillon	1 Mio
  Taille minimale de la mémoire tampon cryptographique générique	500 Kio
  Nombre minimal de sessions simultanées	30
  Nombre minimal de clés par session	20
  Nombre total minimal de clés (toutes les sessions)	80
  Minimum Total Number of DRM Keys (toutes les sessions)	6
  Taille du message	16 Kio
  Frames déchiffrés par seconde	60 FPS

  Mettre fin aux nouvelles exigences

• 2.2.7.2 Camera: mises à jour des exigences concernant la classe Media Performance pour l'appareil photo.

  Voir la révision

  Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

  • [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution d'au moins 12 mégapixels permettant la capture vidéo à 4K à 30 images par seconde. La caméra arrière principale est celle qui possède l'ID d'appareil photo le plus bas.
  • [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution d'au moins 5 mégapixels et prendre en charge la capture vidéo à 1080p à 30 images par seconde. La caméra frontale principale est celle qui possède l'ID d'appareil photo le plus bas.
  • [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel avec une valeur FULL ou supérieure pour les deux caméras principales.
  • [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux caméras principales.
  • [7.5/H-1-5] DOIT avoir une latence de capture JPEG de "camera2" inférieure à 1 000 ms pour une résolution de 1080p telle que mesurée par le test PerformanceTest de la caméra CTS dans des conditions d'éclairage SIT (3 000 K) pour les deux caméras principales.
  • [7.5/H-1-6] DOIT avoir une latence de démarrage de l'appareil photo 2 (ouvrir la caméra à la première image d'aperçu) inférieure à 500 ms, telle que mesurée par le test PerformanceTest de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
  • [7.5/H-1-8] DOIT prendre en charge CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW et android.graphics.ImageFormat.RAW_SENSOR pour la caméra arrière principale.
  • [7.5/H-1-9] DOIT disposer d'une caméra principale arrière compatible avec les résolutions 720p ou 1080p à 240 FPS.
  • [7.5/H-1-10] DOIT avoir une valeur ZOOM_RATIO inférieure à 1,0 pour les caméras principales si une caméra RVB ultra grand angle orientée dans la même direction.
  • [7.5/H-1-11] DOIT implémenter une diffusion simultanée de flux avant arrière sur les caméras principales.
  • [7.5/H-1-12] DOIT prendre en charge CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION pour les caméras avant et arrière principales.
  • [7.5/H-1-13] DOIT prendre en charge la fonctionnalité LOGICAL_MULTI_CAMERA pour les caméras principales si plus d'une caméra RVB orientée dans la même direction.
  • [7.5/H-1-14] DOIT prendre en charge la fonctionnalité STREAM_USE_CASE pour la caméra avant principale et la caméra arrière principale.

  Mettre fin aux nouvelles exigences

• 2.2.7.3 Hardware (Matériel) : mises à jour des exigences de classe Media Performance pour le matériel.

  Voir la révision

  Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

  • [7.1.1.1/H-2-1] DOIT avoir une résolution d'écran d'au moins 1080p.
  • [7.1.1.3/H-2-1] DOIT avoir une densité d'écran d'au moins 400 ppp.
  • [7.6.1/H-2-1] DOIT disposer d'au moins 8 Go de mémoire physique.

  Mettre fin aux nouvelles exigences

• 2.2.7.4 Performance : mises à jour de la classe Media Performance pour Performance.

  Voir la révision

  Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.T pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

  • [8.2/H-1-1] DOIT garantir des performances d'écriture séquentielle d'au moins 125 Mo/s.
  • [8.2/H-1-2] DOIT garantir des performances d'écriture aléatoire d'au moins 10 Mo/s.
  • [8.2/H-1-3] DOIT garantir des performances de lecture séquentielle d'au moins 250 Mo/s.
  • [8.2/H-1-4] DOIT garantir des performances de lecture aléatoire d'au moins 40 Mo/s.

  Mettre fin aux nouvelles exigences

• 2.5.1 Matériel: mises à jour des exigences concernant l'accéléromètre à 3 axes et le gyroscope à 3 axes, ainsi que les exigences relatives aux caméras extérieures.

  Voir la révision

  Implémentations pour les appareils automobiles:

  • [7.3.1/A-0-4] DOIT se conformer au système de coordonnées du capteur de voiture d'Android.
  • [7.3/A-SR] Il est VISIBLE d'inclure un accéléromètre à 3 axes et un gyroscope à 3 axes.
  • [7.3/A-SR] Il est STRONGLY_RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_HEADING.

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

  • [7.3.1/A-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 100 Hz.

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

  • [7.3.1/A-SR] 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 à 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 Automotive incluent un gyroscope:

  • [7.3.4/A-2-1] DOIT pouvoir signaler des événements avec 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] Il est FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope sur +/-250 dps afin d'optimiser la résolution possible.

  Mettre fin aux nouvelles exigences

  Si les implémentations d'appareils Automotive incluent un gyroscope à trois axes:

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

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

  • [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 capteur TYPE_HEADING, celles-ci:

  • [7.3.4/A-4-3] DOIT pouvoir signaler des événements avec une fréquence d'au moins 1 Hz.
  • [7.3.4/A-SR] StrongLY_RECOMMENDED pour signaler les événements avec une fréquence d'au moins 10 Hz.
  • DEVRAIT faire référence au nord géographique.
  • DEVRAIT être disponible même lorsque le véhicule est immobile.
  • DEVRAIT avoir une résolution d'au moins 1 degré.

  Mettre fin aux nouvelles exigences

  Une caméra de l'extérieur est une caméra qui capture les scènes en dehors de l'implémentation de l'appareil, comme la caméra de recul une caméra embarquée .

  Si les implémentations d'appareils automobiles incluent une caméra offrant une vue extérieure, celles-ci:

  • Il est FORTEMENT RECOMMANDÉ d'orienter les [7.5.5/A-SR] de sorte que la grande dimension de l'appareil photo s'aligne sur l'horizon.

  • DEVRAIT prendre en charge le framework de synchronisation Android.

  • Un autofocus matériel ou logiciel peut être implémenté dans le pilote de l'appareil photo.

  Si les implémentations d'appareils automobiles incluent une ou plusieurs caméras offrant une vue extérieure et chargent le service EVS (Exterior View System), alors pour ce type de caméra:

  • [7.5/A-2-1] NE DOIT PAS pivoter ni dupliquer horizontalement l'aperçu de l'appareil photo.

  Implémentations pour les appareils automobiles:

  • PEUT inclure une ou plusieurs caméras disponibles pour des applications tierces.

  Si les implémentations d'appareils automobiles incluent au moins une caméra et la mettent à la disposition des applications tierces:

  • [7.5/A-3-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any.
  • [7.5/A-3-2] NE DOIT PAS déclarer la caméra en tant que caméra système.
  • PEUVENT être compatibles avec les caméras externes décrites dans la section 7.5.3.
  • PEUT inclure des fonctionnalités (telles que l'autofocus, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

  Mettre fin aux nouvelles exigences

• 2.5.5 Modèle de sécurité : nouvelles exigences concernant les autorisations d'accès à l'appareil photo pour les appareils automobiles.

  Voir la révision

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

  • [9.8.2/A-2-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'une application accède aux données en direct de l'appareil photo, mais pas lorsqu'elle n'est accessible que par une ou plusieurs applications détenant les rôles décrits dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].

  • [9.8.2/A-2-2] NE DOIT pas masquer l'indicateur d'appareil photo pour les applications système ayant des interfaces utilisateur visibles ou une interaction directe de l'utilisateur.

  Mettre fin aux nouvelles exigences

• 2.6.1 Configuration requise pour les tablettes – Matériel : mise à jour des exigences concernant la taille de l'écran des tablettes.

  Voir la révision

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

  • La taille d'écran est supérieure à 7 pouces et inférieure à 18 pouces en diagonale.

  Taille de l'écran

  • [7.1.1.1/Tab-0-1] DOIT avoir un écran compris entre 7 et 18 pouces.

3. Logiciel

• 3.2.2 Paramètres de compilation : mise à jour des caractères ASCII dans getSerial().

  Voir la révision

  • [C-0-1] Pour fournir des valeurs cohérentes et significatives entre les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs que les implémentations d'appareils DOIVENT respecter.

  Paramètre	Détails
  getSerial()	DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique sur tous les appareils ayant le même MODEL et le même MANUFACTURER. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière “^[a-zA-Z0-9]+$”.

• 3.2.3.5 Intents d'application conditionnels : mise à jour des exigences concernant les intents d'application conditionnels.

  Voir la révision

  Si les implémentations d'appareils incluent un grand écran (généralement avec une largeur et une hauteur d'écran de 600 dp ou plus) et sont compatibles avec la fonctionnalité de fractionnement, elles:

  • [C-17-1] DOIT avoir 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.

  Mettre fin aux nouvelles exigences

• 3.5.1 Restriction des applications : mises à jour des restrictions liées aux applications.

  Voir la révision

  Si les implémentations d'appareils mettent en œuvre un mécanisme propriétaire permettant de 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 restreinte, elles:

  • [C-1-1] DOIT autoriser l'utilisateur à voir la liste des applications soumises à restriction.
  • [C-1-2] DOIT fournir une affordance à l'utilisateur pour 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 mauvais comportement en termes d'état du système, mais PEUT appliquer les restrictions des applications lors de la détection d'un mauvais comportement de l'état du système, comme les wakelocks figés, les services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les personnes chargées de la mise en œuvre des 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 uniquement 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 aux applications lorsqu'un utilisateur désactive 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 au cours de la période de 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 à partir d'une application.

  • [C-1-7] NE DOIT PAS limiter l'application au premier plan qui est 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 la meilleure application de premier plan.

  • [C-1-9] DOIT signaler tous ces événements de restrictions propriétaires via UsageStats.

  • [C-1-10] DOIT fournir un document ou un site Web public et clair décrivant la façon dont les restrictions propriétaires sont appliquées. Ce document ou ce site Web DOIT inclure les éléments suivants:

    • Conditions de déclenchement des restrictions propriétaires
    • les types de restrictions qui peuvent être appliqués à une application et de quelle manière ;
    • Les modalités d'exemption de ces restrictions pour une application
    • Manière dont une application peut demander une exemption des restrictions propriétaires si elle accepte ce type d'exception pour les applications que l'utilisateur peut installer.

  Si une application est préinstallée sur l'appareil et qu'elle n'a jamais été explicitement utilisée par un utilisateur depuis plus de 30 jours, le [C-1-3] [C-1-5] en est exempté.

  Mettre fin aux nouvelles exigences

• 3.8.1 Lanceur d'applications (écran d'accueil) : mises à jour de la prise en charge de monochrome/adaptive-icon.

  Voir la révision

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

  • [C-6-1] DOIT être utilisé uniquement lorsqu'un utilisateur les active explicitement (par exemple, via les paramètres ou le menu de sélection du fond d'écran).

  Mettre fin aux nouvelles exigences

• 3.8.2 Widgets: mise à jour de la présence de widgets d'applications tierces dans le Lanceur d'applications.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers:

  • [C-1-2] DOIT inclure la compatibilité intégrée avec AppWidgets et exposer les affordances d'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur d'applications.

• 3.8.3.1 Présentation des notifications : clarification de la définition des notifications prioritaires.

  Voir la révision

  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.

• 3.8.3.3 Mode Priorité/Ne pas déranger : mise à jour pour inclure le mode Priorité dans les exigences du mode Ne pas déranger.

  Voir la révision

  Ne pas déranger / Mode Priorité

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

• 3.8.6 Thèmes: nouvelles exigences pour les palettes de tons dynamiques.

  Voir la révision

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

  • [C-1-4] DOIT générer des palettes de tonalités 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 de tonalités dynamiques à l'aide de 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.

    "Couleur source" utilisée pour générer des palettes de tons dynamiques lorsqu'elles sont envoyées avec android.theme.customization.system_palette (comme indiqué dans Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES).

  • [C-1-6] DOIT avoir une valeur de chrominance CAM16 supérieure ou égale à 5.

    • DEVRAIT être dérivé du fond d'écran via com.android.systemui.monet.ColorScheme#getSeedColors, qui fournit plusieurs couleurs sources valides parmi lesquelles choisir.

    • DEVRAIT utiliser la valeur 0xFF1B6EF3 si aucune des couleurs fournies ne répond aux exigences de couleur source ci-dessus.

  Mettre fin aux nouvelles exigences

• 3.8.17 Presse-papiers: ajout d'une section sur les exigences pour le contenu du presse-papiers.

  Voir la révision

  3.8.17. Presse-papiers

  Implémentations pour les appareils:

  • [C-0-1] NE DOIT PAS envoyer de données de presse-papiers à un composant, une activité, un service ni via une connexion réseau, sans action explicite de l'utilisateur (par exemple, en appuyant sur un bouton en superposition), sauf pour les services mentionnés à la section 9.8.6 Capture de contenu et Recherche d'applications.

  Si les implémentations d'appareils génèrent un aperçu visible par l'utilisateur lorsque le 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 aux exigences du presse-papiers.

  Mettre fin aux nouvelles exigences

• 3.9.1.1 Provisionnement des propriétaires d'appareils : mises à jour des exigences de provisionnement des propriétaires d'appareils.

  Voir la révision

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

  • [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application de propriétaire d'appareil, comme décrit ci-dessous :
    • Lorsque ni les utilisateurs ni de données utilisateur n'ont été configurés dans l'implémentation de l'appareil :
      • [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 d'appareil ou propriétaire de profil si l'appareil déclare la prise en charge des communications NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de 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 de profil, en fonction des valeurs de android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES, sauf si le contexte indique qu'il n'y a qu'une seule option valide. (par exemple, pour le provisionnement par NFC où le provisionnement de propriétaire de profil n'est pas disponible).
      • [C-1-9] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE à l'application Propriétaire de l'appareil si un propriétaire d'appareil est établi lors du provisionnement, quelle que soit la méthode de provisionnement utilisée. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que l'application Propriétaire de l'appareil n'a pas terminé.
    • Lorsque l'implémentation de l'appareil contient des données utilisateur ou , elle :
      • [C-1-7] NE DOIT plus enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil.
  • [C-1-2] DOIT afficher un avis de divulgation approprié (comme référencé dans l'AOSP) et obtenir le consentement explicite de l'utilisateur final avant qu'une application ne soit définie comme propriétaire de l'appareil, sauf si l'appareil est configuré de manière programmatique pour le mode démo en magasin avant l'interaction avec l'utilisateur final à l'écran. exiger une action affirmative avant ou pendant le processus de provisionnement pour autoriser une application. Le consentement peut être obtenu par l'action de l'utilisateur ou par certains moyens programmatiques, mais une notification de divulgation appropriée (comme référencée dans AOSP) DOIT être affichée avant le lancement du provisionnement par le propriétaire de l'appareil. De plus, le mécanisme de consentement des propriétaires d'appareils programmatiques utilisé (par les entreprises) pour le provisionnement des propriétaires d'appareils NE DOIT PAS interférer avec l'expérience prête à l'emploi pour une utilisation non professionnelle.
  • [C-1-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'applications d'autres propriétaires de l'appareil.

  Si les implémentations d'appareils déclarent android.software.device_admin, mais incluent également une solution propriétaire de gestion d'appareils Device Owner et fournissent un mécanisme permettant de promouvoir une application configurée dans la solution en tant que "Propriétaire d'appareil équivalent" au "Propriétaire de l'appareil" standard tel qu'il est reconnu par les API DevicePolicyManager d'Android, elles:

  • [C-2-1] DOIT mettre en place un processus permettant de vérifier que l'application faisant l'objet de la promotion appartient à une solution d'entreprise légitime de gestion des appareils et qu'elle a été configurée dans la solution propriétaire pour disposer des droits équivalents en tant que "Propriétaire de l'appareil".
  • [C-2-2] DOIT afficher la même mention de consentement pour le propriétaire de l'appareil AOSP que celle initiée par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
  • [C-2-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'applications appartenant à d'autres propriétaires de l'appareil.
  • PEUT disposer de données utilisateur sur l'appareil avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".

• 3.9.4 Exigences relatives aux rôles de gestion des appareils : ajout d'une section sur les exigences concernant les rôles de gestion des appareils.

  Voir la révision

  3.9.4 Exigences relatives aux rôles de gestion des règles relatives aux appareils

  Si les implémentations d'appareils signalent android.software.device_admin ou android.software.managed_users, alors:

  • [C-1-1] DOIT prendre en charge 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 relatives aux appareils PEUT être définie en définissant config_devicePolicyManagement sur le nom du package. Le nom du package DOIT être suivi de : 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 prendre en charge le provisionnement sans application de titulaire de rôle de gestion des règles relatives aux appareils (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 relatives aux appareils 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.

  Mettre fin aux nouvelles exigences

• 3.18 Contacts: ajout d'informations pour les nouveaux contacts.

  Voir la révision

  Default account for new contacts (Compte par défaut pour les nouveaux contacts) : Contacts Provider fournit des API permettant de gérer les paramètres du compte par défaut lors de la création d'un contact.

  Si les implémentations de l'appareil préchargent une application de contacts, celle-ci:

  • [C-2-1] DOIT gérer l'intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT pour lancer une UI de sélection de compte et enregistrer le paramètre dans le fournisseur de contacts lorsqu'un compte est sélectionné.

  • [C-2-2] DOIT respecter le paramètre de compte par défaut lors du traitement de Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT pour ContactsContracts.Contacts.CONTENT_TYPE et ContactsContract.RawContacts.CONTENT_TYPE en sélectionnant initialement le compte.

  Mettre fin aux nouvelles exigences

4. Compatibilité avec les packages d'applications

• 4. Compatibilité avec les packages d'applications : mises à jour de la version du schéma de signature APK.

  Voir la révision

  Implémentations pour les appareils:

  • [C-0-2] DOIT prendre en charge la validation des fichiers ".apk" à l'aide des APK Signature Scheme v3.1 , APK Signature Scheme v3, APK Signature Scheme v2 et de la signature JAR.

  • [C-0-9] DOIT prendre en charge la validation des fichiers .apk à l'aide des APK Signature Scheme v4 et APK Signature Scheme v4.1 .

5. Compatibilité multimédia

• 5.1.2 Décodage audio: ajout de nouvelles exigences pour les décodeurs capables de produire du contenu audio multicanal.

  Voir la révision

  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) vers le format PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être acceptés:

  • [C-7-1] DOIT être configuré par l'application à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT pour contrôler si le contenu est réduit en stéréo (si vous utilisez une valeur de 2) ou si la sortie est effectuée à l'aide du nombre natif de canaux (lorsque vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour qu'il produise six canaux lorsqu'il est alimenté en contenu 5.1.
  • [C-7-2] Lors du décodage, le décodeur DOIT annoncer le masque de canal utilisé sur le format de sortie à l'aide de la clé KEY_CHANNEL_MASK, à l'aide des constantes android.media.AudioFormat (exemple : 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 qu'elles peuvent produire du contenu audio multicanal (c'est-à-dire plus de deux canaux) lorsqu'ils fournissent du contenu multicanal compressé, procédez comme suit:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de pouvoir configurer le décodeur pour pouvoir être configuré par l'application à l'aide du décodage avec la clé KEY_MAX_OUTPUT_CHANNEL_COUNT afin de contrôler si le contenu est réduit en stéréo (si vous utilisez une valeur de 2) ou si la sortie utilise le nombre natif de canaux (si vous utilisez une valeur égale ou supérieure à ce nombre). Par exemple, une valeur égale ou supérieure à 6 configure un décodeur pour qu'il produise six canaux lorsqu'il est alimenté en contenu 5.1.
  • [C-SR] Lors du décodage, il est FORTEMENT RECOMMANDÉ d'annoncer le masque de canal utilisé sur le format de sortie avec la clé KEY_CHANNEL_MASK, à l'aide des constantes android.media.AudioFormat (exemple : CHANNEL_OUT_5POINT1).

  Mettre fin aux nouvelles exigences

• 5.4.1 Informations sur la capture audio et le micro : mises à jour des sources audio compatibles pour les flux d'entrée audio.

  Voir la révision

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

  • [C-1-1] DOIT autoriser la capture de contenu audio brut présentant les caractéristiques suivantes pour tout flux d'entrée AudioRecord ou AAudio qui a bien été ouvert. Les caractéristiques suivantes DOIVENT être au minimum acceptées:

    • Format:PCM linéaire 16 bits
    • Taux d'échantillonnage:8 000, 11 025, 16 000, 44 100 et 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.
    • [C-1-4] DOIT respecter l'API MicrophoneInfo et indiquer correctement les informations concernant les micros disponibles sur l'appareil accessible aux applications tierces via l'API AudioManager.getMicrophones(), pour les enregistrements audio actifs avec MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED ou VOICE_PERFORMANCE. et les micros actuellement actifs, auxquels les applications tierces peuvent accéder via les API AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones().

• 5.4.2 Capture pour la reconnaissance vocale : mises à jour des exigences concernant le flux audio de reconnaissance vocale et exigences supplémentaires pour les niveaux de gain du micro.

  Voir la révision

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

  • DEVRAIT enregistrer le flux audio de reconnaissance vocale avec des caractéristiques d'amplitude par rapport à la fréquence approximativement plates: plus précisément, ±3 dB, de 100 Hz à 4 000 Hz.
  • DEVRAIT enregistrer le flux audio de reconnaissance vocale avec une sensibilité d'entrée définie de sorte qu'une source de niveau de puissance sonore (SPL) de 90 dB à 1 000 Hz génère un RMS de 2 500 pour les échantillons 16 bits.

  • DEVRAIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: ±3 dB de 100 Hz à 4 000 Hz pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • Les [C-SR] sont FORTEMENT RECOMMANDÉS pour présenter des niveaux d'amplitude dans la plage des basses fréquences, en particulier de ±20 dB de 30 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour présenter des niveaux d'amplitude dans la plage des hautes fréquences, en particulier de ±30 dB de 4 000 Hz à 22 KHz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • DEVRAIT définir la sensibilité de l'entrée audio de sorte qu'une source à tonalités sinusoïdales de 1 000 Hz lue à 90 dB d'un niveau de pression acoustique (SPL) de 90 dB (mesurée à côté du micro) produise une réponse idéale de RMS 2 500 dans une plage de 1 770 et 3 530 pour une source audio de 16 bits ou -22.3

  Mettre fin aux nouvelles exigences

• 5.4.6 Niveaux de gain du micro : Exigences concernant les niveaux de gain du micro déplacées à la section 5.4.2.

  Voir la révision

  5.4.6. Niveaux de gain du micro [Moved to 5.4.2]

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

  • DEVRAIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±3 dB de 100 Hz à 4 000 Hz pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour présenter des niveaux d'amplitude dans la plage de basses fréquences, en particulier de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour présenter des niveaux d'amplitude dans la plage des hautes fréquences, en particulier de ±30 dB de 4 000 Hz à 22 kHz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
  • DEVRAIT définir la sensibilité de l'entrée audio de sorte qu'une source de tonalités sinusoïdales de 1 000 Hz lue à un niveau de pression sonore (SPL) de 90 dB génère une réponse avec un RMS de 2 500 pour des échantillons de 16 bits (ou une échelle complète de -22,35 dB pour les échantillons audio à virgule flottante/double précision) pour chaque source de reconnaissance vocale utilisée pour l'enregistrement.

• 5.5.4 Déchargement audio : modifications apportées aux exigences de lecture du déchargement audio.

  Voir la révision

  Si les appareils sont compatibles avec la lecture de déchargement audio, ils:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de couper le contenu audio lu sans interruption entre deux clips de même format lorsque spécifié par l'API AudioTrack sans interruption et le conteneur multimédia pour MediaPlayer.

• 5.6 Audio Latency : mises à jour des exigences de latence audio.

  Voir la révision

  Pour les besoins de cette section, utilisez les définitions suivantes:

  • gigue de sortie à froid. La variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
  • gigue d'entrée à froid. La variabilité entre les mesures distinctes des valeurs de latence d'entrée à froid.

  Si les implémentations d'appareils déclarent android.hardware.audio.output, ils DOIVENT respecter ou dépasser les exigences suivantes:

  • [C-1-2] Latence de sortie à 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.

  Si les implémentations d'appareils déclarent android.hardware.audio.output, il est VIVEMENT RECOMMANDÉ de respecter ou de dépasser les exigences suivantes:

  • [C-SR] Latence de sortie à froid de 100 millisecondes ou moins sur le chemin de données du locuteur. Les appareils existants et nouveaux qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉS de répondre à ces exigences dès maintenant. Dans une prochaine version de la plate-forme, une latence de sortie à froid de 200 ms ou moins sera exigée.
  • [C-SR] Minimiser la gigue à la sortie à froid.

  Si les implémentations d'appareils incluent android.hardware.microphone, ils DOIVENT répondre aux exigences suivantes pour l'audio d'entrée:

  • [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.

  Si les implémentations d'appareils incluent android.hardware.microphone, il est FORTEMENT RECOMMANDÉ de répondre à ces exigences audio d'entrée:

  • [C-SR] Latence d'entrée froide de 100 millisecondes ou moins sur le chemin de données du micro. Les appareils existants et nouveaux qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉS de répondre à ces exigences dès maintenant. Dans une prochaine version de la plate-forme, une latence d'entrée à froid de 200 ms ou moins sera obligatoire.

  • [C-SR] Latence d'entrée continue inférieure ou égale à 30 millisecondes.
  • [C-SR] Réduisez la gigue à l'entrée à froid.

• 5.10 Audio professionnel : modifications des exigences de latence audio pour une assistance audio professionnelle.

  Voir la révision

  Si les implémentations d'appareils indiquent la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles:

  • [C-1-2] DOIT présenter une latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, de 25 millisecondes ou moins et DOIT être inférieure ou égale à 10 millisecondes sur au moins un chemin pris en charge.
  • [C-1-5] DOIT respecter les latences et les exigences audio USB à l'aide de l'API AAudio native audio et de AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
  • [C-1-8] DOIT avoir une latence moyenne "Tap-to-tone" de 80 millisecondes ou moins sur au moins 5 mesures sur le chemin de données entre le haut-parleur et le micro.
  • [C-SR] SONT FORTEMENT RECOMMANDÉS de fournir un niveau de performances constant du processeur lorsque l'audio est actif et que la charge du processeur varie. Vous devez tester cette fonctionnalité à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel s'exécutant sur un framework audio simulé qui mesure les performances du système. Pour en savoir plus sur les benchmarks, consultez la documentation SynthMark. L'application SynthMark doit être exécutée à l'aide de l'option "Automated Test" (Test automatisé) et obtenir les résultats suivants : * voicemark.90 >= 32 voix *Latencymark.Fixed.little <= 15 ms *Latencymark.dynamic.little <= 50 ms
  • DEVRAIT avoir une latence entre l'entrée tactile et la sortie audio inférieure ou égale à 40 ms.

  Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs, ils:

  • [C-2-1] DOIT avoir une latence audio aller-retour continue moyenne, telle que définie dans la section 5.6 Latence audio, de 20 millisecondes ou moins, supérieure à 5 mesures avec un écart absolu inférieur à 5 millisecondes sur le chemin du connecteur audio à l'aide d'un dongle de bouclage audio.

• 5.12 Vidéo HDR : ajout d'une section sur les exigences concernant les vidéos HDR.

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

• 6.1 Outils pour les développeurs : mises à jour de la connectivité et des exigences du noyau GPU.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi ou Ethernet, ils:

  • [C-4-1] DOIT faire en sorte que la méthode AdbManager#isAdbWifiSupported() renvoie true.

  Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi ou Ethernet et incluent au moins une caméra, ils:

  • [C-5-1] DOIT faire en sorte que la méthode AdbManager#isAdbWifiQrSupported() renvoie true.

  • Informations sur les GPU

    Implémentations pour les appareils:

    • [C-6-1] DOIT implémenter la commande shell dumpsys gpu --gpuwork pour afficher les données de travail agrégées 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/.

  Mettre fin aux nouvelles exigences

7. Compatibilité matérielle

• 7.1.4.1 OpenGL ES: mise à jour vers les extensions recommandées.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

  • DEVRAIT prendre en charge les extensions EGL_IMG_context_priority et EGL_EXT_protected_content.

  Mettre fin aux nouvelles exigences

• 7.1.4.2 Vulkan: mises à jour de la version compatible avec Vulkan.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, celles-ci:

  • [SR] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.3. Vulkan 1.1
  • NE DOIT PAS prendre en charge une version de variante Vulkan (par exemple, la partie variante de la version principale de Vulkan DOIT être nulle).

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

  • [SR] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.3. Vulkan 1.1

  Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, elles:

  • DEVRAIT prendre en charge VkPhysicalDeviceProtectedMemoryFeatures et VK_EXT_global_priority.
  • [C-1-12] NE DOIT PAS énumérer la compatibilité avec l'extension VK_KHR_performance_query.
  • [C-SR] Sont FORTEMENT RECOMMANDÉS pour répondre aux exigences spécifiées par le profil Android Baseline 2021.

• 7.2.3 Touches de navigation:

  Voir la révision

  Implémentations pour les appareils:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ de rendre toutes les fonctions de navigation annulables. L'option "Annulable" est définie comme la capacité de l'utilisateur à empêcher l'exécution de la fonction de navigation (par exemple, revenir à l'accueil, revenir en arrière, etc.) si le balayage n'est pas relâché au-delà d'un certain seuil.

  Mettre fin aux nouvelles exigences

  Si la fonction de navigation vers l'arrière est fournie et que l'utilisateur annule le geste de 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 envoyé.

  Si la fonction de navigation vers l'arrière est fournie, mais que l'application de premier plan n'a PAS de OnBackInvokedCallback enregistré, procédez comme suit:

  • 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'appareils prennent en charge 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 barre de navigation, alors:

  • [C-9-1] DOIT prendre en charge les icônes adaptées aux enfants ou la navigation basée sur des boutons, comme indiqué dans le code AOSP.

  Mettre fin aux nouvelles exigences

• 7.3.1 Accéléromètre : mises à jour des exigences relatives aux capteurs des accéléromètres.

  Voir la révision

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

  • [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
  • Les [SR] sont VIVEMENT RECOMMANDÉS d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
  • Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est FORTEMENT RECOMMANDÉ de répondre à cette exigence sur les appareils Android afin de pouvoir les mettre à niveau vers la prochaine version de la plate-forme, qui pourrait devenir OBLIGATOIRE.
  • DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.

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

  • [C-2-1] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est FORTEMENT RECOMMANDÉ de répondre à cette exigence pour les appareils Android afin de pouvoir effectuer une mise à niveau vers la prochaine version de la plate-forme, qui pourrait devenir OBLIGATOIRE.
  • DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document 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] Sont STRONGLY_RECOMMENDED pour implémenter et signaler le capteur TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED.

  Mettre fin aux nouvelles exigences

  Si les implémentations d'appareils incluent un accéléromètre à 3 axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER est implémenté:

  • [C-4-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.

  Si les implémentations d'appareils incluent un accéléromètre à 3 axes et un capteur de gyroscope à 3 axes, ils:

  • [C-5-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.

  Si les implémentations d'appareils incluent un accéléromètre à 3 axes, un gyroscope à 3 axes et un magnétomètre, ils:

  • [C-6-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

• 7.3.4 Gyroscopes: mises à jour des exigences concernant les capteurs pour les gyroscopes.

  Voir la révision

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

  • [C-1-1] DOIT pouvoir signaler des événements avec 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é en cours d'utilisation, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
  • [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier avec le taux d'échantillonnage, mais DOIT être contrainte par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à un taux d'échantillonnage de 1 Hz, il DOIT ne pas être supérieur à 1e-7 rad^2/s^2.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution de 16 bits ou plus.
  • DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

  Mettre fin aux nouvelles exigences

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

  • [C-2-1] DOIT implémenter le capteur TYPE_GYROSCOPE.

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

  • [C-3-1] DOIT implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES.
  • [C-SR] Sont STRONGLY_RECOMMENDED pour implémenter et signaler le capteur TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED.

  Mettre fin aux nouvelles exigences

  Si les implémentations d'appareils comprennent un gyroscope à trois axes, un capteur d'accéléromètre et un capteur 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 à 3 axes et un gyroscope à 3 axes, ils:

  • [C-5-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.

• 7.3.10 Biometric Sensors : mises à jour des exigences concernant les capteurs biométriques.

  Voir la révision

  Les capteurs biométriques peuvent être classés en tant que classe 3 (anciennement Strong), classe 2 (anciennement Faible) ou classe 1 (anciennement Convenience) en fonction de leurs taux d'acceptation de spoofing et d'imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique pour interagir avec la plate-forme et les applications tierces. Les capteurs doivent répondre aux exigences supplémentaires décrites ci-dessous s'ils souhaitent être classés dans la classe 1, la classe 2 ou la classe 3. Les capteurs sont classés par défaut dans la classe 1 et doivent répondre aux exigences supplémentaires décrites ci-dessous s'ils souhaitent être classés dans la classe 2 ou la classe 3. Les biométriques de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, détaillées ci-dessous.

  Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 1 (anciennement commodité), procédez comme suit:

  • [C-1-11] DOIT avoir un taux d'acceptation de spoof et d'imposteurs ne dépassant pas 30%, avec (1) un taux d'acceptation de parodie et d'imposteur pour les espèces d'instruments d'attaque de présentation de niveau A (PAI) de niveau A ne dépassant pas 30%, et (2) un taux de spoofing et d'acceptation d'acceptation des espèces PAI de niveau B ne dépassant pas 40 % par les métriques de test d'Android.

  Mettre fin aux nouvelles exigences

  Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 2 (anciennement Faible), procédez comme suit:

  • [C-2-2] DOIT avoir un taux d'acceptation de spoof et d'imposteurs n'excédant pas 20%, avec (1) un taux d'acceptation de parodie et d'imposteur pour les espèces d'instruments d'attaque de présentation de niveau A (PAI) de niveau A ne dépassant pas 20%, et (2) un taux d'acceptation de spoof et d'imposteur des espèces PAI de niveau B inférieur à 30 % des métriques de PAI de niveau B

  Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 3 (anciennement Strong), elles:

  • [C-3-3] DOIT avoir un taux d'acceptation de spoof et d'imposteurs n'excédant pas 7%, avec (1) un taux d'acceptation de parodie et d'imposteur pour les espèces d'instruments d'attaque de présentation de niveau A (PAI) de niveau A inférieur ou égal à 7%, et (2) un taux d'acceptation de spoof et d'imposteurs pour les espèces PAI de niveau B ne dépassant pas 20%, selon les métriques du protocole Android .

• 7.3.13 IEEE 802.1.15.4 (UWB) : ajout d'une section sur les exigences pour la UWB.

  Voir la révision

  7.3.13. IEEE 802.1.15.4 (UWB)

  Si les implémentations d'appareils sont compatibles 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 l'indicateur de fonctionnalité matérielle android.hardware.uwb.
  • [C-1-3] DOIT prendre en charge tous les profils UWB pertinents définis dans l'implémentation Android.
  • [C-1-4] DOIT fournir une affordance utilisateur pour permettre à l'utilisateur d'activer/de désactiver la radio UWB.
  • [C-1-5] DOIT faire en sorte que les applications qui utilisent la radio UWB détiennent l'autorisation UWB_RANGING (dans le groupe d'autorisations NEARBY_DEVICE).
  • [C-1-6] Il est FORTEMENT RECOMMANDÉ de réussir les tests de conformité et de certification pertinents définis par les organisations standards, y compris FIRA, CCC et CSA.

  Mettre fin aux nouvelles exigences

• 7.4.1 Téléphonie: mises à jour des exigences en matière de téléphonie pour les paramètres de téléphonie GSM et CDMA, ainsi que les paramètres d'utilisation du réseau mobile.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant aux développeurs tiers d'accéder à la fonctionnalité eSIM, celles-ci:

  • [C-3-1] DOIT déclarer l'indicateur de fonctionnalité android.hardware.telephony.euicc. fournir une implémentation complète de EuiccManager API.

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA:

  • [C-6-1] Les éléments 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 lors de l'envoi et de la réception de SMS et de 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 prendre en charge la saisie de codes de numéroteur 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 visuelle des messages vocaux aux utilisateurs si elle prend en charge les transcriptions visuelles des messages vocaux.
  • [C-6-5] DOIT représenter tous les éléments SubscriptionInfo avec des UUID de groupe équivalents en tant qu'abonnement unique dans toutes les affordances visibles par l'utilisateur qui affichent et contrôlent les informations de la carte SIM. Les interfaces de paramètres qui correspondent à Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS ou EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS sont des exemples de ces affordances.
  • [C-6-6] NE DOIT PAS afficher ni autoriser le contrôle d'une SubscriptionInfo avec un UUID de groupe et un bit opportuniste non nuls dans les affordances visibles par l'utilisateur qui autorisent la configuration ou le contrôle des paramètres de la carte SIM.

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA et fournissent une barre d'état système, procédez comme suit:

  • [C-6-7] DOIT sélectionner un abonnement actif représentatif pour un UUID de groupe donné afin de l'afficher à l'utilisateur dans toutes les affordances qui fournissent des informations sur l'état de la carte SIM. Il peut s'agir, par exemple, de l'icône de signal mobile de la barre d'état ou du bloc Réglages rapides.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de choisir l'abonnement représentatif comme abonnement aux données actives, sauf si l'appareil fait l'objet d'un appel vocal, au cours duquel il est FORTEMENT RECOMMANDÉ que l'abonnement représentatif soit l'abonnement vocal actif.

  Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA:

  • [C-6-8] DOIT être capable d'ouvrir et d'utiliser simultanément le nombre maximal de canaux logiques (20 au total) pour chaque UICC conformément à l'ETSI TS 102 221.
  • [C-6-10] NE DOIT PAS appliquer l'un des comportements suivants aux applications d'opérateurs actives (telles que désignées par TelephonyManager#getCarrierServicePackageName) automatiquement ou sans confirmation explicite de l'utilisateur :
    • Révoquer ou limiter l'accès au réseau
    • Révoquer les autorisations
    • Limitez l'exécution d'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'appareils incluent la téléphonie GSM ou CDMA et que tous les abonnements actifs non opportuns qui partagent un UUID de groupe sont désactivés, physiquement supprimés de l'appareil ou marqués comme opportunistes, l'appareil:

  • [C-7-1] DOIT désactiver automatiquement tous les abonnements opportunistes actifs restants dans le même groupe.

  Si les implémentations d'appareils incluent la téléphonie GSM, mais pas la téléphonie CDMA, ils:

  • [C-8-1] NE DOIT PAS déclarer PackageManager#FEATURE_TELEPHONY_CDMA.
  • [C-8-2] DOIT générer une exception IllegalArgumentException lors des tentatives de définition de n'importe quel type de réseau 3GPP2 dans des masques de bits de type de réseau préférés ou autorisés.
  • [C-8-3] DOIT renvoyer une chaîne vide à partir de TelephonyManager#getMeid.

  Si les implémentations d'appareils prennent en charge les eUICC avec plusieurs ports et profils, elles:

  • [C-11-1] DOIT déclarer l'indicateur de fonctionnalité android.hardware.telephony.euicc.mep.

  Mettre fin aux nouvelles exigences

• 7.4.1.1 Compatibilité avec le blocage des numéros : mises à jour des exigences concernant le blocage des numéros.

  Voir la révision

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

  • [C-1-4] NE DOIT PAS écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.

  • [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 en dehors de la vue du journal d'appels par défaut dans l'application de téléphonie préinstallée.
  • DEVRAIT fournir une affordance utilisateur pour afficher les appels bloqués dans l'application de téléphonie préinstallée.

  Mettre fin aux nouvelles exigences

• 7.4.1.3 Déchargement de Keepalive NAT-T cellulaire: nouvelle section pour le déchargement de Keepalive NAT-T cellulaire.

  Voir la révision

  Déchargement cellulaire NAT-T Keepalive

  Implémentations pour les appareils:

  • DEVRAIT inclure la prise en charge du déchargement du message keepalive cellulaire.

  Si les implémentations d'appareils prennent en charge le déchargement des messages keepalive cellulaire et les expose à des applications tierces, elles:

  • [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
  • [C-1-2] DOIT prendre en charge au moins un emplacement keepalive simultané sur le réseau mobile.
  • [C-1-3] DOIT prendre en charge autant d'emplacements de message keepalive cellulaires simultanés que ceux acceptés par la HAL de radio cellulaire.
  • [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge au moins trois emplacements de message keepalive cellulaire par instance radio.

  Si les implémentations d'appareils ne prennent pas en charge le déchargement des messages keepalive cellulaire:

  • [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

  Mettre fin aux nouvelles exigences

• 7.4.2.5 Localisation Wi-Fi (délai aller-retour Wi-Fi (DAR)) : modifications apportées à la précision de la localisation Wi-Fi.

  Voir la révision

  Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent la fonctionnalité à des applications tierces, celles-ci:

  • [C-1-4] DOIT être précis à 2 mètres près pour une bande passante de 80 MHz au 68e centile (calculé avec la fonction de distribution cumulative).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de générer un rapport précis à 1,5 mètre pour une bande passante de 80 MHz au 68e centile (calculé à l'aide de la fonction de distribution cumulative).

  Mettre fin aux nouvelles exigences

• 7.4.2.6 Déchargement de Keepalive Wi-Fi : mise à jour pour ajouter les exigences de déchargement de Keepalive cellulaire.

  Voir la révision

  Implémentations pour les appareils:

  • DEVRAIT inclure la prise en charge du déchargement Wi-Fi keepalive.

  Si les implémentations d'appareils prennent en charge le déchargement du message keepalive Wi-Fi et exposent cette fonctionnalité à des applications tierces, elles:

  • [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.
  • [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés sur le Wi-Fi
    et au moins un emplacement keepalive sur le réseau mobile.

  Si les implémentations d'appareils ne prennent pas en charge le déchargement du message keepalive Wi-Fi, elles:

  • [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

• 7.4.2.9 Trust on First Use (TOFU) (Approuver à la première utilisation) : ajout de la section sur les exigences concernant la confiance lors de la première utilisation.

  Voir la révision

  7.4.2.9 Trust On First Use (TOFU) (Confiance lors de la première utilisation)

  Si les implémentations d'appareils sont compatibles avec TOFU (Trust on First Usage) et permettent à l'utilisateur de définir des configurations WPA/WPA2/WPA3-Enterprise, elles:

  • [C-4-1] DOIT fournir à l'utilisateur l'option de choisir d'utiliser TOFU.

  Mettre fin aux nouvelles exigences

• 7.4.3 Bluetooth: mise à jour de la configuration Bluetooth requise.

  Voir la révision

  Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

  • DEVRAIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC) avec A2DP.

  Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioSupported(), elles:

  • [C-7-1] DOIT prendre en charge le client monodiffusion.
  • [C-7-2] DOIT prendre en charge 2M PHY.
  • [C-7-3] DOIT prendre en charge la publicité LE Extended.
  • [C-7-4] DOIT prendre en charge au moins deux connexions CIS dans un pipeline CIG.
  • [C-7-5] DOIT activer simultanément le client de monodiffusion BAP, le coordinateur de définition CSIP, le serveur MCP, le contrôleur VCP et le serveur CCP.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer le client monodiffusion HAP.

  Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastSourceSupported(), elles:

  • [C-8-1] DOIT prendre en charge au moins 2 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 prendre en charge la publicité LE Periodic.

  Si les implémentations d'appareils renvoient true pour l'API BluetoothAdapter.isLeAudioBroadcastAssistantSupported(), elles:

  • [C-9-1] DOIT être compatible avec PAST (Periodic Advertising Sync Transfer).
  • [C-9-2] DOIT prendre en charge la publicité LE Periodic.

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

  • [C-10-1] DOIT que les mesures de l'RSSI soient comprises dans une plage de +/-9 dB pour 95% des mesures à 1 m d'un appareil de référence émettant dans un environnement de ligne de vue ADVERTISE_TX_POWER_HIGH.
  • [C-10-2] DOIT inclure les corrections Rx/Tx pour réduire les écarts par canal, de sorte que les mesures sur chacun des trois canaux, sur chacune des antennes (si plusieurs sont utilisées), se situent à plus ou moins -3 dB les unes des autres pour 95% des mesures.
  • [C-SR] 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 de distance d'un appareil de référence émettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de mesurer et de compenser le décalage Tx pour s'assurer que le RSSI BLE médian est de -60 dBm +/-10 dB lors de la recherche depuis un appareil de référence situé à 1 m de distance et en transmettant à ADVERTISE_TX_POWER_HIGH, où les appareils sont orientés de sorte qu'ils se trouvent sur des "plans parallèles" avec des écrans orientés dans la même direction.

  Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans les Exigences concernant l'étalonnage de présence.

  Si les implémentations d'appareils sont compatibles avec la version Bluetooth 5.0, ils:

  • [C-SR] SONT FORTEMENT RECOMMANDÉS de fournir une assistance dans les domaines suivants :
    • LE 2M PHY
    • LE Codec PHY
    • Extension LE Advertising Extension
    • Publicité périodique
    • Au moins 10 ensembles d'annonces
    • Au moins huit connexions LE simultanées. Chaque connexion peut appartenir à l'un ou l'autre des rôles de topologie de connexion.
    • Confidentialité de la couche de liaison LE
    • Une "liste de résolution" d'au moins huit entrées

  Mettre fin aux nouvelles exigences

• 7.4.9 UWB: ajout d'une section sur les exigences concernant le matériel UWB.

  Voir la révision

  7.4.9. UWB

  Si les implémentations d'appareils indiquent la compatibilité avec la fonctionnalité android.hardware.uwb via la classe android.content.pm.PackageManager, elles:

  • [C-1-1] DOIT s'assurer que les mesures de distance se situent à moins de +/-15 cm pour 95 % des mesures dans l'environnement de vision à une distance d'un mètre dans une chambre non réfléchissante.
  • [C-1-2] DOIT s'assurer que la médiane des mesures de distance à 1 m de l'appareil de référence se situe dans les limites de [0,75 m, 1,25 m], où la distance de vérité terrain est mesurée à partir du bord supérieur de l'appareil testé, face vers le haut et incliné de 45 degrés.

  Il est FORTEMENT RECOMMANDÉ de suivre les étapes de configuration des mesures spécifiées dans les Exigences concernant l'étalonnage de présence.

  Mettre fin aux nouvelles exigences

• Caméras 7.5: mises à jour des exigences liées à la capacité de sortie HDR 10 bits.

  Voir la révision

  Si les implémentations d'appareils sont compatibles avec la capacité de sortie HDR 10 bits, les conditions suivantes s'appliquent:

  • [C-2-1] DOIT prendre en charge au moins le profil HDR HLG pour chaque appareil photo compatible avec une sortie 10 bits.
  • [C-2-2] DOIT prendre en charge une sortie 10 bits pour la caméra arrière principale ou la caméra avant principale.
  • [C-SR] sont FORTEMENT RECOMMANDÉS de prendre en charge une sortie 10 bits pour les deux caméras principales.
  • [C-2-3] DOIT prendre en charge les mêmes profils HDR pour toutes les sous-caméras physiques compatibles BACKWARD_COMPATIBLE d'une caméra logique et pour l'appareil photo logique lui-même.

  Pour les appareils photo logiques compatibles avec la technologie HDR 10 bits et qui implémentent l'API android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO:

  • [C-3-1] DOIT prendre en charge le basculement entre toutes les caméras physiques rétrocompatibles via la commande CONTROL_ZOOM_RATIO de la caméra logique.

  Mettre fin aux nouvelles exigences

• 7.7.2 Mode hôte USB : révisions pour les ports à double rôle.

  Voir la révision

  Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et l'USB Type-C, ils:

  • [C-4-1] DOIT implémenter la fonctionnalité de port double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3). Pour les ports double rôle, sur les appareils équipés d'un connecteur audio 3,5 mm, la détection du récepteur USB (mode hôte) PEUT être désactivée par défaut, mais il DOIT être possible pour l'utilisateur de l'activer.

• 7.11 Media Performance Class : mise à jour pour inclure Android T.

  Voir la révision

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

  • [C-1-3] DOIT respecter toutes les exigences de la "classe de performance multimédia" décrites dans la section 2.2.7.

  En d'autres termes, la classe de performance multimédia dans Android T n'est définie que pour les appareils portables de version T, S ou R.

  Mettre fin aux nouvelles exigences

  Consultez la section 2.2.7 pour connaître les exigences spécifiques à chaque appareil.

9. Compatibilité des modèles de sécurité

• 9.1 Autorisations: étendez les chemins d'accès acceptés pour les listes d'autorisation d'autorisations pour les applications préinstallées aux fichiers APEX.

  Voir la révision

  • [C-0-2] Les autorisations dont l'protectionLevel est 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 que des fichiers ApEX) et se trouver dans le sous-ensemble des autorisations explicitement ajoutées à la liste d'autorisation pour chaque application. L'implémentation d'AOSP répond à cette exigence en lisant et en accordant les autorisations system/priv-app à la liste d'autorisation pour chaque application à partir des fichiers du dossier etc/permissions/.

• 9.7 Fonctionnalités de sécurité : mises à jour des exigences d'initialisation pour maintenir l'intégrité du noyau.

  Voir la révision

  Les fonctionnalités d'intégrité du noyau et d'auto-protection font partie intégrante de la sécurité Android. Implémentations pour les appareils:

  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau afin d'empêcher 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 paramètres locaux.

  Mettre fin aux nouvelles exigences

• 9.8.7 Confidentialité – Accès au presse-papiers : effacez automatiquement les données du presse-papiers 60 minutes après une activité de couper/copier/coller afin de protéger la confidentialité des utilisateurs.

  Voir la révision

  Implémentations pour 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 active.
  • [C-0-2] DOIT effacer les données du presse-papiers au plus tard 60 minutes après leur dernier placement dans le presse-papiers ou sa dernière lecture.

• 9.11 Clés et identifiants : mises à jour des exigences concernant l'écran de verrouillage sécurisé, y compris l'ajout des algorithmes ECDH et 3DES aux algorithmes de chiffrement.

  Voir la révision

  Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

  • [C-1-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA, ECDH (si IKeyMintDevice) et HMAC, ainsi que des fonctions de hachage de la famille MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée en toute sécurité du code exécuté 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 peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. 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 vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.

• 9.11.1 Secure Lock Screen, Authentication, Virtual Devices (Écran de verrouillage sécurisé, authentification et appareils virtuels) : section sur les exigences supplémentaires pour les appareils virtuels et les transferts d'authentification.

  Voir la révision

  Si les implémentations d'appareils ajoutent ou modifient des 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 l'emplacement:

  • [C-6-3] L'utilisateur DOIT être invité à répondre à une question d'authentification principale recommandée (par code, schéma ou mot de passe, par exemple) au moins une fois toutes les quatre heures. Lorsqu'un jeton physique répond aux exigences des implémentations TrustAgent dans C-X, les restrictions de délai avant expiration définies dans C-9-5 s'appliquent à la place.

  Si les implémentations d'appareils permettent aux applications de créer des écrans virtuels secondaires et ne prennent pas en charge les événements d'entrée associés, tels que 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] DOIT déconnecter tous les appareils virtuels au terme du délai d'inactivité
  • [C-10-3] DOIT disposer d'un délai d'inactivité
  • [C-10-4] DOIT verrouiller tous les écrans lorsque l'utilisateur lance un verrouillage, y compris via l' affordance de blocage de l'utilisateur 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 la création d'événements d'entrée associés via VirtualDeviceManager lorsque DevicePolicyManager.setNearbyAppStreamingPolicy l'indique
  • [C-10-7] DOIT utiliser un presse-papiers distinct uniquement pour chaque appareil virtuel (ou désactiver le presse-papiers pour les appareils virtuels)
  • [C-10-11] DOIT désactiver l'UI d'authentification sur les appareils virtuels, y compris la saisie de facteurs de connaissances et l'invite biométrique
  • [C-10-12] DOIT empêcher l'affichage des intents initiés à partir d'un appareil virtuel uniquement sur le même appareil virtuel
  • [C-10-13] NE DOIT pas utiliser l'état de verrouillage d'un appareil virtuel comme autorisation d'authentification de l'utilisateur auprès du système Android Keystore. Consultez KeyGenParameterSpec.Builder.setUserAuthentication*.

  Lorsque les implémentations d'appareils permettent à l'utilisateur de transférer le facteur de connaissances principal pour l'authentification 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 connaissances 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 connaissances de l'appareil source vers l'appareil cible, de sorte qu'il ne puisse pas être déchiffré à distance ni utilisé pour déverrouiller à distance l'un ou l'autre des appareils.
  • [C-11-2] DOIT, sur l'appareil source , demander à l'utilisateur de confirmer le facteur de connaissances de l'appareil source avant de le transférer vers l'appareil cible.
  • [C-11-3] DOIT, sur un appareil cible dépourvu de tout facteur de connaissances d'authentification principal défini, demandez à l'utilisateur de confirmer un facteur de connaissances transféré sur l'appareil cible avant de le définir comme facteur de connaissances d'authentification principal pour l'appareil cible et avant de rendre disponibles les données transférées à partir d'un appareil source.

  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:

  • [C-12-1] DOIT appeler grantTrust() avec l'indicateur uniquement lorsqu'il est connecté à un appareil physique proche doté de son propre écran de verrouillage et lorsque l'utilisateur a authentifié son identité sur cet écran de verrouillage. Pour répondre aux exigences d'authentification de l'utilisateur, les appareils à proximité peuvent utiliser des mécanismes de détection au poignet ou sur le corps après le déverrouillage unique d'un utilisateur.
  • [C-12-2] DOIT mettre l'implémentation de l'appareil à l'état TrustState.TRUSTABLE lorsque l'écran est éteint (par exemple, en appuyant sur un bouton ou en cas d'expiration du délai d'affichage) et que TrustAgent n'a pas révoqué l'approbation. L'AOSP satisfait à cette exigence.
  • [C-12-3] NE DOIT faire passer l'appareil de l'état TrustState.TRUSTABLE à l'état TrustState.TRUSTED que si le TrustAgent continue d'accorder l'approbation en fonction des exigences de C-12-1.
  • [C-12-4] DOIT appeler TrustManagerService.revokeTrust() après un délai maximal de 24 heures à compter de l'octroi de l'approbation, après une période d'inactivité de huit heures, ou en cas de perte de la connexion sous-jacente à l'appareil physique proche.

  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 VIRTUAL_DISPLAY_FLAG_SECURE, ils:

  • [C-13-8] DOIT empêcher le démarrage sur l'appareil virtuel des activités avec l'attribut android:canDisplayOnRemoteDevices ou les métadonnées android.activity.can_display_on_remote_devices dont la valeur est "false".
  • [C-13-9] DOIT empêcher le démarrage des activités qui n'activent pas explicitement le streaming et qui indiquent qu'elles affichent du contenu sensible, y compris via SurfaceView#setSecure, FLAG_SECURE ou SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, sur l'appareil virtuel.
  • [C-13-10] DOIT désactiver l'installation d'applications lancées à partir d'appareils virtuels.

  Mettre fin aux nouvelles exigences

• 9.11.2 Strongbox: faire de la résistance aux attaques internes (IAR) une exigence nécessaire.

  Voir la révision

  Pour valider la conformité avec les normes [C-1-3] à [C-1-9], les implémentations d'appareils:

  • Les [C-SR] sont FORTEMENT RECOMMANDÉS pour fournir une résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature de micrologiciel ne peut pas produire de micrologiciel entraînant la fuite de secrets par la StrongBox, le contournement des exigences de sécurité fonctionnelles ou l'accès à 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 le HAL IAuthSecret. IAR deviendra une exigence OBLIGATOIRE dans Android 14.

• 9.11.3 Identifiants d'identité : ajout d'informations sur la mise en œuvre de la référence du système Identifiants d'identité.

  Voir la révision

  Le système d'identifiants d'identité est défini et réalisé 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 les documents d'identité des utilisateurs. Implémentations pour les appareils:

  Le projet Open Source Android en amont fournit une implémentation de référence d'une application de confiance (libeic) pouvant être utilisée pour implémenter le système d'identification d'identité.

  Mettre fin aux nouvelles exigences

• 9.11.4 Attestation d'ID : ajout d'une section pour l'exigence d'attestation d'ID.

  Voir la révision

  9.11.4. Attestation d'identité

  Les implémentations d'appareils DOIVENT prendre en charge l'attestation d'ID.

  Mettre fin aux nouvelles exigences

• 9.17 Android Virtualization Framework : ajout d'une section sur les conditions requises pour le framework de virtualisation Android.

  Voir la révision

  9.17. Framework de virtualisation Android

  Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hôte Android:

  • [C-1-1] DOIT prendre en charge toutes les API définies par le package android.system.virtualmachine.*.
  • [C-1-2] NE DOIT PAS modifier le modèle d'autorisation ni le modèle SELinux Android pour la gestion des machines virtuelles protégées.
  • [C-1-3] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy fournis dans le projet Android Open Source (AOSP) en amont. De plus, la stratégie DOIT se compiler avec toutes les règles ne pas autoriser présentes.
  • [C-1-4] NE DOIT PAS autoriser du code non approuvé (applications tierces, par exemple) à créer et exécuter une machine virtuelle protégée. Remarque: Cela pourrait changer dans les prochaines versions d'Android.
  • [C-1-5] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter du code qui ne fait pas partie de l'image d'usine ou de ses mises à jour. Tout ce qui n'est pas couvert par le démarrage validé Android (par exemple, les fichiers téléchargés sur Internet ou téléchargés indépendamment) NE DOIT PAS être exécuté sur une machine virtuelle protégée.

  Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), toute instance de machine virtuelle protégée:

  • [C-2-1] DOIT pouvoir exécuter tous les systèmes d'exploitation disponibles dans l'apex de virtualisation au sein d'une machine virtuelle protégée.
  • [C-2-2] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter un système d'exploitation qui n'est pas signé par le responsable de l'implémentation de l'appareil ou le fournisseur de l'OS.
  • [C-2-3] NE DOIT PAS autoriser une machine virtuelle protégée à exécuter des données en tant que code (par exemple, SELinux n'autorise jamais execmem).
  • [C-2-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le système/sepolicy/microdroid fournis en amont dans le projet Android Open Source (AOSP).
  • [C-2-5] DOIT implémenter des mécanismes de défense en profondeur des machines virtuelles protégées (par exemple, SELinux pour les VM préemptives), même pour les systèmes d'exploitation autres que Microdroid.
  • [C-2-6] DOIT s'assurer que le micrologiciel de la VM préemptive refuse de démarrer s'il ne peut pas vérifier l'image initiale.
  • [C-2-7] DOIT s'assurer que le micrologiciel de la VM préemptive refuse de démarrer si l'intégrité du fichier instance.img est compromise.

  Si l'appareil est compatible avec les API du framework de virtualisation Android (android.system.virtualmachine.*), l'hyperviseur:

  • [C-3-1] NE DOIT PAS permettre à une pVM d'accéder à une page appartenant à une autre entité (c'est-à-dire une autre pVM ou un hyperviseur), sauf s'il est explicitement partagé par le propriétaire de la page. Cela inclut la VM hôte. Cela s'applique à la fois aux accès au processeur et à la zone de marché désignée.
  • [C-3-2] DOIT effacer une page après son utilisation par une VM et avant qu'elle ne soit renvoyée à l'hôte (par exemple, lorsque la pVM est détruite).
  • [C-3-3] DOIT s'assurer que le micrologiciel d'une pVM est chargé et exécuté avant tout code dans une pVM.
  • [C-3-4] DOIT s'assurer que le Cci et les IDC fournis à une instance de VM préemptive ne peuvent être dérivés que de cette instance particulière.

  Si l'appareil est compatible avec les API du framework de virtualisation Android, procédez comme suit dans tous les domaines:

  • [C-4-1] NE DOIT PAS fournir à une pVM une fonctionnalité permettant de contourner le modèle de sécurité Android.

  Si l'appareil est compatible avec les API du framework de virtualisation Android:

  • [C-5-1] DOIT prendre en charge la compilation isolée d'une mise à jour de l'environnement d'exécution ART.

  Si l'appareil prend en charge les API du framework de virtualisation Android, procédez comme suit pour la gestion des clés:

  • [C-6-1] DOIT utiliser la chaîne DICE racine à un point que l'utilisateur ne peut pas modifier, même sur des appareils déverrouillés. (pour éviter toute usurpation d'identité).
  • [C-6-2] DOIT effectuer le processus "DICE" correctement, c'est-à-dire fournir les valeurs correctes. Mais vous n'aurez peut-être pas besoin d'aller dans les moindres détails.

  Mettre fin aux nouvelles exigences

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android et demander des éclaircissements ou signaler des problèmes que vous pensez que le document ne couvre pas.