Définition de compatibilité Android 12

1. Introduction

Ce document énonce les exigences à respecter pour que les appareils soient compatibles avec Android 12.

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

Dans ce document, un "implémentateur d'appareils" ou "implémentateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 12. 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 12, les implémentations d'appareils DOIVENT respecter les exigences présentées dans cette définition de la compatibilité, y compris les documents incorporés par référence.

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

C'est pourquoi le projet Open Source Android est à la fois l'implémentation de référence et l'implémentation privilégiée d'Android. Il est vivement recommandé aux implémentateurs d'appareils de baser leurs implémentations dans la mesure du possible 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 réussir les tests logiciels deviendra beaucoup plus difficile. Il est de la responsabilité de l'implémentateur de garantir une compatibilité comportementale totale avec l'implémentation Android standard, y compris 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 auxquelles ce document fait référence sont dérivées directement ou indirectement du SDK Android et sont fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Toutes les informations techniques fournies dans les ressources associées dans ce document sont considérées comme faisant partie de cette définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

Toutes les autres exigences, qui s'appliquent universellement à toutes les implémentations d'appareils Android, sont listées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le nom "Exigences de base" dans ce document.

1.1.2. ID de la condition

Un ID de contrainte est attribué aux contraintes obligatoires.

• L'ID est attribué uniquement pour les exigences obligatoires.
• Les exigences FORTEMENT RECOMMANDÉES sont marquées comme [SR], mais aucun ID n'est attribué.
• L'ID se compose de trois parties : l'ID de type d'appareil, l'ID de condition et l'ID de l'exigence (par exemple, C-0-1).

Chaque ID est défini comme suit:

