Définition de compatibilité Android 11

1. Introduction

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

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

Dans ce document, un "outil de mise en œuvre d'appareil" est une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 11. 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 11, les implémentations d'appareils DOIVENT respecter les exigences présentées dans la présente Définition de compatibilité, y compris tout document intégré via une référence.

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

Pour cette raison, le projet Android Open Source est à la fois la référence et l'implémentation préférée d'Android. Il est FORTEMENT RECOMMANDÉ de baser leurs implémentations sur le code source "en amont" disponible dans le projet Android Open Source. Bien que certains composants puissent être remplacés par d'autres implémentations, il est FORTEMENT RECOMMANDÉ de ne pas suivre cette pratique, car il sera beaucoup plus difficile de réussir les tests logiciels. Il incombe à l'utilisateur chargé de la mise en œuvre d'assurer une compatibilité totale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par ce document.

La plupart des ressources mentionnées dans ce document proviennent directement ou indirectement du SDK Android. D'un point de vue fonctionnel, elles sont identiques aux informations contenues dans la documentation de ce SDK. En cas de désaccord entre cette définition de compatibilité ou la suite de tests de compatibilité avec la documentation du SDK, celle-ci fait autorité. Tous les détails techniques fournis dans les ressources ci-dessous de ce document sont considérés comme faisant partie de la présente 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 à l'ensemble des implémentations d'appareils Android, sont énumérées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le terme "Exigences principales" dans ce document.

1.1.2. Identifiant du prérequis

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

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

Chaque ID est défini comme suit:

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

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

L'identifiant du champ obligatoire figurant dans la section 2 commence par l'identifiant de la section correspondante, suivi de celui décrit ci-dessus.

• Dans la section 2, l'ID se compose des éléments suivants : ID de section / ID du type d'appareil, ID de la condition et ID des exigences (par exemple, 7.4.3/A-0-1).

2. Types d'appareils

Bien que le projet Android Open Source fournisse une pile logicielle pouvant être utilisée pour divers types d'appareils et facteurs de forme, certains d'entre eux bénéficient d'un écosystème de distribution d'applications relativement mieux établi.

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

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils décrits DOIVENT respecter l'ensemble des exigences des autres sections de cette définition de compatibilité.

2.1 Configurations des appareils

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

2.2. Configuration requise pour les appareils portables

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

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

• Disposer d'une source d'alimentation qui permet la mobilité, telle qu'une batterie.
• La diagonale de l'écran doit être comprise entre 3,3 pouces (ou 2,5 pouces pour les appareils lancés à un niveau d'API antérieur à Android 11) à 8 pouces.

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

2.2.1. Matériel

Implémentations pour les appareils portables:

• [7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible Android répondant à toutes les exigences décrites dans le présent document.
• [7.1.1.3/H-SR] Il est FORTEMENT RECOMMANDÉ de donner aux utilisateurs la possibilité de modifier la taille d'affichage (densité d'écran).

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

• [7.1.1.1/H-1-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces soit d'au moins 2 pouces sur les bords courts et de 2,7 pouces sur les bords longs. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans ce document sont exemptés de cette exigence.

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

• [7.1.1.1/H-2-1]* DOIT faire en sorte que l'écran logique mis à disposition pour les applications tierces se trouve à au moins 2,7 pouces sur les bords courts. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans ce document sont exemptés de cette exigence.

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

• [7.1.4.5/H-1-1] DOIT faire la promotion 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 les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables incluent une connexion limitée, ils:

• [7.4.7/H-1-1] DOIT fournir le mode Économiseur de données.

Si les implémentations d'appareils portables incluent une caméra logique qui répertorie les fonctionnalités utilisant CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elles:

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

Implémentations pour les appareils portables:

• [7.6.1/H-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile pour les données privées de l'application (également appelée partition "/data").
• [7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsque moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

Si les implémentations d'appareils portables déclarent ne prendre en charge qu'une ABI 32 bits:

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

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

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

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

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

• [7.6.1/H-5-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'en 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+ (HD ou 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'en FHD (par exemple, WSXGA+).

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

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

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

• [7.6.1/H-9-1] DOIT déclarer le flag de fonctionnalité android.hardware.ram.low.
• [7.6.1/H-9-2] DOIT disposer d'au moins 1,1 Go de stockage non volatile pour les données privées des applications (également appelée partition "/data").

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

• [7.6.1/H-10-1] DOIT disposer d'au moins 4 Go de stockage non volatile pour les données privées de l'application (également appelée partition "/data").
• DEVRAIT déclarer le flag de fonctionnalité android.hardware.ram.normal.

Implémentations pour les appareils portables:

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

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

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

Si les implémentations d'appareils portables incluent un port USB prenant en charge le mode hôte:

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

Implémentations pour les appareils portables:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de NE PAS utiliser d'actionneur haptique (vibreur) à masse rotative excentrique(ERM).
• [7.10/H]* DEVRAIT placer l'actionneur à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'implémenter toutes les constantes publiques pour le code haptique clair dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_Release, KEYBOARD_TAP, LONG_KEYKEY, ETUAL, VESTURE_MOVIR, VTUAL_MOVER).
• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'implémenter toutes les constantes publiques pour le retour haptique clair dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques pour l'affichage haptique enrichi dans android.os.VibrationEffect.
• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'utiliser ces mappages de constantes haptiques associées.
• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de suivre l'évaluation de la qualité pour les API createOneShot() et createWaveform().
• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de vérifier les capacités d'évolutivité de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

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

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

• [7,10/H]* DEVRAIT déplacer l'actionneur haptique sur l'axe X en orientation portrait.

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

• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de définir une fréquence de résonance de l'objet LRA sur l'axe X inférieure à 200 Hz.

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

• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'effectuer une évaluation de la qualité des constantes haptiques.

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 d'applications tierces:

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

Les implémentations d'appareils portables DOIVENT prendre en charge les formats d'encodage vidéo suivants et les mettre à la disposition d'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 d'applications tierces:

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

2.2.3. Logiciels

Implémentations pour les appareils portables:

• [3.2.3.1/H-0-1] DOIT disposer d'une application qui gère les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT comme décrit dans les documents du SDK, et fournir à l'utilisateur l'allocation d'accès aux données du fournisseur de documents via l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* DOIT précharger au moins une application ou un composant de service avec un gestionnaire d'intents pour tous les modèles de filtre d'intent public définis par les intents d'application suivants, listés ici.
• [3.2.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ de précharger une application de messagerie capable de gérer les intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE afin d'envoyer un e-mail.
• [3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
• [3.4.2/H-0-1] DOIT inclure une application de navigateur autonome pour la navigation Web de l'utilisateur standard.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut compatible avec l'épinglage des raccourcis, des widgets et des widgetFeatures dans l'application.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lancement par défaut qui affiche les badges correspondant aux icônes des applications.
• [3.8.2/H-SR] SONT FORTEMENT RECOMMANDÉS 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 importants via les classes d'API Notification et NotificationManager.
• [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
• [3.8.3/H-0-3] DOIT prendre en charge les notifications prioritaires.
• [3.8.3/H-0-4] DOIT inclure un volet des notifications, permettant à l'utilisateur de contrôler directement les notifications (par exemple, répondre, répéter, ignorer ou bloquer) les notifications par le biais des affordances de l'utilisateur telles que des boutons d'action ou le panneau de configuration, comme implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via RemoteInput.Builder setChoices() dans le volet des notifications sans intervention supplémentaire de l'utilisateur.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher toutes les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans ce volet.
• [3.8.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true à côté des réponses affichées par Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] 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, celles-ci:

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

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

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

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

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

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

• [3.9/H-1-1] DOIT implémenter l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android.
• [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, sauf lorsque l'appareil est configuré de sorte qu'il se signale comme un appareil à faible RAM ou qu'il alloue un espace de stockage interne (non amovible) en tant qu'espace de stockage partagé.

Si les implémentations d'appareils portables sont compatibles avec les API ControlsProviderService et Control et autorisent les applications tierces à publier des commandes de contrôle des appareils:

• [3.8.16/H-1-1] DOIT déclarer le flag de fonctionnalité android.software.controls et le définir sur true.
• [3.8.16/H-1-2] DOIT fournir à l'utilisateur la possibilité d'ajouter, de modifier, de sélectionner et d'utiliser les commandes de son appareil préféré à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control.
• [3.8.16/H-1-3] DOIT fournir un accès à cette affordance de l'utilisateur dans trois interactions à partir d'un lanceur d'applications par défaut.
• [3.8.16/H-1-4] DOIT afficher avec précision dans cette affordance utilisateur le nom et l'icône de chaque application tierce qui fournit des commandes via l'API ControlsProviderService, ainsi que tous les champs spécifiés fournis par les API Control.

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

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

Implémentations pour les appareils portables:

• [3.10/H-0-1] DOIT prendre en charge les services d'accessibilité tiers.
• [3.10/H-SR] Il est FORTEMENT RECOMMANDÉ de précharger les services d'accessibilité sur l'appareil avec des fonctionnalités comparables ou supérieures aux services d'accessibilité Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) tels que fournis dans le projet Open Source TalkBack.
• [3.11/H-0-1] DOIT être compatible avec l'installation de moteurs de synthèse vocale tiers.
• [3.11/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.
• [3.13/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'interface utilisateur "Réglages rapides".

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

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

Si la fonction de navigation est fournie sous la forme d'une action à l'écran basée sur un geste:

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

Si les implémentations d'appareils portables proposent une fonction de navigation sous forme de geste depuis n'importe où sur les bords gauche et droit de l'écran:

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

Performances et puissance

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

Implémentations pour les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

Modèle de sécurité

Implémentations pour les appareils portables:

• [9.1/H-0-1] DOIT autoriser les applications tierces à accéder aux statistiques d'utilisation via l'autorisation android.permission.PACKAGE_USAGE_STATS et fournir un mécanisme accessible à l'utilisateur pour accorder ou révoquer l'accès à ces applications en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS.

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

• [9.11/H-0-2]* DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/H-0-3]* Les algorithmes cryptographiques RSA, AES, ECDSA et HMAC DOIVENT être implémentés, ainsi que les fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [9.11/H-0-4]* DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, 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 Open Source Android en amont fournit la couche HAL (Gatekeeper Hardware Abstraction Layer) et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/H-0-5]* DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareils. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

• [9.11/H-1-1] DOIT permettre à l'utilisateur de choisir le délai de mise en veille le plus court, c'est-à-dire un temps de transition de 15 secondes maximum entre le déverrouillage et l'état verrouillé.
• [9.11/H-1-2] DOIT fournir une affordance à l'utilisateur pour masquer les notifications et désactiver toutes les formes d'authentification, à l'exception de l'authentification principale décrite dans la section 9.11.1 Secure Lock Screen (Écran de verrouillage sécurisé). L'AOSP répond aux exigences du mode de verrouillage.

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

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

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

• [9.5/H-3-1] NE DOIT PAS accepter les profils restreints, mais DOIT s'aligner sur la mise en œuvre AOSP des contrôles permettant d'autoriser ou de désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* DOIT exposer un binaire /system/bin/perfetto à l'utilisateur shell, dont la cmdline est conforme à la documentation de Perfetto.
  • [6.1/H-0-3]* Le binaire Perfetto DOIT accepter comme 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]* DOIT fournir, via le binaire Perfetto, au moins les sources de données décrites dans la documentation de perfetto.
  • [6.1/H-0-6]* Le daemon de traçage Perfetto DOIT être activé par défaut (propriété système persist.traced.enable).

2.2.7 Classe de performance des médias portables

Reportez-vous à la section 7.11 pour connaître la définition de la classe de performance multimédia.

Contenus multimédias

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

• [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matérielle pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle (AVC ou HEVC) dans n'importe quelle combinaison de codecs s'exécutant simultanément à une résolution de 720p à 30 FPS.
• [5.1/H-1-3] DOIT annoncer le nombre maximal de sessions d'encodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel (AVC ou HEVC) dans n'importe quelle combinaison de codecs exécutée simultanément à une résolution de 720p à 30 FPS.
• [5.1/H-1-5] DOIT annoncer le nombre maximal de sessions d'encodeur et de décodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle et de sessions d'encodeur vidéo matériel (AVC ou HEVC) dans toute combinaison de codecs exécutée simultanément à une résolution de 720p à 30 FPS.
• [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 65 ms ou moins pour une session d'encodage vidéo de 1080p ou moins élevée pour tous les encodeurs vidéo matériels (autres que le codec Dolby Vision) en charge. Cette charge désigne une session simultanée de transcodage vidéo de 1080p à 720p effectuée à l'aide de codecs vidéo matériels et de l'initialisation de l'enregistrement audio/vidéo 1080p.
• [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 50 ms ou moins pour une session d'encodage audio de 128 kbit/s ou moins pour tous les encodeurs audio en charge.Ici, la "charge" désigne une session simultanée de transcodage vidéo 1080p à 720p utilisant des codecs vidéo matériels et l'enregistrement audio/vidéo initial.
• [5.3/H-1-1] NE DOIT PAS supprimer plus d'une image en 10 secondes (c'est-à-dire une perte de frames inférieure à 0,333 %) pour une session vidéo 1080p à 30 FPS soumise à une charge. La charge désigne une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC de 128 kbit/s.
• [5.3/H-1-2] NE DOIT PAS supprimer plus d'une image en 10 secondes lors d'un changement de résolution vidéo au cours d'une session vidéo de 30 FPS soumise à une charge élevée. La charge désigne une session simultanée de transcodage vidéo 1080p à 720p effectuée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC de 128 kbit/s.
• [5.6/H-1-1] DOIT avoir une latence tap-to-ton inférieure à 100 millisecondes à l'aide du test Tap-to-Ton OboeTester ou du test Tap-to-Ton de CTS Verifier.

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_CODES.MEDIA_PERFORMANCE_CLASS, les conditions suivantes s'appliquent:

• [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution d'au moins 12 mégapixels permettant la capture vidéo à 4K à 30 images par seconde. La caméra arrière principale est celle dont l'ID d'appareil photo est le plus bas.
• [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution d'au moins 4 mégapixels permettant l'enregistrement vidéo à 1080p à 30 images par seconde. La caméra frontale principale est celle dont l'ID d'appareil photo est le plus bas.
• [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel avec une valeur FULL ou supérieure pour la caméra principale arrière, et LIMITED ou supérieure pour la caméra avant principale.
• [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux caméras principales.
• [7.5/H-1-5] DOIT avoir une latence de capture JPEG de "camera2" inférieure à 1 000 ms pour une résolution de 1080p telle que mesurée par le test de performance de la caméra CTS dans les conditions d'éclairage SIT (3 000 K) des deux caméras principales.
• [7.5/H-1-6] DOIT avoir une latence de démarrage de la caméra 2 (ouverture de la caméra à la première image d'aperçu) inférieure à 600 ms, telle que mesurée par le test de performance de la caméra CTS dans les conditions d'éclairage ITS (3 000 K) des deux caméras principales.

Matériel

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

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

Performances

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

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

2.3. Configuration requise pour la télévision

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

Les implémentations d'appareils Android sont classées dans la catégorie "Téléviseur" si elles répondent à l'ensemble des critères suivants:

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

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

Matériel

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

Si les appareils de télévision incluent un port USB compatible avec le mode hôte:

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

Pour les téléviseurs 32 bits:

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

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

Pour les téléviseurs 64 bits:

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

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

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

Implémentations pour les téléviseurs:

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

2.3.2. Multimédia

Les téléviseurs DOIVENT prendre en charge les formats d'encodage et de décodage audio suivants et les mettre à la disposition d'applications tierces:

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

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

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

Implémentations pour les téléviseurs:

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

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

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

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

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

Les téléviseurs DOIVENT être compatibles avec le décodage H.264, tel que détaillé dans la section 5.3.4, pour des fréquences d'images et des résolutions vidéo standards allant jusqu'à:

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

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

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

Si les téléviseurs équipés de décodeurs matériels H.265 prennent en charge le décodage H.265 et le profil de décodage UHD, ils:

• [5.3.5/T-2-1] DOIT prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil de niveau principal "Main10 Level 5"

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

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

Les téléviseurs équipés de décodeurs matériels VP9 DOIVENT prendre en charge le décodage VP9, comme détaillé dans la section 5.3.7, aux fréquences d'images et résolutions vidéo standards allant jusqu'à:

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

Si les téléviseurs équipés de décodeurs matériels VP9 prennent en charge le décodage VP9 et le profil de décodage UHD:

• [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 de 10 bits).

Implémentations pour les téléviseurs:

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

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

• [5.8/T-0-1] DOIT définir le mode de sortie HDMI de manière à sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou de 60 Hz.
• [5.8/T-SR] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur.
• [5.8] DEVRAIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation de la vidéo pour la région dans laquelle l'appareil est vendu.

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

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

Si les téléviseurs ne sont pas compatibles avec le décodage UHD, mais avec un écran externe connecté via HDMI, ils:

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

Logiciels

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

Performances et puissance

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

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

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

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

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

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

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

Implémentations pour les téléviseurs:

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

Modèle de sécurité

Implémentations pour les téléviseurs:

• [9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/T-0-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, 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 Open Source Android en amont fournit la couche HAL (Gatekeeper Hardware Abstraction Layer) et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/T-0-4] DOIT prendre en charge l'attestation des clés, lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareils. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

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

Si l'implémentation d'un téléviseur implique plusieurs utilisateurs et ne déclare pas le flag de fonctionnalité android.hardware.telephony:

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

Si l'implémentation d'un téléviseur implique plusieurs utilisateurs et déclare le flag de fonctionnalité android.hardware.telephony:

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

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

Implémentations pour les téléviseurs:

• Perfetto
  • [6.1/T-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur shell, dont la cmdline est conforme à la documentation de Perfetto.
  • [6.1/T-0-2] Le binaire Perfetto DOIT accepter comme 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 de tampon de protocole conforme au schéma défini dans la documentation de Perfetto.
  • [6.1/T-0-4] DOIT fournir, via le binaire Perfetto, au moins les sources de données décrites dans la documentation de Perfetto.

2.4. Configuration requise pour la montre

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

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

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

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

Matériel

Implémentations sur les montres:

• [7.1.1.1/W-0-1] DOIT disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.

• [7.2.3/W-0-1] L'utilisateur DOIT disposer de la fonction Accueil et de la fonction Retour, sauf si elle se trouve dans UI_MODE_TYPE_WATCH.

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

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

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

• [7.3.3/W-1-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/W-1-2] DOIT indiquer les pseudo-plages et taux de pseudo-plage GNSS. En conditions de ciel ouvert, après avoir déterminé la position, tout en restant à l'arrêt ou en se déplaçant avec un carré d'accélération inférieur à 0, 2 mètre par seconde, il est suffisant pour calculer la position à 20 mètres et la vitesse à 0, 2 mètre par seconde, au moins 95% du temps.

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

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

Implémentations sur les montres:

• [7.4.3/W-0-1] DOIT être compatible avec le Bluetooth.

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

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

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

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

Multimédia

Aucune exigence supplémentaire.

Logiciels

Implémentations sur les montres:

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

Implémentations sur les montres:

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

Les implémentations d'appareils de montre qui déclarent le flag de fonctionnalité android.hardware.audio.output:

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

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

• [3.11/W-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.

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

Performances et puissance

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

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

Implémentations sur les montres:

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

Modèle de sécurité

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

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

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

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

2.5. Exigences concernant l'automobile

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

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

• s'intègrent dans un véhicule automobile ou peuvent y être branchés ;
• utilisent un écran situé sur le siège conducteur comme écran principal ;

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

Matériel

Implémentations pour les appareils automobiles:

• [7.1.1.1/A-0-1] DOIT disposer d'un écran d'au moins 6 pouces en diagonale.

• [7.1.1.1/A-0-2] DOIT disposer d'une mise en page de taille d'écran d'au moins 750 dp x 480 dp.

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

• [7.2.3/A-0-2] DOIT envoyer à la fois l'événement d'appui normal et l'événement d'appui prolongé de la fonction Retour (KEYCODE_BACK) à l'application de premier plan.
• [7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.
• [7.3/A-0-2] La valeur de l'indicateur NIGHT_MODE DOIT être cohérente avec le mode Jour/Nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.
• [7.3/A-0-3] DOIT indiquer le champ d'informations supplémentaires du capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
• [7.3/A-0-1] PEUVENT reconnaître la localisation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est désactivée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteur et/ou les identifiants de propriété de véhicule correspondants utilisés.
• [7.3/A-0-2] L'établissement demandé via LocationManager#requestLocationUpdates() NE DOIT PAS être mis en correspondance sur la carte.

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

• [7.3.1/A-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 100 Hz.
• [7.3.1/A-1-2] DOIT être conforme au système de coordonnées du capteur de voiture Android.

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

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

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

• [7.3.3/A-3-1] DOIT déterminer la position la toute première fois que le récepteur GPS/GNSS est allumé ou après au moins quatre jours en 60 secondes.
• [7.3.3/A-3-2] DOIT respecter les critères de délai de première correction décrits dans les articles 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres demandes de localisation (c'est-à-dire les demandes qui ne sont pas effectuées depuis le début ou après plus de quatre jours). La condition 7.3.3/C-1-2 est généralement respectée dans les véhicules non connectés à un réseau de données cellulaires, à l'aide des prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule et la possibilité de détecter le véhicule pendant au moins 60 secondes avec une précision de position conforme à 7.3.3/C-1-3, ou une combinaison des deux.

Implémentations pour les appareils automobiles:

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

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

• [7.4.5/A] DEVRAIT inclure la prise en charge de la connectivité des données par réseau mobile.

• [7.4.5/A] PEUT utiliser la constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID de l'API système pour les réseaux qui devraient être disponibles pour les applications système.

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

Implémentations pour les appareils automobiles:

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

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

• [7.5/A-1-1] NE DOIT PAS avoir de caméras extérieures accessibles via les API Android Camera, à moins qu'elles ne respectent les exigences principales relatives aux caméras.
• [7.5/A-SR] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter l'aperçu de l'appareil photo ou de ne pas le reproduire horizontalement.
• [7.5.5/A-SR] Il est FORTEMENT RECOMMANDÉ d'être orientés de sorte que la dimension longue de la caméra soit alignée sur l'horizon.
• [7.5/A-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'au moins 1,3 mégapixel.
• DEVRAIT être équipé d'un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• DEVRAIT être compatible avec le framework de synchronisation Android.
• Un autofocus matériel ou logiciel peut être implémenté dans le pilote de l'appareil photo.

Implémentations pour les appareils automobiles:

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

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

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

• [7.6.1/A-SR] SONT FORTEMENT RECOMMANDÉS de réduire les frais 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 ppp ou moins sur les écrans de petite taille
  • ldpi ou inférieur sur les très grands écrans
  • mdpi ou inférieur sur les grands écrans

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

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

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

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

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

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

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

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

  • 280 ppp ou moins sur les écrans de petite taille
  • ldpi ou inférieur sur les très grands écrans
  • mdpi ou inférieur sur les grands écrans

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

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

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

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

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

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

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

2.5.2. Multimédia

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

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

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

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

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

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

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

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

Logiciels

Implémentations pour les appareils automobiles:

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

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

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

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

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

Implémentations pour les appareils automobiles:

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

• [3.2.3.1/A-0-1] DOIT précharger au moins une application ou un composant de service avec un gestionnaire d'intents pour tous les formats de filtres 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 lorsque des applications tierces le demandent.

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

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

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

• [3.14/A-0-1] DOIT inclure un framework d'interface utilisateur compatible avec les applications tierces utilisant les API multimédias, comme décrit dans la section 3.14.
• [3.14/A-0-2] DOIT permettre à l'utilisateur d'interagir de manière sécurisée avec les applications multimédias 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 pour accéder à l'activité de préférences d'une Application multimédia, mais DOIT l'activer uniquement lorsque les Restrictions liées à l'expérience utilisateur de la voiture ne sont pas en vigueur.
• [3.14/A-0-5] DOIT afficher les messages d'erreur définis par les applications multimédias et DOIT prendre en charge les extras facultatifs ERROR_RESOLUTION_ACTION_LABEL et ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DOIT prendre en charge une affordance de recherche dans l'application pour les applications compatibles.
• [3.14/A-0-7] DOIT respecter les définitions CONTENT_STYLE_BROWSABLE_HINT et CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de la hiérarchie MediaBrowser.

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

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

Implémentations pour les appareils automobiles:

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

Performances et puissance

Implémentations pour les appareils automobiles:

• [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans un espace de stockage non volatile pour chaque UID de processus afin que les statistiques soient accessibles aux développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence via le module de noyau uid_sys_stats.
• [8.3/A-1-3] DOIT être compatible avec le mode Garage.
• [8.3/A] DOIT être en mode garage pendant au moins 15 minutes après chaque trajet, sauf dans les cas suivants :
  • La batterie est déchargée.
  • Aucun job inactif n'est planifié.
  • Le conducteur quitte le mode garage.
• [8.4/A-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [8.4/A-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
• [8.4/A-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond à cette exigence via l'implémentation du module de noyau uid_cputime.
• [8.4/A] DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.
• [8.4/A-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur de l'application via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

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

• [9.5/A-1-1] NE DOIT PAS permettre aux utilisateurs d'interagir avec l'utilisateur système headless ni d'y accéder, sauf pour le provisionnement des appareils.
• [9.5/A-1-2] DOIT devenir un Utilisateur secondaire avant le BOOT_COMPLETED.
• [9.5/A-1-3] DOIT prendre en charge la création d'un Utilisateur invité, même lorsque le nombre maximal d'utilisateurs sur un appareil a été atteint.

Implémentations pour les appareils automobiles:

• [9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/A-0-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [9.11/A-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et, 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 Open Source Android en amont fournit la couche HAL (Gatekeeper Hardware Abstraction Layer) et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [9.11/A-0-4] DOIT prendre en charge l'attestation des clés, lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareils. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

Implémentations pour les appareils automobiles:

• [9.14/A-0-1] DOIT contrôler les messages provenant de sous-systèmes de véhicule du framework Android, par exemple en ajoutant à une liste d'autorisation les types et sources de messages autorisés.
• [9.14/A-0-2] DOIT surveiller les attaques par déni de service à partir du framework Android ou d'applications tierces. Cela permet d'éviter que des logiciels malveillants inondent le réseau des véhicules de trafic, ce qui peut entraîner des dysfonctionnements dans leurs sous-systèmes.

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

Implémentations pour les appareils automobiles:

• Perfetto
  • [6.1/A-0-1] DOIT exposer un binaire /system/bin/perfetto à l'utilisateur shell, dont la cmdline est conforme à la documentation de Perfetto.
  • [6.1/A-0-2] Le binaire Perfetto DOIT accepter comme 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 les tablettes

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

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

Les implémentations de tablettes ont des exigences similaires à celles des implémentations d’appareils portables. Les exceptions sont indiquées par un astérisque (*) et données à titre de référence dans la présente section.

Matériel

Taille de l'écran

• [7.1.1.1/Tab-0-1] DOIT avoir un écran compris entre 7 et 18 pouces.

Gyroscope

Si les implémentations de tablettes comprennent un gyroscope à 3 axes, elles:

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

Mémoire et stockage minimaux (section 7.6.1)

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

Mode périphérique USB (section 7.7.1)

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

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

Mode de réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences concernant la réalité virtuelle ne s'appliquent pas aux tablettes.

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

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

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

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

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

2.6.2. Logiciels

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

3. Logiciels

3.1. Compatibilité des API gérées

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

Implémentations pour les appareils:

• [C-0-1] DOIT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android ou toute API accompagnée du marqueur "@SystemApi" dans le code source Android en amont.

• [C-0-2] DOIT prendre en charge et préserver l'ensemble des classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).

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

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

• [C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, qui sont définies comme des méthodes et des champs dans les packages de langage Java qui se trouvent dans le chemin de classe de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation @hide, mais pas avec @SystemAPI, comme décrit dans les documents du SDK, ainsi que les membres des classes privées et package-private.

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

• [C-0-7] DOIT prendre en charge le mécanisme de mise à jour dynamique de la configuration signée pour supprimer les interfaces non SDK d'une liste restreinte en intégrant une configuration signée dans n'importe quel APK à l'aide des clés publiques existantes présentes dans AOSP.

  Cependant, ils:

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

3.1.1. Extensions Android

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

Implémentations pour les appareils Android:

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

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

• [C-0-3] DOIT prendre en charge toutes les API définies par les versions d'extension renvoyées par android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel), de la même manière que les autres API gérées, conformément aux exigences de la section 3.1.

3.1.2. Bibliothèque Android

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

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

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

3.2. Compatibilité avec les API soft

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

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

Paramètre	Détails
VERSION.VERSION	Version du système Android en cours d'exécution, dans un format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans 11.
VERSION.SDK	Version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 11, ce champ DOIT contenir la valeur entière 11_INT.
VERSION.SDK_INT	Version du système Android en cours d'exécution, dans un format accessible au code d'application tierce. Pour Android 11, ce champ DOIT contenir la valeur entière 11_INT.
VERSION SUPPLÉMENTAIRE	Valeur choisie par l'outil d'implémentation de l'appareil qui désigne le build spécifique du système Android en cours d'exécution, dans un format lisible par l'humain. Cette valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. Ce champ est généralement utilisé pour indiquer le numéro de build ou l'identifiant de modification de contrôle de source utilisé pour générer la compilation. La valeur de ce champ DOIT être encodable au format ASCII 7 bits imprimable et correspondre à l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ	Valeur choisie par l'outil de mise en œuvre de l'appareil identifiant le matériel interne spécifique utilisé par l'appareil, dans un format lisible par l'humain. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE	Valeur reflétant la marque associée à l'appareil, telle que connue des utilisateurs finaux. DOIT être dans un format lisible et représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
ABI_COMPATIBLES	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité de l'API native :
ABI_PRIS EN CHARGE_32_BIT	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité de l'API native :
SUPPORTED_64_BIT_ABIS	Nom du deuxième ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité de l'API native :
ABI_CPU	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité de l'API native :
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention d'ABI) du code natif. Consultez la section 3.3. Compatibilité de l'API native :
APPAREIL	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du développement ou le nom de code identifiant la configuration des caractéristiques matérielles et le design industriel de l'appareil. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom d'appareil NE DOIT PAS changer pendant la durée de vie du produit.
Empreinte	Chaîne qui identifie cette compilation de manière unique. Il DOIT être raisonnablement lisible par l'humain. Il DOIT suivre ce modèle: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Par exemple : acme/myproduct/ mydevice:11/LMYXX/3359:userdebug/test-keys L'empreinte NE DOIT PAS inclure d'espaces blancs. La valeur de ce champ DOIT être encodable au format ASCII 7 bits.
MATÉRIEL	Nom du matériel (depuis la ligne de commande du noyau ou /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
HÉBERGEUR	Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans un format lisible. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID	Identifiant choisi par le responsable de la mise en œuvre de l'appareil pour faire référence à une version spécifique, dans un format lisible. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent faire la distinction entre les versions logicielles. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT	Dénomination commerciale du fabricant d'équipement d'origine (OEM) du produit. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni aucune chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom de l'appareil connu de l'utilisateur final. Ce nom DOIT être identique au nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni aucune chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
PRODUIT	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce nom de produit NE DOIT PAS changer pendant sa durée de vie.
SÉRIE	DOIT renvoyer la valeur "UNKNOWN".
TAGS	Liste de tags séparés par une virgule, choisis par l'outil d'implémentation de l'appareil, qui permettent de distinguer davantage le build. Les tags DOIVENT être encodables au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+" et DOIVENT comporter l'une des valeurs correspondant aux trois configurations de signature type de la plate-forme Android : "release-keys", "dev-keys" et "test-keys".
DURÉE	Valeur représentant l'horodatage du moment où la compilation s'est produite.
MACH	Valeur choisie par l'outil de mise en œuvre de l'appareil spécifiant la configuration d'exécution du build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'environnement d'exécution Android classiques: user, userdebug ou eng.
UTILISATEUR	Nom ou ID de l'utilisateur (ou de l'utilisateur automatisé) qui a généré la compilation. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
VERSION.SECURITY_PATCH	Valeur indiquant le niveau du correctif de sécurité d'un build. Cela DOIT signifier que le build n'est en aucune façon vulnérable à l'un des problèmes décrits dans le bulletin de sécurité publique d'Android désigné. Il DOIT être au format [AAAA-MM-JJ] et correspondre à une chaîne définie documentée dans le bulletin de sécurité public Android ou dans l'avis de sécurité Android, par exemple "2015-11-01".
VERSION.BASE_OS	Valeur représentant le paramètre FINGERPRINT pour le build, qui est par ailleurs identique à celle-ci, à l'exception des correctifs fournis dans le bulletin de sécurité publique Android. Il DOIT indiquer la valeur correcte et, si une telle compilation n'existe pas, signaler une chaîne vide ("").
CHARGEUR DE CHARGEMENT	Valeur choisie par l'équipe chargée de la mise en œuvre de l'appareil identifiant la version spécifique du bootloader interne utilisée dans l'appareil, dans un format lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DOIT (être ou renvoyer) une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l'appareil, dans un format lisible par l'humain. Si un appareil ne dispose pas d'un dispositif radio/modem interne, il DOIT renvoyer la valeur NULL. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial()	DOIT (être ou renvoyer) un numéro de série matériel, qui DOIT être disponible et unique sur tous les appareils ayant le même MODEL et le même MANUFACTURER. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".

Compatibilité des intents

Intents d'application courants

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

Implémentations pour les appareils:

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

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

Résolution d'intent

• [C-0-1] Android est une plate-forme extensible. Par conséquent, les implémentations sur les appareils DOIVENT autoriser le remplacement de chaque schéma d'intent référencé dans la section 3.2.3.1 , à l'exception des paramètres, par des applications tierces. L'implémentation Open Source d'Android en amont autorise cette opération par défaut.

• [C-0-2] Les responsables de la mise en œuvre d'appareils NE DOIVENT PAS accorder de privilèges spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de s'associer à ces modèles et d'en prendre le contrôle. Cette interdiction inclut, sans s'y limiter, la désactivation de l'interface utilisateur du sélecteur, qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même schéma d'intent.

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

• Cependant, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des formats d'URI spécifiques (par exemple, http://play.google.com) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un schéma de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le schéma d'intent principal du navigateur pour "http://".

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

• [C-0-4] DOIT essayer de valider les filtres d'intent en suivant les étapes de validation définies dans la spécification Digital Asset Links, telle qu'elle est implémentée par le gestionnaire de packages dans le projet Android Open Source en amont.
• [C-0-5] DOIT tenter de valider les filtres d'intent lors de l'installation de l'application et définir tous les filtres d'intent d'URI validés avec succès en tant que gestionnaires d'application par défaut pour leurs URI.
• PEUT définir des filtres d'intent d'URI spécifiques en tant que gestionnaires d'application par défaut pour leurs URI, s'ils sont validés, mais que la vérification d'autres filtres d'URI candidats échoue. Si une implémentation d'un appareil effectue cette opération, elle DOIT fournir à l'utilisateur des remplacements de format par URI appropriés dans le menu des paramètres.
• DOIT fournir à l'utilisateur des commandes de liens vers une application par application dans les paramètres, comme suit :
  • [C-0-6] L'utilisateur DOIT pouvoir ignorer de manière globale le comportement par défaut des liens d'application pour qu'une application soit toujours ouverte, toujours ouverte ou toujours ouverte, ce qui doit s'appliquer de la même manière à tous les filtres d'intent d'URI des candidats.
  • [C-0-7] L'utilisateur DOIT pouvoir voir la liste des filtres d'intent d'URI candidats.
  • L'implémentation de l'appareil PEUT donner à l'utilisateur la possibilité d'ignorer des filtres d'intent d'URI candidats spécifiques qui ont été validés avec succès, par filtre d'intent.
  • [C-0-8] L'implémentation de l'appareil DOIT donner aux utilisateurs la possibilité d'afficher et de remplacer des filtres d'intent d'URI candidats spécifiques si l'implémentation de l'appareil permet à certains filtres d'intent d'URI candidats de réussir la vérification, tandis que d'autres peuvent échouer.

Espaces de noms des intents

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

Intents de diffusion

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

Implémentations pour les appareils:

• [C-0-1] DOIT diffuser les intents de diffusion publique répertoriés ici en réponse aux événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'est pas en conflit avec la section 3.5, car la limitation applicable aux applications en arrière-plan est également décrite dans la documentation du SDK. En outre, certains intents de diffusion sont soumis à une condition de compatibilité matérielle. Si l'appareil prend en charge le matériel nécessaire, ils DOIVENT diffuser les intents et fournir le comportement conformément à la documentation du SDK.

Intents d'application conditionnels

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

Le cas échéant, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le schéma de filtre d'intent et les méthodes d'API décrits dans la documentation du SDK, comme ci-dessous.

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

• [C-1-1] DOIT respecter l'intent android.settings.HOME_SETTINGS pour afficher un menu de paramètres d'application par défaut sur 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 SMS par défaut.

• [C-2-2] DOIT respecter l'intent android.telecom.action.CHANGE_DEFAULT_DIALER pour afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut.

  • DOIT utiliser l'interface utilisateur de l'application Téléphone par défaut sélectionnée par l'utilisateur pour les appels entrants et sortants, sauf pour les appels d'urgence, qui doivent utiliser l'application Téléphone préinstallée.

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

• [C-2-4] DOIT autoriser android.telecom.CallRedirectionService pour une application qui détient le rôle android.app.role.CALL_REDIRECTION.

• [C-2-5] DOIT fournir à l'utilisateur l' affordance de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.
• [C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW, et fournir une activité permettant d'envoyer ou d'afficher des SMS.
• [C-SR] Il est fortement recommandé de respecter les intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW et android.intent.action.DIAL avec une application de téléphonie préchargée qui peut gérer ces intents et fournir un traitement 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 à afficher un menu de paramètres par défaut de l'application pour le paiement sans contact.
• [C-3-2] DOIT respecter l'intent android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT pour afficher une activité qui ouvre une boîte de dialogue demandant à l'utilisateur de modifier le service d'émulation de carte par défaut pour une catégorie spécifique, comme décrit dans le SDK.

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

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

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

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

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

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

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

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

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

• [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 les services d'accessibilité tiers:

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

Si les implémentations d'appareils prennent en charge la fonctionnalité Wi-Fi Easy Connect et exposent cette fonctionnalité à des applications tierces, celles-ci:

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

Si les implémentations d'appareils proposent le mode Économiseur de données, ils: * [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 d'appareils ne proposent pas le mode Économiseur de données:

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

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

• [C-12-1] DOIT respecter les intents android.media.action.STILL_IMAGE_CAMERA et android.media.action.STILL_IMAGE_CAMERA_SECURE et lancer l'appareil photo en mode Image fixe, comme décrit dans le SDK.
• [C-12-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.
• [C-12-3] DOIT respecter uniquement les applications Android préinstallées pour gérer les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE et MediaStore.ACTION_VIDEO_CAPTURE suivants, comme décrit dans le document relatif au 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 d'amener l'utilisateur à ajouter l'administrateur de l'appareil au système (ou lui permettre de le refuser).

• [C-13-2] DOIT respecter les intents android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, android.app.action.PROVISION_MANAGED_PROFILE.

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

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

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

• Les [C-SR] sont FORTEMENT RECOMMANDÉS fournissent un mécanisme accessible à l'utilisateur pour accorder ou révoquer l'accès aux statistiques d'utilisation en réponse à l'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS pour les applications qui déclarent l'autorisation android.permission.PACKAGE_USAGE_STATS.

Si les implémentations d'appareils visent à empêcher des applications, y compris des applications préinstallées, d'accéder aux statistiques d'utilisation:

• [C-15-1] DOIT toujours disposer d'une activité qui gère le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais DOIT l'implémenter en tant qu'opération no-op, afin d'obtenir un comportement équivalent à celui d'un refus d'accès de l'utilisateur.

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

• [C-SR] 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_EXEMPLE_TEXT qui ont une activité permettant de les exécuter, comme décrit dans le SDK.

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

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

Activités sur des écrans secondaires ou multiples

Si les implémentations sur les appareils permettent de lancer des activités Android normales sur plusieurs écrans, celles-ci:

• [C-1-1] DOIT définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
• [C-1-2] DOIT garantir la compatibilité de l'API de la même manière qu'une activité exécutée sur l'écran principal.
• [C-1-3] DOIT envoyer la nouvelle activité sur le même écran que l'activité qui l'a lancée lorsque la nouvelle activité est lancée sans spécifier d'écran cible via l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DOIT détruire toutes les activités lorsqu'un écran avec l'indicateur Display.FLAG_PRIVATE est supprimé.
• [C-1-5] DOIT masquer le contenu de manière sécurisée sur tous les écrans lorsque l'appareil est verrouillé avec un écran de verrouillage sécurisé, sauf si l'application active l'affichage en haut de l'écran de verrouillage à l'aide de l'API Activity#setShowWhenLocked().
• DEVRAIT avoir android.content.res.Configuration correspondant à 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 d'appareils autorisent le lancement des activités Android normales sur des écrans secondaires et que celui-ci comporte l'indicateur android.view.Display.FLAG_PRIVATE:

• [C-3-1] Seul le propriétaire de l'écran, du système et des activités qui y figurent DOIT pouvoir lancer la lecture sur cet écran. Tout le monde peut lancer un écran doté de l'indicateur android.view.Display.FLAG_PUBLIC.

3.3. Compatibilité avec les API natives

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

• [SR] FORTEMENT RECOMMANDÉ d'utiliser les implémentations des bibliothèques listées ci-dessous issues du projet Android Open Source en amont.

3.3.1. Interfaces binaires d'application

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

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec une ou plusieurs ABI du NDK Android définies.
• [C-0-2] DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler du code natif, à l'aide de la sémantique JNI (Java Native Interface) standard.
• [C-0-3] DOIT être compatible avec la source (c'est-à-dire avec les en-têtes) et binaire (pour l'ABI) avec chaque bibliothèque requise dans la liste ci-dessous.
• [C-0-5] DOIT indiquer avec précision l'interface binaire d'application (ABI) native compatible avec l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacune sous la forme d'une liste d'ABI séparées par une virgule, classées de la plus à la moins préférée.

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

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

• [C-0-7] DOIT mettre à la disposition des applications incluant du code natif l'ensemble des bibliothèques suivantes, fournissant des API natives:

  • libaaudio.so (compatibilité native avec AAudio)
  • libamidi.so (compatibilité MIDI native, si la fonctionnalité android.software.midi est revendiquée comme décrit dans la section 5.9)
  • libandroid.so (prise en charge des activités Android natives)
  • libc (bibliothèque C)
  • libcamera2ndk.so
  • libdl (lien dynamique)
  • libEGL.so (gestion de la surface OpenGL native)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (journalisation Android)
  • libmediandk.so (compatibilité avec les API de médias natifs)
  • libm (bibliothèque de mathématiques)
  • libneuralnetworks.so (API Neural Networks)
  • libOpenMAXAL.so (compatible avec OpenMAX AL 1.0.1)
  • libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
  • libRS.so
  • libstdc++ (compatibilité minimale avec C++)
  • libvulkan.so (Vulkan)
  • libz (compression Zlib)
  • Interface JNI

• [C-0-8] NE DOIT PAS ajouter ni supprimer de fonctions publiques pour les bibliothèques natives répertoriées ci-dessus.

• [C-0-9] DOIT répertorier des bibliothèques supplémentaires non-AOSP exposées directement à des applications tierces dans /vendor/etc/public.libraries.txt.
• [C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, à des applications tierces ciblant le niveau d'API 24 ou supérieur, car elles sont réservées.
• [C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que bien que tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit plus en détail les exigences liées à l'implémentation complète de chaque fonction correspondante.
• [C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction Vulkan 1.0 principaux, ainsi que les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via la bibliothèque libvulkan.so. Notez que bien que tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences liées à l'implémentation complète de chaque fonction correspondante.
• DEVRAIT être créé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Android Open Source en amont.

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

3.3.2. Compatibilité avec le code natif ARM 32 bits

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

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

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

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

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

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

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

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

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

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

• Le composant WebView DOIT inclure un maximum de fonctionnalités HTML5 et, s'il est compatible, DOIT être conforme aux spécifications HTML5.

• [C-1-3] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de moteur de rendu distinct DOIT détenir des privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, n'avoir aucun accès au répertoire de données de l'application, n'avoir aucun accès direct au réseau et n'avoir accès qu'aux services système minimaux requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

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

Compatibilité du navigateur

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

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

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

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

3.5. Compatibilité comportementale de l'API

Implémentations pour les appareils:

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

Le comportement de chaque type d'API (gérée, logicielle, native et Web) doit être cohérent avec l'implémentation préférée du projet Android Open Source en amont. Voici quelques domaines de compatibilité spécifiques:

• [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
• [C-0-2] Les appareils NE DOIVENT PAS modifier la sémantique du cycle de vie ou du cycle de vie d'un type particulier de composant système (service, activité, ContentProvider, etc.).
• [C-0-3] Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.
• Les appareils NE DOIVENT PAS modifier les limites appliquées aux applications en arrière-plan. Plus précisément, pour les applications en arrière-plan :
  • [C-0-4], ils DOIVENT cesser d'exécuter des rappels enregistrés par l'application pour recevoir les sorties de GnssMeasurement et GnssNavigationMessage.
  • [C-0-5] il DOIT limiter la fréquence des mises à jour fournies à l'application via la classe d'API LocationManager ou la méthode WifiManager.startScan().
  • [C-0-6] Si l'application cible le niveau d'API 25 ou supérieur, elle NE DOIT PAS enregistrer de broadcast receivers pour les diffusions implicites d'intents Android standards dans le fichier manifeste de l'application, sauf si l'intent de diffusion nécessite une autorisation "signature" ou "signatureOrSystem" protectionLevel, ou si ces derniers figurent sur la liste des exceptions.
  • [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT arrêter ses services en arrière-plan, comme si l'application avait appelé la méthode stopSelf() des services, sauf si l'application était placée sur une liste d'autorisation temporaire pour gérer une tâche visible par l'utilisateur.
  • [C-0-8] Si l'application cible le niveau d'API 25 ou supérieur, il DOIT débloquer les wakelocks qu'elle détient.
• [C-0-9] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants comme sept premières valeurs de tableau de la méthode Security.getProviders(), dans l'ordre donné et avec les noms et classes indiqués (tels que renvoyés par Provider.getName()) et les classes, sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Les appareils PEUVENT renvoyer des fournisseurs supplémentaires en fonction de la liste 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. AndroidKeyStoreBCSolution : android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

La liste ci-dessus n'est pas exhaustive. La suite de tests de compatibilité (CTS) teste la compatibilité comportementale d'une partie importante de la plate-forme, mais pas de toutes. Il est de la responsabilité de l'outil de mise en œuvre de veiller à la compatibilité du comportement avec le projet Android Open Source. C'est pourquoi, dans la mesure du possible, les responsables de la mise en œuvre des appareils DOIVENT utiliser le code source disponible via le projet Android Open Source, plutôt que de réimplémenter des parties importantes du système.

3.5.1. Restriction d'application

Si les implémentations d'appareils implémentent un mécanisme propriétaire pour restreindre les applications et que ce mécanisme est plus restrictif que le bucket Rare App Standby, ils:

• [C-1-1] DOIT fournir une affordance de l'utilisateur permettant à celui-ci de voir la liste des applications dont l'accès est limité.
• [C-1-2] DOIT fournir une affordance à l'utilisateur pour activer / désactiver les restrictions sur chaque application.
• [C-1-3] NE DOIT PAS appliquer automatiquement des restrictions sans preuve de mauvais comportement de l'état du système, mais PEUVENT appliquer les restrictions aux applications lors de la détection d'un comportement médiocre de l'état du système, comme les wakelocks figés, les services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les responsables de la mise en œuvre 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 uniquement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés comme critères.
• [C-1-4] NE DOIT PAS appliquer automatiquement des restrictions aux applications lorsqu'un utilisateur les désactive manuellement, 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 dont l'accès est limité appelle cette API.
• [C-1-7] NE DOIT PAS limiter l'application au premier plan qui est explicitement utilisée par l'utilisateur.
• [C-1-8] DOIT suspendre les restrictions appliquées à une application qui devient l'application de premier plan lorsque l'utilisateur commence explicitement à utiliser l'application qui était auparavant restreinte.

3.6. Espaces de noms de l'API

Android respecte les conventions d'espace de noms des packages et des classes définies par le langage de programmation Java. Pour assurer la compatibilité avec les applications tierces, les développeurs d'appareils NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) aux espaces de noms de package suivants:

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

En d'autres termes, ils:

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

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

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

Cependant, les spécialistes de la mise en œuvre d'appareils PEUVENT ajouter des API personnalisées en dehors de l'espace de noms Android standard, mais les API personnalisées:

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

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

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

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

Implémentations pour les appareils:

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

• [C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Consultez la section 7.1.1 pour obtenir les définitions de la taille et de la densité de l'écran.)

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

• DEVRAIT exécuter des tests à données aléatoires dans différents modes d'exécution et architectures cibles pour assurer la stabilité de l'environnement d'exécution. Reportez-vous à JFuzz et DexFuzz sur le site Web du projet Android Open Source.

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

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

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

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

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

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

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

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

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

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

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

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

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

• [C-5-1] DOIT respecter la méthode API NotificationChannel.setShowBadge(). En d'autres termes, affichez une affordance visuelle associée à l'icône d'application si la valeur est définie sur true, et n'affichez aucun schéma de badge d'icône d'application lorsque tous les canaux de notification de l'application ont défini la valeur sur false.
• PEUT remplacer les badges d'icône d'application par leur système de badges propriétaires lorsque des applications tierces indiquent la compatibilité avec le système de badges propriétaires 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 , comme Notification.Builder.setNumber() et l'API Notification.Builder.setBadgeIconType().

Widgets

Android est compatible avec les widgets d'applications tiers. Il suffit de définir un type de composant, ainsi que l'API et le cycle de vie correspondants qui permettent aux applications d'exposer un AppWidget à l'utilisateur final.

Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers:

• [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
• [C-1-2] DOIT inclure la prise en charge intégrée des AppWidgets et exposer les affordances d'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 grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android.
• PEUT prendre en charge les widgets d'application sur l'écran de verrouillage.

Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers et l'épinglage de raccourcis dans l'application:

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

3.8.3. Notifications

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

Présentation des notifications

Si les implémentations sur les appareils permettent aux applications tierces d'avertir les utilisateurs en cas d'événements notables, elles:

• [C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si l'implémentation d'un appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibreur. Si l'implémentation d'un appareil manque de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est détaillé dans la section 7.
• [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système. Toutefois, elles PEUVENT offrir une expérience utilisateur différente de celle fournie dans l'implémentation de référence Android Open Source.
• [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é dans le SDK.
• [C-1-5] DOIT fournir une affordance à l'utilisateur pour bloquer et modifier la notification d'une application tierce spécifique pour chaque canal et niveau de package d'application.
• [C-1-6] DOIT également fournir une affordance utilisateur pour afficher les canaux de notification supprimés.
• [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies via Notification.MessagingStyle à côté du texte de la notification, sans intervention supplémentaire de l'utilisateur. Par exemple, DOIT afficher toutes les ressources, y compris les icônes fournies via android.app.Person, dans une conversation de groupe définie via setGroupConversation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de faire apparaître automatiquement une affordance de l'utilisateur pour bloquer la notification d'une certaine application tierce pour chaque canal et niveau de package d'application après que l'utilisateur a ignoré cette notification à plusieurs reprises.
• DEVRAIT prendre en charge les notifications enrichies.
• DEVRAIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
• DEVRAIT avoir une affordance utilisateur pour mettre en attente les notifications.
• PEUVENT gérer uniquement la visibilité et le moment où les applications tierces peuvent informer les utilisateurs d'événements importants afin d'atténuer les problèmes de sécurité tels que la distraction au volant.

Android 11 prend en charge les notifications de conversation, qui utilisent MessagingStyle et fournit un ID de raccourci People (Contacts).

Implémentations pour les appareils:

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

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

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

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

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

Si les implémentations d'appareils sont compatibles avec les notifications prioritaires :

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

Service d'écoute des notifications

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

Implémentations pour les appareils:

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

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

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

Ne pas déranger

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

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

3.8.4. Rechercher

Android inclut des API qui permettent aux développeurs d'intégrer la recherche à leurs applications et d'exposer les données de celles-ci dans la recherche système globale. En règle générale, cette fonctionnalité consiste en une interface système unique qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions à mesure que l'utilisateur saisit du texte et d'afficher les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir des fonctionnalités de recherche dans leurs propres applications et de fournir les résultats à l'interface utilisateur de recherche globale courante.

• Les implémentations d'appareils Android DOIVENT inclure une recherche globale, une interface utilisateur de recherche unique et partagée à l'échelle du système, capable de proposer des suggestions en temps réel en réponse à une entrée utilisateur.

Si les implémentations d'appareils implémentent l'interface de recherche globale, elles:

• [C-1-1] DOIT implémenter les API permettant aux applications tierces d'ajouter des suggestions au champ de recherche lorsque celui-ci est exécuté en mode de recherche globale.

Si aucune application tierce utilisant la recherche globale n'est installée:

• Le comportement par défaut DEVRAIT consister à afficher les résultats et les suggestions des moteurs de recherche Web.

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

Si les implémentations d'appareils prennent en charge l'action d'assistance, celles-ci:

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

Alertes et toasts

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

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

• [C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent TYPE_APPLICATION_OVERLAY . L'implémentation d'AOSP répond à cette exigence grâce à des commandes dans le volet des notifications.

• [C-1-2] DOIT respecter l'API Toast et afficher des Toasts à partir des applications auprès des utilisateurs finaux de manière très visible.

3.8.6. Thèmes

Android fournit des "thèmes" qui permettent aux applications d'appliquer des styles à l'ensemble d'une activité ou d'une application.

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

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

• [C-1-1] NE DOIT PAS modifier les attributs du thème Holo associés aux applications.
• [C-1-2] DOIT être compatible avec la famille de thèmes "Material" et NE DOIT PAS modifier les attributs du thème Material ni leurs éléments exposés aux applications.
• [C-1-3] DOIT définir la famille de polices "sans-serif" sur Roboto version 2.x pour les langues prises en charge par Roboto, ou fournir une affordance utilisateur pour remplacer la police utilisée pour la famille "sans-serif" par la version Roboto 2.x pour les langues prises en charge par Roboto.

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

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

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

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

• [C-2-1] DOIT utiliser du blanc pour les icônes d'état système (intensité du signal et niveau de la batterie, par exemple) et les notifications envoyées par le système, sauf si l'icône indique un état problématique ou si une application demande l'affichage d'une barre d'état lumineuse à l'aide de l'indicateur SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.
• [C-2-2] Les implémentations d'appareils Android DOIVENT modifier la couleur des icônes d'état système en noir (pour en savoir plus, reportez-vous à R.style) lorsqu'une application demande l'affichage d'une barre d'état de voyant.

3.8.7. Fonds d'écran animés

Android définit un type de composant, ainsi que l'API et le cycle de vie correspondants qui permettent aux applications d'exposer un ou plusieurs fonds d'écran animés à l'utilisateur final. Les fonds d'écran animés sont des animations, des motifs ou des images similaires aux capacités de saisie 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 diffuser tous les fonds d'écran animés, sans limitation de fonctionnalité, à une fréquence d'images raisonnable sans aucun effet négatif sur les autres applications. Si les limitations du matériel entraînent le plantage, le dysfonctionnement des fonds d'écran et/ou des applications, une utilisation excessive du processeur ou de la batterie, ou une fréquence d'images trop faible, le matériel est considéré comme incapable d'exécuter des fonds d'écran animés. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécutera pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL. En effet, l'utilisation d'un fond d'écran animé avec un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

• [C-1-1] DOIT signaler l'indicateur de fonctionnalité de plate-forme android.software.live_wallpaper.

3.8.8. Changement d'activité

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

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

Si les implémentations d'appareils incluant la touche de navigation des fonctions récentes comme indiqué dans la section 7.2.3 modifient l'interface, elles:

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

3.8.9. Gestion des entrées

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

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

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

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

À partir d'Android 5.0, l'API Remote Control Client a été abandonnée au profit du modèle de notification multimédia, qui permet aux applications multimédias d'intégrer les commandes de lecture affichées sur l'écran de verrouillage.

3.8.11. Économiseurs d'écran (anciennement Dreams)

Consultez la section 3.2.3.5 pour en savoir plus sur les paramètres permettant de configurer les économiseurs d'écran.

3.8.12. Position

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

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

3.8.13. Unicode et police

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

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

• [C-1-1] DOIT pouvoir afficher ces caractères emoji avec un glyphe de couleur.
• [C-1-2] DOIT inclure la prise en charge des éléments suivants :
  • Police Roboto 2 avec des épaisseurs différentes : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
  • Compatibilité totale avec Unicode 7.0 des caractères latins, grecs et cyrilliques, y compris les plages latins étendus A, B, C et D, et tous les glyphes du bloc de symboles monétaires d'Unicode 7.0.
• DEVRAIT prendre en charge la carnation et les différents emoji familiaux, comme indiqué dans le rapport technique Unicode 51.

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. Multifenêtre

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

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

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

• [C-2-1] DOIT précharger un lanceur d'applications redimensionnable par défaut.
• [C-2-2] DOIT recadrer l'activité ancrée d'un écran partagé multifenêtre, mais DOIT afficher son contenu si l'application Lanceur d'applications est la fenêtre sélectionnée.
• [C-2-3] DOIT respecter les valeurs AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight déclarées de l'application de lancement tierce, et ne pas remplacer ces valeurs lorsqu'une partie du contenu de l'activité ancrée s'affiche.

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

• [C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque: * l'application cible le niveau d'API 26 ou supérieur et déclare android:supportsPictureInPicture ; * la cible de niveau 25 ou inférieur, et déclare à la fois android:resizeableActivity et android:supportsPictureInPicture ;
• [C-3-2] DOIT exposer les actions dans leur SystemUI, comme spécifié par l'activité PIP en cours via l'API setActions().
• [C-3-3] DOIT accepter des formats supérieurs ou égaux à 1:2.39 et inférieurs ou égaux à 2.39:1, comme spécifié par l'activité PIP via l'API setAspectRatio().
• [C-3-4] DOIT utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP. Si le mode PIP n'est pas implémenté, la clé DOIT être disponible pour l'activité de premier plan.
• [C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher en mode PIP. L'implémentation AOSP répond à cette exigence en disposant de commandes dans le volet des notifications.

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

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

3.8.15. Découpe de l'écran

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

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

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

3.8.16. Commandes de contrôle des appareils

Android inclut les API ControlsProviderService et Control qui permettent aux applications tierces de publier des commandes de contrôle des appareils. Les utilisateurs bénéficient ainsi d'informations et d'actions rapides.

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

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications sécurisées d'effectuer des tâches d'administration des appareils au niveau du système, telles que l'application de règles relatives aux mots de passe ou l'effacement à distance, par le biais de l'API Android Device Administration.

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

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

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

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

• [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
  • Lorsque l'implémentation de l'appareil ne contient pas encore de données utilisateur :
    • [C-1-3] DOIT signaler true pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-4] DOIT enregistrer l'application DPC en tant qu'application du propriétaire de l'appareil en réponse à l'action d'intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] DOIT enregistrer l'application DPC en tant qu'application Propriétaire de l'appareil si l'appareil déclare la compatibilité NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de type MIME MIME_TYPE_PROVISIONING_NFC.
  • Lorsque l'implémentation de l'appareil dispose de données utilisateur, elle :
    • [C-1-6] DOIT signaler false pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NE DOIT PAS enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil.
• [C-1-2] DOIT exiger une action affirmative avant ou pendant le processus de provisionnement pour que l'application soit définie comme propriétaire de l'appareil. Le consentement peut être obtenu via une action de l'utilisateur ou par des moyens programmatiques, mais une notification de divulgation appropriée (comme indiqué dans l'AOSP) DOIT être affichée avant le lancement du provisionnement par le propriétaire de l'appareil. De plus, le mécanisme de recueil du consentement des propriétaires d'appareils programmatiques (par les entreprises) utilisé (par les entreprises) pour le provisionnement par les propriétaires d'appareils NE DOIT PAS interférer avec l'expérience prête à l'emploi pour une utilisation non professionnelle.
• [C-1-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'applications appartenant à d'autres propriétaires de l'appareil.

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

• [C-2-1] DOIT mettre en place un processus permettant de vérifier que l'application faisant l'objet de la promotion appartient à une solution d'entreprise légitime de gestion des appareils et qu'elle a déjà été configurée dans la solution propriétaire pour disposer des droits équivalents en tant que "Propriétaire de l'appareil".
• [C-2-2] DOIT afficher la même mention de consentement pour le propriétaire de l'appareil AOSP que la procédure lancée par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Propriétaire de l'appareil".
• PEUVENT disposer de données utilisateur sur l'appareil avant l'enregistrement de l'application DPC en tant que "Propriétaire de l'appareil".

3.9.1.2 Provisionnement des profils gérés

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

• [C-1-1] DOIT implémenter les API permettant à une application 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é (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE) DOIT être aligné sur l'implémentation d'AOSP.

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

  • Icône cohérente ou autre affordance de l'utilisateur (par exemple, l'icône d'information 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 la setShortSupportMessage.
  • Icône de l'application DPC.

3.9.2 Prise en charge des profils gérés

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

• [C-1-1] DOIT prendre en charge les profils gérés via les API android.app.admin.DevicePolicyManager.
• [C-1-2] DOIT autoriser la création d'un seul profil géré.
• [C-1-3] DOIT utiliser un badge d'icône (semblable au badge professionnel en amont AOSP) pour représenter les applications et widgets gérés, ainsi que les autres éléments d'interface utilisateur dotés d'un badge tels que les applications récentes et les notifications.
• [C-1-4] DOIT afficher une icône de notification (semblable au badge professionnel en amont AOSP) pour indiquer que l'utilisateur se trouve dans une application de profil géré.
• [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se met en marche (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
• [C-1-6] Lorsqu'un profil géré existe, DOIT afficher une affordance visuelle dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré à l'utilisateur principal, ou inversement, s'il est activé par l'outil de contrôle des règles relatives aux appareils.
• [C-1-7] Lorsqu'un profil géré existe, DOIT exposer les affordances d'utilisateur suivantes pour l'utilisateur principal et le profil géré :
  • Les données sont séparées pour l'utilisation de la batterie, de l'emplacement, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées dans le profil utilisateur principal ou le profil géré
  • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré
  • Gestion indépendante des comptes au sein de l'utilisateur principal ou du profil géré.
• [C-1-8] DOIT s'assurer que le clavier, les contacts et les applications de messagerie préinstallés peuvent rechercher et consulter des informations sur l'appelant dans le profil géré (le cas échéant) en plus de celles du profil principal, si l'outil de contrôle des règles relatives aux appareils le permet.
• [C-1-9] DOIT s'assurer qu'il satisfait à toutes les exigences de sécurité applicables à un appareil sur lequel plusieurs utilisateurs sont activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.

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

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

3.9.3 Assistance aux utilisateurs gérés

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

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

3.10. Accessibilité

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

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

• [C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android décrite dans la documentation du SDK concernant les API d'accessibilité.
• [C-1-2] DOIT générer des événements d'accessibilité et fournir le AccessibilityEvent approprié à toutes les implémentations AccessibilityService enregistrées, comme indiqué dans le SDK.
• [C-1-4] DOIT ajouter un bouton dans la barre de navigation du système permettant à l'utilisateur de contrôler le service d'accessibilité lorsque les services d'accessibilité activés déclarent AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON . Notez que pour les implémentations d'appareils sans barre de navigation système, cette exigence n'est pas applicable, mais les implémentations d'appareils DOIVENT fournir une affordance à l'utilisateur pour contrôler ces services d'accessibilité.

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

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

3.11. Synthèse vocale

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

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

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

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

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

3.12. Framework d'entrée TV

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

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

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

3.13. Réglages rapides

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

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

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

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent des applications non à commande vocale (les Applications) qui interagissent avec des applications tierces via MediaBrowser ou MediaSession, les Applications:

• [C-1-2] DOIT afficher clairement les icônes obtenues via getIconBitmap() ou getIconUri() et les titres obtenus via getTitle(), comme décrit dans le MediaDescription. Peut raccourcir les titres afin de respecter les réglementations de sécurité (par exemple, les distractions au volant).

• [C-1-3] DOIT afficher l'icône de l'application tierce lors de l'affichage du contenu fourni par celle-ci.

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

• [C-1-5] DOIT considérer le fait d'appuyer deux fois sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme étant KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

Les implémentations d'appareils DOIVENT répondre aux exigences suivantes:

• [C-0-1] Les applis instantanées DOIVENT disposer uniquement d'autorisations dont le champ android:protectionLevel est défini sur "instant".
• [C-0-2] Les applis instantanées NE DOIVENT PAS interagir avec les applications installées via des intents implicites, sauf dans les cas suivants :
  • Le filtre de format d'intent du composant est exposé et comporte CATEGORY_BROWSABLE
  • L'action est l'une des suivantes : ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
  • La cible est explicitement exposée avec android:visibleToInstantApps.
• [C-0-3] Les applis instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
• [C-0-4] Les applis instantanées NE DOIVENT PAS voir d'informations sur les applis instantanées sur l'appareil, sauf si elles se connectent explicitement à l'application installée.

Si les implémentations d'appareils prennent en charge les applis instantanées, celles-ci:

• [C-1-1] DOIT fournir les affordances suivantes pour l'interaction avec les applis instantanées. L'AOSP répond aux exigences avec l'UI système, les paramètres et le lanceur d'applications par défaut.
• [C-1-2] DOIT fournir une affordance utilisateur pour afficher et supprimer les applis instantanées mises en cache localement pour chaque package d'application.
• [C-1-3] DOIT fournir une notification utilisateur persistante pouvant être réduite lorsqu'une appli instantanée est exécutée au premier plan. Cette notification utilisateur DOIT inclure que les applis instantanées ne nécessitent pas d'installation et fournir une affordance de l'utilisateur qui redirige l'utilisateur vers l'écran d'informations de l'application dans les paramètres. Pour les applis instantanées lancées via des intents Web, comme défini à l'aide d'un intent avec une action définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance utilisateur supplémentaire DOIT permettre à l'utilisateur de ne pas lancer l'appli instantanée et de lancer le lien associé avec le navigateur Web configuré, si un navigateur est disponible sur l'appareil.
• [C-1-4] DOIT autoriser l'accès aux applis instantanées en cours à partir de la fonction "Récents" si celle-ci est disponible sur l'appareil.
• [C-1-5] DOIT précharger un ou plusieurs composants d'applications ou de services avec un gestionnaire d'intents pour les intents répertoriés dans le SDK, et rendre ces intents visibles pour les applis instantanées.

3.16. Association d'un appareil associé

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

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

• [C-1-1] DOIT déclarer l'indicateur 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 indiquer les affordances de l'utilisateur pour lui permettre de sélectionner/confirmer qu'un appareil associé est présent et opérationnel.

3.17. Applications lourdes

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

• [C-1-1] DOIT disposer d'une seule application installée spécifiant cantSaveState à la fois dans le système. Si l'utilisateur quitte une application sans la quitter explicitement (par exemple, en appuyant sur la touche d'accueil tout en laissant une activité active dans le système, au lieu de revenir en arrière sans aucune activité active restante dans le système), les implémentations d'appareils DOIVENT donner la priorité à cette application dans la RAM comme elles le font pour les autres éléments censés rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une application de ce type est exécutée en arrière-plan, le système peut toujours lui appliquer des fonctionnalités de gestion de l'alimentation, telles que la limitation de l'accès au processeur et au réseau.
• [C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participera pas au mécanisme normal d'enregistrement/de restauration de l'état une fois que l'utilisateur aura lancé une deuxième application déclarée avec l'attribut cantSaveState.
• [C-1-3] NE DOIT PAS appliquer d'autres modifications de stratégie aux applications qui spécifient cantSaveState, telles que la modification des performances du processeur ou de la priorisation de la planification.

Si les implémentations d'appareils ne déclarent pas la fonctionnalité FEATURE_CANT_SAVE_STATE:

• [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 les API Contacts Provider qui permettent aux applications de gérer les coordonnées stockées sur l'appareil. Les données de contact saisies directement sur l'appareil sont généralement synchronisées avec un service Web, mais il est possible qu'elles ne soient stockées que localement sur l'appareil. Les contacts qui ne sont stockés que sur l'appareil sont appelés contacts locaux.

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

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

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

Implémentations pour les appareils:

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

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

• [C-1-1] Le ACCOUNT_NAME du compte local personnalisé DOIT être renvoyé d'ici le ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Le ACCOUNT_TYPE du compte local personnalisé DOIT être renvoyé d'ici le ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] Les contacts bruts insérés par des applications tierces avec le compte local par défaut (c'est-à-dire en définissant des valeurs nulles pour ACCOUNT_NAME et ACCOUNT_TYPE) DOIVENT être insérés dans le compte local personnalisé.
• [C-1-4] Les contacts bruts insérés dans un compte local personnalisé NE DOIVENT pas être supprimés lors de l'ajout ou de la suppression de comptes.
• [C-1-5] Les opérations de suppression effectuées sur le compte local personnalisé DOIVENT entraîner la suppression immédiate et définitive des contacts bruts (comme si le paramètre CALLER_IS_SYNCADAPTER était défini sur "true"), même si le paramètre CALLER\_IS\_SYNCADAPTER était défini sur "false" ou n'était pas spécifié.

4. Compatibilité avec les packages d'applications

Implémentations pour les appareils:

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

Implémentations pour les appareils:

• [C-0-2] DOIT prendre en charge la validation des fichiers ".apk" à l'aide des APK Signature Scheme v3 , APK Signature Scheme v2 et de la signature JAR.
• [C-0-3] NE DOIT PAS étendre les formats de bytecode .apk, manifest Android, Dalvik bytecode ou RenderScript d'une manière qui empêcherait leur installation et leur exécution sur d'autres appareils compatibles.

• [C-0-4] NE DOIT PAS autoriser les applications autres que le "programme d'installation officiel" actuel du package à désinstaller l'application en mode silencieux sans confirmation de l'utilisateur, comme indiqué dans le SDK pour l'autorisation DELETE_PACKAGE. Les seules exceptions sont l'application de vérification des packages système qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application de gestionnaire de stockage qui gère l'intent ACTION_MANAGE_STORAGE.

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

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

  • Il DOIT déclarer l'autorisation REQUEST_INSTALL_PACKAGES ou définir la valeur de android:targetSdkVersion sur 24 ou moins.
  • L'utilisateur DOIT avoir été autorisé à installer des applications provenant de sources inconnues.

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

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

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

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

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

• Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre aux exigences du [C-0-8] et du [C-0-9] via une mise à jour logicielle système, elles PEUVENT être exemptées de ces exigences.

5. Compatibilité multimédia

Implémentations pour les appareils:

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

Implémentations pour les appareils:

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

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

Veuillez noter que ni Google, ni l'Open Handset Alliance ne prétendent que l'absence de brevets tiers pour ces codecs. Il est conseillé aux personnes qui ont l'intention d'utiliser ce code source dans du matériel ou des logiciels que les mises en œuvre de ce code, y compris dans des logiciels Open Source ou des sharewares, peuvent nécessiter des licences de brevet des titulaires de brevets concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

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

Si les intégrations d'appareils déclarent android.hardware.microphone, ils DOIVENT accepter l'encodage des formats audio suivants et les mettre à la disposition des applications tierces:

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

Tous les encodeurs audio DOIVENT prendre en charge:

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

5.1.2. Décodage audio

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

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

• [C-1-1] Profil MPEG-4 AAC (AAC LC)
• [C-1-2] Profil MPEG-4 HE AAC (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
• [C-1-4] AAC ELD (AAC à faible décalage amélioré)
• [C-1-11] xHE-AAC (profil HE AAC étendu ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de plage dynamique ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, y compris des formats audio haute résolution jusqu'à 24 bits, un taux d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne concerne que le décodage, et qu'un appareil est autorisé à sous-échantillonner et à réduire le mixage pendant la phase de lecture.
• [C-1-10] Opus

Si les implémentations d'appareils sont compatibles avec le décodage des tampons d'entrée AAC des flux multicanaux (c'est-à-dire plus de deux canaux) vers le format PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être acceptés:

• [C-2-1] Le décodage DOIT être effectué sans sous-mixage (par exemple, un flux 5.0 AAC doit être décodé en cinq canaux PCM et un flux 5.1 AAC doit être décodé en six canaux PCM).
• [C-2-2] Les métadonnées de plage dynamique DOIVENT être telles que définies dans la section "Dynamic Range Control (DRC)" de la norme ISO/IEC 14496-3, et les clés DRC android.media.MediaFormat pour configurer les comportements liés à la plage dynamique du décodeur audio. Les clés AAC DRC ont été introduites dans l'API 21 et sont les suivantes: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] Il est FORTEMENT RECOMMANDÉ que les exigences C-2-1 et C-2-2 ci-dessus soient satisfaites par tous les décodeurs audio AAC.

Lors du décodage des fichiers audio USAC, MPEG-D (ISO/IEC 23003-4):

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

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

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

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

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

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

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

5.1.3. Détails des codecs audio

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

5.1.4. Encodage d'image

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

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

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

Si les implémentations d'appareils acceptent l'encodage HEIC via android.media.MediaCodec pour le type de média MIMETYPE_IMAGE_ANDROID_HEIC, elles:

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

5.1.5. Décodage d'images

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

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

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Brut

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

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

• [C-2-1] DOIT prendre en charge la sortie d'un format équivalent à 8 bits si l'application le demande, par exemple via la configuration ARGB_8888 de android.graphics.Bitmap.

5.1.6. Détails des codecs image

Format/Codec	Détails	Types de fichiers/formats de conteneur acceptés
JPEG	Base+progressive	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Brute		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	Image, collection d'images, séquence d'images	HEIF (.heif), HEIC (.heic)

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

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

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

• [C-1-3] DOIT accepter au moins l'un des formats de couleurs YUV420 8:8:8 planaires ou semi-planaires: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de les accepter dans les deux cas.

5.1.7. Codecs vidéo

• Pour garantir une qualité acceptable pour les services de streaming vidéo sur le Web et de vidéoconférence, les appareils DOIVENT utiliser un codec matériel VP8 conforme aux exigences.

Si les implémentations d'appareils incluent un décodeur ou un encodeur vidéo:

• [C-1-1] Les codecs vidéo DOIVENT prendre en charge des tailles de bytebuffer de sortie et d'entrée qui acceptent la plus grande trame compressée et non compressée possible, conformément aux exigences de la norme et de la configuration, mais sans surallouer.

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

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

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

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

Si les implémentations d'appareils font la promotion de la compatibilité avec les profils HDR via Display.HdrCapabilities:

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

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

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

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

• [C-4-1] DOIT utiliser par défaut le format de couleur optimisé pour l'affichage matériel s'il est configuré avec une sortie en surface.
• [C-4-2] DOIT utiliser par défaut un format de couleurs YUV420 8:8:8 optimisé pour la lecture du processeur s'il est configuré pour ne pas utiliser la sortie en surface.

5.1.8. Liste des codecs vidéo

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

5.1.9. Sécurité du codec multimédia

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du codec multimédia décrites ci-dessous.

Android prend en charge OMX, une API d'accélération multimédia multiplate-forme, ainsi que Codec 2.0, une API d'accélération multimédia peu coûteuse.

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

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

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

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

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

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

5.1.10. Caractérisation du codec multimédia

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

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

En particulier :

• [C-1-2] Codecs dont le nom commence par "OMX". DOIT utiliser les API OMX et avoir des noms conformes aux consignes d'attribution de noms OMX IL.
• [C-1-3] Codecs dont le nom commence par "c2". DOIT utiliser l'API Codec 2.0 et avoir des noms conformes aux consignes d'attribution de noms de Codec 2.0 pour Android.
• [C-1-4] Codecs dont le nom commence par "OMX.google." ou "c2.android". NE DOIT PAS être caractérisé par un fournisseur ou une accélération matérielle.
• [C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) ayant accès à des pilotes matériels autres que les outils d'allocation de mémoire et les mappeurs NE DOIVENT PAS être considérés comme exclusivement logiciels.
• [C-1-6] Les codecs qui ne figurent pas dans le projet Android Open Source ou qui ne sont pas basés sur le code source de ce projet DOIVENT être définis comme des fournisseurs.
• [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être considérés comme étant accélérés par le matériel.
• [C-1-8] Les noms de codec NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIVENT prendre en charge le décodage, et ceux nommés "encodeurs" DOIVENT prendre en charge l'encodage. Les codecs dont les noms contiennent des formats multimédias DOIVENT prendre en charge ces formats.

Si les implémentations d'appareils sont compatibles avec les codecs vidéo:

• [C-2-1] Tous les codecs vidéo DOIVENT publier des données de fréquence d'images atteignables pour les tailles suivantes, sous réserve qu'elles soient prises en charge par le codec:

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	176 x 144 px (H263, MPEG2, MPEG4) 352 x 288 px (encodeur MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (autre)	704 x 576 px (H263) 640 x 360 px (VP8, VP9) 640 x 480 px (encodeur MPEG4) 720 x 480 px (autre)	1408 x 1152 px (H263) 1 280 x 720 px (autre)	1 920 x 1 080 px (autres que MPEG4)	3840 x 2160 px (HEVC, VP9)

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

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec n'importe quel encodeur vidéo et le mettent à la disposition d'applications tierces:

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

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

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

Si les implémentations d'appareils sont compatibles avec les encodeurs vidéo H.264, VP8, VP9 ou HEVC et le rendent disponible pour des applications tierces:

• [C-2-1] DOIT être compatible avec les débits configurables dynamiquement.
• DEVRAIT prendre en charge des fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée d'affichage instantanée en fonction des horodatages des tampons d'entrée et allouer son segment de bits en fonction de cette durée d'image.

Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le rendent disponible pour les applications tierces, celles-ci:

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

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

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

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:

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

5.2.2. H.264

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

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

Si les mises en œuvre des appareils indiquent que l'encodage H.264 est accepté pour les vidéos en résolution 720p ou 1080p via les API multimédias:

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	20 FPS	30 ips	30 ips	30 ips
Débit vidéo	384 kbit/s	2 Mbit/s	4 Mbit/s	10 Mbit/s

5.2.3. VP8

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

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

Si les intégrations sur les appareils indiquent la compatibilité de l'encodage VP8 pour les vidéos en résolution 720p ou 1080p via les API multimédias:

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

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

5.2.4. VP9

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

• [C-1-2] DOIT prendre en charge le profil 0 de niveau 3.
• [C-1-1] DOIT prendre en charge l'écriture de fichiers Matroska WebM.
• [C-1-3] DOIT générer des données CodecPrivate.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.
• Les [SR] sont FORTEMENT RECOMMANDÉS pour prendre en charge les profils de décodage HD, comme indiqué dans le tableau suivant, s'il existe un encodeur matériel.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils déclarent être compatibles avec Profile 2 ou Profile 3 via les API Media:

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

5.2.5. H265

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

• [C-1-1] DOIT prendre en charge le profil principal de niveau 3.
• DEVRAIT prendre en charge les profils d'encodage HD, comme indiqué dans le tableau suivant.
• Les [SR] sont FORTEMENT RECOMMANDÉS pour prendre en charge les profils d'encodage HD, comme indiqué dans le tableau suivant, s'il existe un encodeur matériel.

	SD	HD – 720p	HD – 1080p	UHD
Résolution vidéo	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.3. Décodage vidéo

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

• [C-1-1] DOIT prendre en charge le changement de résolution vidéo et de fréquence d'images dynamiques via les API Android standards dans le même flux pour tous les codecs VP8, VP9, H.264 et H.265 en temps réel et jusqu'à la résolution maximale acceptée par chaque codec sur l'appareil.

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

• [C-1-1] DOIT être compatible avec le profil principal de niveau 3.1 et le profil de référence. La prise en charge des options ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) et RS (segments redondants) est FACULTATIVE.
• [C-1-2] DOIT être capable de décoder les vidéos avec les profils SD (définition standard) répertoriés dans le tableau suivant et encodées avec le profil de référence et le profil principal de niveau 3.1 (y compris 720p30).
• DOIT être capable de décoder des vidéos avec les profils HD (haute définition), comme indiqué dans le tableau suivant.

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1280 x 720 px	1920 x 1080 px
Fréquence d'images vidéo	30 ips	30 ips	60 FPS	30 FPS (60 FPS pour la télévision)
Débit vidéo	800 Kbit/s	2 Mbit/s	8 Mbit/s	20 Mbit/s

5.3.5. H.265 (HEVC)

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

• [C-1-1] DOIT prendre en charge le niveau principal du profil principal de niveau 3 et les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.
• [C-1-2] DOIT être compatible avec les profils de décodage HD indiqués dans le tableau suivant en cas de décodeur matériel.

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	352 x 288 px	720 x 480 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30/60 FPS (60 FPS, téléviseur avec décodage matériel H.265)	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils déclarent être compatibles avec un profil HDR via les API Media:

• [C-3-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises de l'application, et permettre l'extraction et la sortie des métadonnées HDR requises à partir du flux de bits et/ou du conteneur.
• [C-3-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

• [C-1-1] DOIT être compatible avec les profils de décodage vidéo SD, comme indiqué dans le tableau suivant.
• DEVRAIT être compatible avec les profils de décodage HD, comme indiqué dans le tableau suivant.

Si les implémentations d'appareils sont compatibles avec le codec VP9 et un décodeur matériel:

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

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	320 x 180 px	640 x 360 px	1280 x 720 px	1920 x 1080 px	3840 x 2160 px
Fréquence d'images vidéo	30 ips	30 ips	30 ips	30 FPS (téléviseur avec décodage matériel VP9)	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations d'appareils sont compatibles avec VP9Profile2 ou VP9Profile3 via les API multimédias CodecProfileLevel:

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

Si les implémentations d'appareils sont compatibles avec un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API multimédias:

• [C-4-1] Les implémentations d'appareils DOIVENT accepter les métadonnées HDR requises (KEY_HDR_STATIC_INFO pour tous les profils HDR, et "KEY_HDR10_PLUS_INFO" pour les profils HDR10Plus) de l'application. Ils DOIVENT également être compatibles avec l'extraction et la sortie des métadonnées HDR requises à partir du flux de bits et/ou du conteneur.
• [C-4-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

Si les implémentations d'appareils déclarent être compatibles avec le décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION , elles:

• [C-1-1] DOIT fournir un extracteur compatible Dolby Vision.
• [C-1-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).
• [C-1-3] DOIT définir l'index de piste des couches de base rétrocompatibles (le cas échéant) de sorte qu'ils soient identiques à ceux de la couche Dolby Vision combinée.

5.3.9. AV1

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

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

5.4. Enregistrement audio

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

5.4.1. Capture audio brute et informations sur le micro

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

• [C-1-1] DOIT autoriser la capture de contenus audio bruts présentant 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

• DEVRAIT permettre la capture d'un contenu audio brut présentant les caractéristiques suivantes:

  • Format: PCM linéaire 16 bits et 24 bits
  • Taux d'échantillonnage: 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
  • Canaux: autant de canaux que le nombre de micros sur l'appareil.

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

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

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

  • Format: PCM linéaire 16 bits
  • Taux d'échantillonnage: 22 050, 48 000 Hz
  • Canaux: stéréo
  • [C-1-4] DOIT respecter l'API MicrophoneInfo et indiquer correctement les informations concernant les micros disponibles sur les appareils 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 une capture radio AM et DVD de qualité du contenu audio brut, elles:

• [C-2-1] DOIT effectuer une capture sans suréchantillonnage à un ratio supérieur à 16 000:22050 ou 44 100:48 000.

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

5.4.2. Capturer pour la reconnaissance vocale

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

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

Si les implémentations d'appareils déclarent android.hardware.microphone et des technologies de suppression du bruit (réduction) adaptées pour la reconnaissance vocale, elles:

• [C-2-1] DOIT permettre de contrôler cet effet audio avec l'API android.media.audiofx.NoiseSuppressor.
• [C-2-2] DOIT identifier de manière unique chaque implémentation de technologie de suppression du bruit via le champ AudioEffect.Descriptor.uuid.

5.4.3. Capturer pour réacheminer la lecture

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

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

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

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

5.4.4. Annulateur d'écho acoustique

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

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

Si les implémentations de l'appareil fournissent un annulant d'écho acoustique inséré dans le chemin audio de capture lorsque AudioSource.VOICE_COMMUNICATION est sélectionné, ils:

• Les [C-SR] sont STRONGLY_RECOMMENDED à le déclarer via la AcousticEchoCanceler méthode API AcousticEchoCanceler.isAvailable()
• Les [C-SR] sont STRONGLY_RECOMMENDED pour permettre le contrôle de cet effet audio avec l'API AcousticEchoCanceler.
• Les [C-SR] sont STRONGLY_RECOMMENDED pour identifier de manière unique chaque implémentation de 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 un accès simultané au micro par un service d'accessibilité qui capture avec AudioSource.VOICE_RECOGNITION et au moins une application capturant un élément AudioSource.
• [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle Assistant et au moins une application effectuant une 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 capture avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application capture via AudioSource.VOICE_COMMUNICATION, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec l'autorisation CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Si plusieurs applications effectuent une capture simultanée et qu'aucune de ces applications ne dispose d'une interface utilisateur, celle qui a commencé à capturer le plus récemment reçoit du contenu audio.

5.4.6. Niveaux de gain du micro

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

• DEVRAIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±3 dB de 100 Hz à 4 000 Hz pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
• DEVRAIT définir la sensibilité de l'entrée audio de sorte qu'une source de tonalités sinusoïdales de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 90 dB génère une réponse avec un RMS de 2 500 pour des échantillons de 16 bits (ou une échelle de -22,35 dB pour les échantillons à virgule flottante/double précision) pour chaque source audio utilisée pour l'enregistrement de la reconnaissance vocale.
• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour présenter des niveaux d'amplitude dans la plage des basses fréquences, en particulier de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour présenter des niveaux d'amplitude dans la plage des hautes fréquences: de ±30 dB de 4 000 Hz à 22 kHz par rapport à la bande de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

5.5. Lecture audio

Android permet d'autoriser les applications à lire du contenu audio via le périphérique de sortie audio, comme défini dans la section 7.8.2.

5.5.1. Lecture audio brute

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

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

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

• DEVRAIT autoriser la lecture d'un contenu audio brut présentant les caractéristiques suivantes:

  • Taux d'échantillonnage: 24 000, 48 000

5.5.2. Effets audio

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

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

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

5.5.3. Volume de sortie audio

Implémentations pour les appareils automobiles:

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

5.6. Latence audio

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

Pour les besoins de cette section, utilisez les définitions suivantes:

• latence de sortie. Intervalle entre le moment où une application écrit une trame de données codées PCM et le moment où le son correspondant est présenté à l'environnement par un transducteur sur l'appareil ou un signal qui quitte l'appareil via un port et peut être observé en externe.
• latence de sortie à froid. Latence de sortie de la première trame, lorsque le système de sortie audio a été inactif et mis hors tension avant la requête.
• latence de sortie continue. Latence de sortie des frames suivants, une fois que l'appareil lit du contenu audio.
• la latence d'entrée. Intervalle entre le moment où un son est présenté par l'environnement à l'appareil au niveau d'un transducteur ou un signal sur l'appareil via un port et lorsqu'une application lit la trame correspondante de données codées PCM.
• perd input. Partie initiale d'un signal d'entrée inutilisable ou indisponible.
• latence d'entrée à froid. Somme du temps d'entrée perdu et de la latence d'entrée pour la première trame, lorsque le système d'entrée audio a été inactif et hors tension avant la requête.
• latence d'entrée continue. Latence d'entrée des trames suivantes pendant la capture audio par l'appareil.
• gigue de sortie à froid. La variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
• gigue d'entrée à froid. La variabilité entre les différentes mesures des valeurs de latence d'entrée à froid.
• la latence aller-retour continue. Somme de la latence d'entrée continue et de la latence de sortie continue, plus une période de tampon. La période de mise en mémoire tampon permet à l'application de traiter le signal, et le temps nécessaire à l'application pour atténuer la différence de phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon OpenSL ES PCM Ensemble d'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 relative de trame dans un flux et du temps estimé où cette trame entre ou sort du pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.
• glitch. Interruption temporaire ou valeur d'échantillon incorrecte du signal audio, généralement causée par une sous-utilisation de la mémoire tampon en sortie, une surcharge de la mémoire tampon en entrée ou toute autre source de bruit numérique ou analogique.

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

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

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] Latence de sortie à froid de 100 millisecondes ou moins. Les appareils nouveaux et existants qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉS de répondre à ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence de sortie à froid de 200 ms ou moins.
• [C-SR] Latence de sortie continue inférieure ou égale à 45 millisecondes.
• [C-SR] Réduisez la gigue à la sortie à froid.
• [C-SR] 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 étalonnage initial, lors de l'utilisation à la fois de la file d'attente de tampon OpenSL ES PCM et des API audio natives AAudio, pour une latence de sortie continue et une latence de sortie à froid sur au moins un périphérique de sortie audio compatible, les deux valeurs sont les suivantes:

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

Si les implémentations d'appareils ne répondent pas aux exigences de l'audio à faible latence via la file d'attente de tampon OpenSL ES PCM et les API audio natives AAudio:

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

Si les implémentations d'appareils incluent android.hardware.microphone, ils DOIVENT respecter ces exigences audio d'entrée:

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

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

• [C-SR] Latence d'entrée froide inférieure ou égale à 100 millisecondes. Les appareils nouveaux et existants qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉS de répondre à ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence d'entrée à froid de 200 ms ou moins.
• [C-SR] Latence d'entrée continue inférieure ou égale à 30 millisecondes.
• [C-SR] Latence aller-retour continue de 50 millisecondes ou moins.
• [C-SR] Réduisez la gigue à l'entrée à froid.
• [C-SR] Limite l'erreur dans les horodatages d'entrée, tels qu'ils sont renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT être compatibles avec les protocoles réseau multimédias pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un décodeur audio ou vidéo:

• [C-1-1] DOIT prendre en charge tous les codecs et formats de conteneur requis dans la section 5.1 via HTTP(S).

• [C-1-2] DOIT prendre en charge les formats de segment multimédia indiqués dans le tableau ci-dessous par rapport au projet de protocole HTTP Live Streaming, version 7.

• [C-1-3] DOIT prendre en charge le profil audio vidéo RTP suivant et les codecs associés dans le tableau RTSP ci-dessous. Pour les exceptions, veuillez consulter les notes de bas de tableau de la section 5.1.

Formats des segments média

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

RTSP (RTP, SDP)

Nom du profil	Référence(s)	Compatibilité avec le codec requise
H264 AVC	RFC 6184	Pour en savoir plus sur H264 AVC, consultez la section 5.1.3.
MP4A-LATM	RFC 6416	Consultez la section 5.1.1 pour en savoir plus sur AAC et ses variantes.
H263-1998	RFC 3551 RFC 4629 RFC 2190	Pour en savoir plus sur le code H263, consultez la section 5.1.3.
H263-2000	RFC 4629	Pour en savoir plus sur le code H263, consultez la section 5.1.3.
AMR	RFC 4867	Pour en savoir plus sur AMR-NB, consultez la section 5.1.1.
AMR-WB	RFC 4867	Pour en savoir plus sur AMR-WB, consultez la section 5.1.1.
MP4V-ES	RFC 6416	Pour en savoir plus sur MPEG-4 SP, consultez la section 5.1.3.
mpeg4 générique	RFC 3640	Consultez la section 5.1.1 pour en savoir plus sur AAC et ses variantes.
MP2T	RFC 2250	Pour en savoir plus, consultez la section Flux de transport MPEG-2 sous la diffusion HTTP en direct.

5.8. Secure Media

Si les implémentations d'appareils prennent en charge la sortie vidéo sécurisée et les surfaces sécurisées, elles:

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

Si les implémentations d'appareils déclarent prendre en charge Display.FLAG_SECURE et le protocole d'affichage sans fil:

• [C-2-1] DOIT sécuriser la liaison au moyen d'un mécanisme cryptographiquement fort, tel que HDCP 2.x ou version ultérieure, pour les écrans connectés via des protocoles sans fil tels que Miracast.

Si les implémentations d'appareils déclarent prendre en charge Display.FLAG_SECURE et les écrans externes filaires, elles:

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

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

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

• [C-1-1] DOIT prendre en charge MIDI sur tous les transports matériels compatibles MIDI pour lesquels il fournit une connectivité générique non-MIDI, lorsque ces transports sont:

  • Mode hôte USB, section 7.7
  • MIDI via Bluetooth LE agissant en tant que rôle central, section 7.4.3

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

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

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

5.10. Audio professionnel

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

• [C-1-1] DOIT signaler la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
• [C-1-2] DOIT présenter une latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, DOIT être inférieure ou égale à 20 millisecondes et DOIT être inférieure ou égale à 10 millisecondes sur au moins un chemin pris en charge.
• [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec les modes hôte USB et périphérique USB.
• [C-1-4] DOIT signaler la prise en charge de la fonctionnalité android.software.midi.
• [C-1-5] DOIT respecter les latences et les exigences audio USB à l'aide de l'API de file d'attente de tampon PCM OpenSL ES et d'au moins un chemin d'accès de l'API audio native AAudio.
• [SR] SONT FORTEMENT RECOMMANDÉS de respecter les latences et les exigences audio USB en utilisant l'API audio natif AAudio sur le chemin MMAP.
• [C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
• [C-1-7] DOIT avoir une latence d'entrée à froid de 200 millisecondes ou moins.
• [SR] SONT FORTEMENT RECOMMANDÉS de fournir un niveau de performances constant du processeur lorsque le son est actif et que la charge du processeur varie. Il doit être testé avec l'ID de commit SynthMark de l'application Android 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark utilise un synthétiseur logiciel qui s'exécute 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 automatisé" et obtenir les résultats suivants :
  • voicemark.90 >= 32 voix
  • latencemark.Fix.little <= 15 ms
  • latencemark.dynamic.little <= 50 ms

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

• DOIT minimiser les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.
• DEVRAIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
• DEVRAIT minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil.
• DEVRAIT minimiser la latence audio sur l'audio numérique USB.
• DEVRAIT documenter les mesures de latence audio sur tous les chemins.
• DOIT réduire la gigue des temps d'entrée du rappel de fin de tampon audio, car cela affecte le pourcentage utilisable de la bande passante complète du processeur par le rappel.
• DEVRAIT ne fournir aucun problème audio dans des conditions d'utilisation normale et avec une latence signalée.
• DEVRAIT ne fournir aucune différence de latence entre les canaux.
• DEVRAIT minimiser la latence moyenne MIDI sur tous les transports.
• DEVRAIT minimiser la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.
• DEVRAIT fournir des horodatages MIDI précis pour tous les transports.
• DOIT minimiser le bruit du signal audio sur les transducteurs intégrés à l'appareil, y compris la période qui suit le démarrage à froid.
• DEVRAIT ne fournir aucune différence d'horloge audio entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Exemples de points de terminaison correspondants : micro et haut-parleur de l'appareil, ou entrée et sortie du connecteur audio.
• DEVRAIT gérer les rappels d'achèvement du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et saisir le rappel de sortie immédiatement après le retour du rappel d'entrée. S'il n'est pas possible de gérer les rappels sur le même thread, entrez le rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à l'application d'avoir une synchronisation cohérente des côtés d'entrée et de sortie.
• DEVRAIT minimiser la différence de phase entre la mise en mémoire tampon de l'audio HAL pour les côtés entrée et sortie des points de terminaison correspondants.
• DEVRAIT minimiser la latence tactile.
• DEVRAIT minimiser la variabilité de la latence tactile en cas de charge (gigue).
• DEVRAIT avoir une latence inférieure ou égale à 40 ms entre l'entrée tactile et la sortie audio.

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

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

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

• [C-2-1] DOIT présenter une latence audio aller-retour continue de 20 millisecondes ou moins sur le chemin du connecteur audio.
• [SR] VIVEMENT RECOMMANDÉ pour respecter la section Caractéristiques des appareils mobiles (connecteurs) des spécifications du casque audio filaire (v1.1).
• La latence audio aller-retour en continu DOIT être inférieure ou égale à 10 millisecondes sur le chemin du connecteur audio.

Si les appareils ne comprennent pas de connecteur audio 3, 5 mm à 4 conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB:

• [C-3-1] DOIT implémenter la classe audio USB.
• [C-3-2] DOIT avoir une latence audio aller-retour continue de 20 millisecondes ou moins sur le port du mode hôte USB en utilisant la classe audio USB.
• La latence audio aller-retour en continu DOIT être inférieure ou égale à 10 millisecondes sur le port du mode hôte USB en utilisant la classe audio USB.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à 8 canaux par direction, un taux d'échantillonnage de 96 kHz et une profondeur de 24 ou 32 bits, en cas d'utilisation avec des périphériques audio USB qui répondent également à ces exigences.

Si les appareils incluent un port HDMI, ils:

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

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

Android est compatible avec l'enregistrement de contenus audio non traités via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, il est accessible avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si les implémentations d'appareils ont l'intention de prendre en charge une source audio non traitée et de la rendre disponible pour les applications tierces:

• [C-1-1] DOIT signaler cette compatibilité via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DOIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-3] DOIT présenter des niveaux d'amplitude dans la plage des basses fréquences, en particulier 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 des hautes fréquences, en particulier de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio non traitée.

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

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

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

• NE DOIT PAS comporter d'autre traitement de signal (contrôle automatique du gain, filtre passe-haut ou annulation d'écho) dans le chemin autre qu'un multiplicateur de niveau pour atteindre la plage souhaitée. Autrement dit :

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

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

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

• [C-2-1] DOIT renvoyer null pour la méthode API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) afin d'indiquer correctement l'absence de compatibilité.
• Les enregistrements [SR] sont FORTEMENT RECOMMANDÉS pour répondre à un maximum d'exigences concernant le chemin du signal pour la source d'enregistrement non traitée.

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

6.1. Outils pour les développeurs

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans le SDK Android.

• Android Debug Bridge (adb)

  • [C-0-2] DOIT prendre en charge adb comme indiqué dans le SDK Android et les commandes shell fournies dans AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys cmd stats
  • [C-0-11] DOIT prendre en charge la commande shell cmd testharness. La mise à niveau des implémentations d'appareils à partir d'une version antérieure d'Android sans bloc de données persistant PEUT être exemptée de l'application 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, charts, netstats, notification, procstats) enregistrés via la commande dumpsys.
  • [C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell cmd stats et la classe d'API système StatsManager.
    • État de premier plan de l'activité modifié
    • Anomalie détectée
    • Fil d'Ariane signalé
    • AppCrashOccured
    • AppStartOccurred (Démarrage de l'application)
    • Niveau de batterie modifié
    • État du mode d'économie de batterie modifié
    • BleScanResultReceived (Résultat reçu)
    • BleScanStateChanged
    • État de facturation modifié
    • DeviceIdleModeStateChanged
    • État du service de premier plan modifié
    • GpsScanStateChanged
    • État du job modifié
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • État de l'écran modifié
    • SyncStateChanged (État de synchronisation modifié)
    • SystèmeElapsedRealtime
    • UidProcessStateChanged
    • État du wakelock modifié
    • Alarme du réveilSure
    • État du verrouillage du Wi-Fi modifié
    • État du verrouillage WifiMulticast modifié
    • État du Wi-Fi modifié
  • [C-0-4] DOIT avoir le daemon adb côté appareil inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer Android Debug Bridge.
  • [C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Le service adb sécurisé active adb sur des hôtes authentifiés connus.
  • [C-0-6] DOIT fournir un mécanisme permettant à adb d'être connecté à partir d'une machine hôte. Plus spécifiquement :

  Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, celles-ci:

  • [C-3-1] DOIT implémenter adb via un réseau local (Ethernet ou Wi-Fi, par exemple).
  • [C-3-2] DOIT fournir des pilotes pour Windows 7, 8 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

  Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi, celles-ci:

  • [C-4-1] DOIT faire en sorte que la méthode AdbManager#isAdbWifiSupported() renvoie true.

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

  • [C-5-1] DOIT faire en sorte que la méthode AdbManager#isAdbWifiQrSupported() renvoie true.

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android. Étant donné que ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme ci-dessus.
• Singe
  • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.
• SysTrace
  • [C-0-9] DOIT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir un mécanisme accessible par l'utilisateur pour activer Systrace.
• Perfetto
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur shell, dont la ligne de commande est conforme à la documentation de Perfetto.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'accepter comme entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto pour le binaire Perfetto.
  • [C-SR] Il est VIVEMENT RECOMMANDÉ d'écrire le binaire de Perfetto pour écrire en sortie une trace protobuf conforme au schéma défini dans la documentation de Perfetto.
  • [C-SR] 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 élément Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le tueur de mémoire faible.
• Mode Harness de test Si les implémentations d'appareils acceptent la commande shell cmd testharness et exécutent cmd testharness enable, elles :
  • [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DOIT implémenter le mode faisceau de test tel que décrit dans la documentation relative au mode faisceau de test.

Si les implémentations d'appareils indiquent la prise en charge de Vulkan 1.0 ou version ultérieure via les flags de fonctionnalité android.hardware.vulkan.version, elles:

• [C-1-1] DOIT fournir une affordance aux développeurs d'applications pour activer/désactiver les couches de débogage GPU.
• [C-1-2] DOIT, lorsque les couches de débogage GPU sont activées, énumérer les couches des bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie du package de plate-forme ou d'application) qui se trouvent dans le répertoire de base des applications débogables afin de prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().

6.2. Options pour les développeurs

Android permet aux développeurs de configurer les paramètres liés au développement d'applications.

Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour les options pour les développeurs:

• [C-0-1] DOIT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer ces options après avoir appuyé sept (7) fois sur Paramètres > À propos de l'appareil > Numéro de version.
• [C-0-2] DOIT masquer les options pour les développeurs par défaut.
• [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas un traitement préférentiel à une application tierce plutôt qu'à une autre afin d'activer les Options pour les développeurs. DOIT fournir un document ou un site Web visibles au public expliquant comment activer les Options pour les développeurs. Ce document ou ce site Web DOIT pouvoir rediriger les utilisateurs vers les documents du SDK Android.
• DEVRAIT afficher une notification visuelle en continu à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
• PEUVENT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant ou en le désactivant visuellement, afin d'éviter toute distraction dans les cas où la sécurité de l'utilisateur est préoccupante.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier qui dispose d'une API correspondante pour les développeurs tiers:

• [C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel désigné comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

• [C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) pour les API des composants DOIVENT toujours être présentées.
• [C-0-3] Les comportements de l'API DOIVENT être implémentés en tant que no-ops d'une manière raisonnable.
• [C-0-4] Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK le permet.
• [C-0-5] Les méthodes API DOIVENT renvoyer des implémentations no-op de classes dans lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• [C-0-6] Les méthodes API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
• [C-0-7] Les implémentations d'appareils DOIVENT indiquer de manière cohérente des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) sur la classe android.content.pm.PackageManager pour la même empreinte de build.

L'API de téléphonie est un exemple type de scénario dans lequel ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées de manière à être implémentées de manière no-ops raisonnable.

7.1. Écran et graphismes

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

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

• taille physique en diagonale. Distance en pouces entre les deux coins opposés de la partie éclairée de l'écran.
• points par pouce (PPP). Nombre de pixels englobés par une étendue linéaire horizontale ou verticale de 1". Lorsque les valeurs PPP sont indiquées, les dpi horizontal et vertical doivent être compris dans la plage.
• format. Rapport entre le nombre de pixels de la dimension la plus longue et celle du côté le plus court de l'écran. Par exemple, un écran de 480 x 854 pixels correspondrait à 854/480 = 1,779, soit approximativement "16:9".
• pixel indépendant de la densité (dp). Unité de pixel virtuel normalisée sur un écran de 160 ppp, calculée comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

Taille et forme de l'écran

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

Implémentations pour les appareils:

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

  • Les appareils dont le paramètre Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_WATCH et qui signalent une taille small pour Configuration.screenLayout DOIVENT avoir au moins 426 dp x 320 dp.
  • Les appareils indiquant une taille normal pour Configuration.screenLayout DOIVENT avoir au moins 480 dp x 320 dp.
  • Les appareils indiquant une taille large pour Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
  • Les appareils indiquant une taille xlarge pour Configuration.screenLayout DOIVENT avoir au moins 960 dp x 720 dp.

• [C-0-2] DOIT respecter correctement la prise en charge déclarée des tailles d'écran par les applications via l'attribut <supports-screens> du fichier AndroidManifest.xml, comme indiqué dans la documentation du SDK Android.

• PEUVENT disposer d'un ou plusieurs écrans compatibles avec Android aux angles arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent un ou plusieurs écrans compatibles avec Android aux angles arrondis, ils:

• [C-1-1] DOIT s'assurer qu'au moins l'une des conditions suivantes est remplie:
• Le rayon des angles arrondis est inférieur ou égal à 38 dp.

• Lorsqu'un cadre de 15 dp x 15 dp est ancré à chaque coin de l'écran logique, au moins un pixel de chaque zone est visible à l'écran.

• DEVRAIT inclure l' affordance de l'utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou qui comprennent une charnière pliable entre plusieurs écrans et mettent ces écrans à disposition pour afficher des applications tierces:

• [C-2-1] DOIT implémenter la dernière version stable disponible de l'API Extensions ou la version stable de l'API side-car à utiliser par la bibliothèque Window Manager Jetpack.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou si une charnière se plie entre plusieurs écrans, et si la charnière ou le pli traverse une fenêtre d'application en plein écran, ils:

• [C-3-1] DOIT indiquer à l'application la position, les limites et l'état de la charnière ou du pli par l'intermédiaire d'extensions ou d'API side-car.

Pour savoir comment implémenter correctement les API d'extension ou side-car, consultez la documentation publique de Window Manager Jetpack.

Format de l'écran

Bien qu'il n'existe aucune restriction concernant le format de l'écran physique pour le ou les écrans compatibles 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 indiquées via les API view.Display et 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 un format inférieur ou égal à 1,86 (environ 16:9), sauf si l'application remplit l'une des conditions suivantes:

  • L'application a déclaré qu'elle était compatible avec un format d'écran plus grand via la valeur de métadonnées android.max_aspect.
  • L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
  • L'appli cible le niveau d'API 24 ou supérieur et ne déclare pas de android:maxAspectRatio qui limiterait le format autorisé.

• [C-0-2] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format égal ou supérieur à 1,3333 (4:3), sauf si l'application peut être étirée plus large en remplissant l'une des conditions suivantes:

  • L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
  • L'application déclare un élément android:minAspectRatio qui limiterait le format autorisé.

• [C-0-3] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_WATCH DOIVENT avoir un format de 1.0 (1:1).

Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT indiquer une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE. Cette valeur NE DOIT PAS changer à aucun moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications apportées à la configuration d'affichage par l'utilisateur (par exemple, la taille d'affichage) définies après le démarrage initial.

• Les implémentations d'appareils DOIVENT définir la densité standard du framework Android la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique pousse la taille d'écran indiquée en dessous de la taille minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement de la densité physique correspond à une taille d'écran inférieure à la plus petite taille d'écran compatible acceptée (largeur de 320 dp), les implémentations d'appareils DOIVENT indiquer la deuxième densité de framework standard Android la plus basse.

S'il existe une affordance pour modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle au-delà de 1,5 fois la densité native ou produire une dimension minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
• [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle en dessous de 0,85 fois la densité native.
• Pour garantir une bonne facilité d'utilisation et des tailles de police cohérentes, il est RECOMMANDÉ de proposer la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus).
• S: x 0,85
• Par défaut: 1x (échelle d'affichage natif)
• Grande: x 1,15
• Plus grande: x1,3
• Plus grande x 1,45

Métriques sur le Réseau Display

Si les implémentations d'appareils incluent un ou plusieurs écrans ou sorties vidéo compatibles Android sur un ou plusieurs écrans compatibles, elles:

• [C-1-1] DOIT indiquer des valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API android.util.DisplayMetrics.

Si les appareils ne comprennent pas d'écran intégré ni de sortie vidéo:

• [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible avec Android, tel que défini dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation prise en charge. Par exemple, un appareil avec un écran à orientation fixe en mode paysage, comme un téléviseur ou un ordinateur portable, DOIT signaler uniquement android.hardware.screen.landscape.
• [C-0-2] DOIT indiquer la valeur correcte correspondant à l'orientation actuelle de l'appareil chaque fois qu'elle est interrogée via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Si les implémentations d'appareils sont compatibles avec les deux orientations d'écran:

• [C-1-1] DOIT prendre en charge l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la requête de l'application pour une orientation d'écran spécifique.
• [C-1-2] NE DOIT PAS modifier la taille ni la densité d'écran indiquées lors du changement d'orientation.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations pour les appareils:

• [C-0-1] DOIT identifier correctement les versions d'OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (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 chaque version d'OpenGL ES qu'elles ont identifiée comme compatible.

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué dans la documentation du SDK Android.
• [C-SR] Sont vivement RECOMMANDÉS pour la compatibilité avec OpenGL ES 3.1.
• DEVRAIT prendre en charge OpenGL ES 3.2.

Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

• [C-2-1] DOIT signaler via les API gérées et les API natives OpenGL ES toute autre extension OpenGL ES mise en œuvre, et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.
• [C-2-2] DOIT prendre en charge les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
• DEVRAIT enregistrer avec précision via la méthode getString(), tout format de compression de texture compatible, généralement spécifique au fournisseur.

Si les implémentations d'appareils déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles:

• [C-3-1] DOIT exporter les symboles de fonction correspondants à cette version en plus des symboles de fonction OpenGL ES 2.0 de la bibliothèque libGLESv2.so.
• [SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'extension OES_EGL_image_external_essl3.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.2, celles-ci:

• [C-4-1] DOIT prendre en charge le pack d'extensions Android OpenGL ES dans son intégralité.

Si les implémentations d'appareils sont compatibles avec le pack d'extensions Android OpenGL ES dans son intégralité, celles-ci:

• [C-5-1] DOIT identifier la compatibilité via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils sont compatibles avec l'extension EGL_KHR_mutable_render_buffer, elles:

• [C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple pour des graphismes 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, celles-ci:

• [SR] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.1.

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

• DEVRAIT inclure la prise en charge de Vulkan 1.1.

Les tests dEQP de Vulkan sont partitionnés en plusieurs listes de tests, chacune étant associée à une date/une version. Ces éléments se trouvent dans l'arborescence source Android sur external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un appareil compatible avec Vulkan à un niveau auto-déclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de test de ce niveau et des versions antérieures.

Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, elles:

• [C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
• [C-1-2] DOIT énumérer au moins un élément VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] DOIT implémenter intégralement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
• [C-1-4] DOIT énumérer les couches contenues dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothè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 traçage ou d'interception de l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
• [C-1-6] DOIT indiquer toutes les chaînes d'extension compatibles avec les API natives Vulkan et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'ils ne prennent pas correctement en charge.
• [C-1-7] DOIT prendre en charge les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
• [C-1-8] DOIT indiquer la version maximale des tests Vulkan dEQP compatibles avec l'indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-9] DOIT être compatible avec la version 132317953 au moins (à partir du 1er mars 2019), comme indiqué dans le flag de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-10] DOIT réussir tous les tests dEQP Vulkan dans les listes de tests entre la version 132317953 et la version spécifiée dans l'indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions VK_KHR_driver_properties et VK_GOOGLE_display_timing.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer d'indicateur de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level ou android.hardware.vulkan.version).
• [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations d'appareils sont compatibles avec Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan:

• [C-3-1] DOIT exposer la prise en charge des types de sémaphore et de handle externes SYNC_FD ainsi que l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT prendre en charge Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle des graphismes 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue en utilisant un tag de fichier manifeste android:hardwareAccelerated ou des appels d'API directs.

Implémentations pour les appareils:

• [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT désactiver l'accélération matérielle si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API Android View.
• [C-0-2] DOIT présenter un comportement cohérent avec la documentation du SDK Android concernant l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans larges

Si des implémentations d'appareils sont compatibles avec les écrans larges via Configuration.isScreenWideColorGamut() , elles:

• [C-1-1] DOIT disposer d'un écran calibré pour les couleurs.
• [C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
• [C-1-3] DOIT disposer d'un écran dont la gamme présente une surface d'au moins 90% de l'espace DCI-P3 dans l'espace xyY de la CIE 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et les signaler correctement.
• [C-1-5] DOIT faire la promotion des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans larges, ils:

• [C-2-1] DEVRAIT couvrir 100% ou plus du sRVB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

Mode de compatibilité des anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" (largeur 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android qui sont antérieures à l'indépendance par rapport à la taille de l'écran.

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 en cas d'autorisation expresse dans ce document.

Tous les écrans compatibles avec Android d'une implémentation d'appareil:

• [C-0-1] DOIT être capable d'afficher des images en couleurs 16 bits.
• DEVRAIT prendre en charge les écrans compatibles avec des graphismes en couleurs 24 bits.
• [C-0-2] DOIT être capable d'afficher des animations.
• [C-0-3] DOIT avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le rapport hauteur/largeur des pixels DOIT être proche du carré (1,0) avec une tolérance de 10 ~ 15 %.

Écrans secondaires

Android est compatible avec les écrans secondaires compatibles Android, ce qui permet d'activer les fonctionnalités de partage multimédia et les API de développement permettant d'accéder aux écrans externes.

Si les appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou avec un écran supplémentaire intégré, ils:

• [C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un mécanisme 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 prennent en charge les applications tierces de l'éditeur de mode de saisie (IME) :

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.software.input_methods.
• [C-1-2] DOIT implémenter intégralement Input Management Framework
• [C-1-3] DOIT disposer d'un clavier virtuel préinstallé.

Implémentations d'appareils: * [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches). * DEVRAIT inclure d'autres implémentations de clavier virtuel. * PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, le trackball et la molette comme mécanismes de navigation non tactile.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

• [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils dépourvus d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour généralement accessibles via une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils:

• [C-0-1] DOIT fournir une affordance utilisateur pour lancer des applications installées dont l'activité a les valeurs <intent-filter> définies avec ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations de téléviseurs. La fonction Accueil DOIT être le mécanisme de cette affordance utilisateur.
• DEVRAIT fournir des boutons pour les fonctions "Récents" et "Retour".

Si les fonctions "Accueil", "Récents" ou "Retour" sont fournies, elles:

• [C-1-1] DOIT être accessible en une seule action (appui, double-clic ou geste, par exemple) lorsque l'un de ces éléments est accessible.
• [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Il peut s'agir, par exemple, d'une icône visible imprimée sur le bouton, d'une icône de logiciel dans la partie de la barre de navigation de l'écran ou d'une démonstration guidée qui guide l'utilisateur pendant la configuration initiale.

Implémentations pour les appareils:

• Il est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme d'entrée pour la fonction de menu, car elle a été abandonnée au profit de la barre d'action depuis Android 4.0.

Si les implémentations d'appareils intègrent la fonction Menu, celles-ci:

• [C-2-1] DOIT afficher le bouton à développer d'actions chaque fois que la fenêtre pop-up du menu à développer d'actions n'est pas vide et que la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position du pop-up de dépassement d'action affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher la fenêtre pop-up de dépassement d'action à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils n'offrent pas la fonction Menu, pour assurer la rétrocompatibilité, elles:

• [C-3-1] DOIT mettre la fonction Menu à la disposition des applications lorsque la valeur de targetSdkVersion est inférieure à 10, que ce soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction Menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils intègrent la fonction d'assistance, elles:

• [C-4-1] DOIT rendre la fonction d'assistance accessible en une seule action (appui, double-clic ou geste, par exemple) lorsque d'autres touches de navigation sont accessibles.
• [SR] FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction HOME pour cette interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:

• [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas accessible aux applications et NE DOIVENT PAS masquer la partie de l'écran accessible aux applications ni gêner leur fonctionnement.
• [C-5-2] DOIT mettre une partie de l'écran à la disposition des applications répondant 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(), de sorte que cette partie distincte de l'écran (la barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

Si la fonction de navigation est fournie sous la forme d'une action à l'écran basée sur un geste:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() NE DOIT être utilisé que pour signaler la zone de reconnaissance des gestes de la page d'accueil.
• [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application au premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale, comme indiqué dans la documentation pour View#setSystemGestureExclusionRects().
• [C-6-3] DOIT envoyer à l'application au premier plan un événement MotionEvent.ACTION_CANCEL une fois que des gestes commencent à être interceptés par un geste système, si l'application au premier plan a déjà envoyé un événement MotionEvent.ACTION_DOWN.
• [C-6-4] DOIT fournir une affordance à l'utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
• DEVRAIT fournir la fonction d'accueil en balayant l'écran vers le haut à partir du bord inférieur de l'orientation actuelle de l'écran.
• DEVRAIT fournir la fonctionnalité "Récents" : balayez l'écran vers le haut et maintenez la pression avant de relâcher, depuis la même zone que pour le geste d'accueil.
• Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application au premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est disponible sur les bords gauche et droit de l'orientation actuelle de l'écran:

• [C-7-1] La fonction de navigation DOIT être "Retour" et être fournie sous 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 à faire glisser personnalisés sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante que le fait de faire glisser l'écran appellera les panneaux mentionnés ci-dessus, et non "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se retrouve sous le tiers supérieur des bords de l'écran, mais il NE DOIT PAS utiliser plus d'un tiers des bords.
• [C-7-3] Lorsque les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY sont définis pour l'application au premier plan, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, comme indiqué dans le SDK.
• [C-7-4] Lorsque les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY sont définis pour l'application au premier plan, les panneaux système à faire glisser personnalisés DOIVENT être masqués jusqu'à ce que l'utilisateur affiche les barres système (c'est-à-dire la barre de navigation et d'état) comme implémenté dans AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes de saisie de pointeur, tels que les écrans tactiles, les pavés tactiles et les faux dispositifs de saisie tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune affordance supplémentaire pour indiquer les objets manipulés.

Implémentations pour les appareils:

• DEVRAIT disposer d'un système de saisie de type pointeur (comme une souris ou tactile).
• DEVRAIT prendre en charge les pointeurs suivis de manière totalement indépendante.

Si les appareils comprennent un écran tactile (tactile ou supérieur) sur un écran principal compatible avec Android:

• [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
• [C-1-2] DOIT signaler les flags de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils comprennent un écran tactile permettant de suivre plusieurs pressions sur un écran principal compatible avec Android, celles-ci:

• [C-2-1] DOIT indiquer les flags 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 nécessitent l'utilisation d'un périphérique d'entrée externe tel qu'une souris ou un trackball (c'est-à-dire qu'elles ne touchent pas directement l'écran) pour la saisie sur un écran principal compatible avec Android et répondent aux exigences de la section 7.2.5 concernant l'écran tactile artificiel:

• [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen.
• [C-3-2] DOIT signaler uniquement android.hardware.faketouch.
• [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

Saisie tactile simulée

L'interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités de l'écran tactile. Par exemple, une souris ou une télécommande qui dirige un curseur à l'écran se rapproche d'un toucher tactile, mais oblige l'utilisateur à pointer ou à sélectionner une option, puis à cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris gyroscopique, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante android.hardware.faketouch, qui correspond à un périphérique d'entrée haute fidélité non tactile (basé sur un pointeur), tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base). L'appareil indique que l'appareil est compatible avec un sous-ensemble émulé de fonctionnalités tactiles.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie de pointeur qu'elles souhaitent proposer, elles:

• DEVRAIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch, elles:

• [C-1-1] DOIT indiquer les positions X et Y absolues de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• [C-1-2] DOIT signaler l'événement tactile avec le code d'action spécifiant le changement d'état qui se produit sur le pointeur descendant ou remontant l'écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le haut et le bas sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• [C-1-4] DOIT prendre en charge les pointeurs vers le bas, vers le haut, vers le bas, puis vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler le double appui sur un objet à l'écran.
• [C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un déplacement tactile.
• [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de le pointer vers le haut, ce qui permet aux utilisateurs de faire glisser un objet sur l'écran.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.distinct, elles:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT prendre en charge le suivi distinct d'au moins deux entrées de pointeur indépendantes.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.jazzhand, elles:

• [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-3-2] DOIT prendre en charge un suivi distinct de 5 (suivi d'une main des doigts) ou plus d'entrées de pointeur de manière entièrement indépendante.

Compatibilité avec les manettes de jeu

Mappages de boutons

Implémentations pour les appareils:

• [C-1-1] DOIT être capable de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent une manette ou sont livrées avec une manette distincte dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:

• [C-2-1] DOIT déclarer le flag de fonctionnalité android.hardware.gamepad

Bouton	Utilisation HID2	Bouton Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0 x 09, 0 x 0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
O1	0x09 0x0005	KEYCODE_BOUTON_Y (100)
Pavé directionnel vers le haut1 Pavé directionnel descendant1	0x01 0x00393	AXIS_HAT_Y4
Pavé directionnel gauche1 Pavé directionnel droit1	0x01 0x00393	AXIS_HAT_X4
Bouton de l'épaule gauche1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1	0x09 0x0008	KEYCODE_BOUTON_R1 (103)
Clic gauche1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Effectuer un clic avec le stick droit1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Accueil1	0x0c 0x0223	KEYCODE_HOME (3)
Retour1	0x0c 0x0224	KEYCODE_BACK (4)

1 Événement clé

2 Les utilisations HID ci-dessus doivent être déclarées dans une manette de jeu CA (0x01 0x0005).

3 Cette utilisation doit avoir un minimum logique de 0, un maximum logique de 7, un minimum physique de 0, un maximum physique de 315, une unité en degrés et une taille de rapport de 4. La valeur logique est définie comme une rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et le bouton vers le haut que l'utilisateur appuie, tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et une pression sur les touches haut et gauche.

4 MotionEvent

Commandes analogiques1	Utilisation HID	Bouton Android
Gâchette gauche	0x02, 0x00C5	AXIS_LTRIGGER
Déclencheur droit	0x02, 0x00C4	AXIS_RTRIGGER
Joystick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API, comme décrit dans la documentation du SDK Android et dans la documentation Android Open Source sur les capteurs.

Implémentations pour les appareils:

• [C-0-1] DOIT 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 SensorManager.getSensorList() et des méthodes similaires.
• [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteur (par exemple, en renvoyant true ou false selon les cas, lorsque les applications tentent d'enregistrer des écouteurs, et non en les appelant lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles:

• [C-1-1] DOIT indiquer toutes les mesures de capteurs en utilisant les valeurs du système international d'unités (métriques) pertinentes pour chaque type de capteur, tel que défini dans la documentation du SDK Android.
• [C-1-2] DOIT transmettre les données de capteurs avec une latence maximale de 100 millisecondes + 2 * "sample_time" dans le cas d'un flux de capteurs dont la latence maximale demandée est de 0 ms lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT indiquer le premier échantillon du capteur dans un délai de 400 millisecondes + 2 x échantillon_temps du capteur en cours d'activation. La justesse de cet échantillon peut être égale à 0.
• [C-1-4] Pour que toute API indiquée dans la documentation du SDK Android soit un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques qui DOIVENT présenter une gigue inférieure à 3 %. La gigue est définie comme l'écart type de la différence des valeurs d'horodatage signalées entre des événements consécutifs.
• [C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer à l'état "suspendu" ou de sortir de l'état "suspendu".
• [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes telle que définie dans la documentation du SDK Android, qui représente l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano().
• [C-SR] Il est FORTEMENT RECOMMANDÉ que l'erreur de synchronisation du code temporel soit inférieure à 100 millisecondes, et DOIT présenter une erreur de synchronisation de l'horodatage inférieure à 1 milliseconde.
• Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie rapportée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et la documentation Android Open Source concernant les capteurs doivent faire autorité.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles:

• [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler cette valeur via la méthode API Sensor.getResolution().

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations pour les appareils:

• DEVRAIT mettre en œuvre ces types de capteurs s'ils incluent des capteurs physiques préalables, comme décrit dans la section Types de capteurs.

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

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Android Open Source sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers et que le capteur ne signale qu'une seule valeur, les implémentations d'appareils:

• [C-3-1] DOIT définir la résolution sur 1 pour le capteur et signaler cette valeur via la méthode API Sensor.getResolution().

Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé à des développeurs tiers, celles-ci:

• [C-4-1] NE DOIT PAS inclure de paramètres d'étalonnage fixes définis en usine dans les données fournies.

Si les implémentations d'appareils comprennent une combinaison d'accéléromètre à 3 axes, d'un gyroscope à 3 axes ou d'un capteur magnétomètre, les deux sont:

• [C-SR] FORTEMENT RECOMMANDÉ de veiller à ce que l'accéléromètre, le gyroscope et le magnétomètre aient une position relative fixe, de sorte que si l'appareil peut être transformé (par exemple, un appareil pliable), les axes du capteur restent alignés et cohérents avec le système de coordonnées du capteur, quel que soit l'état de transformation de l'appareil.

7.3.1. Accéléromètre

Implémentations pour les appareils:

• [C-SR] 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 à 3 axes, ils:

• [C-1-1] DOIT pouvoir signaler des événements avec 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 du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT être capable de mesurer à partir de la chute libre jusqu'à quatre fois la gravité(4g) ou plus sur n'importe quel axe.
• [C-1-5] DOIT avoir une résolution d'au moins 12 bits.
• [C-1-6] DOIT avoir un écart type inférieur à 0,05 m/s^, où l'écart type doit être calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• Les [SR] sont fortement recommandés pour implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
• Il est FORTEMENT RECOMMANDÉ d'ajouter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est FORTEMENT RECOMMANDÉ de répondre à cette exigence sur les appareils Android afin qu'ils puissent passer à la prochaine version de la plate-forme, qui pourrait devenir OBLIGATOIRE.
• DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DEVRAIT avoir une résolution d'au moins 16 bits.
• DOIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et sont compensées, et conservez les paramètres de compensation entre les redémarrages de l'appareil.
• DEVRAIT être compensé en température.

Si les implémentations d'appareils incluent un accéléromètre à 3 axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER est implémenté:

• [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DEVRAIT être inférieure à 2 mW et à 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les appareils comprennent un accéléromètre à 3 axes et un gyroscope à 3 axes, ils:

• [C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Si les appareils comprennent un accéléromètre à 3 axes, un gyroscope à 3 axes et un magnétomètre, ils:

• [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à 3 axes.

Si les implémentations d'appareils incluent un magnétomètre à 3 axes, ils:

• [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
• [C-1-2] DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DOIT rapporter des événements dont la fréquence est d'au moins 50 Hz.
• [C-1-3] DOIT respecter le système de coordonnées du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT pouvoir mesurer entre -900 μT et +900 μT sur chaque axe avant la saturation.
• [C-1-5] DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et une valeur inférieure à 200 μT, en plaçant le magnétomètre éloigné des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
• [C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 μT.
• [C-1-7] DOIT prendre en charge l'étalonnage et la compensation en ligne du biais du fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] DOIT appliquer la compensation du fer doux. L'étalonnage peut être effectué en cours d'utilisation ou pendant la production de l'appareil.
• [C-1-9] DOIT avoir un écart type, calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes au taux d'échantillonnage le plus rapide, ne dépassant pas 1,5 μT ; DOIT avoir un écart type inférieur à 0,5 μT.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si les appareils comprennent un magnétomètre à 3 axes, un capteur d'accéléromètre et un gyroscope à 3 axes, ils:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils comprennent un magnétomètre à 3 axes (un accéléromètre), ils:

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles:

• [C-3-1] DOIT consommer moins de 10 mW.
• DEVRAIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode de traitement par lot à 10 Hz.

7.3.3. GPS

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un récepteur GPS/GNSS.

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

• [C-1-1] DOIT prendre en charge les sorties de localisation à un taux d'au moins 1 Hz lorsqu'il est demandé via LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être capable de déterminer la position en ciel ouvert (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (délai rapide pour la première correction), lorsque la connexion Internet est d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une certaine forme de technique GPS/GNSS assistée ou prévue pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance comprennent l'heure de référence, l'emplacement de référence et les éphémères du satellite/l'horloge).
  • [C-1-6] Une fois ce calcul de localisation effectué, les appareils DOIVENT déterminer leur position, en ciel ouvert, dans un délai de cinq secondes lorsque les demandes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même si la demande suivante est effectuée sans connexion de données et/ou après un redémarrage.

• En ciel ouvert, après avoir déterminé la position, lorsque vous êtes à l'arrêt ou que vous vous déplacez avec un carré d'accélération inférieur à 1 mètre par seconde:

  • [C-1-3] DOIT pouvoir déterminer la position dans un rayon de 20 mètres et la vitesse dans un rayon de 0, 5 mètre par seconde, au moins 95% du temps.
  • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une même constellation.
  • DEVRAIT pouvoir suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, le GPS + au moins un satellite de Glonass, Beidou ou Galileo).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des données de localisation GPS/GNSS normales via l'API du fournisseur de localisation GNSS lors d'un appel téléphonique d'urgence.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de créer un rapport sur les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception des SBAS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les rapports AGC et Fréquence des mesures GNSS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de transmettre toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de transmettre les mesures GNSS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-plages GNSS et les taux de pseudo-plage qui, dans des conditions de ciel ouvert après avoir déterminé la position, sont immobiles ou se déplacent avec un carré d'accélération inférieur à 0,2 mètre par seconde (au carré) pour calculer la position à 20 mètres et la vitesse à 0,2 mètre par seconde, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscope.

Si les implémentations d'appareils comprennent un gyroscope à 3 axes, ils:

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter le capteur TYPE_GYROSCOPE. Il est FORTEMENT RECOMMANDÉ d'implémenter également le capteur TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-4] DOIT avoir une résolution de 12 bits ou plus et DEVRAIT avoir une résolution de 16 bits ou plus.
• [C-1-5] DOIT être compensé en température.
• [C-1-6] DOIT être calibré et compensé en cours d'utilisation, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du taux d'échantillonnage, mais DOIT être contrainte par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à un taux d'échantillonnage de 1 Hz, il DOIT ne pas être supérieur à 1e-7 rad^2/s^2.
• [SR] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

Si les appareils comprennent un gyroscope à 3 axes, un accéléromètre et un magnétomètre, ils:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils comprennent un accéléromètre à 3 axes et un gyroscope à 3 axes, ils:

• [C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Baromètre

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression de l'air ambiant).

Si les implémentations d'appareils comprennent un baromètre, celles-ci:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT pouvoir diffuser des événements avec une fréquence de 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [SR] FORTEMENT RECOMMANDÉ de pouvoir indiquer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
• DEVRAIT avoir une précision absolue de 1 hPa.
• DEVRAIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalant à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les appareils sont équipés d'un thermomètre ambiant (capteur de température), ils:

• [C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température ambiante, et celui-ci DOIT mesurer la température ambiante (de la pièce/l'habitacle du véhicule) à partir de laquelle l'utilisateur interagit avec l'appareil, en degrés Celsius.

Si les appareils sont équipés d'un capteur thermomètre qui mesure une température autre que la température ambiante, telle que la température de l'UC:

• [C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

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é, ils:

• [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, celui-ci NE DOIT PAS être accessible via cette API.
• [C-1-2] DOIT avoir une précision d'au moins 1 bit.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité (tel que défini dans cette section) et les mettent à la disposition des applications tierces, elles:

• [C-1-1] DOIT identifier la capacité via l'indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

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

• [C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui:

  • DOIT avoir une plage de mesure comprise entre -8 g et +8 g, et il est FORTEMENT RECOMMANDÉ d'avoir une plage de mesure comprise entre -16 g et +16 g.
  • DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 3 mW.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de 3 dB correspondant à au moins 80% de la fréquence de Nyquist et d'un spectre de bruit blanc dans cette bande passante.
  • DEVRAIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg/°C.
  • DOIT présenter une non-linéarité ≤ 0,5 % de la courbe la plus adaptée et une variation de la sensibilité par rapport à la température de ≤ 0,03%/C°.
  • DEVRAIT avoir une sensibilité transversale inférieure à 2,5 % et une variation de la sensibilité de l'axe transversal < 0,2% dans la plage de températures de fonctionnement de l'appareil.

• [C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.

• [C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui:

  • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps.
  • DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de 3 dB correspondant à au moins 80% de la fréquence de Nyquist et d'un spectre de bruit blanc dans cette bande passante.
  • DEVRAIT avoir un taux de marche aléatoire inférieur à 0,001 °/s √Hz testé à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
  • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
  • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
  • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
  • L'erreur d'étalonnage DOIT être inférieure à 0,002 rad/s dans une plage de températures comprise entre 10 et 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité g DOIT être inférieure à 0,1°/s/g.
  • DEVRAIT avoir une sensibilité transversale inférieure à 4,0 % et une variation de sensibilité transversale inférieure à 0,3% dans la plage de températures de fonctionnement de l'appareil.

• [C-2-4] DOIT comporter un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.

• [C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui:

  • DOIT avoir une plage de mesure comprise entre -900 et +900 μT.
  • DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
  • DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
  • DOIT présenter un bruit de mesure inférieur à 0,5 uT.

• [C-2-6] DOIT comporter un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que l'TYPE_GEOMAGNETIC_FIELD et en plus:

  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence de signalement est supérieure ou égale à 50 Hz.

• [C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui:

  • La plage de mesure DOIT être comprise entre 300 et 1 100 hPa au minimum.
  • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
  • DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 2 mW.
• [C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui :
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
• [C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-13] L'horodatage du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT se situer à moins de 2, 5 millisecondes l'un de l'autre. L'horodatage du même événement physique signalé par l'accéléromètre et le gyroscope DOIT se situer à 0,25 milliseconde l'un de l'autre.
• [C-2-14] DOIT disposer d'horodatages des événements du capteur du gyroscope sur la même base de temps que le sous-système de l'appareil photo, avec un écart d'une milliseconde près.
• [C-2-15] DOIT fournir des échantillons aux applications dans un délai de 5 millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus à l'application.
• [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsque l'appareil est en mouvement lorsque l'une des combinaisons des capteurs suivants est activée :
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PEUT disposer d'un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT disposer d'une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que l'ensemble des exigences de consommation d'énergie indiquées dans cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle inclut la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits connexes, système de traitement dédié des capteurs, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, celles-ci:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du taux de signalement direct via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
• [C-3-2] DOIT être compatible avec au moins l'un des deux types de canaux directs des capteurs pour tous les capteurs déclarant être compatibles avec le canal direct du capteur.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVRAIT accepter les rapports d'événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations d'appareils comprennent un écran de verrouillage sécurisé:

• DEVRAIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés dans les catégories Classe 3 (anciennement Forte), Classe 2 (anciennement Faible) ou Classe 1 (anciennement Commodité) en fonction de leur taux d'acceptation de spoofing et d'imposteurs, et en fonction de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique pour communiquer avec la plate-forme et les applications tierces. Les capteurs sont classés par défaut dans la classe 1 et doivent répondre aux exigences supplémentaires décrites ci-dessous s'ils souhaitent être classés dans la classe 2 ou la classe 3. Les biométries de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Si les implémentations d'appareils mettent un capteur biométrique à disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, les actions suivantes seront effectuées:

• [C-4-1] DOIT répondre aux exigences biométriques de classe 3 ou 2, telles que définies dans le présent document.
• [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans la classe Authenticators et toute combinaison de ces noms. Inversement, il NE DOIT PAS respecter ni reconnaître des constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de ces valeurs.
• [C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils utilisant la biométrie de classe 3 ou de classe 2. Cette action DOIT présenter uniquement les points d'entrée d'enregistrement pour la biométrie de classe 3 ou de classe 2.

Si les implémentations d'appareils prennent en charge la biométrie passive, elles:

• [C-5-1] DOIT exiger par défaut une étape de confirmation supplémentaire (appuyer sur un bouton, par exemple).
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et de toujours exiger une étape de confirmation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation de sorte qu'un système d'exploitation ou un noyau compromis ne puisse pas en usurper l'identité. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée uniquement) d'un élément sécurisé (SE) qui ne peut être pilotée 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 configurer pour les flux de connexion.

Si les appareils disposent de plusieurs capteurs biométriques, ils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'exiger qu'une seule authentification biométrique soit confirmée par authentification (par exemple, si les capteurs d'empreinte digitale et de visage sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé une fois que l'un d'eux est confirmé).

Pour que les implémentations d'appareils autorisent l'accès aux clés keystore d'applications tierces, les exigences suivantes sont respectées:

• [C-6-1] DOIT respecter les exigences de la classe 3, telles que définies dans la section ci-dessous.
• [C-6-2] DOIT présenter uniquement des données biométriques de classe 3 lorsque l'authentification nécessite BIOMETRIC_STRONG ou que l'authentification est appelée avec un CryptoObject.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 1 (anciennement facilité), procédez comme suit:

• [C-1-1] DOIT avoir un taux de faux acceptations inférieur à 0,002%.
• [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, schéma ou mot de passe sécurisés, et énumérer clairement les risques liés à son activation si les taux d'acceptation de spoofing et d'imposteurs sont supérieurs à 7% selon les protocoles de test biométrique Android.
• [C-1-3] DOIT limiter le taux de tentatives pendant au moins 30 secondes après cinq faux essais de validation biométrique, c'est-à-dire un faux essai dont la qualité de capture (BIOMETRIC_ACQUIRED_GOOD) ne correspond pas à une biométrie enregistrée.
• [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer des identifiants existants ou d'ajouter de nouveaux identifiants d'appareil (code/schéma/mot de passe) sécurisés par TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour le faire.
• [C-1-5] DOIT supprimer complètement toutes les données biométriques permettant d'identifier l'utilisateur en cas de suppression de son compte (y compris en cas de rétablissement de la configuration d'usine).
• [C-1-6] DOIT respecter l'indicateur individuel de cette biométrie (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] DOIT demander à l'utilisateur l'authentification principale recommandée (code, schéma ou mot de passe, par exemple) toutes les 24 heures maximum pour les nouveaux appareils équipés d'Android 10, ou toutes les 72 heures ou moins pour les appareils mis à jour à partir d'une version antérieure d'Android.

• [C-1-8] DOIT demander à l'utilisateur de procéder à l'authentification principale recommandée (code, schéma ou mot de passe, par exemple) après l'une des actions suivantes :

  • un délai d'inactivité de quatre heures, OU
  • 3 tentatives d'authentification biométrique ayant échoué.
  • Le délai d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après n'importe quelle confirmation des identifiants de l'appareil.

  La mise à niveau d'appareils à partir d'une version antérieure d'Android peut être exemptée des règles C-1-8. * [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source afin d'appliquer les contraintes spécifiées dans les [C-1-7] et [C-1-8] pour les nouveaux appareils. * [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir un taux de faux rejets inférieur à 10%, tel que mesuré sur l'appareil. * [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée entre le moment où les données biométriques sont détectées et le déverrouillage de l'écran, pour chaque empreinte biométrique enregistrée.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 2 (anciennement Faible), procédez comme suit:

• [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.
• [C-2-2] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 20 %, tel que mesuré par les protocoles de test biométrique Android.
• [C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du noyau Android, tel que l'environnement d'exécution sécurisé (TEE), ou sur une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé.
• [C-2-4] DOIT faire en sorte que toutes les données identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site du projet Open Source Android.
• [C-2-5] Pour la biométrie basée sur l'appareil photo, alors que l'enregistrement ou l'authentification biométrique sont en cours :
  • DOIT utiliser la caméra dans un mode qui empêche la lecture ou la modification des trames de caméra en dehors de l'environnement d'exécution isolé, ou une puce dotée d'un canal sécurisé vers l'environnement d'exécution isolé.
  • Pour les solutions RVB à caméra unique, les images des caméras PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour permettre des opérations telles que l'aperçu pour l'enregistrement, mais elles NE DOIVENT EN AUCUN CAS être modifiables.
• [C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction entre les enregistrements biométriques individuels.
• [C-2-7] NE DOIT PAS permettre au processeur d'application d'accéder de manière non chiffrée à des données biométriques permettant d'identifier l'utilisateur ni à toute donnée qui en est dérivée (comme les représentations vectorielles continues) en dehors du contexte du TEE.

• [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé, de sorte qu'un piratage du système d'exploitation ou du noyau ne permette pas l'injection directe de données pour s'authentifier à tort en tant qu'utilisateur.

  Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre à l'exigence C-2-8 par le biais d'une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence.

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de l'activité pour toutes les modalités biométriques et la détection de l'attention pour la biométrie du visage.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 3 (anciennement Strong), elles:

• [C-3-1] DOIT respecter toutes les exigences de la classe 2 ci-dessus, à l'exception des [C-1-7] et [C-1-8]. La mise à niveau d'appareils à partir d'une version antérieure d'Android n'est pas exemptée de l'obligation de contrôle C-2-7.
• [C-3-2] DOIT disposer d'une implémentation de keystore intégré au matériel.
• [C-3-3] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 7 %, tel que mesuré par les protocoles de test biométrique Android.
• [C-3-4] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (code, schéma, mot de passe, etc.) toutes les 72 heures au maximum.

7.3.12. Capteur de postures

Implémentations pour les appareils:

• PEUT prendre en charge les capteurs de position avec 6 degrés de liberté.

Si les implémentations d'appareils prennent en charge les capteurs de position à 6 degrés de liberté, ils:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
• [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.13. Capteur d'angle de charnière

Si les appareils sont compatibles avec un capteur d'angle de charnière:

• [C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
• [C-1-2] DOIT prendre en charge au moins deux mesures comprises entre 0 et 360 degrés (inclus, c'est-à-dire 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 permettant de passer des appels vocaux et d'envoyer des SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés de paquets, ils sont destinés aux besoins d'Android et sont considérés comme étant indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité de téléphonie et les API Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir des SMS ne sont pas considérées comme des appareils de téléphonie, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

• Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel téléphonique. Autrement dit, Android est compatible avec les appareils autres que les téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, ils:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony et d'autres sous-indicateurs de fonctionnalité en fonction de la technologie concernée.
• [C-1-2] DOIT mettre en œuvre la compatibilité totale de l'API avec cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie:

• [C-2-1] DOIT implémenter les API complètes en tant que no-ops.

Si les implémentations d'appareils prennent en charge les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant de rendre la fonctionnalité eSIM disponible pour les développeurs tiers:

• [C-3-1] DOIT fournir une implémentation complète de EuiccManager API.

Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure une fonctionnalité de blocage de numéros
• [C-1-2] DOIT implémenter intégralement 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 figurant dans "BlockedNumberProvider" sans aucune interaction avec les applications. Seule exception : le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
• [C-1-4] NE DOIT PAS écrire dans le 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 interface utilisateur 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 d'afficher 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. Toutes les interfaces utilisateur liées au blocage DOIVENT être masquées pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT quand même être respectées.
• DEVRAIT transférer les numéros bloqués vers le fournisseur lorsqu'un appareil passera à Android 7.0.

API Telecom

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

• [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir une affordance à l'utilisateur pour accepter ou rejeter l'appel entrant lorsqu'il est en cours d'appel effectué par une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
• [C-1-3] DOIT disposer d'une application qui implémente InCallService.

• [C-SR] SONT FORTEMENT RECOMMANDÉS d'informer l'utilisateur que l'appel en cours sera interrompu.

  L'implémentation d'AOSP répond à ces exigences par une notification prioritaire qui indique à l'utilisateur que le fait de répondre à un appel entrant entraînera l'interruption de l'autre appel.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de précharger l'application de téléphonie par défaut, qui affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels lorsque l'application tierce définit la touche "Extras" EXTRA_LOG_SELF_MANAGED_CALLS sur son PhoneAccount sur true.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom, comme indiqué ci-dessous :
  • Appelez Connection.onDisconnect() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel en cours.
  • Appelez Connection.onAnswer() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel entrant.
  • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté pendant un appel entrant.
  • Activer/Désactiver le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils sont compatibles avec la norme 802.11 et exposent la fonctionnalité à une application tierce, celles-ci:

• [C-1-1] DOIT implémenter l'API Android correspondante.
• [C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.wifi.
• [C-1-3] DOIT implémenter l'API de multidiffusion comme décrit dans la documentation du SDK.
• [C-1-4] DOIT prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de l'opération, y compris dans les cas suivants :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même lorsqu'elles sont en veille.
• [C-1-5] NE DOIT PAS traiter l'appel de méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif utilisé par défaut pour le trafic de l'application et renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils ne peuvent désactiver l'accès Internet fourni par tout autre fournisseur de réseau (données mobiles, par exemple) que s'ils valident que le réseau Wi-Fi fournit l'accès à Internet.
• [C-1-6] Il est FORTEMENT RECOMMANDÉ de réévaluer l'accès à Internet sur le Network lorsque la méthode API ConnectivityManager.reportNetworkConnectivity() est appelé et, une fois que l'évaluation détermine que le Network actuel ne fournit plus d'accès à Internet, de passer à tout autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source et le nombre de trames des demandes de vérification, une fois au début de chaque analyse, lorsque la STA est déconnectée.
  • Chaque groupe de trames de demande de vérification comprenant une analyse doit utiliser une adresse MAC cohérente (NE DEVRAIT PAS randomiser l'adresse MAC au milieu de l'analyse).
  • Le numéro de séquence des requêtes de vérification doit itérer normalement (de manière séquentielle) entre les demandes de vérification d'une analyse.
  • Le numéro de séquence de la demande de vérification doit être aléatoire entre la dernière demande de vérification d'une analyse et la première demande de vérification de l'analyse suivante.
• [C-SR] SONT FORTEMENT RECOMMANDÉS, lorsque la STA est déconnectée, pour n'autoriser que les éléments suivants dans les trames de requête de vérification :
  • Ensemble de paramètres SSID (0)
  • Ensemble de paramètres DS (3)

Si les implémentations d'appareils sont compatibles avec le mode Économie d'énergie Wi-Fi, tel que défini dans la norme IEEE 802.11, ils:

• [C-3-1] DOIT désactiver le mode Économie d'énergie Wi-Fi chaque fois qu'une application acquiert un verrou WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire() et que le verrouillage est actif.
• [C-3-2] La latence moyenne aller-retour entre l'appareil et un point d'accès lorsque l'appareil est en mode de verrouillage Wi-Fi à faible latence (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] Il est FORTEMENT RECOMMANDÉ de minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrouillage à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et qu'il prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour rechercher la position, ils:

• [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API WifiManager.isScanAlwaysAvailable.

Wi-Fi Direct

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les appareils sont compatibles avec le Wi-Fi Direct, ils:

• [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
• [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• [C-1-3] DOIT être compatible avec le fonctionnement Wi-Fi standard.
• [C-1-4] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Direct simultanément.

7.4.2.2. Configuration du lien direct par tunneling en Wi-Fi

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la configuration TDLS (Wi-Fi Tunneled Direct Link Setup), comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils sont compatibles avec le TDLS et que TDLS est activé par l'API WiFiManager, ils:

• [C-1-1] DOIT déclarer la prise en charge du TDLS via WifiManager.isTdlsSupported.
• DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
• DEVRAIT utiliser une heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pires que de passer par le point d'accès Wi-Fi.

Wi-Fi Aware

Implémentations pour les appareils:

• DEVRAIT inclure la compatibilité avec Wi-Fi Aware.

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

• [C-1-1] DOIT implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.aware.
• [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
• [C-1-4] DOIT appliquer de manière aléatoire l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure des distances Aware est en cours ou qu'un chemin de données Aware est actif (la randomisation n'est pas attendue tant que le chemin de données est actif).

Si les implémentations d'appareils incluent la prise en charge du service Wi-Fi Aware et de la localisation via le Wi-Fi, comme décrit dans la section 7.4.2.5, et que ces fonctionnalités sont exposées à des applications tierces, les mesures suivantes seront prises:

• [C-2-1] DOIT implémenter les API de découverte avec détection de la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Implémentations pour les appareils:

• DEVRAIT prendre en charge Wi-Fi Passpoint.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Passpoint, elles:

• [C-1-1] DOIT implémenter les API WifiManager liées à Passpoint, comme décrit dans la documentation du SDK.
• [C-1-2] DOIT être compatible avec la norme IEEE 802.11u, spécifiquement liée à la découverte et à la sélection de réseaux, comme le service publicitaire générique (GAS) et le protocole de requête réseau d'accès (ANQP).

À l'inverse, si les implémentations d'appareils n'incluent pas la prise en charge du point d'accès Wi-Fi:

• [C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.

Emplacement du Wi-Fi (délai aller-retour Wi-Fi - DAR)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la localisation Wi-Fi.

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent cette fonctionnalité à des applications tierces, ils:

• [C-1-1] DOIT implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
• [C-1-3] DOIT attribuer de manière aléatoire l'adresse MAC source pour chaque rafale de DAR exécuté, tandis que l'interface Wi-Fi sur laquelle le DAR s'exécute n'est pas associée à un point d'accès.

7.4.2.6. Déchargement Wi-Fi Keepalive

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du déchargement Wi-Fi keepalive.

Si les implémentations d'appareils prennent en charge le déchargement du message keepalive Wi-Fi et exposent cette fonctionnalité à des applications tierces, elles:

• [C-1-1] DOIT prendre en charge l'API SocketKeepAlive.

• [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés sur le Wi-Fi et au moins un emplacement keepalive sur le réseau mobile.

Si les implémentations d'appareils ne prennent pas en charge le déchargement du message keepalive Wi-Fi, ils:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement des appareils)

Implémentations pour les appareils:

• DEVRAIT être compatible avec Wi-Fi Easy Connect (DPP).

Si les implémentations d'appareils prennent en charge la fonctionnalité Wi-Fi Easy Connect et exposent cette fonctionnalité à des applications tierces, celles-ci:

• [C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer true.

7.4.3. Bluetooth

Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

• DEVRAIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec les protocoles HFP, A2DP et AVRCP:

• DEVRAIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareils déclarent la fonctionnalité android.hardware.vr.high_performance, elles:

• [C-1-1] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations d'appareils prennent en charge les technologies Bluetooth et Bluetooth à basse consommation:

• [C-2-1] DOIT déclarer les fonctionnalités pertinentes de la plate-forme (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de la plate-forme.
• DEVRAIT implémenter les profils Bluetooth appropriés, tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations d'appareils sont compatibles avec la technologie BLE (Bluetooth basse consommation), elles:

• [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• [C-3-2] DOIT activer les API Bluetooth basées sur un profil d'attribut générique, comme décrit dans la documentation du SDK et dans le fichier android.bluetooth.
• [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() pour indiquer si la logique de filtrage des classes d'API ScanFilter est mise en œuvre.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() pour indiquer si la publicité à basse consommation est acceptée.
• [C-3-5] DOIT mettre en œuvre un délai avant expiration de l'adresse privée résolvable (RPA, Resolvable Private Address) de 15 minutes maximum et effectuer une rotation de l'adresse une fois le délai expiré afin de protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement la technologie BLE pour l'analyse ou la publicité. Pour éviter les attaques chronophages, les intervalles d'expiration DOIVENT également être aléatoires entre 5 et 15 minutes.
• DEVRAIT accepter le déchargement de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
• DEVRAIT permettre le déchargement de la recherche par lot sur le chipset Bluetooth.
• DEVRAIT prendre en charge les annonces multiples comportant au moins 4 emplacements.

Si les implémentations d'appareils prennent en charge la technologie Bluetooth LE et l'utilisent pour la détection de la position, celles-ci:

• [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via le BluetoothAdapter.isBleScanAlwaysAvailable() de l'API système.

Si les implémentations d'appareils incluent la compatibilité avec la technologie Bluetooth LE et le profil d'appareils auditifs, comme décrit dans la section Prise en charge de l'audio des appareils auditifs via la technologie Bluetooth LE:

• [C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, Listen, BluetoothProfile.HEARING_AID).

7.4.4. Communication en champ proche

Implémentations pour les appareils:

• DEVRAIT inclure un émetteur-récepteur et le matériel associé pour la technologie NFC (communication en champ proche).
• [C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord même si elles n'incluent pas la compatibilité NFC ou si elles ne déclarent pas la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation de données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le rendre disponible pour les applications tierces:

• [C-1-1] DOIT signaler la caractéristique android.hardware.nfc à l'aide de la méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes:
• [C-1-2] DOIT être capable d'agir en tant que lecteur/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • ISO Dep (ISO 14443-4)
  • Types de tags du forum NFC 1, 2, 3, 4, 5 (définis par le forum NFC)

• [SR] VIVEMENT RECOMMANDÉ de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Remarque : bien que les normes NFC soient indiquées comme étant FORTEMENT RECOMMANDÉES, il est prévu qu'elles soient remplacées par une OBLIGATION dans la définition de compatibilité d'une prochaine version. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les futures versions. Les appareils nouveaux et existants qui exécutent cette version d'Android sont vivement encouragés à respecter ces exigences dès maintenant afin de pouvoir effectuer la mise à niveau vers les futures versions de la plate-forme.

• [C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.

• DOIT être en mode de détection NFC lorsque l'appareil est activé, avec l'écran actif et l'écran de verrouillage déverrouillé.
• DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) des produits code-barres NFC Thinfilm.

Notez que les liens accessibles au public ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum mentionnées ci-dessus.

Android est compatible avec le mode HCE (émulation de carte hôte NFC).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage des ID d'application (AID), elles:

• [C-2-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hce.
• [C-2-2] DOIT être compatible avec les API NFC HCE, telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent cette fonctionnalité pour des applications tierces:

• [C-3-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de cartes NFC telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent une compatibilité NFC générale comme décrit dans cette section et sont compatibles avec les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/rédacteur, elles:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le SDK Android.
• [C-4-2] DOIT signaler la caractéristique com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas comme une constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles de mise en réseau et API

Capacité réseau minimale

Implémentations pour les appareils:

• [C-0-1] DOIT inclure la compatibilité avec une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT être compatibles avec au moins une norme de données capable d'atteindre 200 Kbit/s ou plus. Exemples de technologies répondant à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth PAN.
• DEVRAIT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (comme Ethernet) est la connexion de données principale.
• PEUT mettre en œuvre plusieurs formes de connectivité de données.

IPv6

Implémentations pour les appareils:

• [C-0-2] DOIT inclure une pile réseau IPv6 et accepter la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
• [C-0-3] DOIT activer IPv6 par défaut.
• DOIT s'assurer que la communication IPv6 est aussi fiable que l'IPv4, par exemple :
  • [C-0-4] DOIT maintenir la connectivité IPv6 en mode Sommeil.
  • [C-0-5] La limitation du débit NE DOIT PAS entraîner la perte de la connectivité IPv6 de l'appareil sur tout réseau compatible IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.
• [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port effectuée localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort) et les API NDK comme getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port sources sur les serveurs Internet (Web).

Le niveau requis de compatibilité IPv6 dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les appareils sont compatibles avec le Wi-Fi, ils:

• [C-1-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, ils:

• [C-2-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur Ethernet.

Si les appareils sont compatibles avec les données mobiles, ils:

• [C-3-1] DOIT prendre en charge le fonctionnement IPv6 (uniquement IPv6 et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, le Wi-Fi et les données mobiles), elles:

• [C-4-1] DOIT respecter simultanément les exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

Portails captifs

Un portail captif est un réseau qui nécessite une connexion pour obtenir l’accès à Internet.

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

• [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif, en envoyant cet intent lors d'un appel à l'API système ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] DOIT détecter les portails captifs et permettre la connexion via l'application de portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris les réseaux cellulaires/mobiles, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide d'un DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode DNS strict privé.
• [C-1-4] DOIT utiliser un DNS chiffré conformément à la documentation du SDK pour android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout le trafic réseau qui ne communique pas explicitement avec le portail captif.
• [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un portail captif, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback et utilisé par défaut par les API de mise en réseau Java telles que java.net.Socket, ainsi que les API natives telles que connect()) correspond à tout autre réseau disponible offrant un accès à Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations pour les appareils:

• [C-0-1] DOIT activer le paramètre de synchronisation automatique du maître pour que la méthode getMasterSyncAutomatically() renvoie la valeur "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, voici les types de connexions:

• [SR] FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

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

• [C-1-1] DOIT prendre en charge toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.

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

• [C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Éléments sécurisés

Si les implémentations d'appareils prennent en charge les éléments sécurisés compatibles avec l'API Open Mobile et les mettent à la disposition des applications tierces, elles:

• [C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via l'API android.se.omapi.SEService.getReaders().

• [C-1-2] DOIT déclarer les flags de fonctionnalité appropriés via android.hardware.se.omapi.uicc pour l'appareil doté d'éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil doté d'éléments sécurisés basés sur eSE et android.hardware.se.omapi.sd pour l'appareil doté d'éléments sécurisés basés sur la SD.

7.5. Appareils photo

Si les implémentations d'appareils incluent au moins une caméra:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
• [C-1-2] DOIT être possible pour qu'une application puisse allouer simultanément trois bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur photo ayant la plus grande résolution de l'appareil, alors que l'appareil photo est ouvert pour effectuer un aperçu de base tout en effectuant une capture.
• [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée gérant les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application réceptrice lorsque celle-ci n'a pas 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, en face de l'écran. Autrement dit, elle immortalise les scènes de l'autre côté de l'appareil, comme un appareil photo traditionnel.

Implémentations pour les appareils:

• DEVRAIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
• [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
• DOIT intégrer un autofocus matériel ou logiciel dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
• PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• PEUT inclure un flash.

Si la caméra dispose d'un flash:

• [C-2-1] La lampe du flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil que l'écran ; c'est-à-dire une caméra généralement utilisée pour filmer l'utilisateur, par exemple pour la visioconférence et des applications similaires.

Implémentations pour les appareils:

• PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra avant:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• [C-1-2] DOIT avoir une résolution VGA d'au moins (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra frontale par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme caméra arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
• [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque celle-ci a explicitement demandé la rotation de l'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application actuelle ne demande pas explicitement la rotation de l'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NE DOIT PAS mettre en miroir les flux d'image fixe ou vidéo finaux qui sont renvoyés aux rappels de l'application ou qui ont été validés dans le stockage multimédia.
• [C-1-6] DOIT mettre en miroir l'image affichée par la vue post-vue de la même manière que le flux d'image d'aperçu de l'appareil photo.
• PEUT inclure des fonctionnalités (autofocus, flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur):

• [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations pour les appareils:

• PEUT inclure la prise en charge d'une caméra externe qui n'est pas toujours connectée.

Si les implémentations d'appareils prennent en charge une caméra externe, celles-ci:

• [C-1-1] DOIT déclarer les indicateurs de fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any.
• [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
• [C-1-3] DOIT réussir les tests CTS de la caméra lorsqu'une caméra externe physique est connectée. Pour en savoir plus sur le test CTS de la caméra, consultez source.android.com.
• DEVRAIT accepter les compressions vidéo telles que MJPEG pour permettre le transfert de flux d'image non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
• PEUT prendre en charge plusieurs appareils photo.
• PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est compatible:

• [C-2-1] Un flux simultané non encodé / MJPEG (QVGA ou résolution supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API permettant d'accéder à l'appareil photo. La nouvelle API android.hardware.camera2 offre des commandes de niveau inférieur à l'application, y compris des flux de rafale et de streaming sans copie efficaces, ainsi que des commandes par image pour l'exposition, le gain, la balance des blancs, la conversion des couleurs, la suppression du bruit, l'amélioration de la netteté, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe obsolète android.hardware.Camera et le package android.hardware.camera2 plus récent DOIVENT présenter des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être identique. Il n'est pas nécessaire que les caractéristiques qui dépendent de la sémantique différente des deux API aient une vitesse ou une qualité identiques, mais DOIVENT être aussi proches que possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux appareils photo, pour toutes les caméras disponibles. Implémentations pour les appareils:

• [C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DOIT être également au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback, que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP (les données de l'octet [] sont transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
• [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo des caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais la mise en œuvre de l'appareil DOIT être compatible avec la conversion au format YV12.)
• [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la capacité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
• [C-0-5] DOIT toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil intègre un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo sans autofocus DOIVENT appeler toutes les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela ne concerne pas un appareil photo sans mise au point automatique). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels de l'API doivent toujours être "faussés" comme décrit dans la description.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans les classes android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître des constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel le permet, et NE DOIVENT PAS être compatibles avec les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'image à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR.
• [C-0-7] DOIT indiquer le niveau d'assistance approprié pour la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et signaler les indicateurs de fonctionnalité du framework appropriés.
• [C-0-8] DOIT également déclarer ses capacités de caméra individuelles android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir ce drapeau si l'une des caméras associées est compatible avec cette fonctionnalité.
• [C-0-9] DOIT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de cette image est ajoutée au Media Store.
• [C-0-10] DOIT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au Media Store.
• [C-0-11] DOIT faire en sorte que toutes les caméras accessibles via l'API android.hardware.Camera obsolète soient également accessibles via l'API android.hardware.camera2.
• [C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS modifiée, y compris, mais sans s'y limiter, en modifiant la géométrie du visage, la couleur de peau ou le lissage de la peau pour une API android.hardware.camera2 ou android.hardware.Camera.
• [C-SR] Pour les appareils équipés de plusieurs caméras RVB orientées dans la même direction, il est FORTEMENT RECOMMANDÉ d'utiliser un appareil photo logique listant la fonctionnalité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, qui se compose de toutes les caméras RVB orientées dans cette direction comme des sous-appareils physiques.

Si les implémentations d'appareils fournissent une API d'appareil photo propriétaire à des applications tierces, celles-ci:

• [C-1-1] DOIT implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
• PEUT fournir des balises et/ou des extensions de fournisseur à l'API android.hardware.camera2.

7.5.5. Orientation de l'appareil photo

Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

• [C-1-1] DOIT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cette règle s'applique quelle que soit l'orientation naturelle de l'appareil. Autrement dit, elle s'applique aux appareils principaux en mode paysage ainsi qu'aux appareils en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un Gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Il DOIT être capable de télécharger des fichiers individuels d'une taille minimale de 100 Mo vers l'emplacement "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations pour les appareils:

• [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "stockage externe partagé", "stockage partagé d'application" ou via le chemin Linux "/sdcard" sur lequel il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", qu'il soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (emplacement de carte Secure Digital, par exemple).
• [C-0-3] DOIT installer le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux entre sdcard et le point d'installation réel.
• [C-0-4] DOIT activer l'espace de stockage cloisonné par défaut pour toutes les applications ciblant le niveau d'API 29 ou supérieur, sauf dans les cas suivants :
  • Lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans son fichier manifeste.
• [C-0-5] DOIT masquer les métadonnées de localisation, telles que les balises GPS Exif, stockées dans 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 si elles remplissent l'une des conditions suivantes:

• Stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital).
• Une partie de la mémoire de stockage interne (non amovible) mise en œuvre dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un espace de stockage amovible pour répondre aux exigences ci-dessus, celles-ci:

• [C-1-1] DOIT implémenter une interface utilisateur toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans l'emplacement.
• [C-1-2] DOIT inclure un support de stockage au format FAT (une carte SD, par exemple) ou montrer sur la boîte et tout autre support disponible au moment de l'achat que ce support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:

• DEVRAIT utiliser l'implémentation AOSP du stockage partagé de l'application interne.
• PEUT partager l'espace de stockage avec les données privées de l'application.

Si les appareils disposent d'un port USB compatible avec le mode périphérique USB, ils:

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données de l'espace de stockage partagé de l'application à partir d'un ordinateur hôte.
• DEVRAIT exposer le contenu des deux chemins de stockage de manière transparente via le service d'analyse multimédia d'Android et android.provider.MediaStore.
• PEUT utiliser la mémoire de stockage de masse USB, mais DOIT utiliser le protocole Media Transfer Protocol pour répondre à cette exigence.

Si les appareils disposent d'un port USB avec mode périphérique USB et compatible avec le protocole Media Transfer Protocol, ils:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DEVRAIT signaler une classe de périphérique USB de 0x00.
• DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile par nature, contrairement à un téléviseur, les implémentations d'appareils sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car toute déconnexion accidentelle peut entraîner une perte/corruption de données.

Si le port du périphérique de stockage amovible se trouve dans un emplacement stable à long terme, comme le compartiment à piles ou un autre couvercle de protection, les configurations d'appareil sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable.

7.7. USB

Si les appareils disposent d'un port USB, ils:

• DEVRAIT prendre en charge le mode périphérique USB et le mode hôte USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils comprennent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT être connecté à un hôte USB doté d'un port USB standard de type A ou de type C.
• [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur de périphérique USB standard via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs de 1,5 A et 3 A conformément à la norme de résistance de type C, et DOIT détecter les changements dans l'annonce si ceux-ci sont compatibles avec un câble USB Type-C.
• [SR] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB de type C. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• [SR] Le port DOIT se trouver en bas de l'appareil (en fonction de l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement lorsque l'appareil est orienté avec le port situé en bas. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• [SR] DEVRAIT mettre en œuvre la prise en charge d'un courant de 1,5 A pendant le bip et le trafic du haut-parleur, comme indiqué dans la version 1.2 des spécifications de recharge de batterie USB. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• [SR] FORTEMENT RECOMMANDÉ de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut, ou qui modifient les rôles du récepteur ou de la source, cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les modes USB Power Delivery standards. Bien que cela soit considéré comme "VENTEMENT RECOMMANDÉ", dans les futures versions d'Android, nous pourrions EXÉCUTER tous les appareils de type C pour assurer une interopérabilité totale avec les chargeurs standards de type C.
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour les données et le changement de rôle d'alimentation lorsqu'ils prennent en charge les modes USB Type-C et hôte USB.
• DEVRAIT prendre en charge l'alimentation électrique pour la recharge haute tension et la prise en charge d'autres modes tels que l'affichage.
• DEVRAIT implémenter l'API Android Open Accessory (AOA) et sa spécification comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, ils:

• [C-2-1] DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory.
• [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne iInterface de la description de l'interface de la mémoire de stockage de masse USB.

7.7.2. Mode hôte USB

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

• [C-1-1] DOIT implémenter l'API hôte USB Android comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
• [C-1-2] DOIT implémenter la prise en charge de la connexion de périphériques USB standards. En d'autres termes, ils DOIVENT :
  • Disposer d'un port de type C intégré à l'appareil ou expédier vos produits avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB Type-C standard (appareil USB Type-C)
  • disposer d'un appareil de type A ou l'expédier avec un ou plusieurs câbles adaptant un port propriétaire de l'appareil à un port USB de type A standard ;
  • disposer d'un port micro-AB intégré, qui DOIT être livré avec un câble adapté à un port standard de type A ;
• [C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant un port USB de type A ou micro-AB dans un port de type C (réceptacle).
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB comme indiqué dans la documentation du SDK Android.
• DOIT prendre en charge la recharge du périphérique USB connecté en mode hôte, indiquer un courant source d'au moins 1,5 A, comme indiqué dans la section sur les paramètres de terminaison de la révision 1.2 des spécifications du câble et du connecteur USB Type-C pour les connecteurs USB Type-C, ou utiliser une plage actuelle de sortie du port de recharge en aval(CDP) comme indiqué dans les spécifications de recharge de la batterie USB, révision AB 1.2 pour les connecteurs USB Type-C.
• DEVRAIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et la classe audio USB, ils:

• [C-2-1] DOIT être compatible avec la classe USB HID.
• [C-2-2] DOIT prendre en charge la détection et la mise en correspondance 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 avec les constantes KeyEvent, comme indiqué ci-dessous :
  • ID d'utilisation (0x0CD) de la page d'utilisation (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID d'utilisation (0x0E9) de la page d'utilisation (0xC): KEYCODE_VOLUME_UP
  • ID d'utilisation de la page d'utilisation (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID d'utilisation (0x0CF) de la page d'utilisation (0xC): KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et le framework d'accès au stockage (SAF), elles:

• [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leur contenu accessible via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et l'USB Type-C, ceux-ci:

• [C-4-1] DOIT implémenter la fonctionnalité Port double rôle définie par la spécification USB Type-C (section 4.5.1.3.3).
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge DisplayPort, DEVRAIT prendre en charge les tarifs de données USB SuperSpeed, et il est VIVEMENT RECOMMANDÉ de prendre en charge Power Delivery pour le transfert de données et de rôle de l'alimentation.
• [SR] FORTEMENT RECOMMANDÉ DE NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la révision 1.2 des spécifications relatives au câble et au connecteur USB Type-C.
• DEVRAIT implémenter le modèle try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter le modèle try.SNK.

7.8. Son

Micro

Si les implémentations d'appareils incluent un micro, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio décrites dans la section 5.4.
• [C-1-3] DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• [SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'enregistrement par ultrasons proches, comme décrit dans la section 7.8.3.

Si l'intégration d'un appareil n'inclut pas de micro:

• [C-2-1] NE DOIT PAS signaler la constante de caractéristique android.hardware.microphone.
• [C-2-2] DOIT implémenter l'API d'enregistrement audio au moins comme no-ops, conformément à la section 7.

Sortie audio

Si les appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio, comme un connecteur audio 3,5 mm à 4 conducteurs ou un port en mode hôte USB utilisant la classe audio USB, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.audio.output.
• [C-1-2] DOIT respecter les exigences relatives à la lecture audio décrites dans la section 5.5.
• [C-1-3] DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge la lecture par ultrasons, comme décrit dans la section 7.8.3.

Si les appareils ne comprennent pas de haut-parleur ni de port de sortie audio:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] DOIT implémenter les API liées à la sortie audio au moins comme no-ops.

Dans cette section, un "port de sortie" est une interface physique, telle qu'un connecteur audio 3,5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de sorties audio sur des protocoles basés sur la radio, tels que le Bluetooth, le Wi-Fi ou les réseaux mobiles, ne signifie pas qu'un "port de sortie" est inclus.

Ports audio analogiques

Pour être compatibles avec les casques audio et autres accessoires audio utilisant la prise audio 3, 5 mm dans l'écosystème Android, les implémentations d'appareils qui incluent un ou plusieurs ports audio analogiques:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un des ports audio, un connecteur audio de 3,5 mm à 4 conducteurs.

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

• [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et stéréo dotés d'un micro.
• [C-1-2] DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA.
• [C-1-3] DOIT prendre en charge la détection et la mise en correspondance des codes de clavier pour les trois plages suivantes d'impédance équivalente entre le micro et les conducteurs de terre sur la fiche audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG au moment d'insérer la fiche, mais seulement lorsque tous les contacts de la fiche touchent les segments correspondants sur le connecteur.
• [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 ohms.
• [C-1-6] DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper le code de clavier pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la fiche audio :
  • 110-180 ohm:KEYCODE_VOICE_ASSIST
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge les prises audio avec l'ordre de broche OMTP.
• [C-SR] sont FORTEMENT RECOMMANDÉS de prendre en charge les enregistrements audio à partir d'un casque stéréo doté d'un micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à 4 conducteurs, sont compatibles avec un micro et diffusent l'android.intent.action.HEADSET_PLUG avec la valeur de micro supplémentaire définie sur 1, les appareils:

• [C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

Ports audio numériques

Pour être compatibles avec les casques et autres accessoires audio utilisant des connecteurs USB-C et implémenter la classe audio USB dans l'écosystème Android, conformément aux spécifications des casques USB Android.

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

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz.

Implémentations pour les appareils:

• DOIT indiquer correctement la prise en charge de la fonctionnalité audio proche ultrasons via l'API AudioManager.getProperty, comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT respecter les exigences suivantes:

• [C-1-1] La réponse de puissance moyenne du micro dans la bande de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
• [C-1-2] Le rapport signal/bruit non pondéré du microphone entre 18,5 kHz et 20 kHz pour un ton de 19 kHz à -26 dBFS DOIT ne pas être inférieur à 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true" (vrai) :

• [C-2-1] La réponse moyenne du haut-parleur sur la plage de 18,5 kHz à 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations sur des appareils: * DEVRAIT fournir un chemin de signal audio sans faille pour les flux d'entrée et de sortie sur les appareils portables, tel que défini par zéro glitch mesuré lors d'un test d'une minute par chemin. Effectuez un test avec l'outil de test de glitch automatisé [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

Le test nécessite un dongle de bouclage audio, utilisé directement dans un connecteur 3,5 mm et/ou associé à un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester prend actuellement en charge les chemins d'accès AAudio. Par conséquent, les combinaisons suivantes DOIVENT être testées pour détecter des problèmes avec AAudio:

Mode Performances	Partage	Taux d'échantillonnage sortant	En chan	Chans.
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	1	2
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	2	1
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	1	2
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	2	1
AUCUN	PARTAGÉ	48000	1	2
AUCUN	PARTAGÉ	48000	2	1
AUCUN	PARTAGÉ	44100	1	2
AUCUN	PARTAGÉ	44100	2	1
AUCUN	PARTAGÉ	16000	1	2
AUCUN	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants pour le rapport signal sur bruit (SNR) et la distorsion harmonique totale (THD) pour le sinus de 2 000 Hz.

Transducteur	THD	Numéro SNR
haut-parleur intégré principal, mesuré à l'aide d'un micro de référence externe	< 3,0%	>= 50 dB
microphone intégré principal, mesuré à l'aide d'un haut-parleur de référence externe	< 3,0%	>= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés avec l'adaptateur de rebouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés avec l'adaptateur de rebouclage	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de "réalité virtuelle" (RV), y compris des expériences RV mobiles de haute qualité. Les implémentations d'appareils DOIVENT implémenter ces API et ces comportements correctement, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android prend en charge le mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est axée sur l'utilisateur.

7.9.2. Mode Réalité virtuelle - Hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, ils:

• [C-1-1] DOIT comporter au moins deux cœurs physiques.
• [C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
• [C-1-3] DOIT prendre en charge le mode Performances soutenues.
• [C-1-4] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.2.
• [C-1-5] DOIT accepter android.hardware.vulkan.level 0.
• DEVRAIT prendre en charge android.hardware.vulkan.level 1 ou version ultérieure.
• [C-1-6] DOIT implémenter EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace et exposer les extensions 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] 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'afficher les extensions dans la liste des extensions GL disponibles.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge Vulkan 1.1.
• [C-SR] 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] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan dans laquelle flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et queueCount est au moins égal à 2.
• [C-1-7] Le processeur graphique et l'écran DOIVENT être capables de synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu alterné des contenus de réalité virtuelle à 60 images par seconde avec deux contextes de rendu s'affiche sans artefact de déchirure visible.
• [C-1-9] DOIT implémenter la prise en charge des options AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, comme décrit dans le NDK.
• [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Sont FORTEMENT RECOMMANDÉS pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs couches et indicateurs et formats spécifiés dans C-1-10.
• [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-10 Mbit/s ou 2 instances de 1 920 x 6 Mbit/s à 1 920 x 10 Mbit/s).
• [C-1-12] DOIT être compatible avec les formats HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressés à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS et 20 Mbit/s d'instances 0 FPS à 0 Mbit/s (équivalent de 0 Mbit/s à 0 Mbit/s).
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs de température cutanée précises.
• [C-1-14] DOIT disposer d'un écran intégré et sa résolution DOIT être au moins de 1 920 x 1 080.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser une résolution d'écran d'au moins 2 560 x 1 440 pixels.
• [C-1-15] L'écran DOIT mettre à jour une fréquence d'au moins 60 Hz en mode RV.
• [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance inférieure ou égale à 5 millisecondes, la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
• [C-1-18] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension section 7.4.3.
• [C-1-19] DOIT accepter et signaler correctement le type de canal direct pour tous les types de capteurs par défaut suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
• [C-1-21] DOIT respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour la région android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser la fonctionnalité android.hardware.sensor.hifi_sensors.
• [C-1-22] DOIT avoir une latence du mouvement de bout en bout et des photons ne dépassant pas 28 millisecondes.
• [C-SR] Il est FORTEMENT RECOMMANDÉ que la latence du mouvement de bout en bout et du photon ne dépasse pas 20 millisecondes.
• [C-1-23] DOIT avoir un ratio de première image, c'est-à-dire le ratio entre la luminosité des pixels sur la première image après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable (au moins 85 %).
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de première image d'au moins 90%.
• PEUT fournir un cœur exclusif à l'application de premier plan et prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application de premier plan.

Si un cœur exclusif est pris en charge, le noyau:

• [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus de l'espace utilisateur sur celui-ci (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUVENT permettre à certains processus du noyau de s'exécuter si nécessaire.

7.10. Technologies haptiques

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

7.11. Classe Media Performance

La classe de performance multimédia de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Les exigences relatives à la classe de performance multimédia sont définies pour chaque version d'Android à partir de R (version 30). La valeur spéciale de 0 indique que l'appareil n'appartient pas à une classe de performance multimédia.

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

• [C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.

• [C-1-2] DOIT être une implémentation d'appareil portable.

• [C-1-3] DOIT respecter toutes les exigences de la "classe de performance multimédia" décrites dans la section 2.2.7.

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

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lorsqu'ils développent une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être proposée à l'utilisateur final si certaines conditions minimales sont requises pour garantir une fréquence d'images et des temps de réponse cohérents dans les applications et les jeux. Les implémentations d'appareils, selon le type d'appareil, PEUVENT comporter des exigences mesurables en termes de latence de l'interface utilisateur et de changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes dans le stockage de données privé de l'application (partition /data) permet aux développeurs d'applications de définir des attentes qui faciliteront la conception de leur logiciel. Les implémentations d'appareils, selon leur type, PEUVENT être soumises à certaines exigences décrites dans la section 2 concernant les opérations de lecture et d'écriture suivantes:

• Performances d'écriture séquentielle. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec un tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec un tampon d'écriture de 4 Ko.
• Performances de lecture séquentielle. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo avec un tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

Si les implémentations d'appareils incluent des fonctionnalités visant à améliorer la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, Sommeil) ou étendent les fonctionnalités qui n'appliquent pas de restrictions plus strictes que le bucket de mise en veille des applications rares, elles:

• [C-1-1] NE DOIT PAS déroger à l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de wakeup, ni pour l'utilisation des paramètres système globaux des modes d'économie d'énergie App Standby et Sommeil.
• [C-1-2] NE DOIT PAS déroger à l'implémentation AOSP concernant l'utilisation de paramètres globaux pour la gestion de la limitation des tâches, des alarmes et du réseau pour les applications de chaque bucket en mode Mise en veille des applications.
• [C-1-3] NE DOIT PAS dévier de l'implémentation AOSP pour le nombre de buckets de mise en veille des applications utilisés pour la mise en veille des applications.
• [C-1-4] DOIT implémenter les buckets de mise en veille des applications et la fonctionnalité Sommeil comme décrit dans la section Gestion de l'alimentation.
• [C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de permettre à l'utilisateur d'activer et de désactiver l'économiseur de batterie.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Mise en veille des applications.

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP et que cette extension applique des restrictions plus strictes que le bucket de mise en veille des applications rares, reportez-vous à la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou l'ensemble des quatre états de veille définis par l'ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles:

• [C-1-1] NE DOIT entrer dans cet état qu'après que l'utilisateur a effectué une action explicite pour désactiver l'appareil (par exemple, en fermant un capot qui fait partie physiquement de l'appareil, ou en éteignant un véhicule ou une télévision) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le capot ou en rallumant le véhicule ou la télévision).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles:

• [C-2-1] DOIT respecter le code C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran ou le processeur).

  À l'inverse, vous DEVEZ quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans le présent SDK.

  Par exemple, bien que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur fonctionnant via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer à l'état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris des mesures explicites pour 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 distribué à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur l'a désactivé. Ces exemples ne sont pas exhaustifs. AOSP implémente de nombreux signaux de wakeup qui déclenchent un wakeup à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Avec une comptabilisation et des rapports plus précis sur la consommation d'énergie, le développeur de l'application bénéficie à la fois des incitations et des outils nécessaires pour optimiser le modèle de consommation d'énergie de l'application.

Implémentations pour les appareils:

• [SR] FORTEMENT RECOMMANDÉ de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle de chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [SR] FORTEMENT RECOMMANDÉ de consigner toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
• [SR] 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.
• [SR] FORTEMENT RECOMMANDÉ de mettre cette consommation d'énergie à la disposition du développeur de l'application via la commande shell adb shell dumpsys batterystats.
• DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure d'attribuer sa consommation d'énergie à une application.

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée très performantes, soit à cause des autres applications s'exécutant en arrière-plan, soit à cause de la limitation du processeur due aux limites de température. Android inclut des interfaces de programmation. Ainsi, lorsque l'appareil est compatible, l'application de premier plan peut demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode API PowerManager.isSustainedPerformanceModeSupported().

• DEVRAIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils sont compatibles avec le mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan un niveau de performances constant pendant au moins 30 minutes, lorsque l'application le demande.
• [C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent au moins deux cœurs de processeur:

• DEVRAIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan supérieure.

Si les implémentations d'appareils permettent de réserver un cœur exclusif à l'application de premier plan, elles:

• [C-2-1] DOIT indiquer à l'aide de la méthode d'API Process.getExclusiveCores() les numéros d'identification des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
• [C-2-2] NE DOIT PAS autoriser les processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application, de s'exécuter sur les cœurs exclusifs. Cependant, certains processus du noyau PEUVENT s'exécuter si nécessaire.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, celles-ci:

• [C-3-1] DOIT renvoyer une liste vide via la méthode API Process.getExclusiveCores().

9. Compatibilité des modèles de sécurité

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API de la documentation pour les développeurs Android.

• [C-0-2] DOIT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers ou d'autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android. Plus précisément, ils DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK ; aucune autorisation ne peut être omise, modifiée ni ignorée.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne figurent pas dans l'espace de noms android.\*.

• [C-0-2] Les autorisations dont l'protectionLevel est PROTECTION_FLAG_PRIVILEGED NE DOIT être accordée qu'aux applications préinstallées dans le ou les chemins privilégiés de l'image système et dans le sous-ensemble d'autorisations explicitement ajoutées à la liste d'autorisation pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en honorant les autorisations de la liste d'autorisation pour chaque application à partir des fichiers du chemin etc/permissions/ et en utilisant le chemin system/priv-app comme chemin privilégié.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec une targetSdkVersion supérieure à 22 les demandent au moment de l'exécution.

Implémentations pour les appareils:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider s'il doit accorder les autorisations d'exécution demandées et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] DOIT comporter une seule et unique implémentation des deux interfaces utilisateur.
• [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf dans les cas suivants :
  • 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 espace de stockage distant hors appareil. Il est équipé d'un matériel sécurisé dont la protection est équivalente ou supérieure à celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations pour les appareils:

• [C-0-7] DOIT respecter les propriétés d'autorisation d'accéder à la position Android lorsqu'une application demande des données de localisation ou d'activité physique via l'API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter:

  • Localisation de l'appareil (latitude et longitude, par exemple).
  • Informations permettant de déterminer ou d'estimer la position de l'appareil (SSID, BSSID, ID de cellule GSM, emplacement du réseau auquel l'appareil est connecté, etc.).
  • Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils:

• [C-0-8] DOIT obtenir le consentement de l'utilisateur pour permettre à une application d'accéder aux données de localisation ou d'activité physique.
• [C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application disposant des autorisations suffisantes, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

• [C-0-10] Les autorisations comportant l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si:

  • Un fichier APK d'application se trouve dans la partition du système.
  • L'utilisateur attribue un rôle associé aux autorisations hardRestricted à une application.
  • Le programme d'installation accorde le hardRestricted à une application.
  • Une application se voit attribuer le hardRestricted sur une version antérieure d'Android.

• [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT bénéficier d'un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles ne sont pas ajoutées à la liste d'autorisation, comme décrit dans le SDK, où un accès complet et limité est défini pour chaque autorisation softRestricted (par exemple, READ_EXTERNAL_STORAGE).

Si les implémentations d'appareils permettent à l'utilisateur de choisir les applications qui peuvent se superposer aux autres applications avec une activité qui gère l'intent ACTION_MANAGE_OVERLAY_PERMISSION, elles:

• [C-2-1] DOIT s'assurer que toutes les activités avec des filtres d'intent pour l'intent ACTION_MANAGE_OVERLAY_PERMISSION ont le même écran d'interface utilisateur, quelles que soient l'application de lancement ou les informations qu'elle fournit.

9.2. UID et isolation de processus

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec le modèle de bac à sable des applications Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct.
• [C-0-2] DOIT prendre en charge l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme indiqué dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations d'accès aux fichiers Android défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un logiciel ou d'une technologie autres que le format exécutable Dalvik ou du code natif. Autrement dit :

• [C-0-1] Les environnements d'exécution alternatifs DOIVENT être des applications Android et respecter le modèle de sécurité Android standard, tel que décrit ailleurs dans la section 9.

• [C-0-2] Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le mécanisme <uses-permission>.

• [C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS permettre aux applications d'utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

• [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées qui utilisent un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards de partage de l'ID utilisateur et de certificat de signature.

• [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec les bacs à sable correspondant à d'autres applications Android, ni leur accorder ou obtenir l'accès.

• [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec d'autres applications, ni accordés, ni accordés à d'autres applications.

• [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses dans les implémentations d'appareils.

• [C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.

• [C-0-9] Lorsqu'une application doit utiliser une ressource d'appareil pour laquelle il existe une autorisation Android correspondante (telle que l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

• [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les capacités des applications de cette manière, il DOIT répertorier toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

• D'autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

• Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications qui les utilisent.

9.5. Compatibilité multi-utilisateur

Android permet de gérer plusieurs utilisateurs et d'isoler complètement les utilisateurs.

• Les implémentations sur les appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur s'ils utilisent des supports amovibles comme stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs:

• [C-1-1] DOIT respecter les exigences suivantes liées à la compatibilité multi-utilisateur.
• [C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API.
• [C-1-3] DOIT disposer d'un répertoire de stockage d'application partagé séparé et isolé (également appelé /sdcard) pour chaque instance d'utilisateur.
• [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées pour celui-ci ne peuvent pas répertorier, lire ou écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
• [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations d'appareils utilisent des supports amovibles pour les API de stockage externe. Étant donné que le contenu multimédia deviendra ainsi illisible pour un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel.

9.6. Avertissement relatif aux SMS premium

Android permet d'avertir les utilisateurs de la réception d'un SMS premium. Les SMS premium sont des SMS envoyés à un service enregistré auprès d'un opérateur et susceptibles d'entraîner des frais pour l'utilisateur.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.telephony, elles:

• [C-1-1] DOIT avertir les utilisateurs avant d'envoyer un SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) Security-Enhanced Linux (SELinux), le système de bac à sable seccomp et d'autres fonctionnalités de sécurité dans le noyau Linux. Implémentations pour les appareils:

• [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité sont implémentés en deçà de l'infrastructure Android.
• [C-0-2] NE DOIT PAS disposer d'une interface utilisateur visible lorsqu'une violation de sécurité est détectée et bloquée avec succès par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT disposer d'une interface utilisateur visible en cas de non-respect de la sécurité débloqué, entraînant ainsi un exploit réussi.
• [C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée en dessous du framework Android configurable pour l'utilisateur ou le développeur d'applications.
• [C-0-4] NE DOIT PAS permettre à une application pouvant affecter une autre application via une API (telle qu'une API Device Administration) de configurer une règle rompant la compatibilité.
• [C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin qu'il soit possible d'accorder un accès plus restreint pour chaque processus, comme décrit sur le site du projet Android Open Source.
• [C-0-6] DOIT mettre en œuvre un mécanisme de bac à sable pour l'application du noyau permettant de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Open Source Android en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation des groupes de threads (TSYNC), comme décrit dans la section "Configuration du noyau" sur source.android.com.

Les fonctionnalités d'intégrité du noyau et d'auto-protection font partie intégrante de la sécurité Android. Implémentations pour les appareils:

• [C-0-7] DOIT implémenter des mécanismes de protection contre le débordement de la mémoire tampon de la pile du noyau. CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG sont des exemples de mécanismes de ce type.
• [C-0-8] DOIT mettre en œuvre des protections strictes de la mémoire du noyau où le code exécutable est en lecture seule, les données en lecture seule ne sont pas exécutables ni en écriture, et les données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DOIT implémenter une vérification des limites de taille d'objet statique et dynamique des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec le niveau d'API 28 ou supérieur.
• [C-0-10] NE DOIT PAS exécuter la mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, avec le PXN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur des appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire de l'espace utilisateur dans le noyau en dehors des API d'accès à la copie utilisateur normales (par exemple, le PAN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-12] DOIT implémenter l'isolation des tables de pages du noyau si le matériel est vulnérable à la faille CVE-2017-5754 sur tous les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] DOIT implémenter le renforcement de la prédiction de branche si le matériel est vulnérable à la faille CVE-2017-5715 sur tous les appareils livrés à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation et qui sont marquées en lecture seule après l'initialisation (par exemple, __ro_after_init).

• [C-SR] SONT FORTEMENT RECOMMANDÉS de randomiser la disposition du code du noyau et de la mémoire, et d'éviter toute exposition qui pourrait compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau afin de fournir une protection supplémentaire contre les attaques par réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

• [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver Control-Flow Integrity (CFI), Shadow Call Stack (SCS) ou Integer Overflow Sanitization (IntSan) sur les composants pour lesquels ils sont activés.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tout composant supplémentaire de l'espace utilisateur sensible à la sécurité, comme expliqué dans CFI et IntSan.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau afin d'empêcher l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les paramètres locaux.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau afin d'empêcher l'utilisation d'allocations de segments de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Il NE DOIT PAS supposer la valeur utilisée par le noyau pour initialiser ces allocations.

Si les implémentations d'appareils utilisent un noyau Linux, elles:

• [C-1-1] DOIT implémenter SELinux.
• [C-1-2] DOIT définir SELinux sur le mode d'application global.
• [C-1-3] DOIT configurer tous les domaines en mode "Enforcing". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/fournisseur.
• [C-1-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le dossier "system/sepolicy" fourni dans le projet Android Open Source (AOSP) en amont. De plus, la règle DOIT se compiler avec toutes les règles "Neverallow" présentes, à la fois pour les domaines AOSP SELinux et pour les domaines spécifiques à l'appareil ou au fournisseur.
• [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application, avec des restrictions SELinux par application sur le répertoire de données privé de chaque application.
• DEVRAIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et n'ajouter à cette règle que pour leur propre configuration spécifique à l'appareil.

Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre aux exigences du [C-1-1] et du [C-1-5] via une mise à jour logicielle système, elles PEUVENT être exemptées de ces exigences.

Si les implémentations d'appareils utilisent un noyau autre que Linux:

• [C-2-1] DOIT utiliser un système de contrôle des accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et gère cet historique via UsageStatsManager.

Implémentations pour les appareils:

• [C-0-1] DOIT conserver une durée de conservation raisonnable de cet historique utilisateur.
• [SR] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle qu'elle est configurée par défaut dans l'implémentation d'AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via StatsManager et l'API système IncidentManager.

Implémentations pour les appareils:

• [C-0-2] DOIT inclure uniquement les champs marqués d'un DEST_AUTOMATIC dans le rapport d'incident créé par la classe IncidentManager de l'API System.
• [C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour enregistrer d'autres événements que ceux décrits dans les documents du SDK StatsLog. Si d'autres événements système sont consignés, ils PEUVENT utiliser un identifiant atomique différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient des informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran ou le rapport de bug) hors de l'appareil sans l'autorisation de l'utilisateur ou sans lui envoyer de notifications claires en cours.
• [C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur, permettant la capture d'informations sensibles affichées sur l'écran chaque fois que la diffusion ou l'enregistrement d'écran sont activés via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs une affordance de désactiver l'affichage futur du consentement de l'utilisateur.
• [C-0-3] DOIT recevoir une notification d'activité en cours à l'utilisateur lorsque la fonctionnalité de diffusion ou d'enregistrement d'écran est activée. AOSP répond à cette exigence en affichant une icône de notification d'activité en cours dans la barre d'état.

Si les implémentations d'appareils incluent une fonctionnalité dans le système qui capture le contenu affiché à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou par d'autres moyens propriétaires décrits dans la section 9.8.6 Capture de contenu, elles:

• [C-1-1] DOIT recevoir une notification permanente à l'utilisateur chaque fois que cette fonctionnalité est activée et qu'elle capture ou enregistre activement des vidéos.

Si les implémentations d'appareils incluent un composant prêt à l'emploi, capable d'enregistrer le son ambiant et/ou d'enregistrer le contenu audio lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, elles:

• [C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil le contenu audio brut enregistré ou tout autre format pouvant être reconverti en contenu audio d'origine ou en télécopie, sauf avec le consentement explicite de l'utilisateur.

9.8.3. Connectivité

Si les appareils disposent d'un port USB compatible avec le mode périphérique USB, ils:

• [C-1-1] DOIT présenter une interface utilisateur demandant l'autorisation de l'utilisateur avant d'autoriser l'accès au contenu de la mémoire de stockage partagée via le port USB.

9.8.4. Trafic réseau

Implémentations pour les appareils:

• [C-0-1] DOIT préinstaller pour le magasin de l'autorité de certification approuvé par le système les mêmes certificats racine que ceux fournis en amont dans le projet Android Open Source en amont.
• [C-0-2] DOIT être livré avec un magasin d'autorités de certification racine d'utilisateur vide.
• [C-0-3] DOIT afficher un avertissement indiquant à l'utilisateur que le trafic réseau peut être surveillé, lorsqu'une autorité de certification racine est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations d'appareils:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
  • Ce trafic réseau peut être surveillé.
  • Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé automatiquement par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, le préchargement d'un service VPN avec android.permission.CONTROL_VPN accordé), elles:

• [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par le responsable du contrôle des règles relatives aux appareils via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas , l'utilisateur n'a pas besoin de fournir un consentement distinct, mais il DOIT seulement être notifié.

Si les implémentations d'appareils implémentent une affordance utilisateur pour activer la fonction "VPN permanent" d'une application VPN tierce, elles:

• [C-3-1] DOIT désactiver cette affordance utilisateur pour les applications qui n'acceptent pas le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.8.5. Identifiants des appareils

Implémentations pour les appareils:

• [C-0-1] DOIT empêcher une application d'accéder au numéro de série de l'appareil et, le cas échéant, au code IMEI/MEID, au numéro de série de la carte SIM et à l'identité IMSI (International Mobile Subscriber Identity) depuis une application, sauf si elle répond à l'une des exigences suivantes :
  • est une application d'opérateur signée qui est validée par les fabricants d'appareils.
  • L'autorisation READ_PRIVILEGED_PHONE_STATE a été accordée.
  • dispose de privilèges d'opérateur tels que définis dans les droits d'opérateur de l'UICC.
  • est un propriétaire de l'appareil ou du profil disposant de l'autorisation READ_PHONE_STATE.
  • (Pour le numéro de série de la carte SIM et l'ICCID uniquement) Conformément à la réglementation locale, l'application doit détecter les modifications apportées à l'identité de l'abonné.

9.8.6. Capture de contenu

Android, via l'API System ContentCaptureService ou par d'autres moyens propriétaires, est compatible avec un mécanisme d'implémentation d'appareil permettant de capturer les interactions suivantes entre les applications et l'utilisateur.

• Texte et images affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure.
• Données multimédias, telles que du contenu audio ou vidéo, enregistrées ou lues par l'appareil.
• Événements d'entrée (par exemple, touche, souris, geste, voix, vidéo et accessibilité)
• Tout autre événement fourni par une application au système via l'API Content Capture ou une API propriétaire aux fonctionnalités similaires.
• Texte ou autres données envoyés via TextClassifier API au TextClassifier du système (c'est-à-dire au service système) pour comprendre la signification du texte et générer les prochaines actions prédites en fonction de celui-ci.

Si les implémentations d'appareils collectent les données ci-dessus, elles:

• [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées sur l'appareil. Ce chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android ou de l'un des algorithmes de chiffrement listés dans la version 26 ou ultérieure de l'API, comme décrit dans le SDK de chiffrement.
• [C-1-2] NE DOIT PAS sauvegarder de données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ou de toute autre méthode de sauvegarde.
• [C-1-3] DOIT envoyer l'ensemble de ces données et le journal de l'appareil uniquement à l'aide d'un mécanisme protégeant la confidentialité. Le mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale et empêchent la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels", afin d'éviter l'introspection de toutes les données utilisateur (par exemple, implémentées à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
• [C-1-4] NE DOIT PAS associer ces données à l'identité d'un 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 applications, sauf en cas de consentement explicite de l'utilisateur à chaque partage.
• [C-1-6] DOIT fournir une affordance à l'utilisateur pour effacer les données collectées par l'ContentCaptureService ou le moyen propriétaire si les données sont stockées sur l'appareil sous quelque forme que ce soit.

Si les implémentations d'appareils incluent un service qui implémente l'API système ContentCaptureService ou tout service propriétaire qui capture les données comme décrit ci-dessus:

• [C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer le service de capture de contenu par une application ou un service qu'ils peuvent installer, et DOIT autoriser uniquement le service préinstallé à capturer de telles données.
• [C-2-2] NE DOIT PAS permettre à des applications autres que le service de capture de contenu préinstallé de capturer de telles données.
• [C-2-3] DOIT fournir une affordance à l'utilisateur pour désactiver le service de capture de contenu.
• [C-2-4] NE DOIT PAS omettre les affordances de l'utilisateur pour gérer les autorisations Android détenues par le service de capture de contenu et qui suivent le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de séparer les composants du service de capture de contenu, par exemple de ne pas lier le service ou les ID de processus de partage des autres composants système, sauf dans les cas suivants:

  • Téléphonie, contacts, UI du système et médias

9.8.7. Accès au presse-papiers

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS renvoyer de données tronquées dans le presse-papiers (par exemple, via l'API ClipboardManager), sauf si l'application est l'IME par défaut ou celle qui est actuellement active.

9.8.8. Position

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS activer/désactiver le paramètre de localisation de l'appareil ni les paramètres de recherche Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ni à l'initiative de l'utilisateur.
• [C-0-2] DOIT fournir à l'utilisateur les autorisations d'accès aux informations de localisation, y compris les demandes de localisation récentes, les autorisations au niveau de l'application et l'utilisation de la recherche Wi-Fi/Bluetooth pour déterminer la position.
• [C-0-3] DOIT s'assurer que l'application qui utilise l'API de contournement de la localisation d'urgence [LocationRequest.setLocationSettingsIgnored()] est une session d'urgence lancée par l'utilisateur (par exemple, appeler le 112 ou envoyer un SMS au 112). Pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction de l'utilisateur actif si un accident ou un accident est détecté (par exemple, pour répondre aux exigences d'appel électronique).
• [C-0-4] DOIT préserver la capacité de l'API de contournement de la localisation d'urgence à contourner les paramètres de localisation de l'appareil sans les modifier.
• [C-0-5] DOIT programmer une notification de rappel à l'utilisateur lorsqu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Par défaut, les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas afficher d'informations sur les autres applications installées (voir Visibilité des packages dans la documentation du SDK Android).

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou supérieur des détails d'une autre application installée, sauf si l'application est déjà en mesure de voir les détails de cette autre application installée via les API gérées. Cela inclut, sans s'y limiter, les informations exposées par les API personnalisées ajoutées par l'outil de mise en œuvre de l'appareil ou accessibles via le système de fichiers.

9.8.10. Rapport de bug de connectivité

Si les implémentations d'appareils génèrent des rapports de bug à l'aide de l'API System BUGREPORT_MODE_TELEPHONY avec BugreportManager, elles:

• [C-1-1] DOIT obtenir le consentement de l'utilisateur chaque fois que l'API System BUGREPORT_MODE_TELEPHONY est appelée pour générer un rapport et NE DOIT PAS inviter l'utilisateur à donner son consentement pour toutes les futures requêtes de l'application.
• [C-1-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur lorsque les rapports commencent à être générés, et NE DOIT PAS le renvoyer à l'application à l'origine de la demande sans le consentement explicite de l'utilisateur.
• [C-1-3] DOIT générer des rapports demandés contenant au moins les informations suivantes :
  • Dump TelephonyDebugService
  • Vidage du registre de téléphonie
  • Vidage du service WifiService
  • Vidage ConnectivityService
  • Vidage de l'instance CarrierService du package à l'origine de l'appel (si elle est liée)
  • Tampon journal radio
• [C-1-4] NE DOIT PAS inclure les éléments suivants dans les rapports générés :
  • Toute sorte d'informations sans rapport avec le débogage de la connectivité.
  • Tous types de journaux de trafic des applications installées par l'utilisateur ou de profils détaillés des applications/packages installés par l'utilisateur (les UID sont acceptés, mais pas les noms de packages).
• PEUT inclure des informations supplémentaires qui ne sont associées à aucune identité d'utilisateur. (par exemple, les journaux des fournisseurs).

Si les implémentations d'appareils incluent des informations supplémentaires (par exemple, les journaux du fournisseur) dans le rapport de bug et que ces informations ont un impact sur la confidentialité, la sécurité, la batterie, le stockage ou la mémoire:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de désactiver par défaut un paramètre pour les développeurs. Pour cela, l'AOSP fournit l'option Enable verbose vendor logging dans les paramètres pour les développeurs afin d'inclure des journaux de fournisseurs supplémentaires spécifiques à l'appareil dans les rapports de bug.

9.8.11. Partage de blobs de données

Android, via BlobStoreManager, permet aux applications de transmettre des blobs de données au système à partager avec un ensemble sélectionné d'applications.

Si les implémentations d'appareils sont compatibles avec les blobs de données partagées, comme décrit dans la documentation du SDK, elles:

• [C-1-1] NE DOIT PAS partager de blobs de données appartenant à des applications au-delà de ce qu'elles visaient à autoriser (c'est-à-dire, le champ d'application de l'accès par défaut et les autres modes d'accès pouvant être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess() NE DOIVENT PAS être modifiés). La mise en œuvre de référence AOSP répond à ces exigences.
• [C-1-2] NE DOIT PAS envoyer depuis l'appareil ni partager avec d'autres applications les hachages sécurisés de blobs de données (qui sont utilisés pour contrôler l'accès).

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT respecter les exigences de la section 9.9.1. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans le présent document sont exemptés des exigences des sections 9.9.2 et 9.9.3. À la place, ils DOIVENT respecter les exigences de la section 9.9 du document sur la définition de compatibilité Android correspondant au niveau d'API pour lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter les API en mode Démarrage direct, même si elles ne sont pas compatibles avec le chiffrement du stockage.

• [C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que des emplacements de stockage chiffrés sur les appareils (DE) et CE (identifiants chiffrés) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations pour les appareils:

• [C-0-1] DOIT chiffrer les données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil.
• [C-0-2] DOIT activer le chiffrement du stockage des données par défaut au moment où l'utilisateur a terminé la configuration initiale.

• [C-0-3] DOIT respecter les exigences de chiffrement du stockage des données ci-dessus en appliquant 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 du bloc par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareils sont chiffrées, elles:

• [C-1-1] DOIT démarrer sans demander d'identifiants à l'utilisateur et autoriser les applications compatibles avec le démarrage direct à accéder à l'espace de stockage DE (Device Encrypted) une fois le message ACTION_LOCKED_BOOT_COMPLETED diffusé.
• [C-1-2] DOIT autoriser l'accès à l'espace de stockage CE (Identifiants chiffrés) uniquement après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, code secret, code, schéma ou empreinte) et que le message ACTION_USER_UNLOCKED est diffusé.
• [C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller le stockage protégé par l'API CE sans les identifiants fournis par l'utilisateur, une clé de séquestre enregistrée ou une reprise après redémarrage respectant les exigences de la section 9.9.4.
• [C-1-4] DOIT utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers et métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec chiffrement des métadonnées:

• [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide de l'algorithme AES-256-XTS ou Adiantum. AES-256-XTS fait référence à la norme Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, exploitée en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme spécifié sur https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que la taille des fichiers, la propriété, les modes et les attributs étendus (xattrs).
• [C-1-6] DOIT chiffrer les noms de fichiers à l'aide de l'algorithme AES-256-CBC-CTS ou Adiantum.
• [C-1-12] Si l'appareil dispose d'instructions AES (Advanced Encryption Standard), telles que les extensions de chiffrement ARMv8 sur les appareils ARM ou AES-NI sur les appareils x86, les options AES ci-dessus pour le chiffrement du nom, du contenu et des métadonnées du système de fichiers DOIVENT être utilisées, et non Adiantum.
• [C-1-13] DOIT utiliser une fonction de dérivation de clé non réversible et sécurisée de manière cryptographique (par exemple, HKDF-SHA512) pour extraire les sous-clés nécessaires (par exemple, les clés par fichier) à partir des clés CE et DE. Une "solide cryptographiquement solide et non réversible" signifie que la fonction de dérivation de clé a un niveau de sécurité d'au moins 256 bits et se comporte comme une famille de fonctions pseudo-aléatoires sur ses entrées.

• [C-1-14] NE DOIT PAS utiliser les mêmes clés ou sous-clés de chiffrement basé sur les fichiers (FBE) à des fins de chiffrement différentes (par exemple, pour le chiffrement et la dérivation des clés, ou pour deux algorithmes de chiffrement différents).

• Clés protégeant les zones de stockage CE et DE et les métadonnées du système de fichiers:

• [C-1-7] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine matérielle de confiance de l'appareil.

• [C-1-8] Les clés CE DOIVENT être liées aux identifiants de l'écran de verrouillage d'un utilisateur.
• [C-1-9] Les clés CE DOIVENT être liées à un code secret par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants d'écran de verrouillage.
• [C-1-10] DOIT être unique et distinct, c'est-à-dire que la clé CE ou DE d'un utilisateur ne correspond pas aux clés CE ou DE d'un autre utilisateur.

• [C-1-11] DOIT utiliser les algorithmes de chiffrement, longueurs de clé et modes obligatoires.

• DEVRAIT faire en sorte que les applis essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) prennent en charge le démarrage direct.

Le projet Open Source Android en amont offre une implémentation privilégiée du chiffrement basé sur les fichiers reposant sur la fonctionnalité de chiffrement "fscrypt" du noyau Linux, et du chiffrement des métadonnées basé sur la fonctionnalité "dm-default-key" du noyau Linux.

9.9.3.2. Chiffrement au niveau du bloc par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau du bloc par utilisateur:

• [C-1-1] DOIT activer la prise en charge multi-utilisateur, comme décrit dans la section 9.5.
• [C-1-2] DOIT fournir des partitions par utilisateur, soit à l'aide de partitions brutes, soit de volumes logiques.
• [C-1-3] DOIT utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des appareils de stockage en mode bloc sous-jacents.

• [C-1-4] DOIT utiliser l'algorithme AES-256-XTS pour le chiffrement au niveau du bloc des partitions utilisateur.

• Les clés qui protègent les appareils chiffrés au niveau du bloc par utilisateur:

• [C-1-5] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine matérielle de confiance de l'appareil.

• [C-1-6] DOIT être lié aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau du bloc par utilisateur peut être implémenté à l'aide de la fonctionnalité dm-crypt du noyau Linux sur des partitions par utilisateur.

9.9.4. Reprendre au redémarrage

La reprise au redémarrage permet de débloquer le stockage CE de toutes les applications, y compris celles qui ne sont pas encore compatibles avec le démarrage direct, après un redémarrage initié par une OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

L'implémentation de la fonctionnalité de reprise au redémarrage doit continuer à garantir que lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour celui-ci de récupérer les données de l'utilisateur chiffrées par CE, même si l'appareil est allumé, que le stockage CE est déverrouillé et que l'utilisateur a déverrouillé l'appareil après avoir reçu une mise à jour OTA. Pour la résistance aux attaques internes, nous partons également du principe que l'attaquant parvient à diffuser des clés de signature cryptographique.

Plus spécifiquement :

• [C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour l'attaquant qui possède physiquement l'appareil, puis présente les capacités et limites suivantes:

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • Ce paramètre peut entraîner la réception d'une mise à jour OTA par l'appareil.
  • Peut modifier le fonctionnement de n'importe quel matériel (point d'accès, flash, etc.), sauf dans les cas détaillés ci-dessous, mais cette modification implique un délai d'au moins une heure et un cycle d'arrêt qui détruit le contenu de la RAM.
  • Ne peut pas modifier le fonctionnement d'un matériel protégé contre les accès non autorisés (Titan M, par exemple).
  • Impossible de lire la RAM de l'appareil actif.
  • Impossible d'obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ou de les faire saisir d'une autre manière.

Par exemple, un appareil qui implémente et respecte toutes les descriptions disponibles sur cette page est conforme à la norme [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent que l'état de l'intégrité de l'appareil est transparent. Implémentations pour les appareils:

• [C-0-1] DOIT indiquer correctement, à l'aide de la méthode PersistentDataBlockManager.getFlashLockState() de l'API système, si l'état du bootloader permet de flasher l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils qui effectuent une mise à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

• [C-0-2] DOIT être compatible avec le démarrage validé pour assurer l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans être compatibles avec le démarrage validé sur une version antérieure d'Android et qu'il n'est pas possible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence.

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

• [C-1-1] DOIT déclarer l'indicateur de fonctionnalité de la plate-forme android.software.verified_boot.
• [C-1-2] DOIT effectuer une vérification sur chaque séquence de démarrage.
• [C-1-3] DOIT commencer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et aller jusqu'à la partition système.
• [C-1-4] DOIT mettre en œuvre chaque étape de vérification pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code lors de l'étape suivante.
• [C-1-5] DOIT utiliser des algorithmes de vérification aussi performants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
• [C-1-6] NE DOIT PAS autoriser le démarrage en cas d'échec de la vérification du système, sauf si l'utilisateur consent à tenter quand même de démarrer. Dans ce cas, les données des blocs de stockage non validés NE DOIVENT pas être utilisées.
• [C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
• [C-SR] Si l'appareil comporte plusieurs puces discrètes (par exemple, un processeur radio ou un processeur d'image spécialisé), le processus de démarrage de chacune d'elles est VIVEMENT RECOMMANDÉ pour vérifier chaque étape au démarrage.
• [C-1-8] DOIT utiliser un espace de stockage inviolable pour indiquer si le bootloader est déverrouillé. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] DOIT envoyer une invite à l'utilisateur lorsqu'il est en train d'utiliser l'appareil et exiger une confirmation physique avant d'autoriser la transition du mode verrouillé du bootloader vers le mode déverrouillé du bootloader.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (ex. : démarrage, partitions système) et utiliser un système de stockage inviolable pour stocker les métadonnées servant à déterminer la version minimale autorisée du système d'exploitation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance en racine dans des partitions protégées par le démarrage validé.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier tous les artefacts exécutables chargés par une application privilégiée en dehors de son fichier APK (comme le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
• DEVRAIT mettre en œuvre une protection contre le rollback pour tout composant doté d'un micrologiciel persistant (modem, appareil photo, par exemple) et utiliser un système de stockage avec système d'inviolabilité pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge les versions C-1-8 à C-1-10 sur une version antérieure d'Android et qu'une mise à jour logicielle système ne permet pas de répondre à ces exigences, elles PEUVENT être exemptées.

Le projet Open Source Android en amont offre une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégré au bootloader utilisé pour charger Android.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge la vérification cryptographique du contenu du fichier par rapport à une clé de confiance sans lire l'intégralité du fichier.
• [C-0-4] NE DOIT PAS autoriser la réussite des requêtes de lecture d'un fichier protégé lorsque le contenu en lecture n'est pas vérifié par rapport à une clé approuvée.

Si des implémentations d'appareils sont déjà lancées sans qu'il soit possible de vérifier le contenu des fichiers à l'aide d'une clé de confiance sur une version antérieure d'Android et que vous ne pouvez pas ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence. Le projet Open Source Android en amont fournit une implémentation à privilégier pour cette fonctionnalité, basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations pour les appareils:

• [C-R] Il est RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations d'appareils sont compatibles avec l'API Android Protected Confirmation:

• [C-3-1] DOIT 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), malveillant ou autre, ne peut pas générer de réponse positive sans interaction de l'utilisateur.

• [C-3-3] DOIT s'assurer que l'utilisateur a pu examiner et approuver le message invité, même si l'OS Android, y compris son noyau, est compromis.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations de chiffrement via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

• [C-0-1] DOIT autoriser l'importation ou la génération d'au moins 8 192 clés.
• [C-0-2] L'authentification de l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT comporter un algorithme d'intervalle exponentiel entre les tentatives. Au-delà de 150 tentatives infructueuses, le délai DOIT être d'au moins 24 heures par tentative.
• NE DEVRAIT pas limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

• [C-1-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [C-1-2] DOIT disposer d'implémentations d'algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que des fonctions de hachage des familles MD5, SHA1 et SHA-2, afin de prendre en charge correctement les algorithmes pris en charge par le système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée. Le projet Android Open Source (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée vérifiée par un tiers d'une isolation appropriée basée sur l'hyperviseur sont d'autres options.
• [C-1-3] DOIT procéder à l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et autoriser l'utilisation des clés liées à l'authentification seulement en cas de réussite. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Open Source Android en amont fournit la couche HAL (Gatekeeper Hardware Abstraction Layer) et la couche Trusty, qui peuvent être utilisées pour répondre à cette exigence.
• [C-1-4] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher leur utilisation en tant qu'identifiants d'appareils. Une façon de répondre à cette exigence consiste à partager la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

• [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'attente minimal pouvant atteindre 15 secondes. Les appareils automobiles qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur change de mode, NE peuvent PAS être configurés pour le délai de mise en veille.

9.11.1. Écran de verrouillage sécurisé et authentification

L’implémentation d’AOSP suit un modèle d’authentification à plusieurs niveaux dans lequel une authentification principale basée sur une usine de connaissances peut reposer soit sur une biométrie secondaire forte, soit sur des modalités tertiaires plus faibles.

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes suivantes comme méthode d'authentification principale :
  • Un code PIN numérique
  • Un mot de passe alphanumérique
  • Schéma de balayage sur une grille contenant exactement 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont désignées comme les principales méthodes d'authentification recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les principales méthodes d'authentification recommandées et utilisent une nouvelle méthode d'authentification comme moyen sécurisé de verrouiller l'écran, la nouvelle méthode d'authentification:

• [C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans la section Exiger l'authentification de l'utilisateur pour l'utilisation des clés.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage (à condition qu'elles soient basées sur un secret connu) et utilisent une nouvelle méthode d'authentification à considérer comme un moyen sécurisé de verrouiller l'écran:

• [C-3-1] L'entropie de la longueur d'entrées la plus courte DOIT être supérieure à 10 bits.
• [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
• [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer aucune des méthodes d'authentification principales recommandées (code, schéma, mot de passe) implémentées et fournies dans l'AOSP.
• [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING.
• [C-3-5] Les nouvelles méthodes d'authentification DOIVENT revenir aux méthodes d'authentification principales recommandées (par code, schéma ou mot de passe) toutes les 72 heures au maximum OU indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de leurs données.

Si les implémentations d'appareils ajoutent ou modifient les principales méthodes d'authentification recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie à traiter comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode:

• [C-4-1] DOIT respecter toutes les exigences décrites dans la section 7.3.10 de la classe 1 (anciennement facilité).
• [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui est basée sur un secret connu.
• [C-4-3] DOIT être désactivé et autoriser uniquement l'authentification principale recommandée pour déverrouiller l'écran lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle de protection du clavier en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures() , avec l'un des indicateurs biométriques associés (par exemple, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences de la classe 3 (anciennement Forte) décrites dans la section 7.3.10:

• [C-5-1] Les méthodes DOIVENT être désactivées si l'application DPC (Device Policy Controller) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] L'utilisateur DOIT être invité à procéder à l'authentification principale recommandée (par code, schéma ou mot de passe, par exemple), comme indiqué dans les sections [C-1-7] et [C-1-8] de la section 7.3.10.
• [C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé et DOIVENT respecter les exigences commençant par C-8 dans la présente section ci-dessous.

Si des implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur l'emplacement:

• [C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui repose sur un secret connu et remplit les conditions requises pour être considéré comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser que l'une des méthodes d'authentification principales recommandées pour déverrouiller l'écran lorsque l'application DPC (Device Policy Controller) a défini la règle avec la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par code, schéma ou mot de passe, par exemple) au moins une fois toutes les quatre heures au maximum.
• [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes indiquées dans C-8 ci-dessous.

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

• [C-7-1] DOIT avoir une indication claire dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou qu'il peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouiller automatiquement" et "Verrouillage instantané" dans le menu des paramètres, ainsi qu'une icône permettant de vous distinguer sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et implémenter intégralement toutes les API d'agent de confiance dans la classe DevicePolicyManager, comme la constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NE DOIT PAS implémenter entièrement la fonction TrustAgentService.addEscrowToken() sur un appareil utilisé comme appareil personnel principal (par exemple, portable), mais PEUT-ÊTRE l'implémenter complètement sur des implémentations d'appareils généralement partagées (par exemple, Android Television ou Android Automotive).
• [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
• [C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui où la clé est utilisée. Par exemple, une clé stockée sur un téléphone peut déverrouiller un compte utilisateur sur un téléviseur. Pour les appareils automobiles, le stockage du jeton de séquestre n'est pas autorisé sur quelque partie du véhicule.
• [C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'autoriser le jeton de séquestre à déchiffrer le stockage de données.
• [C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées.
• [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par code, schéma ou mot de passe, par exemple) au moins une fois toutes les 72 heures ou moins, sauf si sa sécurité (par exemple, en cas de distraction au volant) est préoccupante.
• [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par code, schéma ou mot de passe, par exemple), comme décrit dans les sections [C-1-7] et [C-1-8] de la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, en cas de distraction au volant) est préoccupante.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes indiquées dans le document C-8 ci-dessous.
• [C-7-11] NE DOIT PAS autoriser les TrustAgents sur des appareils personnels principaux (portables, par exemple) à déverrouiller l'appareil.Ils ne peuvent les utiliser que pour garder un appareil déjà déverrouillé à l'état déverrouillé pendant une durée maximale de quatre heures. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
• [C-7-12] DOIT utiliser un canal de communication cryptographiquement sécurisé (par exemple, UKEY2) pour transmettre le jeton de séquestre de l'appareil de stockage à l'appareil cible.

Si les appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage qui n'est pas un écran de verrouillage sécurisé, comme décrit ci-dessus, et utilisent une nouvelle méthode d'authentification pour déverrouiller le verrouillage du clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] Il NE DOIT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Ils NE DOIVENT PAS exposer d'API permettant à des applications tierces de modifier l'état de verrouillage.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un processeur sécurisé dédié ainsi que dans l'environnement d'exécution isolé décrit ci-dessus. Ce processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences qu'un appareil doit remplir pour être considéré comme une StrongBox.

Implémentations d'appareils disposant d'un processeur sécurisé dédié:

• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge StrongBox. StrongBox deviendra probablement une exigence dans une prochaine version.

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

• [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DOIT fournir du matériel sécurisé dédié 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, ni aucune mémoire vive (DRAM), coprocesseur ou autre ressource principale avec le processeur d'application (PA).

• [C-1-4] DOIT s'assurer que les périphériques partagés avec le point d'accès ne peuvent en aucun cas modifier le traitement de StrongBox, ni obtenir d'informations à partir de celui-ci. Le point d'accès PEUT désactiver ou bloquer l'accès à StrongBox.

• [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) et immunisée contre la manipulation par le point d'accès.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires produisant une sortie imprévisible et distribuée de manière uniforme.

• Les [C-1-7] DOIVENT disposer d'une résistance à la falsification, y compris à la pénétration physique et aux glitchs.

• [C-1-8] DOIT disposer d'une résistance du canal latéral, y compris la résistance aux fuites d'informations via les canaux latéraux de puissance, de temporisation, de rayonnement électromagnétique et de rayonnement thermique.

• [C-1-9] DOIT disposer d'un stockage sécurisé qui garantit la confidentialité, l'intégrité, l'authenticité, la cohérence et l'actualisation des contenus. L'espace de stockage NE DOIT PAS être lu ni modifié, sauf dans les cas autorisés par les API StrongBox.

• Pour valider la conformité avec les normes [C-1-3] à [C-1-9], les implémentations d'appareils:

  • [C-1-10] DOIT inclure le matériel certifié conforme au profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essais accrédité au niveau national qui procède à une évaluation des failles à fort potentiel d'attaque selon la norme commune d'application du potentiel d'attaque des cartes à puce.
  • [C-1-11] DOIT inclure le micrologiciel qui est évalué par un laboratoire d'essais accrédité au niveau national qui procède à une évaluation des failles à fort potentiel d'attaque, conformément à la norme commune d'application du potentiel d'attaque aux cartes à puce.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, niveau d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement une exigence dans une prochaine version.

• Les [C-SR] sont FORTEMENT RECOMMANDÉS pour offrir une résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature de micrologiciel ne peut pas produire de micrologiciel entraînant la fuite de secrets par la StrongBox, le contournement des exigences de sécurité fonctionnelles ou l'accès à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fourni via le HAL IAuthSecret.

9.11.3. Identifiants d'identité

Le système d'identifiants d'identité est défini et réalisé en implémentant toutes les API du package android.security.identity.*. Ces API permettent aux développeurs d'applications de stocker et de récupérer les documents d'identité des utilisateurs. Implémentations pour les appareils:

• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR] pour implémenter le système d'identification des identités.

Si les implémentations d'appareils implémentent le système d'identification de l'identité, celles-ci:

• [C-0-1] DOIT renvoyer une valeur non nulle pour la méthode IdentityCredentialStore#getInstance().

• [C-0-2] DOIT implémenter le système d'identification des identités (par exemple, les API android.security.identity.*) avec du code communiquant avec une application de confiance dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris la zone de marché désignée.

• [C-0-3] Les opérations cryptographiques nécessaires à l'implémentation du système d'identification des identités (par exemple, les API android.security.identity.*) DOIVENT être entièrement effectuées dans l'application approuvée, et le matériel de clé privée NE DOIT jamais quitter l'environnement d'exécution isolé, sauf si des API de niveau supérieur l'exigent spécifiquement (par exemple, la méthode createEphemeralKeyPair()).

• [C-0-4] L'application de confiance DOIT être implémentée de telle sorte que ses propriétés de sécurité ne soient pas affectées (par exemple, les données d'identification ne sont pas publiées, sauf si les conditions de contrôle d'accès sont remplies, les MAC ne peuvent pas être produits pour des données arbitraires), même si Android est défaillant ou 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 de données utilisateur.
• [C-0-3] DOIT supprimer les données conformément aux normes sectorielles pertinentes, telles que NIST SP800-88.
• [C-0-4] DOIT déclencher le processus de rétablissement de la configuration d'usine ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
• PEUT fournir une option d'effacement rapide des données qui n'effectue qu'une effacement logique des données.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le mode de démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

• [C-1-1] DOIT fournir à l'utilisateur une option permettant d'activer le mode Démarrage sécurisé de manière ininterrompue par rapport aux applications tierces installées sur l'appareil, sauf si l'application tierce est un outil de contrôle des règles relatives aux appareils et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

• [C-1-2] DOIT permettre à l'utilisateur de désinstaller des applications tierces en mode sans échec.

• DEVRAIT donner à l'utilisateur la possibilité d'activer le mode Démarrage sécurisé à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des sous-systèmes critiques du véhicule en utilisant le HAL du véhicule pour envoyer et recevoir des messages sur des réseaux de véhicules tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android afin d'empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits" désignent les détails du contrat de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils:

• [C-0-1] DOIT renvoyer les abonnements à l'application de l'opérateur mobile qui les a initialement fournis.
• [C-0-2] NE DOIT PAS sauvegarder ni importer de forfaits d'abonnement à distance.
• [C-0-3] DOIT autoriser uniquement les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), à partir de l'application de l'opérateur mobile proposant actuellement des abonnements valides.

9.16. Migration des données d'application

Si les implémentations d'appareils permettent de migrer les données d'un appareil vers un autre et ne limitent pas les données d'application qu'elles copient à celles configurées par le développeur de l'application dans le fichier manifeste via l'attribut android:fullBackupContent, elles:

• [C-1-1] NE DOIT PAS lancer de transferts de données d'application à partir d'appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale, comme décrit dans la section 9.11.1 Authentification et écran de verrouillage sécurisés.
• [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 le transfert de données.
• [C-1-3] DOIT utiliser l'attestation des clés de sécurité pour s'assurer que les appareils source et cible lors de la migration d'appareil à appareil sont des appareils Android légitimes et disposent d'un bootloader verrouillé.
• [C-1-4] DOIT migrer uniquement les données d'application vers la même application sur l'appareil cible, avec le même nom de package ET le même certificat de signature.
• [C-1-5] DOIT afficher dans le menu des paramètres une indication que des données ont été transférées via une migration de données d'appareil à appareil sur l'appareil source. Un utilisateur NE DOIT PAS être en mesure de supprimer cette indication.

10. Tests de compatibilité logicielle

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS d'apporter le moins de modifications possible à la référence et à l'implémentation préférée d'Android disponible dans le projet Android Open Source. Cela réduira le risque d'introduire des bugs qui créent des incompatibilités nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations pour les appareils:

• [C-0-1] DOIT réussir la suite de test de compatibilité Android (CTS) disponible dans le projet Open Source Android, en utilisant le logiciel d'expédition final installé sur l'appareil.

• [C-0-2] DOIT garantir la compatibilité en cas d'ambiguïté dans CTS et pour toute réimplémentation de parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. Les versions de la CTS seront indépendantes de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 11.

Implémentations pour les appareils:

• [C-0-3] DOIT réussir la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.

• DEVRAIT utiliser autant que possible l'implémentation de référence dans l'arborescence Android Open Source.

10.2. Vérificateur CTS

L'outil de vérification CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester des fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et d'un capteur.

Implémentations pour les appareils:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans l'outil de vérification CTS.

L'outil de vérification CTS effectue des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations pour les appareils:

• [C-0-2] DOIT réussir tous les tests de l'accéléromètre dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de l'accéléromètre dans l'outil de vérification CTS.

Les scénarios de test des fonctionnalités indiquées comme facultatives dans ce document de définition de compatibilité PEUVENT être ignorés ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement l'outil de vérification CTS, comme indiqué ci-dessus. Cependant, étant donné que de nombreux builds sont très similaires, les développeurs d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le vérificateur CTS uniquement par l'ensemble des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à jour

• [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à niveau "en direct", c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

  • Téléchargements "Over The Air (OTA)" avec mise à jour hors connexion via un redémarrage
  • Mises à jour "partagées" via USB à partir d'un PC hôte.
  • Mises à jour "hors connexion" par un redémarrage et la mise à jour à partir d'un fichier stocké sur un espace de 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 les données partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.

• [C-0-3] La mise à jour complète DOIT être signée et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.

• [C-SR] Le mécanisme de signature est VIVEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide de l'ECDSA NIST P-256.

Si les implémentations de l'appareil incluent la prise en charge d'une connexion de données illimitées comme un profil 802.11 ou un profil PAN Bluetooth (Personal Area Network), les conditions suivantes doivent être réunies:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Pour les implémentations d'appareils lancées avec Android 6.0 ou version ultérieure, le mécanisme de mise à jour DEVRAIT permettre de vérifier que l'image système est identique au résultat attendu après une OTA. L'implémentation OTA basée sur des blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT être compatibles avec les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide de la commande de démarrage HAL.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais pendant la durée de vie raisonnable du produit, déterminée en consultation avec l'équipe de compatibilité Android pour affecter la compatibilité des applications tierces:

• [C-2-1] L'équipe chargée de la mise en œuvre de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme qui vient d'être décrit.

Android inclut des fonctionnalités qui permettent à l'application 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 actions suivantes sont effectuées:

• [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 compatibilité dans cette version:

• Journal des modifications du document

Pour obtenir un résumé des modifications apportées à des sections spécifiques:

1. Introduction
2. Types d'appareils
3. Logiciel
4. Package d'application
5. Multimédia
6. Options et outils pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Test de compatibilité logicielle
11. Logiciel pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils d'affichage du journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications importantes apportées aux exigences de compatibilité.

• Docs
  Modifications esthétiques ou liées à la compilation.

Pour un affichage optimal, ajoutez les paramètres d'URL pretty=full et no-merges aux URL de votre journal de modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler des problèmes qui, selon vous, ne sont pas couverts par le document.