• ID de type d'appareil (voir 2. Types d'appareils)
  • C: Core (Conditions requises appliquées à toutes les implémentations d'appareils Android)
  • H: Appareil portable Android
  • T: Appareil Android Television
  • A: Implémentation d'Android Automotive
  • W: Implémentation de la montre Android
  • Onglet: Implémentation sur tablette Android
• ID de la condition
  • Lorsque l'exigence est inconditionnelle, cet ID est défini sur 0.
  • Lorsque l'exigence est conditionnelle, le nombre 1 est attribué à la première condition, et le nombre augmente de 1 dans la même section et pour le même type d'appareil.
• ID de la condition requise
  • Cet ID commence à 1 et augmente de 1 dans la même section et la même condition.

1.1.3. ID de l'exigence dans la section 2

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

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

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

2. Types d'appareils

Le projet Android Open Source fournit une pile logicielle pouvant être utilisée pour différents types d'appareils et facteurs de forme. Pour assurer la sécurité sur les appareils, la pile logicielle, y compris tout OS de remplacement ou toute implémentation de kernel alternatif, doit s'exécuter dans un environnement sécurisé, comme décrit dans la section 9 et ailleurs dans ce CDD. Il existe quelques types d'appareils dont l'écosystème de distribution d'applications est 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 de l'appareil

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

2.2. Exigences concernant les appareils portables

Un appareil Android portable désigne une implémentation d'appareil Android qui est 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 classées comme appareils portables si elles répondent à l'ensemble des critères suivants:

• disposer d'une source d'alimentation mobile, comme une batterie ;
• Avoir une taille d'écran physique en diagonale comprise entre 3,3 pouces (ou 2,5 pouces pour les implémentations d'appareils livrées avec le niveau d'API 29 ou version antérieure) et 8 pouces.

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

2.2.1. Matériel

Implémentations pour appareils mobiles:

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

• [7.1.1.3/H-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant de modifier la taille de l'écran (densité d'écran).

• [7.1.1.1/H-0-2] DOIT prendre en charge la composition GPU des tampons graphiques d'une taille au moins égale à la résolution la plus élevée de n'importe quel écran intégré.

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

• [7.1.1.1/H-1-1]* L'écran logique mis à la disposition des applications tierces doit mesurer au moins 5,08 cm sur les bords courts et 6,86 cm sur les bords longs. Les appareils livré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]* L'écran logique mis à la disposition des applications tierces doit mesurer au moins 6,9 cm sur le ou les côtés courts. Les appareils livré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 déclarent être compatibles avec les écrans HDR via Configuration.isScreenHdr() , elles:

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

Implémentations pour appareils mobiles:

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

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

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

Implémentations pour appareils mobiles:

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

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

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

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

• [7.3.3/H-2-1] DOIT signaler les mesures GNSS dès qu'elles sont détecté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-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0,2 mètre par seconde près, au moins 95% du temps.

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

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

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

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

Implémentations pour appareils mobiles:

• [7.3.11/H-SR-1] Recommandé pour prendre en charge le capteur de position à six degrés de liberté.
• [7.4.3/H] DOIT inclure la compatibilité avec le Bluetooth et le Bluetooth LE.

Si les implémentations d'appareils portables incluent un appareil photo logique qui liste les fonctionnalités à l'aide de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elles:

• [7.5.4/H-1-1] Le champ de vision (FOV) doit être normal par défaut et doit être compris entre 50 et 95 degrés.

Implémentations pour appareils mobiles:

• [7.6.1/H-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelées partition "/data").
• [7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsqu'il y a moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

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

• [7.6.1/H-1-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 416 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à qHD (par exemple, FWVGA).

• [7.6.1/H-2-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 592 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).

• [7.6.1/H-3-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 896 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).

• [7.6.1/H-4-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise des résolutions de frame buffer jusqu'à QHD (par exemple, QWXGA).

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

• [7.6.1/H-5-1] La mémoire disponible pour le kernel et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de tampon d'affichage jusqu'à qHD (par exemple, FWVGA).

• [7.6.1/H-6-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).

• [7.6.1/H-7-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).

• [7.6.1/H-8-1] La mémoire disponible pour le kernel 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 trame jusqu'à QHD (par exemple, QWXGA).

Notez que la "mémoire disponible pour le kernel 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 à des composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du kernel 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 de l'application (é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 pour les données privées de l'application (également appelée partition "/data").
• DOIT déclarer le commutateur de fonctionnalité android.hardware.ram.normal.

Si les implémentations d'appareils portables incluent au moins 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] Il est vivement recommandé de n'accepter que l'espace utilisateur 32 bits (applications et code système)

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

• [7.6.1/H-1-1] DOIT n'être compatible qu'avec une seule ABI (64 bits uniquement ou 32 bits uniquement).

Implémentations pour appareils mobiles:

• [7.6.2/H-0-1] NE DOIT PAS fournir un espace de stockage partagé d'application inférieur à 1 Go.
• [7.7.1/H] Un port USB compatible avec le mode périphérique DOIT être inclus.

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

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

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

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

Implémentations pour appareils mobiles:

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

Si les implémentations d'appareils portables sont capables de répondre à toutes les exigences de performances pour prendre en charge le mode VR et qu'elles le font, elles:

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

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

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

Fonction	Mappages	Contexte	Comportement
A	Page d'utilisation du HID: 0x0C Utilisation du HID: 0x0CD Clé du noyau: KEY_PLAYPAUSE Clé Android: KEYCODE_MEDIA_PLAY_PAUSE	Lecture des contenus multimédias	Entrée: appui bref Sortie: lecture ou pause
			Entrée: appui prolongé Sortie: lancement de la commande vocale Envoi :android.speech.action.VOICE_SEARCH_HANDS_FREE si l'appareil est verrouillé ou si son écran est éteint. Envoyerandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH dans le cas contraire
		Appel entrant	Entrée: appui bref Sortie: accepter l'appel
			Entrée: Appuyer de manière prolongée sur Sortie: Refuser l'appel
		Appel en cours	Entrée: appui bref Sortie: raccrocher
			Entrée: Appuyez de manière prolongée sur  Sortie: Couper ou réactiver le son du micro
B	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 du HID: 0x0C Utilisation du HID: 0x0EA Clé du noyau: KEY_VOLUMEDOWN Clé Android: VOLUME_DOWN	Lecture de contenus multimédias, Appel en cours	Entrée: appui court ou long Sortie: baisse le volume du système ou du casque
D	Page d'utilisation des périphériques HID: 0x0C Utilisation des périphériques 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 de l'insertion d'une prise, mais uniquement après que les interfaces audio USB et les points de terminaison ont été correctement énumérés afin d'identifier le type de terminal connecté.

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

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

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

• [7.8.2.2/H-3-1] DOIT diffuser l'intent ACTION_HEADSET_PLUG avec le paramètre supplémentaire "micro" défini sur 1.

Lorsque l'API AudioManager.getDevices() est appelée lorsque le périphérique USB est connecté, les éléments suivants sont effectués:

• [7.8.2.2/H-4-1] DOIT lister 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 lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSink() si le champ de type de terminal audio USB est 0x0402.

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

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

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

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

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

• [7.8.2.2/H-SR-1] FORTEMENT RECOMMANDÉ 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(#56_audio-latency)/H-1-1] La latence aller-retour moyenne continue doit être de 800 ms ou moins sur cinq mesures, avec une déviation absolue moyenne inférieure à 100 ms, sur au moins un chemin pris en charge.

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 (ERM).
• [7.10/H]* L'emplacement de l'actionneur DOIT se trouver à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
• [7.10/H]* DOIT implémenter toutes les constantes publiques pour les haptiques claires dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START et GESTURE_END).
• [7.10/H]* DOIT implémenter toutes les constantes publiques pour les haptiques claires dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques pour les haptiques riches dans android.os.VibrationEffect.Composition, à savoir (PRIMITIVE_CLICK et PRIMITIVE_TICK).
• [7.10/H]* : VOUS DEVEZ utiliser ces mappages de constantes haptiques associées.
• [7.10/H]* DOIT suivre une évaluation de la qualité pour les API createOneShot() et createWaveform().
• [7.10/H]* VÉRIFIE les fonctionnalités de la scalabilité de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

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

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

• [7.10/H]* L'actionneur haptique doit déplacer l'axe X en mode portrait.

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

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

Si les implémentations d'appareils portables suivent la mise en correspondance des constantes haptiques, elles:

• [7.10/H]* VÉRIFIEZ L'ÉTAT DE L'Implémentation EN ÉCÉRANT LES API android.os.Vibrator.areAllEffectsSupported() ET android.os.Vibrator.arePrimitvesSupported().
• [7.10/H]* : DOIT effectuer une évaluation de la qualité pour les constantes haptiques.
• [7.10/H]* DOIT fournir une prise en charge de secours pour atténuer le risque de défaillance, comme décrit ici.

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 latence amélioré)

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

2.2.3. Logiciel

Implémentations pour appareils mobiles:

• [3.2.3.1/H-0-1] Une application doit gérer 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 la possibilité d'accéder aux données du fournisseur de documents à l'aide de l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* : DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
• [3.2.3.1/H-SR-1] Nous vous RECOMMANDONS vivement 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 des utilisateurs.
• [3.8.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut compatible avec l'épinglage de raccourcis, de widgets et de widgetFeatures dans l'application.
• [3.8.1/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
• [3.8.1/H-SR-3] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lanceur par défaut qui affiche des badges pour les icônes d'application.
• [3.8.2/H-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les widgets d'applications tierces.
• [3.8.3/H-0-1] DOIT autoriser les applications tierces à avertir les utilisateurs d'événements notables via les classes d'API Notification et NotificationManager.
• [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
• [3.8.3/H-0-3] DOIT prendre en charge les notifications heads-up.
• [3.8.3/H-0-4] DOIT inclure une barre de notification, qui permet à l'utilisateur de contrôler directement (par exemple, répondre, répéter, ignorer, bloquer) les notifications via des affordances utilisateur telles que des boutons d'action ou le panneau de configuration tel qu'implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les choix fournis 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 la barre de notification sans interaction utilisateur supplémentaire.
• [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 le volet des notifications.
• [3.8.3.1/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true en ligne avec les réponses affichées par Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

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

• [3.8.4/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser l'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 des alertes et des notifications silencieuses non conversationnelles, elles:

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

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

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

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

• [3.9/H-1-1] DOIT implémenter l'ensemble des stratégies 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 permettent aux applications tierces de publier des commandes d'appareil, 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 à l'utilisateur une affordance lui permettant d'ajouter, de modifier, de sélectionner et d'utiliser les commandes d'appareil préférées de l'utilisateur à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control.
• [3.8.16/H-1-3] DOIT fournir un accès à cette affordance utilisateur dans les trois interactions à partir d'un lanceur 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.

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

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

Implémentations pour appareils mobiles:

• [3.10/H-0-1] DOIT prendre en charge les services d'accessibilité tiers.
• [3.10/H-SR-1] Il est FORTEMENT RECOMMANDÉ-1 de précharger des services d'accessibilité sur l'appareil comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source talkback.
• [3.11/H-0-1] DOIT prendre en charge l'installation de moteurs TTS 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'UI des paramètres rapides.

Si les implémentations d'appareils portables Android déclarent la prise en charge de FEATURE_BLUETOOTH ou de FEATURE_WIFI, elles:

• [3.16/H-1-1] DOIT prendre en charge la fonctionnalité d'association de l'appareil associé.

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

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

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

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

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé et disposent de 2 Go de mémoire ou plus disponibles 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 l'indicateur de fonctionnalité android.software.managed_users.

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

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

2.2.4. Performances et puissance

• [8.1/H-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIT PAS se produire plus de cinq fois par seconde et DOIT être inférieur à une fois par seconde.
• [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
• [8.1/H-0-3] Changement de tâche. 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 appareils mobiles:

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

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

• [8.3/H-1-1] DOIT fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
• [8.3/H-1-2] L'application DOIT fournir une affordance permettant à l'utilisateur d'afficher toutes les applications exemptées des modes d'économie d'énergie App Standby et Doze.

Implémentations pour appareils mobiles:

• [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [8.4/H-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (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] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.
• [8.4/H] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

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

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

2.2.5. Modèle de sécurité

Implémentations pour appareils mobiles:

• [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 appareils mobiles:

• [9.11/H-0-2] L'implémentation du keystore doit être sauvegardée avec un environnement d'exécution isolé.
• [9.11/H-0-3] DOIT inclure des implémentations des algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du 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 le DMA. Le projet Android Open Source Project (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 examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [9.11/H-0-4] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, uniquement en cas de réussite, autoriser l'utilisation des clés liées à l'authentification. 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 Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/H-0-5] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme 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 une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore compatible avec 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] L'appareil DOIT permettre à l'utilisateur de choisir le délai de mise en veille le plus court, c'est-à-dire la durée de transition entre l'état déverrouillé et l'état verrouillé, qui doit être de 15 secondes ou moins.
• [9.11/H-1-2] DOIT fournir à l'utilisateur la possibilité de masquer les notifications et de désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans la section 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond à cette exigence en tant que mode blocage.

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

• [9.5/H-2-1] DOIT prendre en charge les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et 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 l'indicateur de fonctionnalité android.hardware.telephony, elles:

• [9.5/H-3-1] NE DOIT PAS prendre en charge les profils restreints, mais DOIT respecter l'implémentation des commandes AOSP pour autoriser /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 des mots clés toujours activé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 mots clés sans indication d'accès au micro, elles:

• [9.8/H-1-1] DOIT s'assurer que le service de détection des mots clés ne peut transmettre des données qu'au système ou au ContentCaptureService
• [9.8/H-1-2] Le service de détection de mot clé DOIT s'assurer que le service de détection de mot clé 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 d'audio du micro de plus de 30 secondes pour une requête individuelle déclenchée par du matériel au service de détection de mot clé.
• [9.8/H-1-4] NE DOIT PAS fournir d'audio de micro tamponné datant de plus de huit secondes pour une requête individuelle au service de détection de mots clés.
• [9.8/H-1-5] NE DOIT PAS fournir d'audio du micro tamponné datant 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 en dehors du service de détection de mot clé pour chaque résultat de mot clé réussi.
• [9.8/H-1-7] NE DOIT PAS autoriser la transmission de plus de cinq bits de données en dehors du service de détection de mot clé pour chaque résultat de mot clé négatif.
• [9.8/H-1-8] Le service de détection des mots clés DOIT uniquement autoriser la transmission de données en dehors du service de détection des mots clés sur une requête de validation de mot clé provenant du serveur système.
• [9.8/H-1-9] Une application installable par l'utilisateur NE DOIT PAS fournir le service de détection de mots clés.
• [9.8/H-1-10] Les données quantitatives sur l'utilisation du micro par le service de détection de mot clé NE DOIVENT PAS s'afficher dans l'UI.
• [9.8/H-1-11] DOIT consigner le nombre d'octets inclus dans chaque transmission du service de détection des mots clés pour permettre aux chercheurs en sécurité de l'inspecter.
• [9.8/H-1-12] DOIT prendre en charge un mode débogage qui consigne le contenu brut de chaque transmission du service de détection des mots clés pour permettre aux chercheurs en sécurité de l'inspecter.
• [9.8/H-1-13] DOIT redémarrer le processus hébergeant le service de détection des 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 éventualité.
• [9.8/H-1-14] DOIT afficher l'indicateur du micro, comme décrit dans la section 9.8.2, lorsqu'un résultat de mot clé est transmis au service d'interaction vocale ou à une entité similaire.
• [9.8/H-SR-1] Il est vivement recommandé d'informer les utilisateurs avant de définir une application comme fournisseur du service de détection de mots clés.
• [9.8/H-SR-2] Il est FORTEMENT RECOMMANDÉ d'interdire la transmission de données non structurées en dehors du service de détection de mots clés.

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

• [9.8/H-2-1] L'utilisateur doit être informé explicitement de chaque phrase de mot clé compatible.
• [9.8/H-2-2] NE DOIT PAS conserver les données audio brutes ni les données dérivées via le service de détection de mot clé.
• [9.8/H-2-3] Le service de détection de mot clé NE DOIT PAS transmettre à partir du service de détection de mot clé des données audio, des données pouvant être utilisées pour reconstruire (entièrement ou partiellement) l'audio, ou des contenus audio sans rapport avec le mot clé lui-même, sauf à l'ContentCaptureService.

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

• [9.8.2/H-4-1] L'indicateur du micro DOIT s'afficher 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 les applications disposant des rôles mentionnés dans la section 9.1 avec l'identifiant CDD [C-4-X]. .
• [9.8.2/H-4-2] DOIT afficher la liste des applications récentes et actives qui utilisent le micro, comme indiqué dans PermissionManager.getIndicatorAppOpUsageData(), ainsi que les messages d'attribution qui leur sont associés.
• [9.8.2/H-4-3] L'indicateur du micro ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.
• [9.8.2/H-4-4] DOIT afficher la liste des applications récentes et actives qui utilisent le micro, comme indiqué par PermissionManager.getIndicatorAppOpUsageData(), ainsi que 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] L'indicateur de la caméra DOIT s'afficher lorsqu'une application accède aux données de la caméra en direct, mais pas lorsque la caméra n'est accessible que par une ou plusieurs applications disposant des rôles indiqués dans la section 9.1 avec l'identifiant CDD [C-4-X].
• [9.8.2/H-5-2] DOIT afficher les applications récentes et actives à l'aide de la caméra, comme indiqué par PermissionManager.getIndicatorAppOpUsageData(), ainsi que les messages d'attribution qui leur sont associés.
• [9.8.2/H-5-3] L'indicateur de l'appareil photo ne doit PAS être masqué pour les applications système qui disposent d'une interface utilisateur visible ou d'une interaction directe avec l'utilisateur.

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

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

• [6.1/H-0-1]* : la commande shell cmd testharness doit être prise en charge.

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

• Perfetto
  • [6.1/H-0-2]* DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto.
  • [6.1/H-0-3]* Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
  • [6.1/H-0-4]* Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation de perfetto.
  • [6.1/H-0-5]* : le binaire perfetto doit fournir 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 sur les appareils portables

Pour en savoir plus sur la classe de performances multimédias, consultez la section 7.11.

2.2.7.1. Contenus multimédias

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.R pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• DOIT respecter les exigences multimédias listées dans la section 2.2.7.1 du CDD Android 11.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matériel pouvant s'exécuter 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ériel (AVC, HEVC, VP9* ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément à une résolution de 720p à 30 FPS. *Seules deux instances sont requises si le codec VP9 est présent.
• [5.1/H-1-3] DOIT annoncer le nombre maximal de sessions d'encodeur vidéo matériel pouvant s'exécuter 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* ou version ultérieure) dans n'importe quelle combinaison de codecs exécutée simultanément en résolution 720p à 30 FPS. *Seuls deux instances sont requises si le codec VP9 est présent.
• [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 et d'encodeur vidéo matériels (AVC, HEVC, VP9* ou version ultérieure) dans n'importe quelle combinaison de codecs exécutés simultanément à une résolution de 720p à 30 fps. *Seuls deux instances sont requises si le codec VP9 est présent.
• [5.1/H-1-7] La latence d'initialisation du codec doit être de 50 ms maximum pour une session d'encodage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels (à l'exception du codec Dolby Vision) en charge. La charge est ici définie comme une session de transcodage vidéo uniquement en 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo en 1080p.
• [5.1/H-1-8] La latence d'initialisation du codec doit être de 40 ms ou moins pour une session d'encodage audio de 128 kbit/s ou moins pour tous les encodeurs audio en charge. La charge est ici définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo 1080p.
• [5.3/H-1-1] NE DOIT PAS perdre plus de deux images en 10 secondes (c'est-à-dire moins de 0,333 % de perte d'images) pour une session vidéo 1080p 60 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement de 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC à 128 kbps.
• [5.3/H-1-2] NE DOIT PAS perdre plus de deux images en 10 secondes lors d'un changement de résolution vidéo dans une session vidéo à 60 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC à 128 kbps.
• [5.6/H-1-1] La latence de la fonctionnalité de pression pour un son doit être inférieure à 100 millisecondes à l'aide du test de la fonctionnalité de pression pour un son OboeTester ou du test de la fonctionnalité de pression pour un son du vérificateur CTS.

2.2.7.2. Appareil photo

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.R pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• DOIT respecter les exigences concernant l'appareil photo listées dans la section 2.2.7.2 du CDD Android 11

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• [7.5/H-1-1] L'appareil doit comporter une caméra principale à l'arrière avec une résolution d'au moins 12 mégapixels, compatible avec la capture vidéo en 4K à 30 fps. La caméra arrière principale est la caméra arrière dont l'ID est le plus bas.
• [7.5/H-1-2] L'appareil doit comporter une caméra avant principale d'une résolution d'au moins 5 mégapixels et prendre en charge la capture vidéo en 1080p à 30 FPS. La caméra avant principale est la caméra avant dont l'ID est le plus bas.
• [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel en tant que FULL ou version ultérieure pour la caméra principale arrière et LIMITED ou version ultérieure pour la caméra principale avant.
• [7.5/H-1-4] DOIT être compatible avec CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux caméras principales.
• [7.5/H-1-5] La latence de capture JPEG camera2 doit être inférieure à 1 000 ms pour une résolution de 1080p, comme mesuré par le test de performances de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) pour les deux caméras principales.
• [7.5/H-1-6] La latence de démarrage de camera2 (ouverture de la caméra au premier frame d'aperçu) DOIT être inférieure à 600 ms, comme mesuré par le test de performances 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 être compatible avec CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW et android.graphics.ImageFormat.RAW_SENSOR pour la caméra arrière principale.

2.2.7.3. Matériel

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.R pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• DOIT respecter les exigences matérielles indiquées dans la section 2.2.7.3 du CDD Android 11.

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• [7.1.1.1/H-2-1] La résolution d'écran doit être d'au moins 1 080p.
• [7.1.1.3/H-2-1] La densité d'écran doit être d'au moins 400 ppp.
• [7.6.1/H-2-1] L'ordinateur doit disposer d'au moins 6 Go de mémoire physique.

2.2.7.4. Performances

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.R pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• DOIT respecter les exigences de performances listées dans la section 2.2.7.4 du CDD Android 11

Si les implémentations d'appareils portables renvoient android.os.Build.VERSION_CODES.S pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

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

2.3. Exigences concernant les téléviseurs

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

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

• Vous avez fourni un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur un écran situé à 3 mètres de l'utilisateur.
• Avoir un écran intégré dont la diagonale est supérieure à 60 cm OU inclure un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.

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

2.3.1. Matériel

Implémentations d'appareils TV:

• [7.2.2/T-0-1] La croix directionnelle doit être prise en charge.
• [7.2.3/T-0-1] DOIT fournir les fonctions "Accueil" et "Retour".
• [7.2.3/T-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK).
• [7.2.6.1/T-0-1] DOIT inclure la prise en charge des manettes de jeu et déclarer le flag de fonctionnalité android.hardware.gamepad.
• [7.2.7/T] DOIT fournir une télécommande à partir de laquelle les utilisateurs peuvent accéder à la navigation non tactile et aux entrées des principales touches de navigation.

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

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

Implémentations d'appareils TV:

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

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

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

Si les implémentations de l'appareil TV sont 32 bits:

• [7.6.1/T-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée:

  • 400 dpi ou plus sur les écrans de petite/moyenne taille
  • xhdpi ou version ultérieure sur les grands écrans
  • tvdpi ou version ultérieure sur les écrans très grands

Si les implémentations de l'appareil TV sont 64 bits:

• [7.6.1/T-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée:

  • 400 dpi ou plus sur les écrans de petite/moyenne taille
  • xhdpi ou version ultérieure sur les grands écrans
  • tvdpi ou version ultérieure sur les écrans très grands

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

Implémentations d'appareils TV:

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

2.3.2. Multimédia

Les implémentations d'appareils de télévision DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces:

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

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

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

Implémentations d'appareils TV:

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

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

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

Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage MPEG-2, comme indiqué dans la section 5.3.1, à des fréquences d'images et résolutions vidéo standards jusqu'à:

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

Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage H.264, comme indiqué dans la section 5.3.4, à des fréquences d'images et résolutions vidéo standards jusqu'à:

• [5.3.4/T-1-1] HD 1080p à 60 images par seconde avec le 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 Level 4.2

Les implémentations d'appareils de télévision avec des décodeurs matériels H.265 DOIVENT prendre en charge le décodage H.265, comme indiqué dans la section 5.3.5, aux fréquences d'images et résolutions vidéo standards 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 d'appareils de télévision avec des décodeurs matériels H.265 prennent en charge 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 Main10 de niveau 5

Les implémentations d'appareils de télévision DOIVENT prendre en charge le décodage VP8, comme indiqué dans la section 5.3.6, à des fréquences d'images et résolutions vidéo standards jusqu'à:

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

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

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

Si les implémentations d'appareils de télévision 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-2-1] 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 10 bits).

Implémentations d'appareils TV:

• [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 de passthrough audio compressé (où aucun décodage audio n'est effectué sur l'appareil).

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

• [5.8/T-0-1] DOIT définir le mode de sortie HDMI pour sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou 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] LE MODÈLE DOIT 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 vidéo de la région dans laquelle l'appareil est vendu.

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

• [5.8/T-1-1] La prise en charge de la norme HDCP 2.2 est OBLIGATOIRE.

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

• [5.8/T-2-1] DOIT prendre en charge HDCP 1.4

2.3.3. Logiciel

Implémentations d'appareils TV:

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

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

Implémentations d'appareils TV:

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

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

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

Implémentations d'appareils TV:

• [3.12/T-0-1] DOIT prendre en charge le TV Input Framework.

2.3.4. Performances et puissance

• [8.1/T-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIT PAS se produire plus de cinq fois par seconde et DOIT être inférieur à une fois par seconde.
• [8.2/T-0-1] DOIT assurer 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 assurer des performances de lecture séquentielle d'au moins 15 Mo/s.
• [8.2/T-0-4] DOIT assurer des performances de lecture aléatoire d'au moins 3,5 Mo/s.

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

• [8.3/T-1-1] DOIT fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.

Si les implémentations d'appareils de télévision ne disposent pas de batterie:

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

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

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

Implémentations d'appareils TV:

• [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (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 si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
• [8.4/T-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.3.5. Modèle de sécurité

Implémentations d'appareils TV:

• [9.11/T-0-1] L'implémentation du keystore DOIT être sauvegardée avec un environnement d'exécution isolé.
• [9.11/T-0-2] DOIT inclure des implémentations des algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du 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 le DMA. Le projet Android Open Source Project (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 examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, uniquement en cas de réussite, autoriser l'utilisation des clés liées à l'authentification. 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 Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/T-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme 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 une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore compatible avec un environnement d'exécution isolé.

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

• [9.11/T-1-1] L'appareil 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 minimal autorisé de 15 secondes ou moins.

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

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

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

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

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

• [9.8.2/T-4-1] L'indicateur du micro DOIT s'afficher 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 les applications disposant des rôles mentionnés dans la section 9.1 sur les autorisations avec l'identifiant CDD C-3-X].
• [9.8.2/T-4-2] L'indicateur du micro ne doit PAS être masqué pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions directes avec l'utilisateur.

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

• [9.8.2/T-5-1] DOIT afficher l'indicateur de caméra lorsqu'une application accède aux données de la caméra en direct, mais pas lorsque la caméra n'est accessible que par une ou plusieurs applications disposant des rôles indiqués dans la section 9.1 Autorisations avec l'identifiant CDD [C-3-X].
• [9.8.2/T-5-2] L'indicateur de la caméra ne doit PAS être masqué pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions directes avec l'utilisateur.

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

Implémentations d'appareils TV:

• Perfetto
  • [6.1/T-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto.
  • [6.1/T-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
  • [6.1/T-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation 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

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

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

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

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

2.4.1. Matériel

Implémentations d'appareils de montre:

• [7.1.1.1/W-0-1] L'écran doit avoir une diagonale physique comprise entre 1,1 et 2,5 pouces.

• [7.2.3/W-0-1] La fonction "Accueil" doit être disponible pour l'utilisateur, ainsi que la fonction "Retour", sauf lorsqu'il se trouve dans UI_MODE_TYPE_WATCH.

• [7.2.4/W-0-1] DOIT prendre en charge la saisie par écran tactile.

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

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

• [7.3.3/W-1-1] DOIT signaler les mesures GNSS dès qu'elles sont détecté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-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0,2 mètre par seconde près, au moins 95% du temps.

Si les implémentations d'appareils Watch incluent un gyroscope à trois 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 des appareils de visionnage:

• [7.4.3/W-0-1] DOIT prendre en charge la technologie Bluetooth.

• [7.6.1/W-0-1] Au moins 1 Go de stockage non volatile doit être disponible pour les données privées de l'application (également appelée partition "/data").

• [7.6.1/W-0-2] Le noyau et l'espace utilisateur doivent disposer d'au moins 416 Mo de mémoire.

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

• [7.8.2/W] Peut avoir une sortie audio.

2.4.2. Multimédia

Aucune autre condition requise.

2.4.3. Logiciel

Implémentations des appareils de visionnage:

• [3/W-0-1] VOUS DEVEZ 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 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.

Implémentations des appareils de visionnage:

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

Observez les implémentations d'appareils qui déclarent l'option 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 supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), comme indiqué dans le projet Open Source talkback.

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

• [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 prendre en charge l'installation de moteurs TTS tiers.

2.4.4. Performances et puissance

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

• [8.3/W-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.
• [8.3/W-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.

Implémentations des appareils de visionnage:

• [8.4/W-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [8.4/W-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (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] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.
• [8,4 W] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

2.4.5. Modèle de sécurité

Implémentations des appareils de visionnage:

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

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

• [9.5/W-1-1] DOIT prendre en charge les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

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

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

2.5. Exigences pour le secteur automobile

L'implémentation d'Android Automotive désigne une unité principale de véhicule exécutant Android comme système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'infodivertissement.

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

• Ils sont intégrés à un véhicule automobile ou peuvent y être branchés.
• Utilise un écran sur la rangée du siège conducteur comme écran principal.

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

2.5.1. Matériel

Implémentations d'appareils automobiles:

• [7.1.1.1/A-0-1] L'écran doit mesurer au moins 6 pouces de diagonale physique.

• [7.1.1.1/A-0-2] La mise en page de la taille de l'écran doit être d'au moins 750 dp x 480 dp.

• [7.2.3/A-0-1] DOIT fournir la fonction Accueil et PEUT fournir les fonctions Retour et Récents.

• [7.2.3/A-0-2] DOIT envoyer à l'application de premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK).

• [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 lumière ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.

• [7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires sur le capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.

• [7.3/A-0-1] PEUT calculer la position par triangulation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est déterminée par calcul, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants.

• [7.3/A-0-2] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être mise en correspondance avec la carte.

Si les implémentations d'appareils Automotive 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 Automotive incluent un accéléromètre à trois axes, elles:

• [7.3.1/A-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
• [7.3.1/A-1-2] DOIT respecter le système de coordonnées des capteurs de voiture Android.

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

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

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

• [7.3.3/A-3-1] Le récepteur GPS/GNSS doit déterminer la position la toute première fois qu'il est allumé ou après quatre jours ou plus, dans un délai de 60 secondes.
• [7.3.3/A-3-2] DOIT respecter les critères de temps de première correction décrits dans 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres requêtes de localisation (c'est-à-dire les requêtes qui ne sont pas la première fois ou après plus de quatre jours). L'exigence 7.3.3/C-1-2 est généralement remplie dans les véhicules sans connectivité de données basée sur un réseau mobile, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule avec la possibilité de calculer une position estimée pendant au moins 60 secondes avec une précision de position satisfaisant aux exigences de la section 7.3.3/C-1-3, ou une combinaison des deux.

Implémentations d'appareils automobiles:

• [7.4.3/A-0-1] DOIT prendre en charge le Bluetooth et DOIT prendre en charge le Bluetooth LE.
• [7.4.3/A-0-2] Les implémentations Android Auto doivent prendre en charge les profils Bluetooth suivants :
  • Appels téléphoniques via le profil mains libres (HFP)
  • Lecture de contenus multimédias via le profil de distribution audio (A2DP)
  • Contrôle de la lecture de contenus multimédias via le profil de télécommande (AVRCP).
  • Partage de contacts à l'aide du profil d'accès au carnet d'adresses (PBAP)

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

• [7.4.5/A] DOIT 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 doivent être disponibles pour les applications système.

Une caméra extérieure est une caméra qui image des scènes en dehors de l'implémentation de l'appareil, comme une caméra embarquée.

Implémentations d'appareils automobiles:

• DOIT inclure une ou plusieurs caméras extérieures.

Si les implémentations d'appareils Automotive incluent une caméra extérieure, elles doivent:

• [7.5/A-1-1] Les caméras extérieures ne doivent PAS être accessibles via les API de l'appareil photo Android, sauf si elles respectent les exigences de base de l'appareil photo.
• [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter ni mettre en miroir horizontalement l'aperçu de l'appareil photo.
• [7.5.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de les orienter de sorte que la dimension longue de la caméra soit alignée sur l'horizon.
• [7.5/A-SR-2] Il est vivement recommandé d'avoir une résolution d'au moins 1,3 mégapixels.
• DOIT disposer d'un matériel à mise au point fixe ou à champ d'image étendu (EDOF, extended depth of field).
• DOIT être compatible avec le framework de synchronisation Android.
• Le pilote de la caméra peut implémenter le mode autofocus matériel ou logiciel.

Implémentations d'appareils automobiles:

• [7.6.1/A-0-1] DOIT disposer d'au moins 4 Go d'espace de stockage non volatile pour les données privées de l'application (également appelée partition "/data").

• [7.6.1/A] DOIT formater la partition de données pour améliorer les performances et la longévité du stockage flash, par exemple à l'aide du système de fichiers f2fs.

Si les implémentations d'appareils Automotive fournissent un stockage externe partagé via une partie de l'espace de stockage interne non amovible, elles:

• [7.6.1/A-SR-1] FORTEMENT RECOMMANDÉ pour réduire les coûts 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 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 dpi ou moins sur les écrans de petite/moyenne taille
  • ldpi ou moins sur les écrans très grands formats
  • mdpi ou moins 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 version ultérieure sur les écrans de petite/moyenne taille
  • hdpi ou version ultérieure sur les grands écrans
  • mdpi ou plus sur les écrans très grands

• [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 dpi ou plus sur les écrans de petite/moyenne taille
  • xhdpi ou version ultérieure sur les grands écrans
  • tvdpi ou version ultérieure sur les écrans très grands

• [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 dpi ou plus sur les écrans de petite/moyenne taille
  • 400 dpi ou plus sur les grands écrans
  • xhdpi ou version ultérieure sur les écrans très grands

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 dpi ou moins sur les écrans de petite/moyenne taille
  • ldpi ou moins sur les écrans très grands formats
  • mdpi ou moins 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 version ultérieure sur les écrans de petite/moyenne taille
  • hdpi ou version ultérieure sur les grands écrans
  • mdpi ou plus sur les écrans très grands

• [7.6.1/A-2-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée:

  • 400 dpi ou plus sur les écrans de petite/moyenne taille
  • xhdpi ou version ultérieure sur les grands écrans
  • tvdpi ou version ultérieure sur les écrans très grands

• [7.6.1/A-2-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'une des densités suivantes est utilisée:

  • 560 dpi ou plus sur les écrans de petite/moyenne taille
  • 400 dpi ou plus sur les grands écrans
  • xhdpi ou version ultérieure sur les écrans très grands

Notez que la "mémoire disponible pour le kernel 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 à des composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du kernel sur les implémentations d'appareils.

Implémentations d'appareils automobiles:

• [7.7.1/A] Un port USB compatible avec le mode périphérique DOIT être inclus.

Implémentations d'appareils automobiles:

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

Implémentations d'appareils automobiles:

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

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 des applications tierces:

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

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

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

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

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

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

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

2.5.3. Logiciel

Implémentations d'appareils automobiles:

• [3/A-0-1] La fonctionnalité android.hardware.type.automotive DOIT être déclarée.

• [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 à l'aide de android.car.CarPropertyManager avec android.car.VehiclePropertyIds, elles:

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

Implémentations d'appareils automobiles:

• [3.2.1/A-0-1] DOIT prendre en charge et appliquer toutes les constantes d'autorisation, comme indiqué sur la page de référence sur les 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 les notifications qui utilisent l'API Notification.CarExtender lorsqu'elles sont demandées par des applications tierces.

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

Si les implémentations d'appareils Automotive incluent un bouton PTT:

• [3.8.4/A-1-1] DOIT utiliser un appui bref sur le bouton PTT comme interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService.

Implémentations d'appareils automobiles:

• [3.8.3.1/A-0-1] DOIT afficher correctement les ressources, comme décrit dans la documentation du SDK Notifications on Automotive OS.
• [3.8.3.1/A-0-2] DOIT afficher "PLAY" (LECTURE) et "MUTE" (COUPE-SON) pour les actions de notification à la place de celles fournies via Notification.Builder.addAction().
• [3.8.3.1/A] DOIT limiter l'utilisation de tâches de gestion avancées telles que les commandes par canal de notification. PEUT utiliser l'affordance de l'interface utilisateur par application pour réduire les commandes.

Si les implémentations d'appareils Automotive sont compatibles avec les propriétés HAL 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 d'appareils automobiles:

• [3.14/A-0-1] DOIT inclure un framework d'UI pour prendre en charge les applications tierces qui utilisent les API multimédias, comme décrit dans la section 3.14.
• [3.14/A-0-2] L'application DOIT permettre à l'utilisateur d'interagir de manière sécurisée avec les applications multimédias lorsqu'il conduit.
• [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 permettant d'accéder à l'activité de préférences d'une application multimédia, mais DOIT uniquement l'activer lorsque les restrictions liées à l'expérience utilisateur du véhicule ne sont pas en vigueur.
• [3.14/A-0-5] DOIT afficher les messages d'erreur définis par les applications multimédias et DOIT prendre en charge les éléments 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 avec la recherche.
• [3.14/A-0-7] DOIT respecter les définitions de CONTENT_STYLE_BROWSABLE_HINT et de CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de la hiérarchie MediaBrowser.

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

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

Implémentations d'appareils automobiles:

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

2.5.4. Performances et puissance

Implémentations d'appareils automobiles:

• [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans l'espace de stockage non volatile par UID de chaque processus afin que les statistiques soient disponibles pour les développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Open Source Android 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] Le véhicule DOIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf si :
  • La batterie est déchargée.
  • Aucune tâche inactive n'est planifiée.
  • 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 pour chaque composant matériel et l'épuisement approximatif de la batterie causé 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-heure (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 si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
• [8.4/A-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

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

• [9.5/A-1-1] Le système NE DOIT PAS permettre aux utilisateurs d'interagir avec l'utilisateur du système sans tête ni de passer à cet utilisateur, sauf pour le provisionnement de l'appareil.
• [9.5/A-1-2] L'utilisateur DOIT passer à un utilisateur secondaire avant BOOT_COMPLETED.
• [9.5/A-1-3] L'application DOIT permettre de créer un utilisateur invité, même lorsque le nombre maximal d'utilisateurs sur un appareil a été atteint.

Implémentations d'appareils automobiles:

• [9.11/A-0-1] L'implémentation du keystore DOIT être sauvegardée avec un environnement d'exécution isolé.
• [9.11/A-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du 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 le DMA. Le projet Android Open Source Project (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 examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [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 que si l'authentification aboutit. 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 Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/A-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme 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 une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore compatible avec un environnement d'exécution isolé.

Implémentations d'appareils automobiles:

• [9.14/A-0-1] DOIT contrôler les messages provenant des sous-systèmes du véhicule du framework Android, par exemple en ajoutant à la liste d'autorisation les types et sources de messages autorisés.
• [9.14/A-0-2] Le moniteur doit empêcher les attaques de déni de service provenant du framework Android ou d'applications tierces. Cela permet de se protéger contre les logiciels malveillants qui inondent le réseau du véhicule de trafic, ce qui peut entraîner un dysfonctionnement des sous-systèmes du véhicule.

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

Implémentations d'appareils automobiles:

• Perfetto
  • [6.1/A-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto.
  • [6.1/A-0-2] Le binaire perfetto DOIT accepter en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
  • [6.1/A-0-3] Le binaire perfetto DOIT écrire en sortie une trace protobuf conforme au schéma défini dans la documentation 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 la tablette

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

• À utiliser en le tenant dans les deux mains.
• Ne propose pas de configuration en mode clamshell ou convertible.
• Les implémentations de clavier physique utilisées avec l'appareil se connectent via une connexion standard (par exemple, USB, Bluetooth).
• dispose d'une source d'alimentation qui permet de le déplacer, comme une batterie ;
• La taille de l'écran est supérieure à 7 pouces et inférieure à 18 pouces, mesurée en diagonale.

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

2.6.1. Matériel

Gyroscope

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

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

Mémoire et stockage minimums (section 7.6.1)

Les densités d'écran indiquées pour les écrans petits/normaux 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 d'appareils de tablette incluent un port USB compatible avec le mode périphérique, elles:

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

Mode réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences liées à 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 d'appareils de tablette incluent plusieurs utilisateurs et ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony, elles:

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

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

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

2.6.2. Logiciel

• [3.2.3.1/Tab-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. Logiciel

3.1. Compatibilité avec les API gérées

L'environnement d'exécution de bytecode Dalvik géré est le principal moyen de transport des applications Android. L'API Android est l'ensemble d'interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré.

Implémentations de l'appareil:

• [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 de toute API décorée avec le repère "@SystemApi" dans le code source Android en amont.

• [C-0-2] DOIT prendre en charge/conserver toutes les classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).

• [C-0-3] NE DOIT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.

• [C-0-4] DOIT toujours conserver les API et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. 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 chemin d'accès au chemin d'exécution de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation @hide, mais pas avec un @SystemAPI, comme décrit dans les documents du SDK, ainsi que les membres de classe privés et privés par package.

• [C-0-6] DOIT être fourni avec chaque interface non SDK dans les mêmes listes limitées que celles fournies via les indicateurs provisoires et de liste de refus 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 autres que SDK d'une liste restreinte en insérant la configuration signée dans n'importe quel APK, à l'aide des clés publiques existantes présentes dans AOSP.

  Toutefois, ils:

  • PEUT, si une API masquée est absente ou implémentée différemment dans l'implémentation de l'appareil, placer l'API masquée dans la liste de blocage ou l'omettre de toutes les listes de restriction.
  • PEUT, si une API masquée n'existe pas déjà dans l'AOSP, ajouter l'API masquée à l'une des listes de restriction.

3.1.1. Extensions Android

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

Implémentations d'appareils Android:

• [C-0-1] DOIT précharger l'implémentation AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, les implémentations d'appareils Android 7.0 exécutant le niveau d'API 24 DOIVENT inclure au moins la version 1.

• [C-0-2] DOIT uniquement renvoyer un numéro de version d'extension valide 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 bootclasspath.
• [C-0-2] Vous devez ajouter la bibliothèque org.apache.http.legacy au chemin d'accès des classes de l'application uniquement lorsque l'application remplit l'une des conditions suivantes :
  • Cible le niveau d'API 28 ou inférieur.
  • Déclarer 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.

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

3.2. Compatibilité avec les API souples

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

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

Paramètre	Détails
VERSION.RELEASE	Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans la section Chaînes de version autorisées pour Android 12.
VERSION.SDK	Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 12, ce champ DOIT avoir la valeur entière 12_INT.
VERSION.SDK_INT	Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 12, ce champ DOIT avoir la valeur entière 12_INT.
VERSION.INCREMENTAL	Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android actuellement en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour les différents builds mis à la disposition des utilisateurs finaux. L'utilisation typique de ce champ consiste à indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build. La valeur de ce champ DOIT être encodable en ASCII 7 bits imprimable et correspondre à l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ	Valeur choisie par l'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE	Valeur reflétant le nom de la marque associé à l'appareil tel qu'il est connu des utilisateurs finaux. DOIT être au format lisible par l'humain et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives
SUPPORTED_32_BIT_ABIS	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives
SUPPORTED_64_BIT_ABIS	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
APPAREIL	Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en 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.
FINGERPRINT	Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il doit respecter ce modèle: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemple : acme/myproduct/     mydevice:12/LMYXX/3359:userdebug/test-keys L'empreinte ne doit PAS inclure d'espaces blancs. La valeur de ce champ DOIT être encodable en ASCII 7 bits.
MATÉRIEL	Nom du matériel (à partir de la ligne de commande du noyau ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
HOST	Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'utilisateur. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID	Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT	Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est imposée 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.
SOC_MANUFACTURER	Nom commercial du fabricant du système sur une puce (SOC) principal utilisé dans le produit. Les appareils du même fabricant de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser. La valeur de ce champ DOIT être encodable en ASCII 7 bits, DOIT correspondre à l'expression régulière "^([0-9A-Za-z ]+)", NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égale à "unknown". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
SOC_MODEL	Nom du modèle du système sur une puce (SoC) principal utilisé dans le produit. Les appareils avec le même modèle de SOC doivent utiliser la même valeur constante. Veuillez demander au fabricant du SOC la constante à utiliser. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^([0-9A-Za-z ._/+-]+)$". Elle NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égale à "unknown". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE	Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il doit s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est imposée 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'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code 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 en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom de produit NE DOIT PAS changer pendant la durée de vie du produit.
ODM_SKU	Valeur facultative choisie par l'implémentateur de l'appareil, qui contient l'unité de gestion des stocks (SKU) utilisée pour suivre les configurations spécifiques de l'appareil, par exemple les périphériques inclus avec l'appareil lors de la vente. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière ^([0-9A-Za-z.,_-]+)$.
SERIAL	DOIT renvoyer "UNKNOWN".
TAGS	Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Les balises DOIVENT être encodables en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+". Elles DOIVENT avoir l'une des valeurs correspondant aux trois configurations de signature de plate-forme Android typiques: release-keys, dev-keys et test-keys.
DURÉE	Valeur représentant le code temporel de la compilation.
MACH	Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution du build. Ce champ DOIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng.
UTILISATEUR	Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatisé) ayant généré le build. Aucune exigence n'est requise concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
SECURITY_PATCH	Valeur indiquant le niveau du correctif de sécurité d'un build. Il DOIT indiquer que le build n'est en aucun cas vulnérable à l'un des problèmes décrits dans le bulletin de sécurité public Android désigné. Elle 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".
BASE_OS	Valeur représentant le paramètre FINGERPRINT de la version qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte et, si un tel build n'existe pas, indiquer une chaîne vide ("").
BOOTLOADER	Valeur choisie par l'implémentateur de l'appareil pour identifier la version spécifique du bootloader interne utilisée sur l'appareil, au format lisible par l'utilisateur. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DOIT (être ou renvoyer) une valeur choisie par l'implémentateur de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l'appareil, au format lisible par l'homme. Si un appareil ne dispose pas de radio/modem interne, il DOIT renvoyer NULL. La valeur de ce champ DOIT pouvoir être encodée en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial()	DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique pour tous les appareils du même MODÈLE et du même FABRICANT. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application courants

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

Implémentations de l'appareil:

• [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 publics définis par les intents d'application suivants listés ici et de fournir un traitement, c'est-à-dire de répondre aux attentes du développeur pour ces intents d'application courants, comme décrit dans le SDK.

Pour connaître les intents d'application obligatoires pour chaque type d'appareil, consultez la section 2.

3.2.3.2. 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 de "Paramètres", d'être remplacé par des applications tierces. L'implémentation Open Source d'Android en amont permet cela par défaut.

• [C-0-2] Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et de les contrôler. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.

• [C-0-3] Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.

• Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des modèles d'URI spécifiques (par exemple, http://play.google.com) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un format de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le format 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'application par défaut autoritaire 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 essayer de valider tous les filtres d'intent en effectuant les étapes de validation définies dans la spécification Digital Asset Links, telles qu'implémentées par le gestionnaire de paquets dans le projet Open Source Android 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 URI validés avec succès comme gestionnaires d'application par défaut pour leurs URI.
• PEUT définir des filtres d'intent URI spécifiques comme gestionnaires d'application par défaut pour leurs URI, s'ils sont correctement validés, mais que d'autres filtres d'URI candidats ne le sont pas. Si une implémentation d'appareil le fait, elle DOIT fournir à l'utilisateur les forçages de modèle par URI appropriés dans le menu des paramètres.
• DOIT fournir à l'utilisateur des commandes de liens d'application par application dans les paramètres comme suit :
  • [C-0-6] L'utilisateur DOIT pouvoir remplacer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours demander ou ne jamais s'ouvrir, ce qui doit s'appliquer de manière égale à tous les filtres d'intent URI candidats.
  • [C-0-7] L'utilisateur DOIT pouvoir consulter une liste des filtres d'intent URI candidats.
  • L'implémentation de l'appareil PEUT permettre à l'utilisateur de remplacer des filtres d'intent URI candidats spécifiques qui ont été validés, sur la base d'un filtre d'intent.
  • [C-0-8] L'implémentation de l'appareil DOIT permettre aux utilisateurs d'afficher et de remplacer des filtres d'intent d'URI candidats spécifiques si l'implémentation de l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.

3.2.3.3. Espaces de noms d'intent

• [C-0-1] Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android.* ou com.android.*.
• [C-0-2] Les implémentateurs d'appareils NE DOIVENT PAS inclure de composants Android qui respectent de nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation.
• [C-0-3] Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre l'un des 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.

3.2.3.4. Intents de diffusion

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

Implémentations de l'appareil:

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

3.2.3.5. Intents d'application conditionnels

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

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

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

• [C-1-1] DOIT respecter l'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, 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 de 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'UI 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 utiliseraient l'application Téléphone préinstallée.

• [C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour fournir à l'utilisateur la possibilité de configurer le ConnectionServices associé au PhoneAccounts, ainsi qu'un PhoneAccount par défaut que le fournisseur de services de télécommunications utilisera pour passer des appels sortants. L'implémentation AOSP répond à cette exigence en incluant un menu "Option de compte d'appel" dans le menu des paramètres "Appels".

• [C-2-4] DOIT autoriser android.telecom.CallRedirectionService pour une application disposant du rôle android.app.role.CALL_REDIRECTION.

• [C-2-5] DOIT fournir à l'utilisateur la possibilité de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.

• [C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW, et fournir une activité pour envoyer/afficher des SMS.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ 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 numérotation préchargée pouvant gérer ces intents et fournir l'exécution comme décrit dans le SDK.

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 d'application par défaut pour les paiements sans contact.
• [C-3-2] DOIT respecter l'intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT pour afficher une activité qui ouvre une boîte de dialogue demandant à l'utilisateur de modifier le service d'émulation de carte par défaut pour une certaine catégorie, comme décrit dans le SDK.

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

• [C-4-1] DOIT respecter ces 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 pour 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 de l'appareil sont compatibles avec la fonctionnalité de mode Ne pas déranger, elles:

• [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é dans laquelle l'utilisateur peut accorder ou refuser à l'application l'accès aux configurations de règles de non-déranger.

Si les implémentations de l'appareil 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 modes de saisie tiers en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

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

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

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

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

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

• [C-10-1] DOIT fournir une interface utilisateur dans les paramètres, 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 de l'appareil ne fournissent pas le mode Économiseur de données, elles:

• [C-11-1] Une activité doit gérer l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mais elle peut l'implémenter en tant que "no-op".

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

• [C-12-3] DOIT respecter 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 UI afin de guider l'utilisateur lors de l'ajout de l'administrateur de l'appareil au système (ou lui permettre de le refuser).

• [C-13-2] DOIT respecter les intents android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD et android.app.action.START_ENCRYPTION, et doit disposer d'une activité pour répondre à ces intents, comme décrit dans le SDK ici.

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

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

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

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir un mécanisme accessible par 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 ont l'intention d'interdire à toute application, y compris les applications préinstallées, d'accéder aux statistiques d'utilisation, elles:

• [C-15-1] Une activité doit toujours gérer le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais elle doit l'implémenter comme une opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès de l'utilisateur est refusé.

Si les implémentations de l'appareil 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 utilisateur via un mécanisme similaire, elles:

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

Si les implémentations de l'appareil sont compatibles avec VoiceInteractionService et qu'elles ont installé plusieurs applications utilisant cette API en même temps, 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 les intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et android.speech.tts.engine.GET_SAMPLE_TEXT. Une activité doit être fournie pour exécuter ces intents, comme décrit dans le SDK ici.

Android est compatible avec les écrans de veille interactifs, auparavant appelés "Dreams". Les écrans de veille permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur une station d'accueil. Implémentations de l'appareil:

• DOIT inclure la prise en charge des écrans de veille et fournir une option de paramètres permettant aux utilisateurs de configurer des écrans de veille en réponse à l'intent android.settings.DREAM_SETTINGS.

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

Si les implémentations d'appareils permettent de lancer des activités Android normales sur plusieurs écrans, elles:

• [C-1-1] Vous DEVEZ définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
• [C-1-2] DOIT garantir la compatibilité des API semblable à celle d'une activité exécutée sur l'écran principal.
• [C-1-3] DOIT placer 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 choisit de s'afficher au-dessus de l'écran de verrouillage à l'aide de l'API Activity#setShowWhenLocked().
• DOIT avoir android.content.res.Configuration, qui correspond à cet écran, pour s'afficher, fonctionner correctement et assurer la compatibilité si une activité est lancée sur un écran secondaire.

Si les implémentations de l'appareil permettent de lancer des activités Android normales sur des écrans secondaires et qu'un écran secondaire comporte l'indicateur android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilité avec les API natives

La compatibilité du code natif est difficile. Par conséquent, les implémentateurs d'appareils sont:

• [C-SR-1] Nous vous recommandons vivement d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Open Source Android 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 .so ELF compilé pour l'architecture matérielle de l'appareil appropriée. Étant donné que le code natif est fortement dépendant 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 de l'appareil:

• [C-0-1] DOIT être compatible avec un ou plusieurs ABI Android NDK définis.
• [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 standard de Java Native Interface (JNI).
• [C-0-3] DOIT être compatible avec la source (c'est-à-dire compatible avec l'en-tête) et compatible avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous.
• [C-0-5] DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparée par une virgule, 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 suivante d'ABI et NE DOIT PAS signaler d'ABI qui ne figure pas dans la liste.

  • armeabi (plus compatible en tant que cible par le NDK)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (prise en charge audio native d'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 (lieneur dynamique)
  • libEGL.so (gestion des surfaces OpenGL natives)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (journalisation Android)
  • libmediandk.so (compatibilité avec les API multimédias natives)
  • libm (bibliothèque mathématique)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (compatibilité minimale avec C++)
  • libvulkan.so (Vulkan)
  • libz (compression zlib)
  • Interface JNI

• [C-0-8] Vous NE DEVEZ PAS ajouter ni supprimer les fonctions publiques des bibliothèques natives listées ci-dessus.

• [C-0-9] DOIT lister les bibliothèques non AOSP supplémentaires exposées directement aux applications tierces dans /vendor/etc/public.libraries.txt.

• [C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, aux applications tierces ciblant le niveau d'API 24 ou version ultérieure, car elles sont réservées.

• [C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et du pack d'extensions Android, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que, bien que tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit plus en détail les exigences concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.

• [C-0-12] DOIT exporter des symboles de fonction pour les symboles de fonction principaux de Vulkan 1.0, 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 concernant le moment où l'implémentation complète de chaque fonction correspondante est attendue.

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

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

3.3.2. Compatibilité du code natif ARM 32 bits

Si les implémentations d'appareils signalent 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 anciennes applications.

Si les implémentations de l'appareil signalent la prise en charge de l'ABI armeabi-v7a, les applications qui utilisent cette ABI:

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

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

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

  • Instructions SWP et SWPB.
  • Opérations de barrière 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] Vous devez utiliser la compilation du projet Chromium à partir du projet Open Source Android en amont sur la branche Android 12 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 ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
  • "Build/$(BUILD)" peut être omis, mais si cette valeur 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 correspondre à la version de Chromium dans le projet Open Source Android en amont.
  • Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

• Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il est compatible avec la fonctionnalité, DOIT se conformer à la spécification HTML5.

• [C-1-4] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès direct au réseau et n'avoir accès qu'aux services système requis au minimum 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 C-1-3.

3.4.2. Compatibilité avec les navigateurs

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

• [C-1-1] DOIT prendre en charge chacune de ces API associées à HTML5 :
  • cache de l'application/opération hors connexion
  • Balise <video>
  • géolocalisation
• [C-1-2] DOIT être compatible avec l'API WebStorage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à Webstorage, IndexedDB devrait devenir un composant obligatoire dans une future version d'Android.
• PEUT fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome.
• DOIT implémenter la compatibilité avec autant de HTML5 que possible dans l'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers).

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

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

3.5. Compatibilité du comportement des API

Implémentations de l'appareil:

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

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

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

3.5.1. Restriction d'application

Si les implémentations d'appareils implémentent un mécanisme propriétaire pour restreindre les applications et que ce mécanisme est plus restrictif que le bucket de mise en veille des applications restreintes, elles:

• [C-1-1] L'application DOIT fournir une affordance permettant à l'utilisateur de voir la liste des applications soumises à des restrictions.
• [C-1-2] DOIT fournir une affordance utilisateur pour activer / désactiver les restrictions sur chaque application.
• [C-1-3] Le système NE DOIT PAS appliquer automatiquement de restrictions sans preuve d'un mauvais état de santé du système, mais PEUT appliquer des restrictions aux applications en cas de détection d'un mauvais état de santé du système, comme des wakelocks bloqués, des services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les implémentateurs de l'appareil, mais DOIVENT être liés à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas purement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés comme critères.
• [C-1-4] Le système NE DOIT PAS appliquer automatiquement des restrictions d'application aux applications lorsqu'un utilisateur a désactivé manuellement les restrictions d'application, et PEUT suggérer à l'utilisateur d'appliquer des restrictions d'application.
• [C-1-5] DOIT informer les utilisateurs si des restrictions sont appliquées automatiquement à une application. Ces informations DOIVENT être fournies dans les 24 heures suivant l'application des restrictions.
• [C-1-6] DOIT renvoyer true pour ActivityManager.isBackgroundRestricted() lorsque l'application limitée appelle cette API.
• [C-1-7] NE DOIT PAS limiter l'application de premier plan utilisée explicitement par l'utilisateur.
• [C-1-8] L'application qui devient l'application de premier plan doit SUSPENDRE les restrictions lorsque l'utilisateur commence à utiliser explicitement l'application qui était auparavant soumise à des restrictions.
• [C-1-10] NE DOIT PAS permettre qu'une application soit automatiquement placée dans le bucket RESTRICTED dans les deux heures suivant la dernière utilisation par un utilisateur.

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

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

3.5.2. Hibernation des applications

Si les implémentations de l'appareil incluent l'hibernation d'application incluse dans AOSP ou étendent 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] Vous devez appliquer la restriction à l'application pour un utilisateur uniquement lorsqu'il est prouvé que l'utilisateur n'a pas utilisé l'application pendant une certaine période. Nous vous recommandons vivement de choisir une durée d'un mois ou plus. L'utilisation DOIT être définie par une interaction utilisateur explicite via l'API UsageStats#getLastTimeVisible() ou par tout élément qui ferait sortir une application de l'état d'arrêt forcé, y compris les liaisons de service, les liaisons de fournisseur de contenu, les diffusions explicites, etc., qui seront suivis par une nouvelle API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] Les restrictions qui affectent tous les utilisateurs de l'appareil DOIVENT être appliquées uniquement lorsqu'il est prouvé que le package n'a été utilisé par AUCUN utilisateur pendant une certaine période. Nous vous recommandons vivement de choisir une durée d'un mois ou plus.
• [C-1-4] L'application NE DOIT PAS être empêchée de répondre aux intents d'activité, aux liaisons de service, aux requêtes du fournisseur de contenu ou aux diffusions explicites.

L'hibernation d'application dans AOSP répond aux exigences ci-dessus.

3.6. Espaces de noms d'API

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

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

En d'autres termes:

• [C-0-1] Vous NE DEVEZ PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni en supprimant des classes ou des champs de classe.
• [C-0-2] Vous NE DEVEZ PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes pour des classes ou des interfaces existantes) ni d'API de test ou système aux API des espaces de noms ci-dessus. Un "élément exposé publiquement" est toute 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 implémentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais ces modifications:

• [C-0-3] NE DOIT PAS avoir d'incidence sur le comportement indiqué et la signature en langage Java de toute API exposée publiquement.
• [C-0-4] NE DOIVENT PAS être annoncés ni exposés aux développeurs.

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

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

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

Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT consulter source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux informations disponibles 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 rendre contraignantes en les incluant dans cette définition de compatibilité.

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

Implémentations de l'appareil:

• [C-0-1] DOIT être compatible avec le format Dalvik Executable (DEX) complet et 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 conformément à la plate-forme Android en amont, comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)

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

• DOIT exécuter des tests de fuzz 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.

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

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

Android inclut une application de lanceur (écran d'accueil) et prend en charge les applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil).

Si les implémentations de l'appareil permettent aux applications tierces de remplacer l'écran d'accueil de l'appareil, elles:

• [C-1-1] Vous DEVEZ 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 sont appelées pour récupérer les icônes.

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

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

À l'inverse, si les implémentations de l'appareil 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 par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager, elles:

• [C-4-1] DOIT prendre en charge toutes les fonctionnalités de raccourcis documentées (par exemple, les raccourcis statiques et dynamiques, les raccourcis d'épinglage) et implémenter entièrement les API de la classe d'API ShortcutManager.

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

• [C-5-1] DOIT respecter la méthode d'API NotificationChannel.setShowBadge(). En d'autres termes, affichez une affordance visuelle associée à l'icône de l'application si la valeur est définie sur true, et n'affichez aucun schéma de badging 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 de badges propriétaire lorsque les applications tierces indiquent la prise en charge du schéma de badges propriétaire via l'utilisation d'API propriétaires, mais DOIT utiliser les ressources et les valeurs fournies via les API de badges de notification décrites dans le SDK, telles que l'API Notification.Builder.setNumber() et l'API Notification.Builder.setBadgeIconType().

3.8.2. Widgets

Android est compatible avec les widgets d'application tiers en définissant un type de composant, une API et un cycle de vie correspondants qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final.

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

• [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
• [C-1-2] DOIT inclure la prise en charge intégrée des AppWidgets et exposer les affordances de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur d'applications.
• [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 de l'appareil sont compatibles avec les widgets d'applications tierces et l'épinglage de raccourcis dans l'application, elles:

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

3.8.3. Notifications

Android inclut les API Notification et NotificationManager qui permettent aux développeurs d'applications tierces d'avertir 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 (par exemple, la barre de notification et la barre système) de l'appareil.

3.8.3.1. Présentation des notifications

Si les implémentations d'appareils autorisent les applications tierces à avertir les utilisateurs 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 une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.
• [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, bien qu'elles PUISSENT fournir une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Open Source Android de référence.
• [C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API afin de mettre à jour, supprimer et 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 utilisateur permettant de bloquer et de modifier la notification d'une application tierce spécifique par niveau de canal et 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 avec le texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, vous devez 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 présenter automatiquement une affordance utilisateur pour bloquer la notification d'une application tierce par canal et niveau de package d'application après que l'utilisateur a ignoré cette notification plusieurs fois.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance permettant à l'utilisateur de contrôler les notifications exposées aux applications auxquelles l'autorisation d'écouteur de notifications a été accordée. La granularité DOIT être telle que l'utilisateur puisse contrôler, pour chaque écouteur de notification, les types de notifications qui sont mis en correspondance avec cet écouteur. Les types DOIVENT inclure les notifications "conversations", "alertes", "silencieuses" et "importantes en cours".
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs une affordance leur permettant de spécifier les applications à exclure de la notification d'un écouteur de notification spécifique.
• DOIT prendre en charge les notifications enrichies.
• DOIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
• DOIT proposer une affordance permettant à l'utilisateur de répéter les notifications.
• NE DOIT GÉRER QUE la visibilité et le moment où les applications tierces peuvent avertir les utilisateurs d'événements notables afin de réduire les problèmes de sécurité tels que la distraction du conducteur.

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

Implémentations de l'appareil:

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

Si les implémentations de l'appareil sont compatibles avec les notifications enrichies, elles:

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

Si les implémentations de l'appareil sont compatibles avec les notifications prioritaires :

• [C-3-1] Vous DEVEZ utiliser la vue et les ressources de notification prioritaire comme décrit 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 utilisateur supplémentaire, comme décrit dans le SDK.

3.8.3.2. Service de notification de l'auditeur

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

Implémentations de l'appareil:

• [C-0-1] DOIT mettre à jour correctement et rapidement l'intégralité des notifications pour tous ces services d'écouteur 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 répétition définie dans l'appel d'API.

Si les implémentations d'appareils disposent d'une affordance permettant à l'utilisateur de suspendre les notifications:

• [C-1-1] DOIT refléter correctement l'état de la notification différée via les API standards telles que NotificationListenerService.getSnoozedNotifications().
• [C-1-2] L'affordance utilisateur doit être disponible pour suspendre les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.

3.8.3.3. Ne pas déranger

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

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

3.8.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 de l'appareil sont compatibles avec l'action d'assistance, elles:

• [C-2-1] L'application DOIT indiquer clairement à l'utilisateur final quand le contexte est partagé, en :
  • Chaque fois que l'application d'assistance accède au contexte, une lumière blanche s'affiche autour des bords de l'écran, qui correspond ou dépasse la durée et la luminosité de l'implémentation du projet Android Open Source.
  • Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu de paramètres de saisie vocale et d'application d'assistance par défaut, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une saisie de 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, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité qui gère l'intent ACTION_ASSIST.

3.8.5. Alertes et notifications toast

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

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

• [C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent TYPE_APPLICATION_OVERLAY. L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notification.

• [C-1-2] DOIT respecter l'API Toast et afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.6. Thèmes

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

Android inclut une famille de thèmes "Holo" et "Material" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android.

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

• [C-1-1] Vous NE DEVEZ PAS modifier l'un des attributs de thème Holo exposés aux applications.
• [C-1-2] DOIT prendre en charge la famille de thèmes "Material" et NE DOIT PAS modifier les attributs de thème Material ni les éléments exposés aux applications.
• [C-1-3] La famille de polices "sans-serif" doit être définie sur Roboto version 2.x pour les langues compatibles avec Roboto, ou une affordance utilisateur doit être fournie pour modifier la police utilisée pour la famille de polices "sans-serif" en Roboto version 2.x pour les langues compatibles avec Roboto.

Android inclut également une famille de thèmes "Par défaut de l'appareil" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème de l'appareil tel que défini par l'implémentateur de l'appareil.

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

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

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

• [C-2-1] Vous devez utiliser le blanc pour les icônes d'état du 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 qu'une application demande une barre d'état claire à l'aide de l'indicateur WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
• [C-2-2] Les implémentations d'appareils Android DOIVENT changer la couleur des icônes d'état du système en noir (pour en savoir plus, consultez R.style) lorsqu'une application demande une barre d'état claire.

3.8.7. Fonds d'écran animés

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

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur les autres applications. Si des limites matérielles provoquent le plantage et/ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une puissance de processeur ou de batterie excessive, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, 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écute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

• [C-1-1] DOIT signaler le flag de fonctionnalité de 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 tâches récemment consultées à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois.

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

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

• [C-1-1] DOIT prendre en charge au moins sept activités affichées.
• DOIT afficher au moins le titre de quatre activités à la fois.
• [C-1-2] DOIT implémenter le comportement d'épinglage de l'écran et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
• DOIT afficher la couleur de surbrillance, l'icône et le titre de l'écran dans les éléments récents.
• DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans.
• DOIT implémenter un raccourci pour passer facilement à l'activité précédente.
• DOIT déclencher l'action de commutation rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est enfoncée deux fois.
• DOIT déclencher le mode multifenêtre en écran partagé, le cas échéant, lorsque la touche de fonction "Récents" est enfoncée de manière prolongée.
• PEUT afficher les contenus récents affiliés sous forme de groupe qui se déplace ensemble.
• [SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) 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 modes de saisie tiers.

Si les implémentations de l'appareil 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. Contrôle des contenus multimédias sur l'écran de verrouillage

L'API Client de télécommande est obsolète à partir d'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 connaître l'intent de paramètres permettant de configurer les écrans de veille.

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,

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

3.8.13. Unicode et police

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

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

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

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

• DOIT fournir à l'utilisateur une méthode d'entrée pour ces caractères emoji.

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

Si les implémentations de l'appareil sont compatibles avec le birman, elles:

• [C-2-1] Le texte doit être affiché avec une police conforme à Unicode par défaut. Une police non conforme à Unicode ne doit pas être définie comme police par défaut, sauf si l'utilisateur la choisit dans le sélecteur de langue.
• [C-2-2] DOIT prendre en charge une police Unicode et une police non conforme à Unicode si une police non conforme à Unicode est prise en charge sur l'appareil. La police non conforme à Unicode NE DOIT PAS supprimer ni écraser la police Unicode.
• [C-2-3] DOIT afficher le texte avec une police non conforme à Unicode UNIQUEMENT SI un code de langue avec le code de script Qaag est spécifié (par exemple, my-Qaag). Aucun autre code de langue ou de région ISO (qu'il soit attribué, non attribué ou réservé) ne peut être utilisé pour faire référence à une police non conforme à l'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 n'importe quelle autre langue.

3.8.14. Multifenêtres

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

• [C-1-1] DOIT implémenter ces modes multifenêtre 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 doit 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 de mode Écran partagé ou Format libre si la hauteur de l'écran est inférieure à 440 dp et la largeur de l'écran est inférieure à 440 dp.
• [C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp dans les modes multifenêtre autres que Picture-in-picture.
• Les implémentations d'appareils avec une taille d'écran xlarge DOIVENT être compatibles avec le mode de dessin libre.

Si les implémentations de l'appareil sont compatibles avec le ou les modes multifenêtre et le mode Écran partagé, elles:

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

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

• [C-3-1] DOIT lancer les activités en mode multifenêtre Picture-in-picture lorsque l'application est:

  • Cibler le niveau d'API 26 ou supérieur et déclarer 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 actuelle via l'API setActions().

• [C-3-3] DOIT prendre en charge les formats supérieurs ou égaux à 1:2,39 et inférieurs ou égaux à 2,39:1, comme spécifié par l'activité PIP via l'API setAspectRatio().

• [C-3-4] Vous devez 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 l'affichage d'une application en mode PIP. L'implémentation AOSP répond à cette exigence en disposant de commandes dans la barre de notification.

• [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 la valeur Configuration.uiMode est différente de UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur et une hauteur minimales de 108 dp.
  • Les appareils dont la valeur Configuration.uiMode est définie sur UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

3.8.15. Encoche

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

Si les implémentations de l'appareil incluent une ou plusieurs découpes d'écran:

• [C-1-5] L'écran ne doit PAS comporter de découpe si le format de l'appareil est 1,0 (1:1).
• [C-1-2] Il ne doit pas y avoir plus d'une découpe par arête.
• [C-1-3] DOIT respecter les indicateurs de découpe d'affichage définis par l'application via l'API WindowManager.LayoutParams, comme décrit dans le SDK.
• [C-1-4] DOIT indiquer les valeurs correctes pour toutes les métriques de découpe définies dans l'API DisplayCutout.

3.8.16. Commandes de contrôle des appareils

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

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2_2_3.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration d'appareils au niveau du système, telles que l'application de stratégies de mot de passe ou l'effacement à distance, via l'API Android Device Administration.

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

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

3.9.1 Préparation de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

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

• [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
  • Lorsque l'implémentation de l'appareil n'a pas encore configuré de données utilisateur :
    • [C-1-5] L'application DPC doit être enregistrée en tant qu'application propriétaire de l'appareil si l'appareil déclare la compatibilité avec la technologie NFC (communication en champ proche) via l'indicateur 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, sauf si le contexte permet de déterminer qu'il n'existe qu'une seule option valide (par exemple, pour le provisionnement basé sur la technologie NFC, où le provisionnement du propriétaire de profil n'est pas pris en charge).
    • [C-1-9] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE à l'application propriétaire de l'appareil si un propriétaire de l'appareil est défini 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 Device Owner n'a pas terminé.
  • Lorsque l'implémentation de l'appareil contient des données utilisateur :
    • [C-1-7] Vous ne devez plus enregistrer d'application DPC en tant qu'application propriétaire de l'appareil.
• [C-1-2] L'application DOIT exiger une action affirmative avant ou pendant le processus de provisionnement pour autoriser l'application à être définie en tant que propriétaire de l'appareil. Le consentement peut être obtenu par action de l'utilisateur ou par des moyens programmatiques, mais un avis de divulgation approprié (comme indiqué dans l'AOSP) DOIT être affiché avant le provisionnement du propriétaire de l'appareil. De plus, le mécanisme de consentement programmatique du propriétaire de l'appareil utilisé (par les entreprises) pour le provisionnement du propriétaire de l'appareil NE DOIT PAS interférer avec l'expérience prête à l'emploi pour un usage non professionnel.
• [C-1-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'autres applications appartenant au propriétaire de l'appareil.

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

• [C-2-1] Un processus doit être mis en place pour vérifier que l'application spécifique promue appartient à une solution de gestion d'appareils d'entreprise légitime et qu'elle a déjà été configurée dans la solution propriétaire pour disposer des droits équivalents à ceux d'un "propriétaire d'appareil".
• [C-2-2] DOIT afficher le même communiqué de consentement du propriétaire de l'appareil AOSP que le flux lancé par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
• PEUT avoir des données utilisateur sur l'appareil avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".

3.9.1.2 Provisionnement de profils gérés

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

• [C-1-1] DOIT implémenter les API permettant à une application de contrôle des règles relatives aux appareils (DPC) 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 être conformes à l'implémentation AOSP.

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

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

• [C-1-4] DOIT lancer le gestionnaire pour l'intent ACTION_PROVISIONING_SUCCESSFUL dans le profil professionnel si un propriétaire de profil est défini lorsque le provisionnement est lancé par l'intent android.app.action.PROVISION_MANAGED_PROFILE et que le DPC a implémenté le gestionnaire.

• [C-1-5] DOIT envoyer la 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 de profil afin que l'application DPC puisse choisir de devenir propriétaire de l'appareil ou propriétaire du profil, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] DOIT envoyer l'intent ACTION_ADMIN_POLICY_COMPLIANCE au profil professionnel lorsqu'un propriétaire de profil est défini lors du provisionnement, quelle que soit la méthode de provisionnement utilisée, sauf lorsque le provisionnement 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 Profile Owner n'a pas terminé.

• [C-1-8] DOIT envoyer la diffusion ACTION_MANAGED_PROFILE_PROVISIONED au DPC du profil personnel lorsqu'un propriétaire de profil est défini, 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'appareil 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] Un seul profil géré peut être créé.
• [C-1-3] DOIT utiliser un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, tels que "Récents" et "Notifications".
• [C-1-4] DOIT afficher une icône de notification (similaire au badge de travail en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de 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, si cette fonctionnalité est activée par le contrôleur de stratégie de l'appareil.
• [C-1-7] Lorsqu'un profil géré existe, il DOIT exposer les affordances utilisateur suivantes à la fois pour l'utilisateur principal et le profil géré :
  • Comptabilisation distincte de la batterie, de la localisation, des données mobiles et de l'utilisation de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées dans l'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 les applications de numérotation, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant du profil géré (le cas échéant) ainsi que celles du profil principal, si le contrôleur de stratégie de l'appareil l'autorise.
• [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs 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 de l'appareil déclarent android.software.managed_users et android.software.secure_lock_screen, elles:

• [C-2-1] DOIT permettre de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications exécutées dans un profil géré uniquement.
  • 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 Open Source Android.
  • Les règles de mot de passe de la DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
• Lorsque les contacts du profil géré sont affichés dans le journal des appels préinstallé, l'interface utilisateur de l'appel, les notifications en cours et les appels manqués, les applications de contacts et de messagerie, ils DOIVENT être associés au même badge que celui utilisé pour indiquer les applications du profil géré.

3.9.3 Assistance utilisateur gérée

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

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

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

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher les mêmes informations sur le consentement du propriétaire de l'appareil AOSP qui ont été affichées dans le flux lancé 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.10. Accessibilité

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

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

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

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

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

3.11. Synthèse vocale

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

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

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

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

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

3.12. TV Input Framework

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

Si les implémentations de l'appareil sont compatibles avec le TIF:

• [C-1-1] Vous DEVEZ déclarer la fonctionnalité de plate-forme android.software.live_tv.
• [C-1-2] DOIT prendre en charge toutes les API TIF afin qu'une application qui utilise ces API et le service d'entrées tierces basées sur TIF puisse être installée et utilisée sur l'appareil.

3.13. Les réglages rapides

Android fournit un composant d'UI de configuration rapide qui permet d'accéder rapidement aux actions fréquemment utilisées ou nécessaires de toute urgence.

Si les implémentations d'appareils incluent un composant d'interface utilisateur des 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 d'une application tierce directement aux paramètres rapides.
• [C-1-3] DOIT afficher toutes les cartes ajoutées par l'utilisateur à partir d'applications tierces, ainsi que les cartes de réglage rapide fournies par le système.

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent des applications non activées par 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 MediaDescription. Peut raccourcir les titres pour respecter les règles de sécurité (par exemple, en cas de distraction du conducteur).

• [C-1-3] DOIT afficher l'icône de l'application tierce chaque fois qu'elle affiche du contenu fourni par cette application tierce.

• [C-1-4] DOIT permettre à l'utilisateur d'interagir avec l'ensemble de la hiérarchie MediaBrowser. PEUT limiter l'accès à une partie de la hiérarchie pour respecter les règles de sécurité (par exemple, en cas de distraction du conducteur), MAIS NE DOIT PAS accorder un traitement préférentiel en fonction du contenu ou du fournisseur de contenu.

• [C-1-5] DOIT considérer le double appui sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

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

• [C-1-1] Les applications instantanées ne doivent être autorisées qu'à utiliser des autorisations dont la valeur android:protectionLevel est définie sur "instant".
• [C-1-2] Les applications instantanées NE DOIVENT PAS interagir avec les applications installées via des intentions implicites, sauf si l'une des conditions suivantes est remplie :
  • Le filtre de modèle d'intent du composant est exposé et comporte CATEGORY_BROWSABLE.
  • L'action est ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
  • La cible est exposée explicitement avec android:visibleToInstantApps
• [C-1-3] Les applications instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
• [C-1-4] Les applications installées NE DOIVENT PAS voir les informations sur les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.

• Les implémentations d'appareils DOIVENT fournir les affordances utilisateur suivantes pour interagir avec les applications instantanées. L'AOSP répond aux exigences avec l'UI système, les paramètres et le lanceur par défaut. Implémentations de l'appareil:

  • [C-1-5] DOIT fournir une affordance utilisateur permettant d'afficher et de supprimer les applications Instant stockées en cache localement pour chaque package d'application individuel.
  • [C-1-6] DOIT fournir une notification utilisateur persistante pouvant être réduite lorsqu'une application instantanée est exécutée au premier plan. Cette notification utilisateur DOIT indiquer que les applications instantanées ne nécessitent pas d'installation et fournir une affordance utilisateur qui redirige l'utilisateur vers l'écran d'informations de l'application dans les paramètres. Pour les applications instantanées lancées via des intents Web, comme défini à l'aide d'un intent dont l'action est définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance utilisateur supplémentaire DOIT permettre à l'utilisateur de ne pas lancer l'application instantanée et de lancer le lien associé avec le navigateur Web configuré, si un navigateur est disponible sur l'appareil.
  • [C-1-7] DOIT permettre d'accéder aux applications Instant exécutées à partir de la fonction "Récents" si elle est disponible sur l'appareil.

• [C-1-8] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent pour les intents listés dans le SDK ici et rendre les intents visibles pour les applications instantanées.

3.16. Association d'un appareil associé

Android est compatible avec l'association d'appareils associés pour gérer plus efficacement l'association avec les appareils associés et fournit l'API CompanionDeviceManager pour que les applications puissent accéder à cette fonctionnalité.

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

• [C-1-1] Vous DEVEZ déclarer le flag de fonctionnalité FEATURE_COMPANION_DEVICE_SETUP .
• [C-1-2] DOIT s'assurer que les API du package android.companion sont entièrement implémentées.
• [C-1-3] DOIT fournir des affordances utilisateur pour que l'utilisateur puisse sélectionner/confirmer qu'un appareil compagnon est présent et opérationnel.

3.17. Applications lourdes

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

• [C-1-1] Une seule application installée doit spécifier cantSaveState en cours d'exécution dans le système à la fois. Si l'utilisateur quitte une telle application sans la quitter explicitement (par exemple, en appuyant sur "Accueil" lorsqu'il quitte une activité active du système, au lieu d'appuyer sur "Retour" alors qu'il n'y a plus d'activités actives dans le système), les implémentations de l'appareil DOIVENT donner la priorité à cette application dans la RAM, comme elles le font pour les autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une telle application est en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, 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 de sauvegarde/restauration d'état normal une fois que l'utilisateur lance une deuxième application déclarée avec l'attribut cantSaveState.
• [C-1-3] NE DOIT PAS appliquer d'autres modifications de règles aux applications qui spécifient cantSaveState, telles que la modification des performances du processeur ou de la priorité de planification.

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

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

3.18. Contacts

Android inclut des API Contacts Provider pour permettre aux applications de gérer les informations de contact stockées sur l'appareil. Les données de contact saisies directement sur l'appareil sont généralement synchronisées avec un service Web, mais elles peuvent également ne résider 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 compte 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. Ils sont créés avec des valeurs null pour les colonnes ACCOUNT_NAME et ACCOUNT_TYPE.

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

Implémentations de l'appareil:

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

Si les implémentations de l'appareil utilisent un compte local personnalisé:

• [C-1-1] Le ACCOUNT_NAME du compte local personnalisé DOIT être renvoyé par ContactsContract.RawContacts.getLocalAccountName.
• [C-1-2] Le ACCOUNT_TYPE du compte local personnalisé DOIT être renvoyé par ContactsContract.RawContacts.getLocalAccountType.
• [C-1-3] Les contacts bruts insérés par des applications tierces 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 le compte local personnalisé NE DOIVENT PAS être supprimés lorsque des comptes sont ajoutés ou supprimés.
• [C-1-5] Les opérations de suppression effectuées sur le compte local personnalisé doivent entraîner la suppression immédiate des contacts bruts (comme si le paramètre CALLER_IS_SYNCADAPTER était défini sur "true"), même si le paramètre CALLER\_IS\_SYNCADAPTER était défini sur "false" ou n'était pas spécifié.

4. Compatibilité du packaging d'applications

Implémentations des appareils:

• [C-0-1] DOIT être en mesure d'installer et d'exécuter les fichiers ".apk" Android générés par l'outil "aapt" inclus dans le SDK Android officiel.
  • Étant donné que l'exigence ci-dessus peut s'avérer difficile, il est RECOMMANDÉ d'utiliser le système de gestion des paquets de l'implémentation de référence AOSP pour les implémentations d'appareils.

Implémentations de l'appareil:

• [C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide du schéma de signature des APK v3, du schéma de signature des APK v2 et de la signature JAR.
• [C-0-3] NE DOIT PAS étendre les formats .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correcte de ces fichiers sur d'autres appareils compatibles.

• [C-0-4] NE DOIT PAS autoriser les applications autres que l'installateur enregistré 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 paquets système qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application de gestion de l'espace de stockage qui gère l'intent ACTION_MANAGE_STORAGE.

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

• [C-0-6] NE DOIT PAS installer de packages d'application à partir de sources inconnues, sauf si l'application qui demande l'installation répond à toutes les exigences suivantes:

  • Il DOIT déclarer l'autorisation REQUEST_INSTALL_PACKAGES ou définir android:targetSdkVersion sur 24 ou moins.
  • L'utilisateur doit avoir autorisé l'installation d'applications à partir de sources inconnues.

• DOIT fournir une affordance utilisateur pour accorder/révoquer l'autorisation d'installer des applications à partir de sources inconnues par application, mais PEUT choisir de l'implémenter comme une opération sans effet et de renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs de faire ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi aucun tel choix n'est présenté.

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

• DOIT fournir une affordance utilisateur permettant de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.

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

• [C-0-9] DOIT prendre en charge la validation des fichiers .apk à l'aide du schéma de signature des fichiers APK v4.

5. Compatibilité multimédia

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans la section 5.1 pour chaque codec déclaré par MediaCodecList.
• [C-0-2] DOIT déclarer et signaler la prise en charge des encodeurs et des décodeurs disponibles pour les applications tierces via MediaCodecList.
• [C-0-3] DOIT être en mesure de décoder correctement et de mettre à la disposition des applications tierces tous les formats qu'il peut encoder. Cela inclut tous les flux de bits générés par ses encodeurs et les profils signalés dans son CamcorderProfile.

Implémentations de l'appareil:

• DOIVENT viser une latence de codec minimale. En d'autres termes, ils doivent :
  • NE DOIT PAS consommer et stocker les tampons d'entrée et ne doit les renvoyer qu'une fois traités.
  • NE DOIT PAS conserver les tampons décodés plus longtemps que spécifié par la norme (par exemple, SPS).
  • NE DOIT PAS conserver les tampons encodés plus longtemps que nécessaire par la structure GOP.

Tous les codecs listés dans la section ci-dessous sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du projet Android Open Source.

Veuillez noter que ni Google ni l'Open Handset Alliance ne font aucune déclaration selon laquelle ces codecs sont exempts de brevets tiers. Les personnes qui souhaitent utiliser ce code source dans des produits matériels ou logiciels sont informées que les implémentations de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevets de la part des titulaires de brevets concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".

Si les implémentations d'appareils déclarent android.hardware.microphone, elles DOIVENT prendre en charge l'encodage des formats audio suivants et les mettre à la disposition des applications tierces:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

Tous les encodeurs audio DOIVENT être compatibles avec les éléments suivants:

• [C-3-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API android.media.MediaCodec.

5.1.2. Décodage audio

Pour en savoir plus, consultez la section 5.1.3. "Détails des codecs audio".

Si les implémentations d'appareils déclarent prendre en charge la fonctionnalité android.hardware.audio.output, elles doivent prendre en charge 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 latence 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 la 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, le 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é à effectuer un downsampling et un downmix lors de la phase de lecture.
• [C-1-10] Opus

Si les implémentations d'appareils prennent en charge le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut de l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge:

• [C-2-1] Le décodage DOIT être effectué sans downmix (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, un flux AAC 5.1 doit être décodé en six canaux PCM).
• [C-2-2] Les métadonnées de plage dynamique DOIVENT être conformes à la définition de la "Contrôle de la plage dynamique (DRC)" dans la norme ISO/CEI 14496-3, ainsi qu'aux 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. Il s'agit de : 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.
• [SR-1] Il est vivement 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 de l'audio USAC, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] Les métadonnées de volume et de DRC DOIVENT être interprétées et appliquées conformément au profil de contrôle de la plage dynamique MPEG-D DRC au niveau 1.
• [C-3-2] Le décodeur DOIT se comporter conformément à la configuration définie avec les clés android.media.MediaFormat suivantes : KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_DRC_EFFECT_TYPE.

Décodeurs de profil MPEG-4 AAC, HE AAC et HE AACv2:

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

Si ISO/IEC 23003-4 est pris en charge et si les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont présentes dans un flux de bits décodé, alors:

• Les métadonnées ISO/CEI 23003-4 doivent prévaloir.

Tous les décodeurs audio DOIVENT être compatibles avec la sortie des éléments suivants:

• [C-6-1] Frames audio PCM 16 bits avec ordre d'octets natif via l'API android.media.MediaCodec.

5.1.3. Détails des codecs audio

Format/Codec	Détails	Types de fichiers/Formats de conteneurs compatibles
Profil MPEG-4 AAC (AAC LC)	Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC brut ADTS (.aac, ADIF non compatible) MPEG-TS (.ts, non accessible, décode uniquement) Matroska (.mkv, décodage uniquement)
Profil MPEG-4 HE AAC (AAC+)	Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
Profil MPEG-4 HE AACv2 (AAC+ amélioré)	Compatibilité avec les contenus mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (AAC à faible latence amélioré)	Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards compris entre 7,35 kHz et 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (.3gp)
AMR-WB	9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz, comme défini dans la documentation sur le codec AMR-WB (Adaptive Multi-Rate – Wideband Speech Codec)	3GPP (.3gp)
FLAC	Pour l'encodeur et le décodeur: au moins les modes mono et stéréo DOIVENT être compatibles. Les taux d'échantillonnage jusqu'à 192 kHz DOIVENT être pris en charge. La résolution 16 bits et 24 bits DOIT être prise en charge. La gestion des données audio FLAC 24 bits DOIT être disponible avec la configuration audio à virgule flottante.	FLAC (.flac) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MP3	Mono/Stéréo 8-320 kbit/s constant (CBR) ou débit variable (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv, décodage uniquement)
MIDI	Types MIDI 0 et 1 Versions 1 et 2 de DLS XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody	Types 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 prendre en charge le PCM linéaire 16 bits et le format à virgule flottante 16 bits. L'extracteur WAVE doit prendre en charge les formats PCM linéaire 16 bits, 24 bits et 32 bits, ainsi que les formats à virgule flottante 32 bits (taux jusqu'à la limite du matériel). Les taux d'échantillonnage doivent être compatibles entre 8 kHz et 192 kHz.	WAVE (.wav)
Opus	Décodage: prise en charge des contenus mono, stéréo, 5.0 et 5.1 avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz. Encodage: prise en charge des contenus mono et stéréo avec des taux d'échantillonnage de 8 000, 12 000, 16 000, 24 000 et 48 000 Hz.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, décodage uniquement) Matroska (.mkv) WebM (.webm)

5.1.4. Encodage d'image

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

Les implémentations d'appareils DOIVENT prendre en charge l'encodage des images suivantes:

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

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

• [C-1-1] DOIT fournir un codec d'encodeur HEVC accéléré par matériel compatible avec le mode de contrôle du débit BITRATE_MODE_CQ, le profil HEVCProfileMainStill et la taille de trame de 512 x 512 px.

5.1.5. Décodage d'image

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

Les implémentations d'appareils DOIVENT 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 de l'appareil sont compatibles avec le décodage vidéo HEVC, elles:

• [C-1-1] DOIT prendre en charge le décodage des images HEIF (HEIC).

Décodeurs d'images compatibles avec un format à profondeur de bits élevée (9 bits ou plus 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 d'image

Format/Codec	Détails	Types de fichiers/Formats de conteneurs compatibles
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) via CodecCapabilities.

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

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

5.1.7. Codecs vidéo

• Pour une qualité acceptable du streaming vidéo Web et des services de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel qui répond aux exigences.

Si les implémentations de l'appareil 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 peuvent accueillir le plus grand frame compressé et non compressé possible, comme dicté par la norme et la configuration, mais aussi ne pas surallouer.

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

• [C-1-3] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de prendre en charge les deux.

• [SR-1] Il est FORTEMENT RECOMMANDÉ que les encodeurs et les décodeurs vidéo soient compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire optimisé matériellement (YV12, NV12, NV21 ou format optimisé par le fournisseur équivalent).

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

Si les implémentations d'appareils annoncent la compatibilité avec le profil HDR via Display.HdrCapabilities, elles:

• [C-2-1] DOIT être compatible avec l'analyse et la gestion des métadonnées statiques HDR.

Si les implémentations d'appareils annoncent la prise en charge de l'actualisation intra via FEATURE_IntraRefresh dans la classe MediaCodecInfo.CodecCapabilities, elles:

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

Sauf indication contraire de l'application à l'aide de la clé de format KEY_COLOR_FORMAT, les implémentations de décodeur vidéo:

• [C-4-1] Le format de couleur optimisé pour l'affichage matériel doit être utilisé par défaut si la sortie est configurée à l'aide de Surface.
• [C-4-2] DOIT utiliser par défaut un format de couleur YUV420 8:8:8 optimisé pour la lecture par CPU si la sortie Surface n'est pas utilisée.

5.1.8. Liste des codecs vidéo

Format/Codec	Détails	Types de fichiers/Formats de conteneurs compatibles
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
H.264 AVC	Pour en savoir plus, consultez les sections 5.2 et 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, non accessible en lecture) Matroska (.mkv, décodage uniquement)
H.265 HEVC	Pour en savoir plus, consultez la section 5.3.	MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
MPEG-2	Main Profile	MPEG2-TS (.ts, non accessible en lecture) MPEG-4 (.mp4, décodage uniquement) Matroska (.mkv, décodage uniquement)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, décodage uniquement)
VP8	Pour en savoir plus, consultez les sections 5.2 et 5.3.	WebM (.webm) Matroska (.mkv)
VP9	Pour en savoir plus, consultez la section 5.3.	WebM (.webm) Matroska (.mkv)

5.1.9. Sécurité des codecs multimédias

Les implémentations d'appareils DOIVENT garantir la conformité aux fonctionnalités de sécurité des codecs multimédias, comme décrit ci-dessous.

Android est compatible avec OMX, une API d'accélération multimédia multiplate-forme, ainsi qu'avec Codec 2.0, une API d'accélération multimédia à faible coût.

Si les implémentations d'appareils sont compatibles avec les contenus multimédias, elles:

• [C-1-1] DOIT prendre en charge les codecs multimédias via les API OMX ou Codec 2.0 (ou les deux), comme dans le Projet Android Open Source, et ne doit pas désactiver ni contourner les protections de sécurité. Cela ne signifie pas spécifiquement que chaque codec DOIT utiliser l'API OMX ou Codec 2.0, mais seulement que la prise en charge d'au moins l'une de ces API DOIT être disponible, et que la prise en charge des API disponibles DOIT inclure les protections de sécurité présentes.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de l'API Codec 2.0.

Si les implémentations de l'appareil ne sont pas compatibles avec l'API Codec 2.0, elles:

• [C-2-1] DOIT inclure le codec logiciel OMX correspondant du projet Open Source Android (s'il est disponible) pour chaque format et type multimédia (encodeur ou décodeur) compatible avec l'appareil.
• [C-2-2] Codecs dont le nom commence par "OMX.google." DOIT être basé sur le code source du projet Android Open Source.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ que les codecs logiciels OMX s'exécutent dans un processus de codec qui n'a pas accès aux pilotes matériels autres que les mappeurs de mémoire.

Si les implémentations de l'appareil sont compatibles avec l'API Codec 2.0, elles:

• [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 multimédia (encodeur ou décodeur) compatible avec l'appareil.
• [C-3-2] DOIT héberger les codecs logiciels Codec 2.0 dans le processus de codec logiciel tel que fourni dans le projet Android Open Source pour permettre d'accorder un accès plus précis aux codecs logiciels.
• [C-3-3] Codecs dont le nom commence par "c2.android." DOIT être basé sur le code source du projet Android Open Source.

5.1.10. Caractérisation des codecs multimédias

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

• [C-1-1] DOIT renvoyer les valeurs correctes de la caractérisation du codec multimédia via l'API MediaCodecInfo.

En particulier :

• [C-1-2] Codecs dont le nom commence par "OMX." DOIVENT utiliser les API OMX et avoir des noms conformes aux consignes de dénomination OMX IL.
• [C-1-3] Codecs dont le nom commence par "c2." DOIVENT utiliser l'API Codec 2.0 et avoir des noms conformes aux consignes de dénomination Codec 2.0 pour Android.
• [C-1-4] Codecs dont le nom commence par "OMX.google." ou "c2.android." NE DOIT PAS être caractérisé comme fournisseur ou comme accélération matérielle.
• [C-1-5] Les codecs exécutés dans un processus de codec (fournisseur ou système) ayant accès à des pilotes matériels autres que les alloueurs et les mappeurs de mémoire NE DOIVENT PAS être caractérisés comme des logiciels uniquement.
• [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 caractérisés comme des fournisseurs.
• [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés comme tels.
• [C-1-8] Les noms de codecs NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIVENT prendre en charge le décodage, et ceux nommés "encodeurs" DOIVENT prendre en charge l'encodage. Les codecs dont le nom contient des formats multimédias DOIVENT prendre en charge ces formats.

Si les implémentations de l'appareil 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 réalisables 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 (H.263, MPEG-2, MPEG-4) 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)	1 408 x 1 152 px (H263) 1 280 x 720 px (autre)	1 920 x 1 080 px (autre que MPEG4)	3 840 x 2 160 px (HEVC, VP9)

• [C-2-2] Les codecs vidéo caractérisés comme accélérés matériellement DOIVENT publier des informations sur les points de performance. Ils DOIVENT chacun lister tous les points de performances standards compatibles (listés dans l'API PerformancePoint), sauf s'ils sont couverts par un autre point de performances standards compatible.
• De plus, ils DOIVENT publier des points de performance étendus s'ils prennent en charge des performances vidéo soutenues autres que l'une des performances standards listées.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le rendent disponible pour les applications tierces, elles:

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

Si les implémentations d'appareils incluent un écran intégré dont la diagonale mesure au moins 6,3 cm, ou incluent un port de sortie vidéo ou déclarent la prise en charge d'une caméra via le flag de fonctionnalité android.hardware.camera.any, elles:

• [C-1-1] DOIT inclure la prise en charge d'au moins l'un des encodeurs vidéo VP8 ou H.264, et le mettre à la disposition des applications tierces.
• DOIT être compatible avec les encodeurs vidéo VP8 et H.264, et les mettre à la disposition des applications tierces.

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

• [C-2-1] DOIT prendre en charge les débits configurables dynamiquement.
• DOIT prendre en charge les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son 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, elles:

• DOIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image accélérés par matériel, et prennent en charge une ou plusieurs caméras matérielles connectées ou enfichables exposées via les API android.camera:

• [C-4-1] Tous les encodeurs vidéo et d'image avec accélération matérielle DOIVENT prendre en charge l'encodage des images de la ou des caméras matérielles.
• DOIT 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 fournissent un encodage HDR, elles:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir un plug-in pour l'API de transcodage fluide afin de convertir le format HDR au format SDR.

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et les rendent disponibles pour les applications tierces, elles:

• [C-1-1] DOIT être compatible avec le niveau de profil de référence 45.
• DOIT prendre en charge les débits configurables de manière dynamique pour l'encodeur compatible.

5.2.2. H.264

Si les implémentations de l'appareil sont compatibles avec le codec H.264, elles:

• [C-1-1] DOIT prendre en charge le niveau 3 du profil de référence. Toutefois, la prise en charge de l'ordre des tranches arbitraire (ASO), de l'ordre des macroblocs flexible (FMO) et des tranches redondantes (RS) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
• [C-1-2] DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) du tableau suivant.
• DOIT 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 signalent la prise en charge 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 prendre en charge les profils d'encodage du tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	20 fps	30 ips	30 ips	30 ips
Débit vidéo	384 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.3. VP8

Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:

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

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

• [C-2-1] DOIT prendre en charge les profils d'encodage du tableau suivant.

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	800 Kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.4. VP9

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

• [C-1-2] DOIT être compatible avec le profil 0 de niveau 3.
• [C-1-1] DOIT être compatible avec l'écriture de fichiers WebM Matroska.
• [C-1-3] DOIT générer des données CodecPrivate.
• DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
• [C-SR-1] Il est vivement recommandé de prendre en charge les profils de décodage HD, comme indiqué dans le tableau suivant, en présence d'un encodeur matériel.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils prétendent prendre en charge le profil 2 ou le profil 3 via les API Media:

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

5.2.5. H.265

Si les implémentations de l'appareil sont compatibles avec le codec H.265, elles:

• [C-1-1] DOIT être compatible avec le profil principal de niveau 3.
• DOIT prendre en charge les profils d'encodage HD indiqués dans le tableau suivant.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les profils d'encodage HD, comme indiqué dans le tableau suivant, en cas de présence d'un encodeur matériel.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.3. Décodage vidéo

Si les implémentations de l'appareil sont compatibles avec les codecs VP8, VP9, H.264 ou H.265, elles:

• [C-1-1] DOIT prendre en charge la résolution vidéo dynamique et le changement de fréquence d'images 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 prise en charge par chaque codec sur l'appareil.

5.3.1. MPEG-2

Si les implémentations d'appareils sont compatibles avec les décodeurs MPEG-2, elles:

• [C-1-1] DOIT prendre en charge le profil principal de niveau élevé.

5.3.2. H.263

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

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

5.3.3. MPEG-4

Si les implémentations d'appareils sont équipées de décodeurs MPEG-4:

• [C-1-1] DOIT être compatible avec le profil simple de niveau 3.

5.3.4. H.264

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

• [C-1-1] DOIT prendre en charge le profil principal de niveau 3.1 et le profil de référence. La prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE.
• [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (Standard Definition) listés dans le tableau suivant et encodés avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
• DOIT être capable de décoder les vidéos avec les profils HD (haute définition) 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 de l'appareil:

• [C-2-1] DOIT prendre en charge les profils de décodage vidéo HD 720p indiqués dans le tableau suivant.
• [C-2-2] DOIT prendre en charge les profils de décodage vidéo HD 1080p 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	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	60 FPS	30 FPS (60 FPS 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 de l'appareil sont compatibles avec le codec H.265, elles:

• [C-1-1] DOIT prendre en charge le niveau 3 du profil principal et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
• [C-1-2] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant en cas de présence d'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, procédez comme suit:

• [C-2-1] Les implémentations d'appareils DOIVENT prendre en charge au moins l'un des formats de décodage H.265 ou VP9 des profils 720p, 1080p 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	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30/60 FPS (60 FPS pour les téléviseurs 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 prétendent être compatibles avec un profil HDR via les API multimédias:

• [C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises de l'application, ainsi que permettre d'extraire et de générer les 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, par exemple).

5.3.6. VP8

Si les implémentations de l'appareil sont compatibles avec le codec VP8, elles:

• [C-1-1] DOIT prendre en charge les profils de décodage SD du tableau suivant.
• DOIT utiliser un codec VP8 matériel qui répond aux exigences.
• DOIT prendre en charge les profils de décodage HD du tableau suivant.

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 FPS (60 FPS pour la télévision)	30 (60 images par secondeTélévision)
Débit vidéo	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.7. VP9

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

• [C-1-1] DOIT prendre en charge les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.

Si les implémentations de l'appareil 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, 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, procédez comme suit:

• [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 720p, 1080p 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	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 FPS (60 FPS sur les téléviseurs avec décodage matériel du format 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 de l'appareil prétendent ê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 de l'appareil prétendent prendre en charge 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, par exemple).

5.3.8. Dolby Vision

Si les implémentations d'appareils déclarent la prise en charge du décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION, elles:

• [C-1-1] DOIT fournir un extracteur compatible avec 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, par exemple).
• [C-1-3] L'indice de piste de la ou des couches de base rétrocompatibles (le cas échéant) DOIT être identique à celui de la couche Dolby Vision combinée.

5.3.9. AV1

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

• [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 listées comme "DÉSIRABLE" depuis Android 4.3, la définition de la compatibilité pour les futures versions prévoit de les remplacer par "OBLIGATOIRE". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences listées comme "DOIT", sinon ils ne pourront pas être compatibles avec Android lors de la mise à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

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

• [C-1-1] DOIT permettre la capture de contenu audio brut avec les caractéristiques suivantes:

  • Format: PCM linéaire, 16 bits
  • Taux d'échantillonnage: 8 000, 11 025, 16 000, 44 100 et 48 000 Hz
  • Canaux: mono

• DOIT permettre la capture de contenu audio brut avec 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 et 48 000 Hz
  • Canaux: autant de canaux que de micros sur l'appareil

• [C-1-2] DOIT capturer à des taux d'échantillonnage supérieurs sans mise à l'échelle.

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

• DOIT permettre la capture de contenu audio brut en qualité radio AM et DVD, ce qui signifie que les caractéristiques suivantes doivent être respectées:

  • 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 sur les micros disponibles sur l'appareil accessibles aux applications tierces via l'API AudioManager.getMicrophones(), ainsi que les micros actuellement actifs accessibles aux applications tierces via les API AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones(). Si les implémentations d'appareils permettent de capturer du contenu audio brut en qualité radio AM et DVD, elles:

• [C-2-1] DOIT capturer sans mise à l'échelle à un format supérieur à 16 000:22 050 ou 44 100:48 000.

• [C-2-2] DOIT inclure un filtre anticrénelage approprié pour tout suréchantillonnage ou sous-échantillonnage.

5.4.2. Enregistrer pour la reconnaissance vocale

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

• [C-1-1] DOIT capturer la source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION à l'un des taux d'échantillonnage, 44 100 et 48 000.
• [C-1-2] DOIT, par défaut, désactiver tout traitement audio de réduction du bruit lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
• [C-1-3] DOIT, par défaut, désactiver tout contrôle automatique du gain lors de l'enregistrement d'un flux audio à partir de la source audio AudioSource.VOICE_RECOGNITION.
• DOIT enregistrer le flux audio de reconnaissance vocale avec des caractéristiques d'amplitude à fréquence à peu près plates: plus précisément, ±3 dB, de 100 Hz à 4 000 Hz.
• DOIT enregistrer le flux audio de reconnaissance vocale avec une sensibilité d'entrée définie de sorte qu'une source de niveau de puissance acoustique (SPL) de 90 dB à 1 000 Hz génère une valeur efficace de 2 500 pour les échantillons 16 bits.
• DOIT enregistrer le flux audio de reconnaissance vocale de sorte que les niveaux d'amplitude PCM suivent de manière linéaire les variations du niveau de pression acoustique d'entrée sur une plage d'au moins 30 dB, de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
• DOIT enregistrer le flux audio de reconnaissance vocale avec un taux de distorsion harmonique totale (THD) inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.

Si les implémentations d'appareils déclarent des technologies android.hardware.microphone et de suppression (réduction) du bruit optimisé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. Capture pour le redirignement de 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 afin que, lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle capture un mix de tous les flux audio, à l'exception des éléments suivants:

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

5.4.4. Annulation de l'écho acoustique

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

• DOIT implémenter une technologie d'annulation de l'écho acoustique (AEC) adaptée à la communication vocale et appliquée au chemin de capture lors de la capture à l'aide de AudioSource.VOICE_COMMUNICATION

Si les implémentations d'appareils fournissent un système d'annulation de l'écho acoustique qui est inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION est sélectionné, elles:

• [C-SR-1] Il est FORTEMENT_RECOMMANDÉ de déclarer cela via la méthode de l'API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR-2] sont FORTEMENT_RECOMMANDÉS pour permettre de contrôler cet effet audio avec l'API AcousticEchoCanceler.
• [C-SR-3] Il est FORTEMENT_RECOMMANDÉ d'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 qui capture avec n'importe quel AudioSource.
• [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application de capture avec 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 effectue une capture avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application effectue une 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) disposant de l'autorisation CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Si deux applications ou plus effectuent une capture en même temps et si aucune d'elles n'a d'UI en superposition, celle qui a commencé la capture le plus récemment reçoit l'audio.

5.4.6. Niveaux de gain du micro

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

• DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près 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.
• DOIT définir la sensibilité d'entrée audio de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 90 dB génère une réponse avec une valeur efficace de 2 500 pour des échantillons de 16 bits (ou -22,35 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chaque microphone utilisé pour enregistrer la source audio de reconnaissance vocale.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de présenter des niveaux d'amplitude dans la plage de fréquences basses: 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 de reconnaissance vocale.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de présenter des niveaux d'amplitude dans la plage de fréquences élevées: en particulier de ±30 dB de 4 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

5.5. Lecture audio

Android permet aux applications de lire de l'audio via le périphérique de sortie audio, comme défini dans la section 7.8.2.

5.5.1. Lecture audio brute

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

• [C-1-1] DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:

  • Formats source: PCM linéaire, 16 bits, 8 bits, virgule flottante
  • Chaînes: mono, stéréo, configurations multicanaux valides avec jusqu'à huit canaux
  • Taux d'échantillonnage (en Hz) :
    • 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100 et 48 000 pour les configurations de canaux indiquées ci-dessus
    • 96 000 Hz en mono et stéréo

5.5.2. Effets audio

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

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

• [C-1-1] DOIT prendre en charge les implémentations EFFECT_TYPE_EQUALIZER et EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via les sous-classes AudioEffect Equalizer et LoudnessEnhancer.
• [C-1-2] DOIT prendre en charge l'implémentation de l'API de visualisation, qui peut être contrôlée via la classe Visualizer.
• [C-1-3] DOIT prendre en charge l'implémentation EFFECT_TYPE_DYNAMICS_PROCESSING contrôlable via la sous-classe AudioEffect DynamicsProcessing.
• DOIT prendre en charge les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER contrôlées via les sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge les effets en virgule flottante et multicanaux.

5.5.3. Volume de sortie audio

Implémentations d'appareils automobiles:

• DOIT permettre d'ajuster le volume audio séparément pour chaque flux audio à l'aide du type de contenu ou de l'utilisation définis par AudioAttributes et de l'utilisation audio de la voiture telle que définie publiquement dans android.car.CarAudioManager.

5.5.4. Déchargement audio

Si les implémentations d'appareils sont compatibles avec la lecture de transfert audio, elles:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de couper le contenu audio sans coupure lu lorsqu'il est spécifié par l'API AudioTrack gapless et le conteneur multimédia pour MediaPlayer.

5.6. Latence audio

La latence audio correspond au délai de transmission d'un signal audio dans un système. De nombreuses classes d'applications s'appuient sur des latences courtes pour obtenir des effets sonores en temps réel.

Aux fins de cette section, utilisez les définitions suivantes:

• latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodées en PCM et le moment où le son correspondant est présenté à l'environnement à un transducteur sur l'appareil ou où le signal quitte l'appareil via un port et peut être observé de l'extérieur.
• Latence de sortie à froid Temps écoulé entre le démarrage d'un flux de sortie et l'heure de présentation du premier frame en fonction des codes temporels, lorsque le système de sortie audio était inactif et éteint avant la requête.
• latence de sortie continue. La latence de sortie pour les frames suivants, une fois que l'appareil lit de l'audio.
• 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 le moment où une application lit le frame correspondant de données codées PCM.
• perte d'entrée. Portion initiale d'un signal d'entrée inutilisable ou indisponible.
• Latence d'entrée à froid Temps écoulé entre le début du flux et la réception du premier frame valide, lorsque le système d'entrée audio était inactif et éteint avant la requête.
• latence d'entrée continue ; La latence d'entrée pour les images suivantes, lorsque l'appareil capture l'audio.
• jitter de sortie à froid. Variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
• jitter d'entrée à froid. Variabilité entre les mesures distinctes des valeurs de latence d'entrée à froid.
• latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. La période de mise en tampon permet à l'application de traiter le signal et de réduire la différence de phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android.
• API audio native AAudio Ensemble des API AAudio dans le NDK Android.
• Code temporel. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.
• glitch. Interruption temporaire ou valeur d'échantillon incorrecte dans le signal audio, généralement causée par un dépassement de la mémoire tampon pour la sortie, un dépassement de la mémoire tampon pour l'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 de pression sur le bouton pour obtenir un son Intervalle de temps entre l'appui sur l'écran et l'émission d'une tonalité générée par cet appui sur le haut-parleur.

Si les implémentations d'appareils déclarent android.hardware.audio.output, elles DOIVENT respecter 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 ms ou moins.

Si les implémentations d'appareils déclarent android.hardware.audio.output, il est FORTEMENT 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 de l'enceinte. Il est vivement recommandé que les appareils existants et les nouveaux appareils exécutant cette version d'Android répondent dès maintenant à ces exigences. Dans une prochaine version de la plate-forme, nous exigerons une latence de sortie à froid de 200 ms ou moins.
• [C-SR-2] Latence de 80 ms ou moins entre le contact et le son
• [C-SR-3] Minimisez le jitter de sortie à froid.
• [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, lorsque vous utilisez l'API audio native AAudio, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, elles sont les suivantes:

• [C-SR-5] IL EST FORTEMENT RECOMMANDÉ de signaler l'audio à faible latence en déclarant le flag de fonctionnalité android.hardware.audio.low_latency.
• [C-SR-6] IL EST FORTEMENT RECOMMANDÉ de respecter les exigences concernant l'audio à faible latence via l'API AAudio.
• [C-SR-7] Nous vous recommandons vivement de vous 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 à celle 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 signaler la prise en charge de l'audio à faible latence.

Si les implémentations d'appareils incluent android.hardware.microphone, elles DOIVENT respecter les exigences suivantes concernant l'entrée audio:

• [C-3-1] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 2 ms. "Erreur" signifie ici l'écart par rapport à la valeur correcte.
• [C-3-2] Latence d'entrée à froid de 500 ms ou moins.

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

• [C-SR-8] Latence d'entrée à froid de 100 millisecondes ou moins sur le chemin de données du micro. Il est vivement recommandé que les appareils existants et les nouveaux appareils exécutant cette version d'Android respectent dès maintenant ces exigences. Dans une prochaine version de la plate-forme, nous exigerons une latence d'entrée à froid de 200 ms ou moins.
• [C-SR-9] Latence d'entrée continue de 30 millisecondes ou moins.
• [C-SR-10] Minimisez le jitter d'entrée à froid.
• [C-SR-11] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

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

• [C-SR-12] Il est vivement recommandé d'avoir une latence aller-retour moyenne continue de 50 ms ou moins sur cinq mesures, avec une déviation absolue moyenne inférieure à 10 ms, sur au moins un chemin compatible.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT prendre en charge les protocoles de réseau multimédia pour la lecture audio et vidéo, comme indiqué 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 être compatible avec les formats de segments multimédias correspondants, comme indiqué dans le tableau des formats de segments multimédias ci-dessous, sur le protocole de streaming HLS, 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 connaître les exceptions, veuillez consulter les notes de bas de page du tableau dans la section 5.1.

Formats de segments multimédias

Formats de segments	Référence(s)	Compatibilité avec les codecs requise
MPEG-2 Transport Stream	ISO 13818	Codecs vidéo : H264 AVC MPEG-4 SP MPEG-2 Pour en savoir plus sur les formats H.264 AVC, MPEG2-4 SP et MPEG-2,consultez la section 5.1.8. Codecs audio: AAC Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.3.
AAC avec cadrage ADTS et tags ID3	ISO 13818-7	Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1 .
WebVTT	WebVTT

RTSP (RTP, SDP)

Nom du profil	Référence(s)	Compatibilité avec les codecs requise
H264 AVC	RFC 6184	Pour en savoir plus sur le format H264 AVC, consultez la section 5.1.8.
MP4A-LATM	RFC 6416	Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.3.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Pour en savoir plus sur le format H.263, consultez la section 5.1.8.
H263-2000	RFC 4629	Pour en savoir plus sur le format H.263, consultez la section 5.1.8.
AMR	RFC 4867	Pour en savoir plus sur AMR-NB, consultez la section 5.1.3.
AMR-WB	RFC 4867	Pour en savoir plus sur AMR-WB, consultez la section 5.1.3.
MP4V-ES	RFC 6416	Pour en savoir plus sur MPEG-4 SP, consultez la section 5.1.8.
mpeg4-generic	RFC 3640	Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.3.
MP2T	RFC 2250	Pour en savoir plus, consultez la section MPEG-2 Transport Stream sous HTTP Live Streaming.

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec la sortie vidéo sécurisée et peuvent prendre en charge les surfaces sécurisées, elles:

• [C-1-1] DOIT déclarer la prise en charge de Display.FLAG_SECURE.

Si les implémentations d'appareils déclarent être compatibles avec Display.FLAG_SECURE et le protocole d'affichage sans fil, elles:

• [C-2-1] La liaison doit être sécurisée à l'aide d'un mécanisme cryptographique puissant tel que HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil tels que Miracast.

Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE et de l'écran externe filaire, elles:

• [C-3-1] DOIT être compatible avec HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible par l'utilisateur.

5.9. MIDI (Musical Instrument Digital Interface)

Si les implémentations d'appareils signalent la prise en charge de la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager, elles:

• [C-1-1] DOIT prendre en charge le MIDI sur tous les transports matériels compatibles avec le MIDI pour lesquels ils fournissent une connectivité générique non MIDI, où ces transports sont:

  • Mode hôte USB, section 7.7
  • MIDI sur Bluetooth LE dans le rôle de maître, section 7.4.3

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

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

• DOIT prendre en charge le mode MIDI sur le périphérique USB, section 7.7

5.10. Audio professionnel

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

• [C-1-1] DOIT indiquer la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
• [C-1-2] La latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, DOIT être de 20 millisecondes ou moins et DEVRAIT être de 10 millisecondes ou moins sur au moins un chemin pris en charge.
• [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et le mode périphérique USB.
• [C-1-4] DOIT indiquer 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 audio native AAudio.
• [C-1-6] La latence de sortie à froid doit être inférieure ou égale à 200 ms.
• [C-1-7] La latence d'entrée à froid doit être inférieure ou égale à 200 millisecondes.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de respecter les latences définies dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à cinq millisecondes sur le chemin de l'enceinte au micro.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de respecter les exigences de l'audio professionnel en termes de latence audio aller-retour continue, de latence d'entrée à froid et de latence de sortie à froid, ainsi que les exigences audio USB à l'aide de l'API audio native AAudio sur le chemin MMAP.
• [C-SR-3] FORTEMENT RECOMMANDÉ pour fournir un niveau de performances de processeur cohérent lorsque l'audio est actif et que la charge du processeur varie. Cela doit être testé à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel exécuté sur un framework audio simulé qui mesure les performances du système. L'application SynthMark doit être exécutée à l'aide de l'option "Test automatique" et obtenir les résultats suivants :
  • voicemark.90 >= 32 voix
  • latencymark.fixed.little <= 15 ms
  • latencymark.dynamic.little <= 50 ms

Pour en savoir plus sur les benchmarks, consultez la documentation de SynthMark.

• DOIT minimiser l'imprécision et la dérive de l'horloge audio par rapport à l'heure normale.
• DOIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
• DOIT minimiser la latence audio sur les transducteurs de l'appareil.
• DOIT réduire la latence audio via l'audio numérique USB.
• DOIT documenter les mesures de la latence audio sur tous les chemins.
• DOIT minimiser le jitter dans les temps d'entrée du rappel de finalisation du tampon audio, car cela affecte le pourcentage utilisable de la bande passante du processeur par le rappel.
• DOIT ne présenter aucun glitch audio en conditions d'utilisation normales avec la latence indiquée.
• DOIT fournir une différence de latence intercanal nulle.
• DOIT réduire la latence moyenne MIDI sur tous les transports.
• DOIT minimiser la variabilité de la latence MIDI sous charge (jitter) sur tous les transports.
• DOIT fournir des codes temporels MIDI précis sur tous les transports.
• DOIT réduire le bruit du signal audio sur les transducteurs de l'appareil, y compris la période immédiatement après le démarrage à froid.
• DOIT fournir une différence de horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Le micro et le haut-parleur de l'appareil, ou l'entrée et la sortie du connecteur audio, sont des exemples de points de terminaison correspondants.
• DOIT gérer les rappels de fin de 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 entrer dans le rappel de sortie immédiatement après le retour du rappel d'entrée. Ou si vous ne pouvez pas gérer les rappels sur le même thread, saisissez le rappel de sortie peu de temps après avoir saisi le rappel d'entrée pour permettre à l'application de disposer d'un timing cohérent pour les côtés d'entrée et de sortie.
• DOIT minimiser la différence de phase entre le tamponnage audio HAL pour les côtés d'entrée et de sortie des points de terminaison correspondants.
• DOIT réduire la latence tactile.
• DOIT minimiser la variabilité de la latence tactile sous charge (jitter).
• La latence entre l'entrée tactile et la sortie audio doit être inférieure ou égale à 40 ms.

Si les implémentations de l'appareil répondent à toutes les exigences ci-dessus, elles:

• [C-SR-4] Il est vivement recommandé de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

Si les implémentations d'appareils incluent un connecteur audio 3,5 mm à quatre conducteurs, elles:

• [C-2-1] DOIT avoir une latence audio aller-retour continue moyenne, comme défini dans la section 5.6 Latence audio, de 20 millisecondes ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à cinq millisecondes sur le chemin du connecteur audio.
• [C-SR-5] Il est vivement recommandé de respecter la section Spécifications de la prise de l'appareil mobile de la spécification des casques audio filaires (v1.1).

Si les implémentations d'appareils omettent une prise audio 3,5 mm à quatre conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB, elles:

• [C-3-1] DOIT implémenter la classe audio USB.
• [C-3-2] DOIT avoir une latence audio aller-retour continue moyenne de 25 ms ou moins, sur cinq mesures avec une déviation absolue moyenne inférieure à 5 ms sur le port en mode hôte USB à l'aide de la classe audio USB. (cela peut être mesuré à l'aide d'un adaptateur USB-3,5 mm et d'un dongle Audio Loopback, 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 dans chaque sens, un taux d'échantillonnage de 96 kHz et une profondeur de 24 bits ou 32 bits, lorsqu'ils sont utilisés avec des périphériques audio USB qui répondent également à ces exigences.
• [C-SR-7] Il est vivement recommandé de répondre à ce groupe d'exigences à l'aide de l'API audio native AAudio sur le chemin MMAP.

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

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

5.11. Capturer pour Unprocessed

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

Si les implémentations d'appareils visent à prendre en charge la source audio non traitée et à la mettre à la disposition des applications tierces, elles:

• [C-1-1] DOIT indiquer la prise en charge via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près 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 de basse fréquence: plus précisément, de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquence moyenne 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 de fréquences élevées: plus précisément, de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes 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é sinusoïdale de 1 000 Hz lue à 94 dB de niveau de pression acoustique (SPL) génère une réponse avec une RMS de 520 pour des échantillons 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-6] Le rapport signal/bruit (SNR) doit être de 60 dB ou plus pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que le rapport signal/bruit est mesuré comme la différence entre 94 dB SPL et le niveau de pression acoustique équivalent du bruit propre, pondéré A).

• [C-1-7] Le taux de distorsion harmonique totale (THD) doit être inférieur à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-8] Le chemin ne doit comporter aucun autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou suppression de l'écho) que le multiplicateur de niveau pour ajuster le niveau à la plage souhaitée. Autrement dit :

  • [C-1-9] Si un traitement du signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et ne doit pas entraîner de retard ni de latence supplémentaire sur le chemin du signal.
  • [C-1-10] Le multiplicateur de niveau, bien qu'il soit autorisé sur le chemin, NE DOIT PAS entraîner de retard ni de latence sur le chemin du signal.

Toutes les mesures de niveau de pression acoustique sont effectuées directement à côté du micro testé. Pour les configurations à plusieurs micros, ces exigences s'appliquent à chaque micro.

Si les implémentations d'appareils déclarent android.hardware.microphone, mais ne sont pas compatibles avec la source audio non traitée, elles:

• [C-2-1] DOIT renvoyer null pour la méthode de l'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), afin d'indiquer correctement l'absence de prise en charge.
• [C-SR-1] est toujours FORTEMENT RECOMMANDÉ pour répondre au maximum aux exigences du chemin de signal de la source d'enregistrement non traitée.

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

6.1. Outils pour les développeurs

Implémentations de l'appareil:

• [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 l'AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys cmd stats
  • [C-0-11] La commande shell cmd testharness doit être prise en charge. La mise à niveau des implémentations d'appareils à partir d'une version antérieure d'Android sans bloc de données persistant peut être exemptée de C-0-11.
  • [C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) enregistrés 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 système StatsManager.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible à l'utilisateur DOIT être disponible pour activer le pont de débogage Android.
  • [C-0-5] DOIT prendre en charge adb sécurisé. Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus.
  • [C-0-6] DOIT fournir un mécanisme permettant à adb de se connecter à 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, elles:

  • [C-3-1] DOIT implémenter adb via un réseau local (tel qu'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 acceptent les connexions ADB à une machine hôte via le Wi-Fi, elles:

  • [C-4-1] La méthode AdbManager#isAdbWifiSupported() DOIT renvoyer true.

  Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via le Wi-Fi et incluent au moins une caméra, elles:

  • [C-5-1] La méthode AdbManager#isAdbWifiQrSupported() DOIT renvoyer true.

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.

• Singe

  • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.

• SysTrace

  • [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.

• Perfetto

  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'écrire en sortie une trace protobuf conforme au schéma défini dans la documentation Perfetto.
  • [C-SR-4] Il est FORTEMENT RECOMMANDÉ de fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation de perfetto.

• Tueur de mémoire faible

  • [C-0-10] DOIT écrire un atome LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le Low Memory Killer.

• Mode Test Harness Si les implémentations d'appareils sont compatibles avec la commande shell cmd testharness et exécutent cmd testharness enable, elles:

  • [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DOIT implémenter le mode Atelier de test comme décrit dans la documentation sur le mode Atelier de test.

Si les implémentations de l'appareil signalent la prise en charge de Vulkan 1.0 ou version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version, elles:

• [C-1-1] DOIT fournir une affordance permettant au développeur d'application d'activer/de désactiver les couches de débogage du GPU.
• [C-1-2] Lorsque les couches de débogage du GPU sont activées, le programme doit énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie de la plate-forme ou du package d'application) situées dans le répertoire de base des applications débogables pour 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. Elles doivent:

• [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 l'élément de menu Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version).
• [C-0-2] Les options pour les développeurs doivent être masquées par défaut.
• [C-0-3] DOIT fournir un mécanisme clair qui ne donne pas de traitement préférentiel à une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous devez fournir un document ou un site Web public décrivant comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible en tant que lien depuis les documents du SDK Android.
• DOIT envoyer une notification visuelle continue à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
• PEUT limiter temporairement l'accès au menu "Options pour les développeurs" en le masquant ou en le désactivant visuellement pour éviter toute distraction dans les 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éclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

• [C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) des API de composant 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 d'API DOIVENT renvoyer des valeurs nulles lorsque cela est autorisé par la documentation du SDK.
• [C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• [C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
• [C-0-7] Les implémentations d'appareils DOIVENT signaler 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 compilation.

L'API Telephony est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que les téléphones, ces API doivent être implémentées comme des opérations sans opération raisonnables.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les composants d'application et les mises en page de l'interface utilisateur en fonction de l'appareil pour s'assurer que les applications tierces fonctionnent correctement sur différentes configurations matérielles. Sur l'écran ou les écrans compatibles avec Android sur lesquels toutes les applications tierces compatibles avec Android peuvent s'exécuter, les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

Les unités référencées par les exigences de cette section sont définies comme suit:

• la taille diagonale physique ; Distance en pouces entre deux coins opposés de la partie éclairée de l'écran.
• points par pouce (ppp). Nombre de pixels compris dans une plage linéaire horizontale ou verticale de 1 pouce. Lorsque des valeurs de PPP sont indiquées, les PPP horizontaux et verticaux doivent se trouver dans la plage.
• format. Rapport entre les pixels de la dimension la plus longue et la dimension la plus courte de l'écran. Par exemple, un écran de 480 x 854 pixels correspond à 854/480 = 1,779, soit environ "16:9".
• pixels indépendants de la densité (dp). Unité de pixel virtuel normalisée à un écran de 160 ppp, calculée comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

7.1.1.1. Taille et forme de l'écran

Le framework d'UI Android est compatible avec différentes tailles de mise en page d'écran logiques et permet aux applications de interroger la taille de mise en page d'écran de la configuration actuelle via Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK et Configuration.smallestScreenWidthDp.

Implémentations de l'appareil:

• [C-0-1] DOIT indiquer la taille de mise en page correcte pour le Configuration.screenLayout, comme défini dans la documentation du SDK Android. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions d'écran logiques en pixels indépendants de la densité (dp) correctes, comme indiqué ci-dessous:

  • Les appareils dont la valeur Configuration.uiMode est définie sur une valeur autre que UI_MODE_TYPE_WATCH et qui indiquent une taille small pour Configuration.screenLayout DOIVENT avoir une taille d'au moins 426 dp x 320 dp.
  • Les appareils qui indiquent une taille normal pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 480 dp x 320 dp.
  • Les appareils qui signalent une taille large pour le Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
  • Les appareils qui indiquent une taille xlarge pour le 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> dans le fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.

• POURRAIENT avoir un ou plusieurs écrans compatibles avec Android avec des coins arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent un ou plusieurs écrans compatibles avec Android avec des coins arrondis, elles:

• [C-1-1] DOIT s'assurer qu'au moins l'une des conditions suivantes est remplie:

  • Le rayon des coins arrondis est inférieur ou égal à 38 dp.
  • Lorsqu'un cadre de 15 dp x 15 dp est ancré à chaque coin de l'affichage logique, au moins un pixel de chaque cadre est visible à l'écran.

• DOIT inclure une affordance utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles avec Android qui sont pliables, ou incluent une charnière pliable entre plusieurs panneaux d'affichage et rendent ces écrans disponibles pour afficher des applications tierces, elles:

• [C-2-1] DOIT implémenter la dernière version stable disponible de l'API extensions ou la version stable de l'API sidecar à utiliser par la bibliothèque Jetpack WindowManager.

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles avec Android qui sont pliables, ou une charnière entre plusieurs panneaux d'affichage, et si la charnière ou le pli croise 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 pliage via des extensions ou des API Sidecar.

Pour savoir comment implémenter correctement les API de sidecar ou d'extension, consultez la documentation publique de Jetpack WindowManager.

7.1.1.2. Format d'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour l'écran ou les écrans compatibles avec Android, le format de l'écran logique sur lequel les applications tierces sont affichées, qui peut être dérivé des valeurs de hauteur et de largeur signalées via les API view.Display et les API Configuration, DOIT respecter les exigences suivantes:

• [C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir une valeur de format inférieure ou égale à 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 peut être redimensionnée 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 pour lesquels Configuration.uiMode est défini sur UI_MODE_TYPE_WATCH DOIVENT avoir une valeur de format définie sur 1,0 (1:1).

7.1.1.3. Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT ne signaler qu'une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE. Cette valeur NE DOIT PAS changer à tout moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications apportées par l'utilisateur à la configuration de l'écran (taille de l'écran, par exemple) après le démarrage initial.

• Les implémentations d'appareils DOIVENT définir la densité de framework Android standard la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique fait passer la taille d'écran signalée en dessous de la taille minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement de la densité physique donne une taille d'écran inférieure à la plus petite taille d'écran compatible prise en charge (320 dp de largeur), les implémentations d'appareil DOIVENT indiquer la densité du framework Android standard la plus basse.

Si une affordance permet de modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille de l'écran NE DOIT PAS être agrandie de plus de 1,5 fois la densité native ni produire une dimension d'écran 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 réduite à moins de 0,85 fois la densité native.
• Pour garantir une bonne usabilité et des tailles de police cohérentes, nous vous RECOMMANDONS de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
  • Petite: 0,85x
  • Par défaut: 1x (échelle d'affichage native)
  • Grande: 1,15 x
  • Plus grand: x 1,3
  • Plus grande : x 1,45

7.1.2. Métriques sur le Réseau Display

Si les implémentations d'appareils incluent l'écran ou la sortie vidéo compatible avec Android sur l'écran ou les écrans compatibles avec Android, 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 intégré ni de sortie vidéo, elles:

• [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible avec Android, comme défini dans l'API android.util.DisplayMetrics pour l'view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations de l'appareil:

• [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 doté d'un écran en mode paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement signaler android.hardware.screen.landscape.
• [C-0-2] DOIT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'il est interrogé via les API android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres.

Si les implémentations de l'appareil sont compatibles avec les deux orientations d'écran, elles:

• [C-1-1] DOIT être compatible avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique.
• [C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran indiquées lorsque l'orientation change.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

7.1.4. Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations de l'appareil:

• [C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode GLES10.getString()) et les API natives.
• [C-0-2] DOIT inclure la prise en charge de toutes les API gérées et API natives correspondantes pour toutes les versions OpenGL ES qu'il a identifiées comme compatibles.

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
• DOIT être compatible avec OpenGL ES 3.2.

Les tests dEQP OpenGL ES sont partitionnés en plusieurs listes de tests, chacune associée à une date/un numéro de version. Ils se trouvent dans l'arborescence source Android à l'emplacement external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt. Un appareil compatible avec OpenGL ES à un niveau autodéclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests à partir de ce niveau et versions antérieures.

Si les implémentations de l'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles:

• [C-2-1] DOIT signaler via les API gérées OpenGL ES et les API natives toutes les autres extensions OpenGL ES qu'il a implémentées, et inversement DOIT NE PAS signaler les chaînes d'extension qu'il n'est pas compatible.
• [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 OpenGL ES compatibles via le commutateur de fonctionnalité android.software.opengles.deqp.level.
• [C-2-4] DOIT prendre en charge au moins 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 figurant dans les listes de tests entre la version 132383489 et la version spécifiée dans le flag de fonctionnalité android.software.opengles.deqp.level, pour chaque version d'OpenGL ES compatible.
• [C-SR-2] Il est vivement recommandé de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
• DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture compatible, qui est généralement spécifique au fournisseur.

Si les implémentations de l'appareil déclarent la prise en charge d'OpenGL ES 3.0, 3.1 ou 3.2, elles:

• [C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension OES_EGL_image_external_essl3.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.2, elles:

• [C-4-1] DOIT être compatible avec l'intégralité du pack d'extensions Android OpenGL ES.

Si les implémentations de l'appareil sont entièrement compatibles avec le pack d'extensions Android OpenGL ES, elles:

• [C-5-1] Vous devez identifier la prise en charge via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils exposent la prise en charge de l'extension EGL_KHR_mutable_render_buffer, elles:

• [C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple d'utilisation pour les graphismes 3D hautes performances.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.1, elles:

• [C-SR-1] Nous vous RECOMMANDONS vivement d'inclure la prise en charge de Vulkan 1.1.

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

• DOIT inclure la compatibilité avec Vulkan 1.1.

Les tests dEQP Vulkan sont partitionnés en plusieurs listes de tests, chacune avec une date/version associée. Ils se trouvent dans l'arborescence source Android à l'emplacement external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un appareil compatible avec Vulkan à un niveau autodéclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests à partir de ce niveau et versions antérieures.

Si les implémentations de l'appareil 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 VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().
• [C-1-3] DOIT implémenter entièrement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
• [C-1-4] DOIT énumérer les calques, contenus dans des bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties().
• [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de tracer ou d'intercepter l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
• [C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan , et inversement NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.
• [C-1-7] DOIT être compatible avec 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 via l'indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-9] DOIT au moins prendre en charge la version 132317953 (à partir du 1er mars 2019) comme indiqué dans le flag de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-10] Tous les tests Vulkan dEQP des listes de tests entre la version 132317953 et la version spécifiée dans l'indicateur de fonctionnalité android.software.vulkan.deqp.level DOIVENT réussir.
• [C-1-11] NE DOIT PAS énumérer la prise en charge des extensions VK_KHR_video_queue, VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions VK_KHR_driver_properties et VK_GOOGLE_display_timing.

Si les implémentations de l'appareil ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer l'un des commutateurs de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations de l'appareil incluent la prise en charge de Vulkan 1.1 et déclarent l'un des commutateurs de fonctionnalité Vulkan, elles:

• [C-3-1] DOIT exposer la prise en charge des types de sémaphores et de poignées externes SYNC_FD, ainsi que de l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT être compatibles avec Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations de l'appareil:

• [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 View Android.
• [C-0-2] DOIT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations de l'appareil:

• [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 à large gamme de couleurs

Si les implémentations d'appareils déclarent prendre en charge les écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut() , elles:

• [C-1-1] L'écran doit être calibré en couleur.
• [C-1-2] L'écran doit couvrir entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
• [C-1-3] L'écran doit avoir une gamme dont la surface est d'au moins 90% de la gamme DCI-P3 dans l'espace xyY CIE 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
• [C-1-5] DOIT indiquer la prise en charge des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR-1] Il est vivement recommandé de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles:

• [C-2-1] DOIT couvrir au moins 100% de l'espace sRGB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Ancien mode de compatibilité des applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent à la taille d'écran "normale" (largeur de 320 dp) pour le bénéfice des anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran.

7.1.6. Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur un écran compatible avec Android. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.

Tous les écrans Android compatibles d'une implémentation d'appareil:

• [C-0-1] DOIT être capable de générer des graphismes couleur 16 bits.
• DOIT être compatible avec les écrans capables d'afficher des graphiques couleur 24 bits.
• [C-0-2] DOIT être capable d'afficher des animations.
• [C-0-3] Le format de pixel (PAR) doit être compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du format carré (1,0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires compatibles avec Android pour permettre les fonctionnalités de partage multimédia et les API de développement pour accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou intégrée, elles:

• [C-1-1] DOIT implémenter le service et l'API système DisplayManager comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations de l'appareil:

• [C-0-1] DOIT inclure un mécanisme de saisie, 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 incluent la prise en charge d'applications tierces d'éditeur de mode de saisie (IME), elles:

• [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité android.software.input_methods.
• [C-1-2] DOIT implémenter entièrement Input Management Framework
• [C-1-3] Un clavier logiciel doit être préinstallé.

Implémentations de l'appareil:

• [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).
• DOIT inclure des implémentations de clavier virtuel supplémentaires.
• POURRA inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, le trackball et la roue comme mécanismes de navigation non tactile.

Implémentations de l'appareil:

• [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 d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas 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 les applications installées qui ont une activité avec <intent-filter> défini avec ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations d'appareils de télévision. La fonction "Accueil" DOIT être le mécanisme de cette affordance utilisateur.
• DOIT fournir des boutons pour les fonctions "Recents" (Actions récentes) et "Back" (Retour).

Si les fonctions Accueil, Récents ou Retour sont fournies, elles:

• [C-1-1] DOIT être accessible par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) si l'une de ces actions est accessible.
• [C-1-2] DOIT indiquer clairement quelle action déclenchera chaque fonction. L'ajout d'une icône visible sur le bouton, l'affichage d'une icône logicielle dans la partie de la barre de navigation de l'écran ou la conduite de l'utilisateur à travers un flux de démonstration guidé par étapes lors de la configuration prête à l'emploi sont des exemples d'indications de ce type.

Implémentations de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas fournir le mécanisme d'entrée pour la fonction Menu, car elle est obsolète au profit de la barre d'action depuis Android 4.0.

Si les implémentations d'appareils fournissent la fonction Menu, elles:

• [C-2-1] Le bouton de menu à développer doit s'afficher chaque fois que le pop-up du menu à développer d'action n'est pas vide et que la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position du pop-up à développer d'action affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher le pop-up à développer 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 la rétrocompatibilité, elles:

• [C-3-1] DOIT mettre la fonction Menu à la disposition des applications lorsque targetSdkVersion est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils fournissent la fonction d'assistance, elles:

• [C-4-1] La fonction d'assistance doit être accessible par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont accessibles.
• [C-SR-2] Nous vous recommandons vivement d'utiliser l'appui prolongé sur la fonction HOME comme interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:

• [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications, et NE DOIVENT PAS masquer ni interférer d'une autre manière avec la partie de l'écran disponible pour les applications.
• [C-5-2] DOIT mettre à disposition une partie de l'écran pour les applications qui répondent aux exigences définies dans la section 7.1.1.
• [C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (également appelée barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() doit être utilisé UNIQUEMENT pour signaler la zone de reconnaissance gestuelle de Home.
• [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale, comme indiqué 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 tactiles commencent à être interceptés pour un geste système, si l'application de premier plan a déjà reçu un événement MotionEvent.ACTION_DOWN.
• [C-6-4] DOIT fournir une affordance utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
• DOIT fournir la fonction Accueil en balayant l'écran vers le haut depuis le bord inférieur de l'orientation actuelle de l'écran.
• DOIT fournir la fonctionnalité "Récents" en balayant l'écran vers le haut et en maintenant le geste avant de le relâcher, à partir de la même zone que le geste "Accueil".
• Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est fournie à partir de n'importe quel bord gauche ou droit de l'orientation actuelle de l'écran:

• [C-7-1] La fonction de navigation DOIT être "Retour" et fournie sous la forme d'un balayage à partir des bords gauche et droit de l'orientation actuelle de l'écran.
• [C-7-2] Si des panneaux système personnalisables à faire glisser sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante indiquant que le glissement vers l'intérieur appelle les panneaux susmentionnés, et donc pas "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur des bords de l'écran, mais il NE DOIT PAS occuper plus d'un tiers de la ou des bordures.
• [C-7-3] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, comme indiqué dans le SDK.
• [C-7-4] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE, les panneaux système personnalisables à balayer DOIVENT être masqués jusqu'à ce que l'utilisateur affiche ou éclaircisse les barres système (également appelées barre de navigation et barre d'état) telles qu'implémentées dans AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée par pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques d'entrée 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 n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés.

Implémentations de l'appareil:

• DOIT disposer d'un système d'entrée de pointeur (souris ou tactile).
• DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante.

Si les implémentations d'appareils incluent un écran tactile (à un seul contact ou mieux) sur un écran principal compatible avec Android, elles:

• [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ de l'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 capable de suivre plusieurs gestes sur un écran principal compatible avec Android, elles:

• [C-2-1] DOIT indiquer les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils s'appuient sur un périphérique d'entrée externe tel qu'une souris ou un trackball (c'est-à-dire qu'ils ne touchent pas directement l'écran) pour la saisie sur un écran principal compatible avec Android et qu'ils répondent aux exigences de simulation de contact de la section 7.2.5, ils:

• [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen.
• [C-3-2] DOIT indiquer uniquement android.hardware.faketouch.
• [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

7.2.5. Saisie tactile fictive

Une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui contrôle un curseur à l'écran s'apparente à un écran tactile, mais l'utilisateur doit d'abord pointer ou mettre en surbrillance l'élément, puis cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate 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é des fonctionnalités de l'écran tactile.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais un autre système de saisie par pointeur qu'ils souhaitent mettre à disposition, elles:

• DOIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch, elles:

• [C-1-1] DOIT indiquer les positions X et Y absolues à l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• [C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou monte sur l'écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le bas et vers le haut 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 le pointeur vers le bas, le pointeur vers le haut, le pointeur vers le bas, puis le pointeur vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double appui sur un objet à l'écran.
• [C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
• [C-1-6] DOIT 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 pointer vers le haut de l'écran, ce qui leur permet de lancer un objet à l'écran.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct, elles:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT prendre en charge le suivi distinct de deux entrées de pointeur indépendantes ou plus.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand, elles:

• [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-3-2] DOIT prendre en charge le suivi distinct de cinq (suivi d'une main avec cinq doigts) ou de plusieurs entrées de pointeur de manière totalement indépendante.

7.2.6. Compatibilité avec les manettes de jeu

7.2.6.1. Mappages des boutons

Implémentations de l'appareil:

• [C-1-1] DOIT être capable de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent un contrôleur ou sont livrées avec un contrôleur distinct dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:

• [C-2-1] Vous devez déclarer l'indicateur de fonctionnalité android.hardware.gamepad.

Bouton	Utilisation de l'HID2	Bouton Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Croix directionnelle vers le haut1 Croix directionnelle vers le bas1	0x01 0x00393	AXIS_HAT_Y4
Flèche vers la gauche du pavé directionnel 1 Flèche vers la droite du pavé directionnel1	0x01 0x00393	AXIS_HAT_X4
Bouton de l'épaule gauche1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic sur le stick droit1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Retour1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).

3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente l'absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".

4 MotionEvent

Commandes analogiques1	Utilisation des périphériques HID	Bouton Android
Gauche	0x02 0x00C5	AXIS_LTRIGGER
Gauche	0x02 0x00C4	AXIS_RTRIGGER
Stick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Stick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API 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 la documentation Open Source Android sur les capteurs.

Implémentations de l'appareil:

• [C-0-1] DOIT signaler 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 les méthodes SensorManager.getSensorList() et similaires.
• [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant true ou false selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas 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 associé à une API correspondante pour les développeurs tiers, ils:

• [C-1-1] DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android.
• [C-1-2] DOIT signaler les données des capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec une latence maximale demandée de 0 ms lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Il est acceptable que cet exemple ait une précision de 0.
• [C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3%, où le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.
• [C-1-5] Le flux d'événements du capteur DOIT empêcher le processeur de l'appareil d'entrer dans un état de suspension ou de se réveiller d'un état de suspension.
• [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Cette valeur représente l'heure à laquelle l'événement s'est produit et est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano().
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir une erreur de synchronisation du code temporel inférieure à 100 millisecondes et DEVRAIT avoir une erreur de synchronisation du code temporel 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 indiquée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API correspondante pour les développeurs tiers, ils:

• [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler la 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. (Exemples : capteur d'orientation et capteur d'accélération linéaire.)

Implémentations de l'appareil:

• DOIT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans la section Types de capteurs.

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

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Open Source 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 la valeur via la méthode d'API Sensor.getResolution().

Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, ils:

• [C-4-1] Les données fournies NE DOIVENT PAS inclure de paramètres de calibrage fixes, déterminés en usine.

Si les implémentations d'appareils incluent une combinaison d'accéléromètre à trois axes, d'un capteur de gyroscope à trois axes ou d'un capteur de magnétomètre, elles sont:

• [C-SR-2] IL EST FORTEMENT RECOMMANDÉ de s'assurer que l'accéléromètre, le gyroscope et le magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes des capteurs restent alignés et cohérents avec le système de coordonnées des capteurs dans tous les états de transformation possibles de l'appareil.

7.3.1. Accéléromètre

Implémentations de l'appareil:

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

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

• [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
• [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
• [C-1-4] DOIT être capable de mesurer de la chute libre jusqu'à quatre fois la gravité(4 g) ou plus sur n'importe quel axe.
• [C-1-5] La résolution doit être d'au moins 12 bits.
• [C-1-6] DOIT avoir une déviation standard ne dépassant pas 0,05 m/s^, où la déviation standard doit être calculée par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• [C-SR-2] sont FORTEMENT RECOMMANDÉS pour implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
• [C-SR-3] Il est vivement recommandé d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est vivement recommandé que les appareils Android répondent à cette exigence afin qu'ils puissent passer à la prochaine version de la plate-forme, où cela pourrait devenir OBLIGATOIRE.
• DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.
• DOIT signaler les événements jusqu'à au moins 200 Hz.
• DOIT avoir une résolution d'au moins 16 bits.
• DOIT être calibré pendant l'utilisation si les caractéristiques changent au cours du cycle de vie et compensées, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• DOIT être compensé en température.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER est implémenté:

• [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:

• [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR-4] Il est vivement recommandé d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes, un capteur de gyroscope à trois axes et un capteur de magnétomètre, elles:

• [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à trois axes.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, elles:

• [C-1-1] Le capteur TYPE_MAGNETIC_FIELD DOIT être implémenté.
• [C-1-2] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DEVRAIT signaler des événements jusqu'à au moins 50 Hz.
• [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
• [C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant de saturer.
• [C-1-5] Le magnétomètre DOIT avoir une valeur de décalage de fer dur inférieure à 700 µT et DEVRAIT avoir une valeur inférieure à 200 µT, en le plaçant loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par le magnétisme).
• [C-1-6] La résolution doit être égale ou plus dense que 0,6 µT.
• [C-1-7] DOIT prendre en charge le calibrage et la compensation en ligne du biais de fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] La compensation du fer doux DOIT être appliquée. L'étalonnage peut être effectué en cours d'utilisation ou lors de la fabrication de l'appareil.
• [C-1-9] L'écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes à la fréquence d'échantillonnage la plus élevée, DOIT être inférieur à 1,5 µT. Il DEVRAIT être inférieur à 0,5 µT.
• [C-1-10] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si les implémentations de l'appareil incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope à trois axes, elles:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes et un accéléromètre, elles:

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles:

• [C-3-1] DOIT consommer moins de 10 mW.
• DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.

7.3.3. GPS

Implémentations de l'appareil:

• [C-SR-1] Il est vivement recommandé d'inclure un récepteur GPS/GNSS.

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

• [C-1-1] DOIT prendre en charge les sorties de position à une fréquence d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être en mesure de déterminer la position en conditions d'espace dégagé (signaux forts, multichemin négligeable, HDOP < 2) sous 10 secondes (temps de première correction rapide), lorsqu'il est connecté à une connexion Internet à débit de données d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une forme de technique GPS/GNSS assistée ou prévue pour réduire le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, l'emplacement de référence et l'éphéméride/l'horloge du satellite).
  • [C-1-6] Après avoir effectué un tel calcul de position, les implémentations d'appareils DOIVENT déterminer sa position, en plein ciel, dans les cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de position initial, même lorsque la requête ultérieure est effectuée sans connexion de données et/ou après un cycle d'alimentation.

• En plein ciel après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré:

  • [C-1-3] DOIT pouvoir déterminer la position à 20 mètres près et la vitesse à 0, 5 mètre par seconde près, au moins 95% du temps.
  • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une constellation.
  • DOIT pouvoir suivre simultanément au moins 24 satellites, issus de plusieurs constellations (par exemple, GPS + au moins un de Glonass, Beidou ou Galileo).

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des sorties de position GPS/GNSS normales via les API du fournisseur de position 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 de SBAS.

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler l'AGC et la fréquence de mesure GNSS.

• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris la direction, la vitesse et la verticale) dans chaque position GPS/GNSS.

• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès qu'elles sont détecté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-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0,2 m/s près, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations de l'appareil:

• [C-SR-1] Il est vivement recommandé d'inclure un capteur de gyroscope.

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

• [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
• [C-1-2] Le capteur TYPE_GYROSCOPE DOIT être implémenté.
• [C-1-4] La résolution doit être d'au moins 12 bits.
• [C-1-5] DOIT être compensé en température.
• [C-1-6] DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-7] La variance ne doit pas dépasser 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais elle DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle NE DOIT PAS dépasser 1e-7 rad^2/s^2.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'erreur de calibrage soit inférieure à 0,01 rad/s lorsque l'appareil est à l'arrêt à température ambiante.
• [C-SR-3] Nous vous RECOMMANDONS vivement d'implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED.
• [C-SR-4] Il est vivement recommandé d'utiliser une résolution de 16 bits ou plus.
• DOIT signaler les événements jusqu'à au moins 200 Hz.

Si les implémentations de l'appareil incluent un gyroscope à trois axes, un capteur d'accéléromètre et un capteur de magnétomètre, elles:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:

• [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

7.3.5. Le baromètre

Implémentations de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique ambiante).

Si les implémentations d'appareils incluent un baromètre, elles:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT être en mesure de diffuser des événements à 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [C-SR-2] IL EST FORTEMENT RECOMMANDÉ de pouvoir enregistrer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
• DOIT avoir une précision absolue de 1 hPa.
• DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalent à 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 implémentations d'appareils incluent un thermomètre ambiant (capteur de température), elles:

• [C-1-1] Le SENSOR_TYPE_AMBIENT_TEMPERATURE doit être défini pour le capteur de température ambiante, et le capteur doit mesurer la température ambiante (pièce/habitacle du véhicule) à partir de l'endroit où l'utilisateur interagit avec l'appareil en degrés Celsius.

Si les implémentations d'appareils incluent un capteur de thermomètre qui mesure une température autre que la température ambiante, telle que la température du processeur, elles:

• [C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

Si les implémentations d'appareils incluent un capteur pour surveiller la température cutanée, elles:

• [C-SR-1] Nous vous RECOMMANDONS vivement de prendre en charge l'API PowerManager.getThermalHeadroom.

7.3.7. Photomètre

• Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

• Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité et ne signalent qu'une lecture binaire "proche" ou "loin", 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 à proximité 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, il NE DOIT PAS être accessible via cette API.
• [C-1-2] Doit avoir une précision d'au moins 1 bit.
• [C-1-3] Vous devez utiliser 0 cm pour la lecture proche et 5 cm pour la lecture éloignée.
• [C-1-4] DOIT indiquer une portée et une résolution maximales de 5.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité, comme défini dans cette section, et les mettent à la disposition d'applications tierces, elles:

• [C-1-1] Vous devez identifier la fonctionnalité via l'indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations de l'appareil déclarent android.hardware.sensor.hifi_sensors, elles:

• [C-2-1] DOIT comporter un capteur TYPE_ACCELEROMETER qui:

  • Doit avoir une plage de mesure d'au moins -8 g à +8 g. Il est fortement recommandé d'avoir une plage de mesure d'au moins -16 g à +16 g.
  • Doit avoir une résolution de mesure d'au moins 2 048 LSB/g.
  • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le SensorDirectChannel RATE_VERY_FAST.
  • DOIT avoir un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence Nyquist et un spectre de bruit blanc dans cette bande passante.
  • L'accélération doit être inférieure à 30 μg √Hz, testée à température ambiante.
  • Le changement de biais par rapport à la température doit être ≤ +/- 1 mg/°C.
  • La non-linéarité de la ligne d'ajustement doit être inférieure ou égale à 0,5%, et la variation de la sensibilité en fonction de la température doit être inférieure ou égale à 0,03%/°C.
  • DOIT avoir une sensibilité croisée de moins de 2,5 % et une variation de la sensibilité croisée de moins de 0,2% dans la plage de température 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 comporter un capteur TYPE_GYROSCOPE qui:

  • DOIT avoir une plage de mesure d'au moins -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 ; DOIT prendre en charge le SensorDirectChannel RATE_VERY_FAST.
  • DOIT avoir un bruit de mesure inférieur à 0,014 °/s/√Hz.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence Nyquist et un spectre de bruit blanc dans cette bande passante.
  • DOIT avoir une marche aléatoire de fréquence inférieure à 0,001 °/s √Hz testée à température ambiante.
  • Le biais doit changer de ≤ +/- 0,05 °/ s / °C par rapport à la température.
  • La sensibilité doit changer de ≤ 0,02% / °C par rapport à la température.
  • La non-linéarité de la droite d'ajustement optimal doit être inférieure ou égale à 0,2%.
  • DOIT avoir une densité de bruit de ≤ 0,007 °/s/√Hz.
  • L'erreur de calibrage doit être inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité à la gravité doit être inférieure à 0,1 °/s/g.
  • DOIT avoir une sensibilité croisée de moins de 4,0 % et une variation de sensibilité croisée de moins de 0,3% dans la plage de température de fonctionnement de l'appareil.

• [C-2-4] DOIT avoir un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.

• [C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui:

  • DOIT avoir une plage de mesure d'au moins -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.
  • Le bruit de mesure doit être inférieur à 0,5 uT.

• [C-2-6] DOIT avoir un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD, et en outre:

  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en tampon d'au moins 600 événements de capteur.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc allant de 1 Hz à au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.

• [C-2-7] DOIT comporter un capteur TYPE_PRESSURE qui:

  • DOIT avoir une plage de mesure d'au moins 300 et 1 100 hPa.
  • 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.
  • Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en tampon d'au moins 300 événements de capteur.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.

• [C-2-8] DOIT avoir un capteur TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] DOIT comporter un capteur TYPE_SIGNIFICANT_MOTION qui:

  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-10] DOIT comporter un capteur TYPE_STEP_DETECTOR qui:

  • DOIT implémenter une forme non réveillé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 à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.

• [C-2-11] DOIT comporter un capteur TYPE_STEP_COUNTER qui:

  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-12] DOIT comporter un capteur TILT_DETECTOR qui:

  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-13] L'horodatage de l'événement du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être compris dans une plage de 2, 5 millisecondes. L'horodatage de l'événement du même événement physique signalé par l'accéléromètre et le gyroscope DOIT être compris entre 0,25 milliseconde et 0,25 milliseconde.

• [C-2-14] Les codes temporels des événements du capteur gyroscopique DOIVENT être basés sur la même base temporelle que le sous-système de la caméra et avoir une erreur inférieure à 1 milliseconde.

• [C-2-15] DOIT envoyer des échantillons aux applications dans les cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.

• [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsque l'appareil est en mouvement lorsque n'importe quelle 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] Un capteur TYPE_PROXIMITY peut être présent, mais s'il l'est, il doit avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle comprend la puissance consommée par l'ensemble de la chaîne de capteurs (le capteur, les circuits de support, tout système de traitement de capteur dédié, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du niveau des taux de rapports directs via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
• [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs pour les capteurs pour tous les capteurs qui déclarent prendre en charge le canal direct pour les capteurs.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DOIT prendre en charge la création de rapports sur les événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations de l'appareil incluent un écran de verrouillage sécurisé, elles:

• DOIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés en classe 3 (anciennement fort), classe 2 (anciennement faible) ou classe 1 (anciennement commodité) en fonction de leurs taux d'acceptation des falsifications et des imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les fonctionnalités du capteur biométrique pour interagir avec la plate-forme et les applications tierces. Les capteurs sont classés en classe 1 par défaut et doivent répondre à des exigences supplémentaires, comme indiqué ci-dessous, s'ils souhaitent être classés en classe 2 ou classe 3. Les biométries de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Si les implémentations de l'appareil mettent un capteur biométrique à la disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, ils:

• [C-4-1] DOIT respecter les exigences de la biométrie de classe 3 ou de classe 2, telles que définies dans ce document.
• [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe Authenticators et toutes les combinaisons de celle-ci. À l'inverse, elles NE DOIVENT PAS respecter ni reconnaître les constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de celles-ci.
• [C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils dotés de technologies biométriques de classe 3 ou de classe 2. Cette action DOIT uniquement présenter les points d'entrée d'enregistrement pour les technologies biométriques de classe 3 ou de classe 2.

Si les implémentations de l'appareil sont compatibles avec les données biométriques passives, elles:

• [C-5-1] Une étape de confirmation supplémentaire (par exemple, appuyer sur un bouton) DOIT être requise par défaut.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de disposer d'un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et de toujours exiger une étape de confirmation.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation afin qu'un système d'exploitation ou un noyau compromis ne puisse pas l'usurper. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche d'entrée/sortie (GPIO) à usage général uniquement d'un élément sécurisé (SE) qui ne peut être piloté que par une pression sur un bouton physique.
• [C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), que les applications peuvent définir pour les flux de connexion.

Si les implémentations d'appareils comportent plusieurs capteurs biométriques, elles:

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne demander qu'une seule authentification biométrique par authentification (par exemple, si les capteurs d'empreinte digitale et de reconnaissance faciale sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé après la confirmation de l'un d'eux).

Pour que les implémentations d'appareils autorisent l'accès aux clés du keystore aux applications tierces, elles doivent:

• [C-6-1] DOIT respecter les exigences de la classe 3 telles que définies dans cette 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 comme un capteur de classe 1 (anciennement Commodité), elles doivent:

• [C-1-1] Le taux de fausse acceptation doit être 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 de l'activer si les taux d'acceptation des attaques par hameçonnage et par usurpation d'identité sont supérieurs à 7 %, comme mesuré par les protocoles de test biométriques Android.
• [C-1-9] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, code, schéma, mot de passe) après un maximum de vingt tentatives incorrectes et un délai de retour d'au moins 90 secondes pour la validation biométrique. Une tentative incorrecte est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
• [C-SR-4] Nous vous RECOMMANDONS vivement de réduire le nombre total de fausses tentatives de vérification biométrique spécifié dans [C-1-9] si les taux d'acceptation des faux et des imposteurs sont supérieurs à 7 %, comme mesuré par les protocoles de test des technologies biométriques Android.
• [C-1-3] Le système doit limiter le nombre de tentatives de vérification biométrique, où une tentative incorrecte est celle dont la qualité de capture (BIOMETRIC_ACQUIRED_GOOD) est adéquate, mais qui ne correspond pas à une empreinte biométrique enregistrée.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter la fréquence des tentatives pendant au moins 30 secondes après cinq tentatives incorrectes pour la validation biométrique, en fonction du nombre maximal de tentatives incorrectes par [C-1-9]. Une tentative incorrecte est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de placer toute logique de limitation de débit dans le TEE.
• [C-1-10] DOIT désactiver l'authentification biométrique une fois que le délai d'expiration de l'authentification principale a été déclenché pour la première fois, comme décrit dans [C-0-2] de la section 9.11.
• [C-1-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 les identifiants existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par le TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour ce faire.
• [C-1-5] Vous DEVEZ supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris via une réinitialisation d'usine).
• [C-1-6] DOIT respecter l'indicateur individuel pour cette empreinte biométrique (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe): a) une fois toutes les 24 heures ou moins pour les appareils lancés avec Android 9 ou version ultérieure, ou b) une fois toutes les 72 heures ou moins pour les appareils qui passent d'Android 8 ou version antérieure.

• [C-1-8] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) ou une biométrie de classe 3 (FORTE) après l'un des événements suivants :

  • un délai d'inactivité de quatre heures ; OU

  • Trois tentatives d'authentification biométrique échouées.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils.

• [C-SR-8] Il est FORTEMENT RECOMMANDÉ de disposer d'un taux de faux rejet inférieur à 10%, mesuré sur l'appareil.

• [C-SR-9] Il est FORTEMENT RECOMMANDÉ de disposer d'une latence inférieure à une seconde, mesurée à partir du moment où la biométrie est détectée jusqu'au déverrouillage de l'écran, pour chaque biométrie enregistrée.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 2 (anciennement faible), elles doivent:

• [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.
• [C-2-2] Le taux d'acceptation des usurpations d'identité et des imposteurs doit être inférieur à 20 %, mesuré par les protocoles de test biométriques Android.
• [C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du noyau Android, tel que l'environnement d'exécution sécurisé (TEE), ou sur une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
• [C-2-4] Toutes les données identifiables DOIVENT être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source.
• [C-2-5] Pour les données biométriques basées sur une caméra, pendant l'authentification ou l'enregistrement biométrique :
  • DOIT utiliser la caméra dans un mode qui empêche la lecture ou la modification des frames de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
  • Pour les solutions à caméra unique RVB, les cadres de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT PAS être modifiables.
• [C-2-6] NE DOIT PAS permettre aux applications tierces de distinguer les enregistrements biométriques individuels.
• [C-2-7] Le processeur d'application NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni à toute donnée dérivée de celles-ci (telles que les représentations vectorielles continues) en dehors du contexte du TEE. La mise à niveau des appareils lancés avec Android 9 ou version antérieure n'est pas exemptée de la règle C-2-7.

• [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre l'injection directe de données pour s'authentifier faussement en tant qu'utilisateur.

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

• [C-2-9] DOIT mettre le capteur biométrique à la disposition des applications tierces.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 3 (anciennement Fort), elles doivent:

• [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] L'implémentation du keystore doit être basée sur du matériel.
• [C-3-3] Le taux d'acceptation des usurpations d'identité et des faux utilisateurs doit être inférieur à 7 %, mesuré par les protocoles de test biométriques Android.
• [C-3-4] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) toutes les 72 heures ou moins.
• [C-3-5] L'ID de l'authentificateur doit être généré à nouveau pour toutes les biométries de classe 3 compatibles sur l'appareil si l'une d'elles est réenregistrée.
• [C-3-6] Les clés du keystore basées sur la biométrie doivent être activées pour les applications tierces.

Si les implémentations de l'appareil contiennent un lecteur d'empreinte digitale sous l'écran (UDFPS), elles:

• [C-SR-11] FORTEMENT RECOMMANDÉ pour éviter que la zone tactile de l'UDFPS n'interfère avec la navigation à trois boutons (que certains utilisateurs peuvent nécessiter à des fins d'accessibilité).

7.3.12. Capteur de position

Implémentations de l'appareil:

• Peut être compatible avec un capteur de position à six degrés de liberté.

Si les implémentations d'appareils sont compatibles avec un capteur de position à six degrés de liberté, elles:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
• [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.13. Capteur d'angle de charnière

Si les implémentations de l'appareil sont compatibles avec un capteur d'angle de charnière, elles:

• [C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
• [C-1-2] DOIT prendre en charge au moins deux lectures entre 0 et 360 degrés (inclus, c'est-à-dire y compris 0 et 360 degrés).
• [C-1-3] DOIT renvoyer un capteur de réveil pour getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Connectivité des données

7.4.1. Téléphonie

Le terme "téléphonie" utilisé par les API Android et ce document fait spécifiquement référence au matériel lié à la réalisation d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée sur le même réseau. En d'autres termes, les fonctionnalités et les API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS ne sont pas considérées comme des appareils de téléphonie, que ce soit ou non via un réseau mobile pour la connectivité de données.

• Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec des appareils autres que des téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony et les autres sous-flags de fonctionnalité en fonction de la technologie.
• [C-1-2] DOIT implémenter une compatibilité complète avec l'API de cette technologie.
• DOIT autoriser tous les types de services mobiles disponibles (2G, 3G, 4G, 5G, etc.) lors des appels d'urgence (quels que soient les types de réseau définis par SetAllowedNetworkTypeBitmap()).

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles:

• [C-2-1] Vous DEVEZ implémenter l'intégralité des API 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 pour rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles:

• [C-3-1] DOIT fournir une implémentation complète de EuiccManager API.

Si les implémentations d'appareils ne définissent pas la propriété système ro.telephony.iwlan\_operation\_mode sur "ancienne", elles:

• [C-4-1] NE DOIT PAS signaler NETWORK_TYPE_IWLAN via NetworkRegistrationInfo#getAccessNetworkTechnology() lorsque NetworkRegistrationInfo#getTransportType() est signalé comme TRANSPORT_TYPE_WWAN pour la même instance NetworkRegistrationInfo.

Si les implémentations d'appareils acceptent un seul enregistrement IMS (IP Multimedia Subsystem) pour les fonctionnalités de service de téléphonie multimédia (MMTEL) et de service de communication enrichi (RCS) et doivent respecter les exigences des opérateurs de téléphonie mobile concernant l'utilisation d'un seul enregistrement IMS pour tout le trafic de signalisation IMS, elles:

• [C-5-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony.ims et fournir une implémentation complète de l'API ImsService pour MMTEL et l'API User Capability Exchange du RCS.
• [C-5-2] DOIT déclarer le flag 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 porteuses dédiées à l'aide du HAL IRadio 1.6 et du provisionnement via un serveur de configuration automatique (ACS) ou un autre mécanisme de provisionnement propriétaire à l'aide de l'API de configuration IMS.

7.4.1.1. Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure la fonctionnalité de blocage des numéros
• [C-1-2] DOIT implémenter entièrement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
• [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans 'BlockedNumberProvider' sans aucune interaction avec les applications. La seule exception est lorsque le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
• [C-1-4] NE DOIT PAS écrire au fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
• [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
• [C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NE DOIT PAS permettre aux utilisateurs secondaires de consulter ni de 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. L'interface utilisateur liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT toujours être respectée.
• DOIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil passe à Android 7.0.

7.4.1.2. API Telecom

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

• [C-1-1] DOIT être compatible avec les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir à l'utilisateur la possibilité d'accepter ou de refuser l'appel entrant lorsque l'utilisateur est en ligne avec 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] L'application doit implémenter InCallService.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à un appel en cours.

  L'implémentation AOSP répond à ces exigences par une notification d'alerte qui indique à l'utilisateur que répondre à un appel entrant entraînera l'abandon de l'autre appel.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger l'application de numérotation par défaut qui affiche une entrée de journal des appels et le nom d'une application tierce dans son journal des appels lorsque l'application tierce définit la clé supplémentaire EXTRA_LOG_SELF_MANAGED_CALLS sur PhoneAccount sur true.

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom comme suit:

  • Appelez Connection.onDisconnect() lorsqu'un appui bref sur l'événement de touche est détecté pendant un appel en cours.
  • Appelez Connection.onAnswer() lorsqu'un appui bref sur l'événement de touche est détecté lors d'un appel entrant.
  • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté lors d'un appel entrant.
  • Activez/Désactivez le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations de l'appareil:

• DOIT inclure la prise en charge d'une ou de plusieurs formes de 802.11.

Si les implémentations d'appareils incluent la prise en charge de 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 l'indicateur de fonctionnalité matérielle android.hardware.wifi.
• [C-1-3] Vous DEVEZ implémenter l'API multicast comme décrit dans la documentation du SDK.
• [C-1-4] DOIT prendre en charge le DNS multicast (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment de l'opération, y compris :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même en mode veille.
• [C-1-5] NE DOIT PAS traiter l'appel de la méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif, qui est utilisé par défaut pour le trafic de l'application et est renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils ne peuvent désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils valident avec succès que le réseau Wi-Fi fournit un accès à Internet.
• [C-1-6] Il est FORTEMENT RECOMMANDÉ, lorsque la méthode de l'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 randomiser l'adresse MAC source et le numéro de séquence des trames de requête de sonde, une fois au début de chaque analyse, lorsque l'unité STA est déconnectée.
• [C-1-8] DOIT utiliser une adresse MAC cohérente (NE DOIT PAS randomiser l'adresse MAC à mi-parcours d'une analyse).
• [C-1-9] DOIT itérer le numéro de séquence de la requête de sonde comme d'habitude (séquentiellement) entre les requêtes de sonde d'une analyse.
• [C-1-10] DOIT randomiser le numéro de séquence de la requête de sonde entre la dernière requête de sonde d'une analyse et la première requête de sonde 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 (FQDN pour Passpoint) avec lequel il communique.
  • L'appareil DOIT fournir à l'utilisateur une option permettant de contrôler la randomisation par SSID (FQDN pour Passpoint) avec des options non randomisées et randomisées, et DOIT définir le mode par défaut pour que les nouvelles configurations Wi-Fi soient randomisées.
• [C-SR-2] Il est vivement recommandé d'utiliser un BSSID aléatoire pour tous les points d'accès qu'il crée.
  • L'adresse MAC DOIT être randomisée et persistante par SSID utilisé par l'AP.
  • L'APPAREIL PEUT offrir à l'utilisateur la possibilité de désactiver cette fonctionnalité. Si une telle option est fournie, la randomisation DOIT être activée par défaut.

Si les implémentations d'appareils incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles:

• DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert un verrouillage WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire(), et que le verrouillage est actif.
• [C-3-2] La latence aller-retour moyenne entre l'appareil et un point d'accès lorsque l'appareil est en mode Verrouillage Wi-Fi à faible latence (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Verrouillage Wi-Fi hautes performances (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] Ils sont FORTEMENT RECOMMANDÉS pour réduire la latence aller-retour Wi-Fi chaque fois qu'un verrouillage à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles:

• [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Direct, elles:

• [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
• [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• [C-1-3] DOIT être compatible avec le fonctionnement normal du Wi-Fi.
• [C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source pour toutes les nouvelles connexions Wi-Fi Direct.

7.4.2.2. Configuration du lien direct en tunnel Wi-Fi

Implémentations de l'appareil:

• DOIT inclure la compatibilité avec la configuration de liaison directe en tunnel Wi-Fi (TDLS), comme décrit dans la documentation du SDK Android.

Si les implémentations de l'appareil incluent la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, elles:

• [C-1-1] DOIT déclarer la prise en charge de TDLS via WifiManager.isTdlsSupported.
• Vous DEVEZ utiliser TDLS uniquement lorsque c'est possible ET avantageux.
• DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles du point d'accès Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Aware.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles:

• [C-1-1] Vous DEVEZ implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
• [C-1-2] Vous DEVEZ déclarer l'option 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 randomiser l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles de 30 minutes maximum et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure de la portée Aware est en cours ou si 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 de l'appareil sont compatibles avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5, et qu'elles exposent ces fonctionnalités aux applications tierces, elles:

• [C-2-1] DOIT implémenter les API de découverte basée sur la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Si les implémentations de l'appareil sont compatibles avec la norme 802.11 (Wi-Fi), elles:

• [C-1-1] DOIT être compatible 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, en particulier en ce qui concerne la découverte et la sélection de réseaux, tels que le service d'annonces génériques (GAS, Generic Advertisement Service) et le protocole ANQP (Access Network Query Protocol).
• [C-1-4] Vous devez déclarer le commutateur de fonctionnalité android.hardware.wifi.passpoint.
• [C-1-5] DOIT suivre l'implémentation AOSP pour détecter, faire correspondre et associer des réseaux Passpoint.
• [C-1-6] DOIT prendre en charge au moins le sous-ensemble de protocoles de provisionnement d'appareils suivant, tel que défini dans la version R2 de la norme Passpoint de la Wi-Fi Alliance: authentification EAP-TTLS et SOAP-XML.
• [C-1-7] DOIT traiter le certificat du serveur AAA comme décrit dans la spécification Hotspot 2.0 R3.
• [C-1-8] DOIT permettre à l'utilisateur de contrôler le provisionnement via le sélecteur de réseau Wi-Fi.
• [C-1-9] Les configurations Passpoint doivent être conservées lors des redémarrages.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'acceptation des conditions d'utilisation.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité d'informations sur les lieux.

À l'inverse, si les implémentations d'appareils n'incluent pas la prise en charge de Wi-Fi Passpoint:

• [C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.

Si un bouton de désactivation de la commande utilisateur Passpoint global est fourni, les implémentations:

• [C-3-1] DOIT activer Passpoint par défaut.

7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi, RTT)

Implémentations de l'appareil:

• DOIT inclure la prise en charge de la position Wi-Fi.

Si les implémentations de l'appareil sont compatibles avec la localisation Wi-Fi et exposent la fonctionnalité aux applications tierces, elles:

• [C-1-1] Vous DEVEZ implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
• [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité android.hardware.wifi.rtt.
• [C-1-3] L'adresse MAC source doit être RANDONNÉE pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.
• [C-1-4] DOIT être précis à ± 2 mètres avec une bande passante de 80 MHz au 68e percentile (calculé avec la fonction de distribution cumulative).

7.4.2.6. Déchargement du keepalive Wi-Fi

Implémentations de l'appareil:

• DOIT inclure la prise en charge de l'externalisation du keepalive Wi-Fi.

Si les implémentations d'appareils prennent en charge le transfert de keepalive Wi-Fi et exposent la fonctionnalité aux 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 Wi-Fi et au moins un emplacement keepalive sur réseau mobile.

Si les implémentations d'appareils n'incluent pas la prise en charge de l'externalisation du keepalive Wi-Fi, elles:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement d'appareils)

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Easy Connect (DPP).

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

• [C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer true.

7.4.2.8. Validation du certificat de serveur Wi-Fi 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 de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas proposer à l'utilisateur la possibilité d'ajouter manuellement un réseau Wi-Fi d'entreprise dans l'application Paramètres.

7.4.3. Bluetooth

Si les implémentations de l'appareil sont compatibles avec le profil Bluetooth Audio, elles:

• DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations de l'appareil sont compatibles avec HFP, A2DP et AVRCP:

• DOIT être compatible avec 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 Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations de l'appareil incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation, elles:

• [C-2-1] Vous DEVEZ déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le respectivement) et implémenter les API de la plate-forme.
• DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations de l'appareil sont compatibles avec le Bluetooth à basse consommation (BLE), 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 le GATT (Generic Attribute Profile) 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 implémentée.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() afin d'indiquer si la publicité à faible consommation est prise en charge.
• [C-3-5] DOIT implémenter un délai avant expiration de l'adresse privée résoluble (RPA) de 15 minutes maximum et faire pivoter l'adresse à l'expiration pour protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement le BLE pour l'analyse ou la publicité. Pour éviter les attaques par cassage de délai, les intervalles de délai DOIVENT également être randomisés entre cinq et 15 minutes.
• DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
• DOIT prendre en charge le transfert de l'analyse groupée vers le chipset Bluetooth.
• DOIT prendre en charge les annonces multiples avec au moins quatre emplacements.

Si les implémentations d'appareils sont compatibles avec le Bluetooth LE et utilisent le Bluetooth LE pour la localisation, elles:

• [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la prise en charge du Bluetooth LE et du profil d'appareils auditifs, comme décrit dans la section Compatibilité audio des appareils auditifs avec Bluetooth LE, elles:

• [C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

Si les implémentations de l'appareil incluent la prise en charge du Bluetooth ou du Bluetooth à basse consommation, elles:

• [C-6-1] DOIT restreindre l'accès à toutes les métadonnées Bluetooth (telles que les résultats de la recherche) qui pourraient être utilisées pour déduire 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 en fonction de son état actuel en premier plan/en arrière-plan.

Si les implémentations de l'appareil 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 qu'il ne dérive pas la position à partir du Bluetooth, les développeurs doivent:

• [C-6-2] L'accès au Bluetooth doit être contrôlé derrière le android.permission.ACCESS_FINE_LOCATION.

7.4.4. Communication en champ proche

Implémentations de l'appareil:

• DOIT inclure un transceiver et du matériel associé pour la communication en champ proche (NFC).
• [C-0-1] Vous DEVEZ implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation des données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition d'applications tierces, elles:

• [C-1-1] Vous DEVEZ signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes, comme indiqué ci-dessous:
• [C-1-2] DOIT être capable de fonctionner comme lecteur/enregistreur NFC Forum (tel que défini par la spécification technique du NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le forum NFC)

• [C-SR-1] Il est vivement recommandé de 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 définies comme "FORTEMENT RECOMMANDÉES", la définition de la compatibilité pour une future version prévoit de les remplacer par "OBLIGATOIRE". Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous vous recommandons vivement de respecter ces exigences dès maintenant pour les appareils existants et les nouveaux qui exécutent cette version d'Android afin qu'ils puissent passer aux futures versions de la plate-forme.

• [C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.

• DOIT être en mode découverte NFC lorsque l'appareil est actif, l'écran actif et l'écran de verrouillage déverrouillé.

• DOIT être en mesure de lire le code-barres et l'URL (si encodés) des produits code-barres NFC Thinfilm.

Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum 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 de l'ID d'application (AID), elles:

• [C-2-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hce.
• [C-2-2] DOIT prendre en charge les API NFC HCE telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles:

• [C-3-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent la compatibilité NFC générale décrite dans cette section et les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/écrivain, elles:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans la documentation du 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 en tant que constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles et API réseau

7.4.5.1. Capacité réseau minimale

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données capable de 200 kbit/s ou plus. EDGE, HSPA, EV-DO, 802.11g, Ethernet et PAN Bluetooth sont des exemples de technologies qui répondent à cette exigence.
• DOIT é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 implémenter plusieurs formes de connectivité de données.

7.4.5.2. IPv6

Implémentations de l'appareil:

• [C-0-2] DOIT inclure une pile réseau IPv6 et prendre en charge 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] Vous devez activer IPv6 par défaut.
  • DOIT s'assurer que la communication IPv6 est aussi fiable qu'IPv4, par exemple :
    • [C-0-4] La connectivité IPv6 doit être maintenue en mode veille.
    • [C-0-5] La limitation de débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau conforme à la norme IPv6 qui utilise des durées de vie de 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 localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort, ainsi que les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port source pour les serveurs Internet (Web).

Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les implémentations de l'appareil sont compatibles avec le Wi-Fi, elles:

• [C-1-1] DOIT être compatible avec le fonctionnement en double pile et en IPv6 uniquement sur le Wi-Fi.

Si les implémentations de l'appareil sont compatibles avec Ethernet, elles:

• [C-2-1] DOIT prendre en charge le fonctionnement à double pile et IPv6 uniquement sur Ethernet.

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

• [C-3-1] DOIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et données mobiles) :

• [C-4-1] L'appareil DOIT simultanément respecter les exigences ci-dessus sur chaque réseau lorsqu'il est connecté simultanément à plusieurs types de réseaux.

7.4.5.3. Portails captifs

Un portail captif désigne un réseau qui nécessite une connexion pour accéder à Internet.

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

• [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif, en envoyant cet intent, lors de l'appel de l'API système ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] DOIT effectuer la détection des portails captifs et prendre en charge la connexion via l'application du portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris un réseau mobile/cellulaire, un réseau Wi-Fi, un réseau Ethernet ou un réseau Bluetooth.
• [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide du DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode strict du DNS privé.
• [C-1-4] Vous devez utiliser un DNS chiffré conformément à la documentation du SDK pour android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout trafic réseau qui ne communique pas explicitement avec le portail captif.
• [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un portail captif, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback et utilisé par défaut par les API réseau Java telles que java.net.Socket et les API natives telles que connect()) est tout autre réseau disponible qui fournit un accès Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations de l'appareil:

• [C-0-1] Le paramètre de synchronisation automatique maître doit être activé par défaut pour que la méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, elles sont:

• [C-SR-1] Nous vous recommandons vivement de proposer le mode Économiseur de données.

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

• [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 de l'appareil ne fournissent pas le mode Économiseur de données, elles:

• [C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Composants sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés 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 indicateurs de fonctionnalité appropriés via android.hardware.se.omapi.uicc pour l'appareil avec des éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil avec des éléments sécurisés basés sur eSE et android.hardware.se.omapi.sd pour l'appareil avec des éléments sécurisés basés sur SD.

7.5. Caméras

Si les implémentations d'appareils incluent au moins une caméra, elles:

• [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité android.hardware.camera.any.
• [C-1-2] Une application DOIT pouvoir allouer simultanément trois bitmaps RGBA_8888 égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution sur l'appareil, lorsque l'appareil photo est ouvert à des fins d'aperçu de base et de capture d'image.
• [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée qui gère les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE est chargée de supprimer la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque l'application destinataire ne dispose pas de ACCESS_FINE_LOCATION.

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, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle.

Implémentations de l'appareil:

• DOIT inclure une caméra arrière.

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

• [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.
• Le pilote de l'appareil photo DOIT implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
• POURRAIENT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
• POURRA inclure un flash.

Si la caméra inclut un flash:

• [C-2-1] Le flash ne doit PAS être allumé 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 d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.

7.5.2. Caméra avant

Une caméra avant est une caméra située du même côté de l'appareil que l'écran. Il s'agit d'une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Implémentations de l'appareil:

• POURRAIENT inclure une caméra avant.

Si les implémentations d'appareils incluent au moins une caméra avant, elles:

• [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 d'au moins VGA (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour qu'elle traite une caméra avant comme la caméra arrière par défaut, même si elle est 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 l'application actuelle a demandé explicitement que l'écran de l'appareil photo soit pivoté 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 en cours n'exige pas explicitement que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés qui sont renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
• [C-1-6] DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de l'appareil photo.
• PEUVENT inclure des fonctionnalités (comme 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 inversé horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations de l'appareil:

• PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations de l'appareil sont compatibles avec une caméra externe, elles:

• [C-1-1] Vous DEVEZ déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
• [C-1-2] DOIT être compatible avec la 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] L'appareil doit réussir les tests CTS de la caméra avec un appareil photo externe physique connecté. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
• DOIT prendre en charge 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 être compatible avec plusieurs caméras.
• Peut prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur l'appareil photo est compatible:

• [C-2-1] Un flux non encodé / MJPEG simultané (résolution VGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. L'API android.hardware.camera2 la plus récente expose le contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de streaming/rafales efficaces sans copie et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du dénoyage, de 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 prise en charge continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision du mode autofocus doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir la même vitesse ni la même qualité, mais DOIVENT correspondre le plus étroitement possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles. Implémentations de l'appareil:

• [C-0-1] Vous devez utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DOIT également être au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données du byte[] 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 pour les caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.)
• [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en sortie 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] Vous devez toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). 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 le mode autofocus, les rappels d'API doivent toujours être "faussés" comme décrit.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe android.hardware.Camera.Parameters et la classe android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), à l'exception de 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 d'appareil photo standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à 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 indiquer les options de fonctionnalité du framework appropriées.
• [C-0-8] DOIT également déclarer les fonctionnalités individuelles de la caméra android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir l'indicateur de fonctionnalité si l'un de ses appareils photo connectés est compatible avec la fonctionnalité.
• [C-0-9] DOIT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée au store multimédia.
• [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 store multimédia.
• [C-0-11] Toutes les caméras doivent être accessibles via l'API android.hardware.Camera obsolète, mais également 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 couleur de la peau du visage ou l'adoucissement de la peau du visage pour toute API android.hardware.camera2 ou android.hardware.Camera.
• [C-SR-1] Pour les appareils équipés de plusieurs caméras RGB orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique qui liste la capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composée de toutes les caméras RGB orientées dans cette direction en tant que sous-appareils physiques.

Si les implémentations d'appareils fournissent une API de caméra propriétaire aux applications tierces:

• [C-1-1] Vous DEVEZ implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
• PEUT fournir des tags et/ou des extensions de fournisseur à l'API android.hardware.camera2.

7.5.5. Orientation de l'appareil photo

Si les implémentations de l'appareil comportent une caméra avant ou arrière, la ou les caméras :

• [C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et 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 de l'orientation portrait principale à l'orientation paysage principale (ou inversement).

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimums

Implémentations de l'appareil:

• [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. Elles DOIVENT être capables de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".

7.6.2. Stockage partagé de l'application

Implémentations de l'appareil:

• [C-0-1] DOIT proposer un espace de stockage à partager entre les applications, souvent appelé "stockage externe partagé", "stockage partagé par les applications" ou par le chemin d'accès Linux "/sdcard" sur lequel il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", que le stockage soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un port de carte numérique sécurisé).
• [C-0-3] Le stockage partagé de l'application DOIT être installé directement sur le chemin d'accès Linux sdcard ou inclure un lien symbolique Linux de sdcard au point d'installation réel.
• [C-0-4] Vous DEVEZ activer le stockage avec portée 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 EXIF GPS, stockées dans les 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 en utilisant l'une des méthodes suivantes:

• Un espace de stockage amovible accessible à l'utilisateur, tel qu'un port de carte Secure Digital (SD).
• Partie du stockage interne (non amovible) implémentée dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles:

• [C-1-1] L'interface utilisateur doit comporter un message toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le port.
• [C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur la boîte et tout autre matériel disponible au moment de l'achat que le support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:

• DOIT utiliser l'implémentation AOSP du stockage partagé 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, elles:

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application à partir d'un ordinateur hôte.
• DOIT exposer le contenu des deux chemins de stockage de manière transparente via le service d'analyseur multimédia d'Android et android.provider.MediaStore.
• PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole de transfert multimédia pour répondre à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole de transfert multimédia, elles:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DOIT indiquer une classe d'appareil USB de 0x00.
• DOIT indiquer un nom d'interface USB de "MTP".

7.6.3. Adoptable Storage

Si l'appareil est censé être mobile, contrairement à la télévision, les implémentations de l'appareil sont les suivantes:

• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption de données.

Si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, tel que le compartiment de la batterie ou une autre protection, les implémentations de l'appareil sont les suivantes:

• [C-SR-2] IMPLÉMENTATION FORTEMENT RECOMMANDÉE du stockage adoptable.

7.7. USB

Si les implémentations d'appareils disposent d'un port USB, elles:

• DOIT être compatible avec le mode périphérique USB et DOIT être compatible avec le mode hôte USB.
• DOIT prendre en charge la désactivation de la signalisation de données via USB.

7.7.1. Mode périphérique USB

Si les implémentations de l'appareil incluent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
• [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur d'appareil standard USB via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs 1,5 A et 3,0 A conformément à la norme de résistance Type-C et DOIT détecter les modifications de la publicité s'ils sont compatibles avec l'USB Type-C.
• [C-SR-1] Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [C-SR-2] Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [C-SR-3] DOIT implémenter la prise en charge de la consommation d'un courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [C-SR-4] Il est vivement recommandé de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/piège, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cette fonctionnalité soit "FORTEMENT RECOMMANDÉE", nous pourrons exiger que tous les appareils Type-C soient entièrement compatibles avec les chargeurs Type-C standards dans les futures versions d'Android.
• [C-SR-5] Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de données et l'échange de rôles d'alimentation lorsqu'ils sont compatibles avec l'USB Type-C et le mode hôte USB.
• DOIT prendre en charge la recharge haute tension et les modes alternatifs tels que la sortie d'écran.
• DOIT 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, elles:

• [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 description de l'interface du stockage de masse USB.

7.7.2. Mode hôte USB

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

• [C-1-1] DOIT implémenter l'API hôte USB Android 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 prendre en charge la connexion de périphériques USB standards. En d'autres termes, il DOIT :
  • Disposer d'un port de type C sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB Type-C standard (appareil USB Type-C).
  • Disposer d'un port de type A sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire sur l'appareil à un port USB de type A standard.
  • Disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble permettant de le connecter à un port Type-A standard.
• [C-1-3] NE DOIT PAS être fourni avec un adaptateur permettant de convertir les ports USB de type A ou micro-AB en port de type C (récepteur).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
• DOIT prendre en charge la recharge de l'appareil périphérique USB connecté en mode hôte ; annoncer un courant de source d'au moins 1,5 A, comme spécifié dans la section "Paramètres de terminaison" de la spécification de la version 1.2 du câble et du connecteur USB Type-C pour les connecteurs USB Type-C ou utiliser la plage de courant de sortie du port en aval de recharge(CDP) comme spécifié dans les spécifications de recharge de la batterie USB, version 1.2 pour les connecteurs Micro-AB.
• DOIT implémenter et prendre en charge les normes USB Type-C.

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

• [C-2-1] DOIT être compatible avec la classe USB HID.
• [C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la requête d'utilisation des commandes vocales aux constantes KeyEvent comme indiqué ci-dessous :
  • Page d'utilisation (0xC) ID d'utilisation (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Page d'utilisation (0xC) ID d'utilisation (0x0E9): KEYCODE_VOLUME_UP
  • Page d'utilisation (0xC) ID d'utilisation (0x0EA): KEYCODE_VOLUME_DOWN
  • Page d'utilisation (0xC) ID d'utilisation (0x0CF): KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le Storage Access Framework (SAF), elles:

• [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leurs contenus accessibles 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 USB Type-C, elles:

• [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).
• [C-SR-2] Il est vivement recommandé de prendre en charge DisplayPort, et de prendre en charge les débits de données USB SuperSpeed. Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de rôle de données et d'alimentation.
• [C-SR-3] Il est vivement recommandé de NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la spécification de la version 1.2 du câble et du connecteur USB Type-C.
• DOIT implémenter le modèle Try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.8. Audio

7.8.1. Micro

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

• [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences d'enregistrement audio de la section 5.4.
• [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement à ultrasons comme décrit dans la section 7.8.3.

Si les implémentations d'appareils omettent un micro, elles:

• [C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
• [C-2-2] L'API d'enregistrement audio doit être implémentée au moins en tant que no-ops, conformément à la section 7.

7.8.2. Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles:

• [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.audio.output.
• [C-1-2] DOIT respecter les exigences de lecture audio de la section 5.5.
• [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de prendre en charge la lecture proche des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] Les API liées à la sortie audio doivent être implémentées en tant que no-ops au moins.

Aux fins de cette section, un "port de sortie" est une interface physique telle qu'une prise audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que le Bluetooth, le Wi-Fi ou le réseau mobile ne peut pas être considérée comme incluant un "port de sortie".

7.8.2.1. Ports audio analogiques

Pour être compatible avec les casques 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, elles:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un port audio avec une prise jack audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils sont dotées d'une prise audio 3,5 mm à quatre conducteurs, elles:

• [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro.
• [C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec la séquence de broches CTIA.
• [C-1-3] DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohms: KEYCODE_VOLUME_UP
  • 360-680 ohms: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise.
• [C-1-5] DOIT être capable de piloter au moins 150 mV ± 10% de la tension de sortie sur une impédance d'enceinte de 32 ohms.
• [C-1-6] La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper sur le code de touche la plage d'impédance équivalente suivante entre les conducteurs du micro et de la terre sur la prise audio :
  • 110 à 180 ohms:KEYCODE_VOICE_ASSIST
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec l'ordre de sortie OMTP.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent le android.intent.action.HEADSET_PLUG avec le micro à valeur supplémentaire défini sur 1, elles:

• [C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.2.2. Ports audio numériques

Pour être compatible avec les casques et autres accessoires audio utilisant des connecteurs USB-C et implémentant (classe audio USB) dans l'écosystème Android, comme défini dans la spécification des casques USB Android.

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.2.1.

7.8.3. Quasi-échographie

L'audio proche des ultrasons correspond à la bande de fréquences de 18,5 kHz à 20 kHz.

Implémentations de l'appareil:

• DOIT signaler correctement la prise en charge de la fonctionnalité audio à ultrasons proches via l'API AudioManager.getProperty comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les exigences suivantes DOIVENT être remplies par les sources audio VOICE_RECOGNITION et UNPROCESSED:

• [C-1-1] La réponse moyenne en puissance 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 entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true":

• [C-2-1] La réponse moyenne de l'enceinte entre 18,5 kHz et 20 kHz DOIT être supérieure d'au moins 40 dB à la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations de l'appareil:

• DOIT fournir un chemin de signal audio sans glitch pour les flux d'entrée et de sortie sur les appareils portables, comme défini par zéro glitch mesuré lors d'un test d'une minute par chemin. Effectuez un test avec le "test de glitch automatique" d'OboeTester.

Le test nécessite un dongle de retour audio, utilisé directement sur un connecteur jack 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester est actuellement compatible avec les chemins AAudio. Par conséquent, les combinaisons suivantes DOIVENT être testées pour détecter les anomalies à l'aide d'AAudio:

Mode Perf	Partage	Taux d'échantillonnage de sortie	Dans Chans	Out Chans
LOW_LATENCY	EXCLUSIVITÉ	NON DÉFINI	1	2
LOW_LATENCY	EXCLUSIVITÉ	NON DÉFINI	2	1
LOW_LATENCY	PARTAGÉ	NON DÉFINI	1	2
LOW_LATENCY	PARTAGÉ	NON DÉFINI	2	1
AUCUNE	PARTAGÉ	48000	1	2
AUCUNE	PARTAGÉ	48000	2	1
AUCUNE	PARTAGÉ	44100	1	2
AUCUNE	PARTAGÉ	44100	2	1
AUCUNE	PARTAGÉ	16000	1	2
AUCUNE	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants pour le rapport signal/bruit (SNR) et la distorsion harmonique totale (THD) pour un signal sinusoïdal de 2 000 Hz.

Transducteur	THD	SNR
Haut-parleur principal intégré, mesuré à l'aide d'un micro de référence externe	< 3,0%	>= 50 dB
Micro intégré principal, mesuré à l'aide d'un haut-parleur de référence externe	< 3,0%	>= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés à l'aide d'un adaptateur de bouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés à l'aide d'un adaptateur de bouclage	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des outils permettant de créer des applications de "réalité virtuelle" (RV), y compris des expériences de RV mobile de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et comportements, comme indiqué dans cette section.

7.9.1. Mode réalité virtuelle

Android est compatible avec le mode VR, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est en mode focus utilisateur.

7.9.2. Mode Réalité virtuelle : hautes performances

Si les implémentations de l'appareil sont compatibles avec le mode VR, elles:

• [C-1-1] Le processeur doit comporter au moins deux cœurs physiques.
• [C-1-2] Vous DEVEZ 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 prendre en charge android.hardware.vulkan.level 0.
• DOIT être compatible avec la version 1 de android.hardware.vulkan.level ou 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 dans la liste des extensions EGL disponibles.
• [C-1-8] DOIT implémenter GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2 et 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] Il est FORTEMENT RECOMMANDÉ de prendre en charge Vulkan 1.1.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de 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 où flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et où queueCount est au moins égal à 2.
• [C-1-7] Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès au tampon d'affichage partagé afin que le rendu alterné des yeux du contenu VR à 60 FPS avec deux contextes de rendu soit affiché sans artefacts de déchirure visibles.
• [C-1-9] DOIT implémenter la prise en charge des indicateurs AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT AHardwareBuffer, comme décrit dans le NDK.
• [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE 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] FORTEMENT RECOMMANDÉ pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs calques, ainsi que les indicateurs et les formats spécifiés dans C-1-10.
• [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS-20 Mbit/s).
• [C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressé à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS-20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-5 Mbit/s).
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température de la peau.
• [C-1-14] DOIT comporter un écran intégré, et sa résolution DOIT être d'au moins 1 920 x 1 080.
• [C-SR-6] Il est vivement recommandé de disposer d'une résolution d'affichage d'au moins 2 560 x 1 440.
• [C-1-15] L'écran doit se mettre à jour à au moins 60 Hz en mode VR.
• [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance de 5 millisecondes maximum, la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
• [C-1-18] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE (section 7.4.3).
• [C-1-19] DOIT prendre en charge 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 vivement 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] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors.
• [C-1-22] La latence de mouvement à photon de bout en bout doit être inférieure à 28 millisecondes.
• [C-SR-9] Il est FORTEMENT RECOMMANDÉ de ne pas dépasser 20 millisecondes de latence de mouvement à photon de bout en bout.
• [C-1-23] Le ratio du premier frame, qui correspond au ratio entre la luminosité des pixels du premier frame après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable, doit être d'au moins 85%.
• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de premier frame d'au moins 90%.
• PEUT fournir un cœur exclusif à l'application de premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer les numéros des cœurs de processeur exclusifs à l'application de premier plan supérieure.

Si le cœur exclusif est compatible, le cœur:

• [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes d'appareils utilisés par l'application), mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.

7.10. Technologie tactile

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.2.1.

7.11. Classe de performances multimédias

La classe de performances multimédias de l'implémentation de l'appareil peut être obtenue à partir de android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. Les exigences de la classe de performances multimédias sont définies pour chaque version d'Android à partir de R (version 30). La valeur spéciale 0 indique que l'appareil ne fait pas partie d'une classe de performances multimédias.

Si les implémentations de l'appareil renvoient une valeur non nulle pour android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, elles:

• [C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.

• [C-1-2] L'implémentation doit être destinée à un appareil portable.

• [C-1-3] DOIT respecter toutes les exigences de la "classe de performance des contenus multimédias" décrites dans la section 2.2.7.

Pour connaître les exigences spécifiques à l'appareil, consultez la section 2.2.7.

8. Performances et puissance

Certains critères de performances et d'alimentation minimaux sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de référence que les développeurs doivent prendre en compte 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 conditions minimales sont remplies pour garantir un taux de rafraîchissement et des temps de réponse cohérents pour les applications et les jeux. Selon le type d'appareil, les implémentations d'appareil PEUVENT avoir des exigences mesurables pour la latence de l'interface utilisateur et le changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes sur le stockage de données privées de l'application (partition /data) permet aux développeurs d'applications de définir des attentes appropriées qui faciliteront leur conception logicielle. Les implémentations d'appareils, en fonction du type d'appareil, PEUVENT avoir certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes:

• Performances d'écriture séquentielle Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 ko.
• Performances de lecture séquentielle Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire Mesuré en lisant un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 ko.

8.3. Modes d'économie d'énergie

Si les implémentations de l'appareil incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, le mode Doze) ou étendent les fonctionnalités pour appliquer des restrictions plus strictes que le bucket de mise en veille des applications RESTRICTED, elles:

• [C-1-1] NE DOIT PAS s'écarter de l'implémentation AOSP pour le déclenchement, la maintenance, les algorithmes de réveil et l'utilisation des paramètres système globaux ou de DeviceConfig pour les modes d'économie d'énergie App Standby et Doze.
• [C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation de paramètres globaux ou de DeviceConfig afin de gérer le débit des tâches, de l'alarme et du réseau pour les applications de chaque bucket en mode veille de l'application.
• [C-1-3] NE DOIT PAS s'écarter de l'implémentation AOSP pour le nombre de buckets App Standby utilisés pour App Standby.
• [C-1-4] DOIT implémenter les buckets de mise en veille des applications et le mode 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 utilisateur pour afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze ou de toute optimisation de la batterie, et DOIT implémenter l'intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS pour demander à l'utilisateur d'autoriser une application à ignorer les optimisations de la batterie.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour activer et désactiver la fonctionnalité Économiseur de batterie.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de fournir une affordance utilisateur pour afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.

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, consultez 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 l'ensemble des quatre états d'alimentation en veille définis par l'interface ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles:

• [C-1-1] Cet état ne doit être atteint que lorsque l'utilisateur a effectué une action explicite pour mettre l'appareil en état d'inactivité (par exemple, en fermant un couvercle qui fait physiquement partie de l'appareil ou en éteignant un véhicule ou un téléviseur) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le couvercle ou en rallumant le véhicule ou le téléviseur).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles:

• [C-2-1] DOIT respecter C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran, le processeur).

  À l'inverse, le SDK DOIT quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

  Par exemple, lorsque les applications tierces demandent à maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou à maintenir le processeur en cours d'exécution via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS entrer en état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris une mesure explicite pour mettre l'appareil en état 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 envoyé à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a mis l'appareil en état inactif. Il ne s'agit pas d'exemples exhaustifs, et AOSP implémente des signaux de réveil étendus qui déclenchent un réveil à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et une création de rapports plus précises de la consommation d'énergie fournissent au développeur d'applications à la fois les incitations et les outils nécessaires pour optimiser le schéma d'utilisation de l'énergie de l'application.

Implémentations de l'appareil:

• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [C-SR-2] Nous vous recommandons vivement de signaler toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
• [C-SR-3] Il est 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] Il est vivement recommandé de rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats au développeur de l'application.
• DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

8.5. Constance des performances

Les performances peuvent fluctuer de manière spectaculaire pour les applications de longue durée hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison du limitation du processeur en raison des limites de température. Android inclut des interfaces programmatiques afin que, lorsque l'appareil est compatible, l'application de premier plan la plus élevée puisse demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations de l'appareil:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode API PowerManager.isSustainedPerformanceModeSupported().

• DOIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils indiquent la prise en charge du mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan un niveau de performances cohérent pendant au moins 30 minutes, lorsque l'application le demande.
• [C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent deux cœurs de processeur ou plus, elles:

• DOIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan supérieure.

Si les implémentations d'appareils permettent de réserver un cœur exclusif pour l'application de premier plan, elles:

• [C-2-1] DOIT indiquer via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs pouvant être réservés par l'application de premier plan supérieure.
• [C-2-2] Le kernel DOIT empêcher l'exécution de tout processus d'espace utilisateur, à l'exception des pilotes d'appareil utilisés par l'application sur les cœurs exclusifs, mais PEUT autoriser l'exécution de certains processus de kernel si nécessaire.

Si les implémentations de l'appareil ne sont pas compatibles avec un cœur exclusif, elles:

• [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 de l'appareil:

• [C-0-1] DOIT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API dans la documentation destinée aux 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/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 listées dans les sous-sections suivantes.

9.1. Autorisations

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations Android et le modèle de rôles Android, comme défini dans la documentation destinée aux 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 peut être omis, modifié ou ignoré.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne se trouvent pas dans l'espace de noms android.\*.

• [C-0-2] Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED ne doivent être accordées qu'aux applications préinstallées dans le ou les chemins d'accès privilégiés de l'image système et dans le sous-ensemble des autorisations explicitement autorisées pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations de la liste d'autorisation pour chaque application à partir des fichiers du chemin d'accès etc/permissions/ et en utilisant le chemin d'accès system/priv-app comme chemin d'accès privilégié.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations de l'appareil:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder les autorisations d'exécution demandées et de fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] Il doit y avoir une seule et unique implémentation des deux interfaces utilisateur.
• [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf si :
  • Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise.
  • Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
• [C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage distant hors appareil, équipé d'un matériel sécurisé offrant une protection équivalente ou plus forte que celle décrite dans le service Google Cloud Key Vault pour éviter les attaques par force brute sur le facteur de connaissance du verrouillage de l'écran.

Implémentations de l'appareil:

• [C-0-7] DOIT respecter les propriétés de l'autorisation d'accéder à la position Android lorsqu'une application demande les données de position ou d'activité physique via une API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter, les éléments suivants:

  • Position de l'appareil (par exemple, latitude et longitude), 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] Vous devez OBLIGATOIREMENT obtenir le consentement de l'utilisateur pour autoriser une application à accéder aux données de localisation ou d'activité physique.
• [C-0-9] Vous devez accorder une autorisation d'exécution UNIQUEMENT à l'application disposant d'une autorisation suffisante, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les seules exceptions aux propriétés d'autorisation d'accès à la position Android ci-dessus concernent les applications qui n'accèdent pas à la position pour déduire ou identifier la position de l'utilisateur. Plus précisément:

• Lorsque les applications disposent de l'autorisation RADIO_SCAN_WITHOUT_LOCATION.
• À des fins de configuration et 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 limitées, ce qui modifie leur comportement.

• [C-0-10] Les autorisations marquées avec l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si:

  • Le fichier APK d'une 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 reçoit l'hardRestricted sur une version antérieure d'Android.

• [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT n'obtenir qu'un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles ne figurent pas sur la liste d'autorisation, comme décrit dans le SDK, où l'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 pour contourner les restrictions d'autorisation définies dans les API setPermissionPolicy et setPermissionGrantState.

• [C-0-13] Vous DEVEZ utiliser les API AppOpsManager pour enregistrer et suivre chaque accès programmatique aux données protégées par des autorisations dangereuses à partir des activités et services Android.

• [C-0-14] Vous devez attribuer des rôles uniquement aux applications dont les fonctionnalités répondent aux exigences du rôle.

• [C-0-15] NE DOIT PAS définir de rôles qui sont des doublons ou des fonctionnalités supersettes des rôles définis par la plate-forme.

Si les appareils signalent android.software.managed_users:

• [C-1-1] Les autorisations suivantes NE DOIVENT PAS être accordées de manière silencieuse par l'administrateur :
  • Position (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION)
  • Caméra (CAMERA)
  • Micro (RECORD_AUDIO)
  • Capteur corporel (BODY_SENSORS)
  • Activité physique (ACTIVITY_RECOGNITION)

Si les implémentations d'appareils permettent à l'utilisateur de choisir quelles applications peuvent dessiner par-dessus d'autres applications avec une activité qui gère l'intent ACTION_MANAGE_OVERLAY_PERMISSION, elles:

• [C-2-1] Vous devez vous 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, quelle que soit l'application à l'origine ou les informations qu'elle fournit.

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

• [C-3-1] Une clause de non-responsabilité doit s'afficher lors de la configuration d'un appareil entièrement géré (configuration du propriétaire de l'appareil) indiquant que l'administrateur informatique peut autoriser les applications à contrôler les paramètres du téléphone, y compris le micro, la caméra et la position, avec des options permettant à l'utilisateur de poursuivre la configuration ou de quitter la configuration, À MOINS que l'administrateur ait désactivé le contrôle des autorisations sur l'appareil.

Si les implémentations d'appareils préinstallent des packages contenant l'un des rôles System UI Intelligence (Intelligence de l'UI du système), System Ambient Audio Intelligence (Intelligence audio ambiante du système), System Audio Intelligence (Intelligence audio du système), System Notification Intelligence (Intelligence de notification du système), System Text Intelligence (Intelligence textuelle du système) ou System Visual Intelligence (Intelligence visuelle du système), les packages:

• [C-4-1] DOIT respecter toutes les exigences décrites pour les implémentations d'appareils dans la section "9.8.6 Capture de contenu".
• [C-4-2] L'application NE DOIT PAS disposer de l'autorisation android.permission.INTERNET. Cette exigence est plus stricte que la recommandation FORTEMENT RECOMMANDÉE indiquée dans la section 9.8.6.
• [C-4-3] NE DOIT PAS se lier à d'autres applications, à l'exception des applications système suivantes: Bluetooth, Contacts, Média, Téléphonie, SystemUI et les composants fournissant des API Internet.Cette exigence est plus stricte que la recommandation FORTEMENT RECOMMANDÉE indiquée dans la section 9.8.6.

9.2. UID et isolation des processus

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge le modèle de bac à sable d'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 en tant que même ID utilisateur Linux, à condition que les applications soient correctement signées et créées, 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 de l'appareil:

• [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. Environnements d'exécution alternatifs

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Autrement dit :

• [C-0-1] Les environnements d'exécution alternatifs DOIVENT être eux-mêmes des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.

• [C-0-2] Les 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 autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

• [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.

• [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ni être accordés à l'accès aux bacs à sable correspondant à d'autres applications Android.

• [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec, être accordés ou accorder à d'autres applications des droits d'accès du super-utilisateur (root) ou de tout autre ID utilisateur.

• [C-0-7] Lorsque les fichiers .apk d'autres environnements d'exécution 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 avec 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 une autorisation Android correspondante est disponible (appareil photo, 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 de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

• Les environnements d'exécution alternatifs DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

• Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et prend en charge l'isolation complète des utilisateurs et le clonage des profils utilisateur avec une isolation partielle(c'est-à-dire un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE).

• Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le multi-utilisateur si elles 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é conforme au 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 de répertoires de stockage d'application partagés (également appelés /sdcard) distincts et isolés pour chaque instance utilisateur.
• [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou le même système de fichiers.
• [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le 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 de l'appareil utilisent un support amovible pour les API de stockage externe. Comme cela rend les supports multimédias illisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel.

Si les implémentations d'appareils prennent en charge plusieurs utilisateurs, pour tous les utilisateurs, à l'exception de ceux créés spécifiquement pour exécuter deux instances de la même application:

• [C-2-1] DOIT disposer de répertoires de stockage d'application partagés (également appelés /sdcard) distincts et isolés pour chaque instance utilisateur.
• [C-2-2] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou le même 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 deux instances de la même application. Ces deux instances partagent un stockage partiellement isolé, sont présentées à l'utilisateur final dans le lanceur en même temps et apparaissent dans la même vue "Récents". Par exemple, cela peut permettre à l'utilisateur d'installer deux instances distinctes d'une même application sur un appareil à double carte SIM.

Si les implémentations d'appareils créent le profil utilisateur supplémentaire décrit ci-dessus, elles:

• [C-3-1] DOIT ne fournir l'accès qu'au stockage ou aux données déjà accessibles au profil utilisateur parent ou appartenant directement à ce profil utilisateur supplémentaire.
• [C-3-2] Ce profil ne doit PAS être utilisé comme profil professionnel.
• [C-3-3] DOIT disposer de répertoires de données d'application privés isolés du compte utilisateur parent.
• [C-3-4] NE DOIT PAS permettre la création du profil utilisateur supplémentaire si un propriétaire d'appareil est provisionné (voir la section 3.9.1) ni permettre la provision d'un propriétaire d'appareil sans d'abord supprimer le profil utilisateur supplémentaire.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout message SMS premium sortant. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur qui peuvent entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.telephony, elles:

• [C-1-1] L'application DOIT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT 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 d'accès obligatoire (MAC) de Security-Enhanced Linux (SELinux), le bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. Implémentations de l'appareil:

• [C-0-1] DOIT assurer la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité est implémentée sous le framework Android.
• [C-0-2] L'interface utilisateur ne doit PAS être 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. Toutefois, elle peut être visible lorsqu'une violation de sécurité non bloquée se produit, ce qui entraîne un exploit réussi.
• [C-0-3] SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android NE DOIT PAS être configurable par l'utilisateur ou le développeur d'applications.
• [C-0-4] Une application pouvant affecter une autre application via une API (telle qu'une API d'administration d'appareils) NE DOIT PAS configurer de règle qui compromet la compatibilité.
• [C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin de pouvoir accorder un accès plus précis à chaque processus, comme décrit sur le site du projet Android Open Source.
• [C-0-6] DOIT implémenter un mécanisme de bac à sable d'application de kernel qui permet de filtrer les appels système à l'aide d'une stratégie configurable à partir de programmes multithread. Le projet Open Source Android en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de threadgroup (TSYNC), comme décrit dans la section "Configuration du kernel" de source.android.com.

L'intégrité du noyau et les fonctionnalités d'autoprotection sont des éléments essentiels de la sécurité Android. Implémentations de l'appareil:

• [C-0-7] Le kernel doit mettre en œuvre des mécanismes de protection contre le débordement de tampon de pile. CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG sont des exemples de tels mécanismes.
• [C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau lorsque le code exécutable est en lecture seule, que les données en lecture seule ne sont pas exécutables ni enregistrables, et que les données enregistrables 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'objets statiques et dynamiques 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 de mémoire d'espace utilisateur lors de l'exécution en mode kernel (par exemple, PXN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire d'espace utilisateur dans le noyau en dehors des API d'accès utilisateurcopy normales (par exemple, PAN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
• [C-0-12] DOIT implémenter l'isolation de la table des pages du noyau si le matériel est vulnérable à CVE-2017-5754 sur tous les appareils livrés à l'origine avec le niveau d'API 28 ou version ultérieure (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] DOIT implémenter le renforcement de la prédiction de branche si le matériel est vulnérable à CVE-2017-5715 sur tous les appareils initialement livrés avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation marquées en lecture seule après l'initialisation (par exemple, __ro_after_init).

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de randomiser la mise en page du code et de la mémoire du noyau, et d'éviter les expositions qui pourraient 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-3] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau pour fournir une protection supplémentaire contre les attaques par réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI), la pile d'appels fantôme (SCS) ou la validation de l'excès de valeurs entières (IntSan) sur les composants qui l'ont activé.

• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tout composant d'espace utilisateur supplémentaire sensible à la sécurité, comme expliqué dans CFI et IntSan.

• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour éviter l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les variables locales.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau pour éviter l'utilisation d'allocations de tas de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Ils NE DOIVENT 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] Vous devez définir SELinux sur le mode d'application forcée global.
• [C-1-3] Vous devez configurer tous les domaines en mode d'application. Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/fournisseur.
• [C-1-4] Vous NE DEVEZ 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 compiler avec toutes les règles neverallow présentes, à la fois pour les domaines SELinux AOSP et les domaines spécifiques à l'appareil/au fournisseur.
• [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou version ultérieure dans des bacs à sable SELinux par application avec des restrictions SELinux par application sur le répertoire de données privées de chaque application.
• DOIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Open Source Android en amont et ne doit ajouter à cette règle que pour sa propre configuration spécifique à l'appareil.

Si les implémentations d'appareils utilisent un noyau autre que Linux ou Linux sans SELinux, elles:

• [C-2-1] Vous devez utiliser un système de contrôle d'accès obligatoire équivalent à SELinux.

Si les implémentations d'appareils utilisent des périphériques d'E/S compatibles avec le DMA, elles:

• [C-SR-8] Il est FORTEMENT RECOMMANDÉ d'isoler chaque appareil d'E/S capable de DMA à l'aide d'un IOMMU (par exemple, le SMMU ARM).

Android contient plusieurs fonctionnalités de défense en profondeur qui sont essentielles à la sécurité des appareils. De plus, Android se concentre sur la réduction des principales classes de bugs courants qui contribuent à une mauvaise qualité et à une mauvaise sécurité.

Pour réduire les bugs de mémoire, les implémentations d'appareils:

• [C-SR-9] Il est FORTEMENT RECOMMANDÉ de les tester à l'aide d'outils de détection des erreurs de mémoire dans l'espace utilisateur tels que MTE pour les appareils ARMv9, HWASan pour les appareils ARMv8+ ou ASan pour les autres types d'appareils.
• [C-SR-10] Nous vous recommandons vivement de les tester à l'aide d'outils de détection des erreurs de mémoire du noyau tels que KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS pour les appareils ARMv9, CONFIG_KASAN_SW_TAGS pour les appareils ARMv8 ou CONFIG_KASAN_GENERIC pour les autres types d'appareils).
• [C-SR-11] 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-12] Il est vivement recommandé d'utiliser un protocole standard pour le partage de mémoire entre Android et le TEE, comme Arm Firmware Framework pour Armv8-A (FF-A).
• [C-SR-13] Il est FORTEMENT RECOMMANDÉ de limiter les applications approuvées à l'accès à la mémoire qui a été explicitement partagée avec elles via le protocole ci-dessus. Si l'appareil est compatible avec le niveau d'exception Arm S-EL2, il doit être appliqué par le gestionnaire de partitions sécurisé. Sinon, cela doit être appliqué par l'OS TEE.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et le gère à l'aide de UsageStatsManager.

Implémentations de l'appareil:

• [C-0-1] DOIT conserver cet historique utilisateur pendant une période de conservation raisonnable.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle que configurée par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via l'API système StatsManager et IncidentManager.

Implémentations de l'appareil:

• [C-0-2] Le rapport d'incident créé par la classe d'API système IncidentManager DOIT inclure uniquement les champs marqués avec DEST_AUTOMATIC.
• [C-0-3] Vous NE DEVEZ PAS utiliser les identifiants d'événement système pour consigner d'autres événements que ceux décrits dans les documents du SDK StatsLog. Si des événements système supplémentaires sont consignés, ils PEUVENT utiliser un identifiant d'atome différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations de l'appareil:

• [C-0-1] IL EST INTERDIT de précharger ou de distribuer des composants logiciels prêts à l'emploi qui envoient les informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran, le rapport de bug) hors de l'appareil sans l'autorisation de l'utilisateur ni les notifications en cours.
• [C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur permettant de capturer toutes les informations sensibles affichées à l'écran de l'utilisateur chaque fois que la diffusion ou l'enregistrement d'écran est activé via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs une affordance pour désactiver l'affichage futur du consentement de l'utilisateur.
• [C-0-3] L'utilisateur doit recevoir une notification continue lorsque la diffusion ou l'enregistrement d'écran est activé. 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 les contenus affichés à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou d'autres moyens propriétaires décrits dans la section 9.8.6 Capture de contenu, elles:

• [C-1-1] L'utilisateur doit recevoir une notification continue chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement des données.

Si les implémentations d'appareils incluent un composant activé par défaut, capable d'enregistrer l'audio ambiant et/ou l'audio lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, elles:

• [C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil l'audio brut enregistré ni tout format pouvant être converti en audio d'origine ou en fac-similé proche, sauf avec le consentement explicite de l'utilisateur.

Un "indicateur de micro" 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 comme étant un micro en cours d'utilisation(par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison de ces éléments).

Un "indicateur de caméra" 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 comme étant une caméra en cours d'utilisation (par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Après la première seconde d'affichage, un indicateur peut changer visuellement, par exemple en devenant plus petit, et n'est pas obligé de s'afficher comme il était présenté et compris à l'origine.

L'indicateur du micro peut être fusionné avec un indicateur d'appareil photo actif, à condition que du texte, des icônes ou des couleurs indiquent à l'utilisateur que l'utilisation du micro a commencé.

L'indicateur de l'appareil photo peut être fusionné avec un indicateur de micro actif, à condition que du texte, des icônes ou des couleurs indiquent à l'utilisateur que l'utilisation de l'appareil photo a commencé.

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

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur du 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 les applications disposant des rôles indiqués 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 qui utilisent le micro, comme renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que les messages d'attribution qui leur sont associés.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur du micro pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions utilisateur directes.

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

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur de caméra lorsqu'une application accède aux données de la caméra en direct, mais pas lorsque la caméra n'est accessible que par une ou plusieurs applications disposant des rôles indiqués dans la section 9.1 Autorisations avec identifiant CDD [C-3-X].
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher les applications récentes et actives à l'aide de la caméra telle qu'elle est renvoyée par PermissionManager.getIndicatorAppOpUsageData(), ainsi que les messages d'attribution qui leur sont associés.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de l'appareil photo pour les applications système qui disposent d'interfaces utilisateur visibles ou d'interactions utilisateur directes.

9.8.3. Connectivité

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

• [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations de l'appareil:

• [C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin d'autorités de certification (CA) approuvées par le système que ceux fournis dans le projet Open Source Android en amont.
• [C-0-2] DOIT être fourni avec un magasin d'autorités de certification racine utilisateur vide.
• [C-0-3] DOIT afficher un avertissement à l'utilisateur indiquant que le trafic réseau peut être surveillé lorsqu'une autorité de certification racine utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations de l'appareil:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
  • Ce trafic réseau peut être surveillé.
  • Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, en préchargeant un service VPN avec android.permission.CONTROL_VPN accordé), ils:

• [C-2-1] DOIT demander l'autorisation de l'utilisateur avant d'activer ce mécanisme, à moins que ce VPN ne soit activé par le contrôleur de stratégie d'appareil via DevicePolicyManager.setAlwaysOnVpnPackage(), auquel cas l'utilisateur n'a pas besoin de fournir un consentement distinct, mais DOIT simplement être informé.

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] Vous devez désactiver cette affordance utilisateur pour les applications qui ne prennent pas en charge le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.8.5. Identifiants des appareils

Implémentations de l'appareil:

• [C-0-1] Une application DOIT empêcher l'accès au numéro de série de l'appareil et, le cas échéant, au code IMEI/MEID, au numéro de série de la carte SIM et à l'IMSI (International Mobile Subscriber Identity), sauf si elle répond à l'une des conditions suivantes :
  • est une application opérateur signée et validée par les fabricants d'appareils.
  • a reçu l'autorisation READ_PRIVILEGED_PHONE_STATE.
  • dispose de privilèges d'opérateur, comme défini dans la section Privilèges de l'opérateur sur la carte UICC.
  • est le propriétaire de l'appareil ou du profil auquel l'autorisation READ_PHONE_STATE a été accordée.
  • (Pour le numéro de série de la SIM/l'ICCID uniquement) les réglementations locales exigent que l'application détecte les modifications de l'identité de l'abonné.

9.8.6. Capture de contenu et recherche dans les applications

Android, via les API système ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou par d'autres moyens propriétaires, prend en charge un mécanisme permettant aux implémentations d'appareils de capturer les interactions de données d'application suivantes entre les applications et l'utilisateur:

• Texte et graphiques 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 des contenus 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 de même capacité.
• Tout texte ou toute autre donnée envoyée via TextClassifier API au System TextClassifier, c'est-à-dire au service système, pour comprendre le sens du texte et générer les actions suivantes prévues en fonction du texte.
• Données indexées par l'implémentation d'AppSearch sur la plate-forme, y compris, mais sans s'y limiter, le texte, les graphiques, les données multimédias ou d'autres données similaires.

Si les implémentations d'appareils capturent 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 comme version d'API 26 ou supérieure décrits 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 ni de toute autre méthode de sauvegarde.
• [C-1-3] DOIT n'envoyer toutes ces données et le journal de l'appareil qu'à l'aide d'un mécanisme protégeant la confidentialité. Le mécanisme de protection de la confidentialité est défini comme "celui qui n'autorise que l'analyse globale et empêche la mise en correspondance des événements consignés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher toute introspection des données par utilisateur (par exemple, implémentée à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
• [C-1-4] NE DOIT PAS associer ces données à une identité 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 décrites dans la section actuelle (9.8.6 Capture de contenu), sauf avec le consentement explicite de l'utilisateur à chaque fois qu'elles sont partagées.
• [C-1-6] DOIT fournir à l'utilisateur la possibilité d'effacer les données collectées par ContentCaptureService ou les moyens propriétaires si les données sont stockées sous quelque forme que ce soit sur l'appareil.
• [C-1-7] DOIT fournir une affordance utilisateur pour désactiver l'affichage des données collectées via AppSearch ou des moyens propriétaires sur la plate-forme Android (par exemple, le 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 basées sur des implémentations Open Source accessibles au public.

Si les implémentations d'appareils incluent un service qui implémente l'API système 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 installable par l'utilisateur et DOIT n'autoriser que les services préinstallés à capturer ces données.
• [C-2-2] NE DOIT PAS autoriser d'autres applications que le mécanisme de services préinstallés à pouvoir capturer de telles données.
• [C-2-3] DOIT fournir une affordance utilisateur pour désactiver les services.
• [C-2-4] NE DOIT PAS omettre l'affordance utilisateur pour gérer les autorisations Android détenues par les services et suivre le modèle d'autorisations Android, comme décrit dans la section 9.1. Autorisation.

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de séparer les services des autres composants système(par exemple, de ne pas lier le service ni de partager les ID de processus), sauf dans les cas suivants:

  • Téléphonie, Contacts, UI du système et multimédia

Android, via SpeechRecognizer#onDeviceSpeechRecognizer(), permet d'effectuer la reconnaissance vocale sur l'appareil, sans impliquer le réseau. Toute implémentation de SpeechRecognizer sur l'appareil DOIT respecter les règles décrites dans cette section.

9.8.7. Accès au presse-papiers

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS renvoyer de données coupées dans le presse-papiers (par exemple, via l'API ClipboardManager) sauf si l'application est l'IME par défaut ou l'application active.

9.8.8. Position

La position inclut des informations de la classe Android Location( telles que la latitude, la longitude et l'altitude), ainsi que des identifiants pouvant être convertis en position. La position peut être aussi précise que le DGPS (Differential Global Positioning System) ou aussi approximative que les positions au niveau du pays (comme le code pays mobile).

Vous trouverez ci-dessous la liste des types de position qui dérivent directement de la position d'un utilisateur ou qui peuvent être convertis en position d'un utilisateur. Cette liste n'est pas exhaustive, mais elle doit servir d'exemple de ce dont la position peut être dérivée directement ou indirectement:

• GPS/GNSS/DGPS/PPP
  • Global Positioning Solution ou Global Navigation Satellite System ou Differential Global Positioning Solution
  • Cela inclut également les mesures GNSS brutes et l'état GNSS.
    • La position précise peut être dérivée des mesures GNSS brutes.
• Technologies sans fil avec des identifiants uniques, tels que :
  • Points d'accès Wi-Fi (adresse MAC, BSSID, nom ou SSID)
  • Bluetooth/BLE (adresse MAC, BSSID, nom ou SSID)
  • UWB (adresse MAC, BSSID, nom ou SSID)
  • ID de la tour de téléphonie mobile (3G, 4G, 5G, etc., y compris toutes les futures technologies de modem mobile disposant d'identifiants uniques)

Pour référence, consultez les API Android qui nécessitent les autorisations ACCESS_FINE_Location ou ACCESS_COARSE_Location.

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS activer/désactiver le paramètre de localisation de l'appareil et les paramètres de balayage Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ou son initiation.
• [C-0-2] DOIT fournir à l'utilisateur la possibilité d'accéder aux informations liées à la position, y compris les demandes de position récentes, les autorisations au niveau de l'application et l'utilisation de la numérisation Wi-Fi/Bluetooth pour déterminer la position.
• [C-0-3] L'application qui utilise l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] doit impérativement être une session d'urgence déclenchée par l'utilisateur (par exemple, composer le 112 ou envoyer un SMS au 112). Toutefois, pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction active de l'utilisateur en cas de détection d'un accident (par exemple, pour répondre aux exigences d'eCall).
• [C-0-4] L'API Emergency Location Bypass doit conserver la possibilité de contourner les paramètres de localisation de l'appareil sans les modifier.
• [C-0-5] DOIT planifier une notification qui rappelle à l'utilisateur qu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Les applications Android qui ciblent le niveau d'API 30 ou version ultérieure ne peuvent pas voir les informations sur les autres applications installées par défaut (voir la section Visibilité du package dans la documentation du SDK Android).

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou version ultérieure les informations sur une autre application installée, sauf si l'application peut déjà voir les informations sur l'autre application installée via les API gérées. Cela inclut, mais sans s'y limiter, les informations exposées par les API personnalisées ajoutées par l'implémentateur 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 dans un espace de stockage externe. Les seules exceptions sont les suivantes :
  • Autorité du fournisseur de stockage externe (applications telles que DocumentsUI, par exemple)
  • Fournisseur de téléchargement qui utilise l'autorité du fournisseur "téléchargements" pour télécharger des fichiers dans l'espace de stockage de l'application.
  • 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 disposent de l'autorisation INSTALL_PACKAGES ne peuvent accéder qu'aux répertoires "obb" dans le but de gérer les fichiers d'extension pour APK.

9.8.10. Rapport de bug sur la connectivité

Si les implémentations d'appareils déclarent l'indicateur 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 à accepter 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 à l'aide de BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes :
  • Dump TelephonyDebugService
  • Dump TelephonyRegistry
  • Dump WifiService
  • Dump ConnectivityService
  • Un vidage de l'instance CarrierService du package appelant (si lié)
  • Tampon journal radio
• [C-1-5] Les rapports générés NE DOIVENT PAS inclure les éléments suivants :
  • Tout type d'information qui n'est pas directement lié au débogage de la connectivité.
  • Tout type de journaux de trafic d'application installé par l'utilisateur ou de profils détaillés des applications/packages installés par l'utilisateur (les UID sont acceptés, mais les noms de package ne le sont pas).
• POURRAIENT inclure des informations supplémentaires qui ne sont associées à aucune identité utilisateur. (par exemple, les journaux du fournisseur).

Si les implémentations d'appareils incluent des informations supplémentaires (par exemple, des journaux du fournisseur) dans les rapports de bugs et que ces informations ont un impact sur la confidentialité/la sécurité/la batterie/le stockage/la mémoire, elles:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir un paramètre de développement par défaut sur "Désactivé". L'implémentation de référence AOSP répond à ce problème 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 bugs.

9.8.11. Partage des blobs de données

Android, via BlobStoreManager, permet aux applications de fournir des blobs de données au système pour les partager avec un ensemble d'applications sélectionné.

Si les implémentations d'appareils prennent en charge les blobs de données partagés, comme décrit dans la documentation du SDK, elles:

• [C-1-1] NE DOIT PAS partager des objets blob de données appartenant à des applications au-delà de ce qu'ils étaient censés autoriser (c'est-à-dire que 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() NE DOIVENT PAS être modifiés). L'implémentation de référence AOSP répond à ces exigences.
• [C-1-2] NE DOIT PAS envoyer de l'appareil ni partager avec d'autres applications les hachages sécurisés des blobs de données (qui sont utilisés pour contrôler l'accès).

9.8.12. Reconnaissance musicale

Android, via l'API système MusicRecognitionManager, prend en charge un mécanisme permettant aux implémentations d'appareils de demander la reconnaissance de la musique, à partir d'un enregistrement audio, et de déléguer la reconnaissance de la musique à une application privilégiée implémentant l'API MusicRecognitionService.

Si les implémentations d'appareils incluent un service qui implémente l'API système MusicRecognitionManager ou tout service propriétaire qui diffuse des données audio comme décrit ci-dessus, elles:

• [C-1-1] L'appelant de MusicRecognitionManager doit disposer de l'autorisation MANAGE_MUSIC_RECOGNITION.
• [C-1-2] Une seule application de reconnaissance musicale préinstallée doit implémenter MusicRecognitionService.
• [C-1-3] NE DOIT PAS permettre aux utilisateurs de remplacer MusicRecognitionManagerService ou MusicRecognitionService par une application ou un service installable par l'utilisateur.
• [C-1-4] DOIT s'assurer que lorsque MusicRecognitionManagerService accède à l'enregistrement audio et le transfère à l'application implémentant MusicRecognitionService, l'accès audio est suivi via des invocations de AppOpsManager.noteOp / startOp.

Si les implémentations de MusicRecognitionManagerService ou MusicRecognitionService sur l'appareil stockent des données audio capturées, elles:

• [C-2-1] NE DOIT PAS stocker d'audio brut ni d'empreinte audio sur disque, ni en mémoire pendant plus de 14 jours.
• [C-2-2] NE DOIT PAS partager ces données en dehors de MusicRecognitionService, sauf avec le consentement explicite de l'utilisateur à chaque fois qu'elles sont partagées.

9.8.13. SensorPrivacyManager

Si les implémentations d'appareils offrent à l'utilisateur une affordance logicielle lui permettant de désactiver l'entrée de l'appareil photo et/ou du micro pour l'implémentation de l'appareil, elles:

• [C-1-1] DOIT renvoyer précisément "true" pour la méthode d'API supportsSensorToggle() appropriée.
• [C-1-2] Lorsqu'une application tente d'accéder à un micro ou à une caméra bloqués, elle DOIT présenter à l'utilisateur une affordance utilisateur non ignorable qui indique clairement que le capteur est bloqué et nécessite un choix pour continuer à le bloquer ou à le débloquer, conformément à l'implémentation AOSP qui répond à cette exigence.
• [C-1-3] DOIT uniquement transmettre des données audio et de caméra vides (ou factices) aux applications et ne pas signaler de code d'erreur si l'utilisateur n'allume pas la caméra ni le micro via l'affordance utilisateur présentée dans [C-1-2] ci-dessus.

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT répondre aux exigences de la section 9.9.1. Les appareils lancés sur un niveau d'API antérieur à celui de ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. Ils DOIVENT plutôt respecter les exigences de la section 9.9 du document de définition de la compatibilité Android correspondant au niveau d'API sur lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations de l'appareil:

• [C-0-1] DOIT implémenter les API du mode Démarrage direct, même si elles ne sont pas compatibles avec le chiffrement de stockage.

• [C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que les emplacements de stockage chiffrés de l'appareil (DE) et des identifiants (CE) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations de l'appareil:

• [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] Le chiffrement du stockage des données DOIT être activé par défaut au moment où l'utilisateur a terminé l'expérience de configuration prête à l'emploi.

• [C-0-3] DOIT respecter la condition de chiffrement du stockage des données ci-dessus en implémentant l'une des deux méthodes de chiffrement suivantes:

  • Chiffrement basé sur les fichiers (FBE) et chiffrement des métadonnées, comme décrit dans la section 9.9.3.1.
  • Chiffrement au niveau des blocs par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations de l'appareil sont chiffrées, elles:

• [C-1-1] DOIT démarrer sans demander à l'utilisateur d'authentifier ses identifiants et autoriser les applications compatibles avec le démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DOIT n'autoriser l'accès au stockage chiffré par identifiants (CE) qu'après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, code, code PIN, schéma ou empreinte digitale) et que le message ACTION_USER_UNLOCKED a été diffusé.
• [C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller le stockage protégé par le CE sans les identifiants fournis par l'utilisateur, une clé d'entiercement enregistrée ou une implémentation de la reprise au redémarrage conforme aux exigences de la section 9.9.4.
• [C-1-4] Vous devez utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers avec chiffrement des métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec le chiffrement des métadonnées:

• [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide d'AES-256-XTS ou d'Adiantum. AES-256-XTS fait référence à l'Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme indiqué sur la page https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que les tailles de fichiers, la propriété, les modes et les attributs étendus (xattr).
• [C-1-6] DOIT chiffrer les noms de fichiers à l'aide d'AES-256-CBC-CTS ou d'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 de fichier, le contenu du fichier et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisées, et non Adiantum.
• [C-1-13] DOIT utiliser une fonction de dérivation de clé cryptographiquement sécurisée et non réversible (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, les clés par fichier) à partir des clés CE et DE. "Cryptographiquement sécurisée et non réversible" signifie que la fonction de dérivation de clé présente une 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] IL EST INTERDIT d'utiliser les mêmes clés ou sous-clés de chiffrement basé sur les fichiers (FBE) à des fins cryptographiques différentes (par exemple, à la fois pour le chiffrement et la dérivation de clé, ou pour deux algorithmes de chiffrement différents).
• [C-1-15] DOIT s'assurer que tous les blocs de contenu de fichier chiffré non supprimés sur un 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. De plus, toutes ces combinaisons DOIVENT être distinctes, sauf lorsque le chiffrement est effectué à l'aide d'un matériel de chiffrement intégré qui n'accepte qu'une longueur d'IV de 32 bits.
• [C-1-16] DOIT s'assurer que tous les noms de fichiers chiffrés non supprimés sur un 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 de système de fichiers chiffrés sur le stockage persistant ont été chiffrés à l'aide de combinaisons distinctes de clé de chiffrement et de vecteur d'initialisation (IV).

• Clés protégeant les zones de stockage CE et DE et les métadonnées du système de fichiers:

  • [C-1-7] DOIT être lié de manière cryptographique à un Keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine de confiance matérielle de l'appareil.
  • [C-1-8] Les clés CE DOIVENT être associées aux identifiants de l'écran de verrouillage de l'utilisateur.
  • [C-1-9] Les clés CE DOIVENT être associé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. Autrement dit, la clé CE ou DE d'un utilisateur ne doit pas correspondre à celle d'un autre utilisateur.
  • [C-1-11] DOIT utiliser les algorithmes de chiffrement, les longueurs de clé et les modes pris en charge de manière obligatoire.
  • [C-1-12] DOIT être effacé de manière sécurisée lors du déverrouillage et du verrouillage du bootloader, comme décrit ici.

• DOIT rendre les applications essentielles préinstallées (Alarme, Téléphone, Messenger, par exemple) 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ée sur la fonctionnalité "dm-default-key" du noyau Linux.

9.9.3.2. Chiffrement au niveau des blocs par utilisateur

Si les implémentations d'appareils utilisent le chiffrement par blocs par utilisateur, elles:

• [C-1-1] DOIT activer la prise en charge du mode multi-utilisateur, comme décrit dans la section 9.5.
• [C-1-2] DOIT fournir des partitions par utilisateur, à l'aide de partitions brutes ou de volumes logiques.
• [C-1-3] Vous DEVEZ utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des dispositifs de stockage en bloc sous-jacents.

• [C-1-4] Vous DEVEZ utiliser AES-256-XTS pour le chiffrement au niveau des blocs des partitions utilisateur.

• Les clés protégeant les appareils chiffrés par 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 de confiance matérielle de l'appareil.
  • [C-1-6] DOIT être associé aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau des blocs par utilisateur peut être implémenté à l'aide de la fonctionnalité "dm-crypt" du noyau Linux sur les partitions par utilisateur.

9.9.4. Reprendre au redémarrage

La reprise au redémarrage permet de déverrouiller l'espace de 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 déclenché par une mise à jour OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

Une implémentation de la reprise au redémarrage doit continuer à s'assurer que lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour ce pirate informatique de récupérer les données chiffrées par le chiffrement côté client de l'utilisateur, même si l'appareil est allumé, que l'espace de stockage côté client est déverrouillé et que l'utilisateur a déverrouillé l'appareil après avoir reçu une mise à jour OTA. Pour la résistance aux attaques internes, nous supposons également que le pirate informatique accède aux clés de signature cryptographiques de diffusion.

Plus spécifiquement :

• [C-0-1] Le stockage CE NE DOIT PAS être lisible, même par le pirate informatique qui dispose physiquement de l'appareil et dispose alors des fonctionnalités et des limites suivantes:

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • Peut entraîner la réception d'une mise à jour OTA par l'appareil.
  • Peut modifier le fonctionnement de n'importe quel matériel (point d'accès, flash, etc.), sauf comme indiqué ci-dessous, mais cette modification implique un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.
  • Impossible de modifier le fonctionnement du matériel anti-piratage (par exemple, Titan M).
  • Impossible de lire la RAM de l'appareil en direct.
  • Ne peut pas obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ni les faire saisir.

Par exemple, une implémentation d'appareil qui implémente et respecte toutes les descriptions disponibles ici sera conforme à [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état de l'intégrité de l'appareil. Implémentations de l'appareil:

• [C-0-1] DOIT indiquer correctement via la méthode de l'API système PersistentDataBlockManager.getFlashLockState() si l'état de son bootloader permet le flashage de l'image système.

• [C-0-2] L'appareil doit être compatible avec le démarrage validé pour garantir son intégrité.

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'elles ne peuvent pas prendre en charge cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence.

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

• [C-1-1] Vous DEVEZ déclarer l'option de fonctionnalité de la plate-forme android.software.verified_boot.
• [C-1-2] Le système DOIT effectuer une validation à chaque séquence de démarrage.
• [C-1-3] La validation doit commencer à partir d'une clé matérielle immuable qui est la racine de confiance et s'étendre jusqu'à la partition système.
• [C-1-4] Vous DEVEZ implémenter chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
• [C-1-5] DOIT utiliser des algorithmes de validation aussi sécurisés que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clé publique (RSA-2048).
• [C-1-6] Le démarrage NE DOIT PAS être autorisé à se terminer lorsque la validation du système échoue, sauf si l'utilisateur accepte de tenter le démarrage de toute façon, auquel cas les données de tout bloc de stockage non validé NE DOIVENT PAS être utilisées.
• [C-1-7] Le bootloader 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 distinctes (par exemple, une radio, un processeur d'image spécialisé), il est FORTEMENT RECOMMANDÉ de vérifier chaque étape du processus de démarrage de chacune de ces puces.
• [C-1-8] DOIT utiliser un stockage inviolable: pour stocker si le bootloader est déverrouillé. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] DOIT inviter l'utilisateur, lorsqu'il utilise l'appareil, et exiger une confirmation physique avant d'autoriser la transition du mode bootloader verrouillé au mode bootloader déverrouillé.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (par exemple, les partitions de démarrage et système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale de l'OS autorisée.
• [C-1-11] Le bootloader doit EFFACER de manière sécurisée toutes les données utilisateur lors du déverrouillage et du verrouillage, conformément à la section 9.12. "Data Deletion" (y compris la partition userdata et tous les espaces NVRAM).
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de valider tous les fichiers APK d'application privilégiés avec une chaîne de confiance enracinée 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 (tel que le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
• DOIT implémenter une protection contre le rollback pour tout composant avec un micrologiciel persistant (par exemple, un modem ou une caméra) et DOIT utiliser un stockage inviolable 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 exigences C-1-8 à C-1-11 sur une version antérieure d'Android et qu'elles ne peuvent pas être prises en charge par une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégrée au bootloader utilisé pour charger Android.

Implémentations de l'appareil:

• [C-0-3] DOIT prendre en charge la vérification cryptographique du contenu du fichier par rapport à une clé approuvée sans lire l'intégralité du fichier.
• [C-0-4] NE DOIT PAS autoriser les requêtes de lecture sur un fichier protégé à aboutir lorsque le contenu lu ne correspond pas à une clé fiable.

Si les implémentations d'appareils sont déjà lancées sans possibilité de vérifier le contenu des fichiers à l'aide d'une clé approuvée sur une version antérieure d'Android et qu'elles ne peuvent pas prendre en charge cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence. Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations de l'appareil:

• [C-SR-4] Il est vivement recommandé de prendre en charge l'API Android Protected Confirmation.

Si les implémentations de l'appareil sont compatibles avec l'API Android Protected Confirmation:

• [C-3-1] Vous DEVEZ signaler 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, qu'il soit malveillant ou non, 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 demandé, 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 cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations de l'appareil:

• [C-0-1] DOIT permettre d'importer ou de générer 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 temporel DOIT être d'au moins 30*2^floor((n-30)/10)) secondes ou d'au moins 24 heures, la valeur la plus faible étant retenue.
• NE DOIT PAS limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle:

• [C-1-1] L'implémentation du keystore doit être sauvegardée avec un environnement d'exécution isolé.
• [C-1-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du 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 le DMA. Le projet Open Source Android (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 examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont d'autres options.
• [C-1-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et ne permettre l'utilisation des clés liées à l'authentification qu'après une authentification réussie. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à n'autoriser que l'environnement d'exécution isolé à effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [C-1-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez 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 une implémentation d'appareil est déjà lancée sur une version antérieure d'Android, cet appareil est exempté de l'obligation d'avoir un keystore compatible avec un environnement d'exécution isolé et d'accepter l'attestation de clé, sauf s'il déclare la fonctionnalité android.hardware.fingerprint, qui nécessite un keystore compatible avec un environnement d'exécution isolé.

• [C-1-5] 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 minimal autorisé de 15 secondes. Les appareils automobiles, qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur change, PEUVENT NE PAS avoir de configuration de délai de mise en veille.
• [C-1-6] DOIT être compatible avec l'un des éléments suivants :
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1, ou
  • IKeyMintDevice version 1.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la version 1 d'IKeyMintDevice.

9.11.1. Verrouillage sécurisé de l'écran et authentification

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux, où une authentification primaire basée sur une usine de connaissances peut être étayée par une biométrie secondaire forte ou par des modalités tertiaires plus faibles.

Implémentations de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de ne définir qu'une seule des méthodes suivantes comme méthode d'authentification principale :
  • Un code numérique
  • Un mot de passe alphanumérique
  • Un balayage sur une grille de 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 primaires 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 de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage si elles sont basées sur un secret connu et qu'elles utilisent une nouvelle méthode d'authentification pour être traitées comme un moyen sécurisé de verrouiller l'écran:

• [C-3-1] L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
• [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
• [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer l'une des méthodes d'authentification primaires recommandées (code, schéma, mot de passe) implémentées et fournies dans AOSP.
• [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la stratégie d'exigences de mot de passe via la méthode DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive que PASSWORD_COMPLEXITY_NONE ou via la méthode DevicePolicyManager.setPasswordQuality() avec une constante plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Les nouvelles méthodes d'authentification DOIVENT soit revenir aux méthodes d'authentification primaires recommandées (code, schéma, mot de passe) toutes les 72 heures ou moins, soit indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de ses données.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur les données biométriques pour être traitée 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 pour la classe 1 (anciennement Convenience).
• [C-4-2] DOIT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu.
• [C-4-3] DOIT être désactivé et n'autoriser que l'authentification primaire recommandée à déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la stratégie de fonctionnalité 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 forte), comme décrit dans la section 7.3.10:

• [C-5-1] Les méthodes DOIVENT être désactivées si l'application du contrôleur de stratégie d'appareil (DPC) a défini la stratégie de qualité des exigences de mot de passe via la méthode DevicePolicyManager.setRequiredPasswordComplexity() avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_LOW ou à l'aide de la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] L'utilisateur DOIT être invité à fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe), 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 cette section ci-dessous.

Si les implémentations de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur la position:

• [C-6-1] Ils DOIVENT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et qui répond aux exigences pour être traitée comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et ne doit autoriser qu'une seule des méthodes d'authentification primaires recommandées à déverrouiller l'écran lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle avec :
  • La méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)
  • 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é à utiliser l'une des méthodes d'authentification primaires recommandées (code, schéma, mot de passe, par exemple) au moins une fois toutes les quatre heures.
• [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.

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

• [C-7-1] Le menu des paramètres et l'écran de verrouillage doivent indiquer clairement quand le verrouillage de l'appareil est différé ou 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" et "Le bouton Marche/Arrêt verrouille instantanément" dans le menu des paramètres, ainsi qu'une icône distincte sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et implémenter entièrement toutes les API de l'agent de confiance dans la classe DevicePolicyManager, comme la constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] La fonction TrustAgentService.addEscrowToken() NE DOIT PAS être implémentée entièrement sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil portable), mais elle PEUT être implémentée entièrement sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou automobile).
• [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
• [C-7-5] Vous NE DEVEZ PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui sur lequel 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 Automotive, le jeton de séquestre ne doit pas être stocké sur une partie du véhicule.
• [C-7-6] DOIT informer l'utilisateur des conséquences sur la sécurité avant d'activer le jeton d'entiercement pour déchiffrer le stockage de données.
• [C-7-7] DOIT disposer d'un mécanisme de remplacement 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 primaire recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les 72 heures, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est en cause.
• [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma, mot de passe) comme décrit dans [C-1-7] et [C-1-8] dans la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est en cause.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.
• [C-7-11] Les TrustAgents sur les appareils personnels principaux (par exemple, les appareils portables) NE DOIVENT PAS être autorisés à déverrouiller l'appareil.Ils ne peuvent être utilisés que pour maintenir un appareil déjà déverrouillé dans cet état pendant un maximum 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 de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller un écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et qu'elles utilisent une nouvelle méthode d'authentification pour déverrouiller le clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la stratégie de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_NONE ou via la méthode DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive que 'PASSWORD_COMPLEXITY_NONE'.
• [C-8-2] Ils NE DOIVENT PAS réinitialiser les minuteurs d'expiration des mots de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Ils NE DOIVENT PAS exposer une API à utiliser par des applications tierces pour modifier l'état de verrouillage.

Si les implémentations d'appareils prennent en charge des états d'alimentation de l'écran distincts via DeviceStateManager ET des états de verrouillage de l'écran distincts via KeyguardDisplayManager, ils:

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser des identifiants conformes aux exigences définies dans la section 9.11.1 ou des identifiants biométriques conformes au moins aux spécifications de classe 1 définies dans la section 7.3.10 pour permettre le déverrouillage indépendant à partir de l'écran de l'appareil par défaut.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de limiter le déverrouillage de l'écran distinct via un délai d'inactivité de l'écran défini.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de permettre à l'utilisateur de verrouiller globalement tous les écrans via le verrouillage à partir 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 dans l'environnement d'exécution isolé décrit ci-dessus. Un tel processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre pour être considéré comme une StrongBox.

Implémentations d'appareils avec un processeur sécurisé dédié:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox. StrongBox deviendra probablement obligatoire dans une prochaine version.

Si les implémentations de l'appareil 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é utilisé pour sauvegarder le keystore et 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, DRAM, coprocesseur ni autre ressource de base 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 des informations de la part 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%) qui est à l'abri de toute manipulation par l'AP.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit une sortie distribuée uniformément et imprévisible.

• [C-1-7] DOIT être résistant aux accès non autorisés, y compris à la pénétration physique et aux glitchs.

• [C-1-8] DOIT être résistant aux canaux auxiliaires, y compris à la fuite d'informations via les canaux auxiliaires d'alimentation, de synchronisation, de rayonnement électromagnétique et de rayonnement thermique.

• [C-1-9] Le stockage doit être sécurisé et garantir la confidentialité, l'intégrité, l'authenticité, la cohérence et la fraîcheur des contenus. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf comme autorisé par les API StrongBox.

• Pour valider la conformité avec [C-1-3] à [C-1-9], les implémentations d'appareils:

  • [C-1-10] DOIT inclure le matériel certifié selon le profil de protection des cartes à puce sécurisées BSI-CC-PP-0084-2014 ou évalué par un laboratoire de test accrédité au niveau national intégrant une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
  • [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire de test accrédité au niveau national, qui intègre une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'un objectif de sécurité, d'un niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement obligatoire dans une prochaine version.

• [C-SR-3] 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 du micrologiciel ne peut pas produire de micrologiciel qui provoque une fuite de secrets par la StrongBox, pour contourner les exigences de sécurité fonctionnelles ou pour permettre l'accès à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à n'autoriser les mises à jour du micrologiciel que lorsque le mot de passe utilisateur principal est fourni via le HAL IAuthSecret.

9.11.3. Informations d'identité

Le système d'identifiants d'identité est défini et obtenu en implémentant toutes les API du package android.security.identity.*. Ces API permettent aux développeurs d'applications de stocker et de récupérer des documents d'identité utilisateur. Implémentations de l'appareil:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter le système d'identifiants d'identité.

Si les implémentations d'appareil implémentent le système d'identifiants, elles:

• [C-1-1] DOIT renvoyer une valeur non nulle pour la méthode IdentityCredentialStore#getInstance().

• [C-1-2] DOIT implémenter le système d'identifiants d'identité (par exemple, les API android.security.identity.*) avec du code qui communique avec une application fiable 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 le DMA.

• [C-1-3] Les opérations cryptographiques nécessaires à l'implémentation du système d'identifiants (par exemple, les API android.security.identity.*) DOIVENT être entièrement effectuées dans l'application de confiance, et le matériel de clé privée ne DOIT JAMAIS quitter l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par des API de niveau supérieur (par exemple, la méthode createEphemeralKeyPair()).

• [C-1-4] L'application de confiance DOIT être implémentée de manière à ce que ses propriétés de sécurité ne soient pas affectées (par exemple, les données d'identifiants ne sont pas publiées que si les conditions de contrôle des accès sont remplies, les adresses MAC ne peuvent pas être générées pour des données arbitraires), même si Android ne fonctionne pas correctement ou est compromis.

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 des données d'usine".
• [C-0-3] DOIT supprimer les données de manière à respecter les normes du secteur applicables, telles que la norme NIST SP800-88, lors d'une "Réinitialisation des données d'usine".
• [C-0-4] DOIT déclencher le processus "Réinitialisation des données 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 de suppression rapide des données qui ne s'effectue qu'au niveau logique.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer en 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] Il est 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 la possibilité de passer en mode Démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf lorsque l'application tierce est un contrôleur de stratégie d'appareil et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

• [C-1-2] L'appareil DOIT permettre à l'utilisateur de désinstaller toutes les applications tierces en mode sans échec.

• DOIT fournir à l'utilisateur la possibilité d'accéder au 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 du système de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec les sous-systèmes critiques du véhicule à l'aide du HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule, tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android pour éviter toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

"Forfaits d'abonnement" désigne les détails du forfait de relation de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils:

• [C-0-1] DOIT renvoyer les forfaits d'abonnement uniquement à l'application du fournisseur de services mobiles qui les a initialement fournis.
• [C-0-2] Vous NE DEVEZ PAS sauvegarder ni importer à distance des abonnements.
• [C-0-3] DOIT n'autoriser que les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), provenant de l'application du fournisseur de services mobiles qui propose actuellement des forfaits d'abonnement valides.

9.16. Migration des données d'application

Si les implémentations d'appareils incluent une fonctionnalité permettant de migrer des données d'un appareil vers un autre et ne limitent pas les données d'application qu'il copie à ce qui est configuré par le développeur de l'application dans le fichier manifeste via l'attribut android:fullBackupContent, ils:

• [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 tout transfert de données.
• [C-1-3] Vous DEVEZ utiliser l'attestation de clé de sécurité pour vous assurer que l'appareil source et l'appareil cible de la migration d'appareil à appareil sont des appareils Android légitimes et qu'ils disposent d'un bootloader verrouillé.
• [C-1-4] Vous NE DEVEZ MIGRER QUE les données d'application vers la même application sur l'appareil cible, avec le même nom de package ET le même certificat de signature.
• [C-1-5] DOIT indiquer dans le menu des paramètres que les données de l'appareil source ont été migrées par une migration de données d'appareil à appareil. Un utilisateur NE DOIT PAS pouvoir supprimer cette indication.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils d'apporter le moins de modifications possible à l'implémentation de référence et privilégiée d'Android disponible dans le projet Android Open Source. Cela réduit le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations de l'appareil:

• [C-0-1] DOIT réussir les tests de la suite de tests de compatibilité Android (CTS) disponible sur le projet Android Open Source, à l'aide du logiciel final fourni sur l'appareil.

• [C-0-2] DOIT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. Le CTS sera versionné indépendamment de cette définition de compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 12.

Implémentations de l'appareil:

• [C-0-3] DOIT réussir les tests de la dernière version du CTS disponible au moment de la finalisation du logiciel de l'appareil.

• DOIT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android.

10.2. Vérificateur CTS

Le vérificateur CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

Implémentations de l'appareil:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans le vérificateur CTS.

Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations de l'appareil:

• [C-0-2] DOIT réussir tous les tests du matériel dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le cas de test de l'accéléromètre dans le vérificateur CTS.

Les cas de test des fonctionnalités indiquées comme facultatives par ce document de définition de la compatibilité PEUVENT être ignorés ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les implémentateurs d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le vérificateur CTS que par l'ensemble de langues incluses, de branding, etc. PEUVENT omettre le test du vérificateur CTS.

11. Logiciels pouvant être mis à jour

• [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau "en direct". Autrement dit, 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 OTA (Over The Air) avec mise à jour hors connexion via le redémarrage.
  • Mises à jour "partagée" via USB à partir d'un PC hôte.
  • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un stockage amovible.

• [C-0-2] Le mécanisme de mise à jour utilisé DOIT prendre en charge 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 et partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.

• [C-0-3] La mise à jour entière DOIT être signée, et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature à l'aide d'une clé publique stockée sur l'appareil.

• [C-SR-1] Le mécanisme de signature est FORTEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide d'ECDSA NIST P-256.

Si les implémentations de l'appareil prennent en charge une connexion de données illimitée, telle que le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network), les appareils:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Les implémentations d'appareils DOIVENT vérifier que l'image système est identique en binaire au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur les blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT prendre en charge les mises à jour système A/B. L'AOSP implémente cette fonctionnalité à l'aide du HAL de contrôle du démarrage.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces:

• [C-2-1] L'implémentateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme décrit précédemment.

Android inclut des fonctionnalités qui permettent à l'application propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, les appareils:

• [C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de la compatibilité dans cette version:

• Documenter le journal des modifications

Pour obtenir un résumé des modifications apportées aux sections sur les personnes:

1. Introduction
2. Types d'appareils
3. Logiciels
4. Emballage d'application
5. Multimédia
6. Outils et options pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Tests de compatibilité logicielle
11. Logiciels pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils pour afficher le journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications substantielles apportées aux exigences de compatibilité.

• Docs
  Modifications esthétiques ou liées à la compilation.

Pour une meilleure visibilité, ajoutez les paramètres d'URL pretty=full et no-merges aux URL de votre journal des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android et demander des précisions ou signaler tout problème que vous pensez ne pas être couvert par le document.