Définition de compatibilité Android 11

1. Introduction

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

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

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

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

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

De nombreuses ressources auxquelles ce document fait référence sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Toutes les informations techniques fournies dans les ressources associées de ce document sont considérées comme faisant partie de cette définition de la compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

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

1.1.2. ID de la condition

Un ID de contrainte est attribué aux contraintes obligatoires.

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

Chaque ID est défini comme suit:

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

1.1.3. ID de l'exigence dans la section 2

L'ID de l'exigence dans la section 2 commence par l'ID de la section correspondante, suivi de l'ID de l'exigence décrit ci-dessus.

• L'ID de la section 2 se compose de : l'ID de la section / l'ID du type d'appareil - l'ID de la condition - l'ID de l'exigence (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 différents types d'appareils et facteurs de forme, certains types d'appareils disposent 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'eux.

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

2.1 Configurations de l'appareil

Pour connaître les principales différences de configuration matérielle en fonction du type d'appareil, consultez les exigences spécifiques à chaque appareil dans la section suivante.

2.2. Exigences concernant les appareils portables

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

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

• disposer d'une source d'alimentation mobile, comme une batterie ;
• Avoir une diagonale d'écran physique comprise entre 3,3 pouces (ou 2,5 pouces pour les appareils lancés avec un niveau d'API antérieur à Android 11) et 8 pouces.

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

Remarque:Les exigences qui ne s'appliquent pas aux tablettes Android sont signalées par un astérisque (*).

2.2.1. Matériel

Implémentations pour appareils mobiles:

• [7.1.1.1/H-0-1] DOIT disposer d'au moins un écran compatible avec Android qui répond à toutes les exigences décrites dans ce document.
• [7.1.1.3/H-SR] Il est FORTEMENT RECOMMANDÉ de permettre aux utilisateurs de modifier la taille de l'écran (densité d'écran).

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

• [7.1.1.1/H-1-1]* L'écran logique mis à la disposition des applications tierces doit mesurer au moins 5,08 cm sur les bords courts et 6,86 cm sur les bords longs. Les appareils lancés avec un niveau d'API antérieur à celui de 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, elles:

• [7.1.1.1/H-2-1]* L'écran logique mis à la disposition des applications tierces doit mesurer au moins 6,9 cm sur le ou les côtés courts. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés de cette exigence.

Si les implémentations d'appareils portables indiquent la prise en charge des écrans HDR via Configuration.isScreenHdr() , elles:

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

Implémentations pour appareils mobiles:

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

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

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

Implémentations pour appareils mobiles:

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

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

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

• [7.3.3/H-2-1] DOIT signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/H-2-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0, 2 m/s près, au moins 95% du temps.

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

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

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

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

Implémentations pour appareils mobiles:

• [7.3.11/H-SR] Recommandé pour prendre en charge le capteur de position à six degrés de liberté.
• [7.4.3/H] La plate-forme DOIT prendre en charge le Bluetooth et le Bluetooth LE.

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

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

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

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

Implémentations pour appareils mobiles:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implémentations pour appareils mobiles:

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

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

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

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

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

Implémentations pour appareils mobiles:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.10/H-SR]* Nous vous RECOMMANDONS FORTEMENT de ne pas utiliser d'actionneur haptique (vibreur) à masse rotative excentrique(ERM).
• [7.10/H]* L'emplacement de l'actionneur DOIT se trouver à proximité de l'endroit où l'appareil est généralement tenu ou touché par les mains.
• [7.10/H-SR]* Nous vous RECOMMANDONS vivement d'implémenter toutes les constantes publiques pour les haptiques claires dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START et GESTURE_END).
• [7.10/H-SR]* Nous vous RECOMMANDONS vivement d'implémenter toutes les constantes publiques pour les haptiques claires dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK), ainsi que toutes les constantes publiques pour les haptiques riches dans android.os.VibrationEffect.Composition, à savoir (PRIMITIVE_CLICK et PRIMITIVE_TICK).
• [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 fonctionnalités de scalabilité de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

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

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

• [7.10/H]* : le moteur haptique doit se déplacer sur l'axe X en mode portrait.

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

• [7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ que la fréquence de résonance de l'LRA de l'axe X soit inférieure à 200 Hz.

Si les implémentations d'appareils portables suivent la mise en correspondance des 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 des applications tierces:

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

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

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

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

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

2.2.3. Logiciel

Implémentations pour appareils mobiles:

• [3.2.3.1/H-0-1] Une application doit gérer les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT, comme décrit dans les documents du SDK, et fournir à l'utilisateur la possibilité d'accéder aux données du fournisseur de documents à l'aide de l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
• [3.2.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ de précharger une application de messagerie capable de gérer les intents ACTION_SENDTO, ACTION_SEND ou ACTION_SEND_MULTIPLE pour envoyer un e-mail.
• [3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
• [3.4.2/H-0-1] L'application doit inclure un navigateur autonome pour la navigation Web des utilisateurs.
• [3.8.1/H-SR] Nous vous RECOMMANDONS vivement d'implémenter un lanceur par défaut compatible avec l'épinglage de raccourcis, de widgets et de widgetFeatures dans l'application.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
• [3.8.1/H-SR] Il est vivement recommandé d'inclure une application de lanceur par défaut qui affiche des badges pour les icônes d'application.
• [3.8.2/H-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les widgets d'applications tierces.
• [3.8.3/H-0-1] Les applications tierces doivent être autorisées à informer les utilisateurs d'événements notables via les classes d'API Notification et NotificationManager.
• [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
• [3.8.3/H-0-3] DOIT prendre en charge les notifications heads-up.
• [3.8.3/H-0-4] DOIT inclure une barre de notification permettant à l'utilisateur de contrôler directement les notifications (par exemple, répondre, répéter, ignorer, bloquer) via des affordances utilisateur telles que des boutons d'action ou le panneau de contrôle tel qu'implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via RemoteInput.Builder setChoices() dans la barre de notification sans interaction utilisateur supplémentaire.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher tous les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
• [3.8.3.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true en ligne avec les réponses affichées par Notification.Remoteinput.Builder.setChoices.
• [3.8.4/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

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

• [3.8.4/H-SR] Nous vous RECOMMANDONS vivement d'utiliser l'appui prolongé sur la touche HOME comme interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3. DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService , ou une activité qui gère l'intent ACTION_ASSIST.

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

• [3.8.4/H-1-1]* Les notifications de conversation doivent être affichées avant les notifications autres que de conversation, à l'exception des notifications de service de premier plan en cours et des notifications importance:high.

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

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

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

• [3.9/H-1-1] DOIT implémenter l'ensemble des stratégies d'administration des appareils définies dans la documentation du SDK Android.
• [3.9/H-1-2] DOIT déclarer la prise en charge des profils gérés via le flag de fonctionnalité android.software.managed_users, sauf lorsque l'appareil est configuré pour s'enregistrer comme un appareil à faible quantité de RAM ou pour qu'il alloue de l'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 permettent aux applications tierces de publier des commandes d'appareil, elles:

• [3.8.16/H-1-1] DOIT déclarer le flag de fonctionnalité android.software.controls et le définir sur true.
• [3.8.16/H-1-2] DOIT fournir une affordance utilisateur permettant d'ajouter, de modifier, de sélectionner et d'utiliser les commandes d'appareil préférées de l'utilisateur à partir des commandes enregistrées par les applications tierces via les API ControlsProviderService et Control.
• [3.8.16/H-1-3] DOIT fournir un accès à cette affordance utilisateur dans les trois interactions à partir d'un lanceur d'applications par défaut.
• [3.8.16/H-1-4] Cette affordance utilisateur DOIT afficher avec précision 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 comportent pas de telles commandes, elles:

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

Implémentations pour appareils mobiles:

• [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 sur l'appareil des services d'accessibilité comparables ou supérieurs aux fonctionnalités des services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), comme indiqué dans le projet Open Source talkback.
• [3.11/H-0-1] DOIT prendre en charge 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 vivement recommandé d'inclure un composant d'UI de paramètres rapides.

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

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

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

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

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

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

2.2.4. Performances et puissance

• [8.1/H-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
• [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
• [8.1/H-0-3] Changement de tâche. Lorsque plusieurs applications ont été lancées, le redémarrage d'une application déjà en cours d'exécution doit prendre moins d'une seconde.

Implémentations pour appareils mobiles:

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

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

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

Implémentations pour appareils mobiles:

• [8.4/H-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [8.4/H-0-2] Toutes les valeurs de consommation d'énergie DOIVENT être exprimées 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 Open Source Android répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
• [8.4/H-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.
• [8.4/H] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

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

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

2.2.5. Modèle de sécurité

Implémentations pour appareils mobiles:

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

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

• [9.11/H-0-2]* : vous devez sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
• [9.11/H-0-3]* : le système doit impérativement implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [9.11/H-0-4]* : L'authentification de l'écran de verrouillage doit être effectuée dans l'environnement d'exécution isolé. Seules les clés liées à l'authentification peuvent être utilisées si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/H-0-5]* : L'appareil DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

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

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

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

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

• [9.5/H-3-1] Les profils restreints NE DOIVENT PAS être pris en charge, mais doivent être conformes à l'implémentation des commandes AOSP pour autoriser ou non d'autres utilisateurs à accéder aux appels vocaux et aux SMS.

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

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

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

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

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

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

2.2.7.1. Contenus multimédias

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

• [5.1/H-1-1] DOIT annoncer le nombre maximal de sessions de décodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur 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-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 et d'encodeur vidéo matériels (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-7] La latence d'initialisation du codec doit être de 65 ms ou moins pour une session d'encodage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels (à l'exception du codec Dolby Vision) en charge. La charge ici est définie comme une session de transcodage vidéo uniquement en 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo en 1080p.
• [5.1/H-1-8] La latence d'initialisation du codec doit être de 50 ms ou moins pour une session d'encodage audio à 128 kbit/s ou moins pour tous les encodeurs audio en charge.La charge ici est définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi que l'initialisation de l'enregistrement audio-vidéo 1080p.
• [5.3/H-1-1] NE DOIT PAS perdre plus d'une image toutes les 10 secondes (c'est-à-dire moins de 0,333 % de perte d'image) pour une session vidéo 1080p 30 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC à 128 kbps.
• [5.3/H-1-2] NE DOIT PAS perdre plus d'un frame en 10 secondes lors d'un changement de résolution vidéo dans une session vidéo à 30 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement 1080p vers 720p simultanée à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC à 128 kbit/s.
• [5.6/H-1-1] La latence de la pression pour un son doit être inférieure à 100 millisecondes à l'aide du test de pression pour un son OboeTester ou du test de pression pour un son 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, elles:

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

2.2.7.3. Matériel

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

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

2.2.7.4. Performances

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

• [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éatoires 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. Exigences concernant les téléviseurs

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

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

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

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

2.3.1. Matériel

Implémentations d'appareils TV:

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

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

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

Implémentations d'appareils TV:

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

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

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

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

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

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

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

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

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

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

Implémentations d'appareils TV:

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

2.3.2. Multimédia

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

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

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

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

Implémentations d'appareils TV:

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

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

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

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

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

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

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

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

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

Si les implémentations d'appareils de télévision avec des décodeurs matériels H.265 prennent en charge le décodage H.265 et le profil de décodage UHD, elles:

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

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

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

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

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

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

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

Implémentations d'appareils TV:

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

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

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

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

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

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

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

2.3.3. Logiciel

Implémentations d'appareils TV:

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

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

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

Implémentations d'appareils TV:

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

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

• [3.11/T-SR] 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 prendre en charge l'installation de moteurs de synthèse vocale tiers.

Implémentations d'appareils TV:

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

2.3.4. Performances et puissance

• [8.1/T-0-1] Latence des images cohérente. La latence des images incohérente ou le délai de rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
• [8.2/T-0-1] DOIT assurer des performances d'écriture séquentielle d'au moins 5 Mo/s.
• [8.2/T-0-2] DOIT assurer 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 d'appareils de télévision incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP ou qui étendent les fonctionnalités incluses dans AOSP, elles:

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

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

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

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

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

Implémentations d'appareils TV:

• [8.4/T-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [8.4/T-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
• [8.4/T-0-3] DOIT indiquer la consommation d'énergie du processeur par UID de chaque processus. Le projet Open Source Android répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
• [8.4/T] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
• [8.4/T-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.3.5. Modèle de sécurité

Implémentations d'appareils TV:

• [9.11/T-0-1] L'implémentation du keystore doit être sauvegardée avec un environnement d'exécution isolé.
• [9.11/T-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/T-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

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

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

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

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

• [9.5/T-3-1] L'application NE DOIT PAS prendre en charge les profils restreints, mais DOIT respecter l'implémentation des commandes AOSP pour autoriser ou non d'autres utilisateurs à accéder aux appels vocaux et aux SMS.

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

Implémentations d'appareils TV:

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

2.4. Configuration requise pour la montre

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

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

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

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

2.4.1. Matériel

Implémentations des appareils de visionnage:

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

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

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

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

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

• [7.3.3/W-1-1] DOIT signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/W-1-2] DOIT indiquer les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0, 2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0, 2 m/s près, au moins 95% du temps.

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

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

Implémentations des appareils de visionnage:

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

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

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

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

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

2.4.2. Multimédia

Aucune autre condition requise.

2.4.3. Logiciel

Implémentations des appareils de visionnage:

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

Implémentations des appareils de visionnage:

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

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

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

Si les implémentations d'appareils de 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 prendre en charge l'installation de moteurs de synthèse vocale tiers.

2.4.4. Performances et puissance

Si les implémentations d'appareils connectés incluent des fonctionnalités de gestion de l'alimentation de l'appareil incluses dans AOSP ou qui en étendent les fonctionnalités, elles:

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

Implémentations des appareils de visionnage:

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

2.4.5. Modèle de sécurité

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

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

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

• [9.5/W-2-1] Les profils restreints NE DOIVENT PAS être compatibles, mais doivent respecter l'implémentation des commandes AOSP pour autoriser ou non d'autres utilisateurs à accéder aux appels vocaux et aux SMS.

2.5. Exigences pour le secteur automobile

L'implémentation d'Android Automotive désigne une unité principale de véhicule qui utilise 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 comme Automotive si elles déclarent la fonctionnalité android.hardware.type.automotive ou si elles répondent à tous les critères suivants.

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

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

2.5.1. Matériel

Implémentations d'appareils automobiles:

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

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

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

• [7.2.3/A-0-2] DOIT envoyer à l'application au premier plan l'événement de pression normale et de pression prolongée de la fonction Retour (KEYCODE_BACK).
• [7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.
• [7.3/A-0-2] La valeur de l'indicateur NIGHT_MODE DOIT être cohérente avec le mode jour/nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de lumière ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.
• [7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires sur le capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
• [7.3/A-0-1] PEUT calculer la position par triangulation en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est déterminée par un calcul de position, nous vous recommandons vivement d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants utilisés.
• [7.3/A-0-2] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être mise en correspondance avec la carte.

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

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

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

• [7.3.4/A-2-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 100 Hz.
• [7.3.4/A-2-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] Nous vous RECOMMANDONS vivement de configurer la plage de mesure du gyroscope sur +/- 250 dps afin de maximiser la résolution possible.

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

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

Implémentations d'appareils automobiles:

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

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

• [7.4.5/A] DOIT prendre en charge la connectivité de données basée sur un réseau mobile.

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

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

Implémentations d'appareils automobiles:

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

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

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

Implémentations d'appareils automobiles:

• [7.6.1/A-0-1] 4 Go de stockage non volatile minimum doivent être disponibles pour les données privées de l'application (également appelée partition "/data").

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

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

• [7.6.1/A-SR] FORTEMENT RECOMMANDÉ pour réduire les coûts d'E/S sur les opérations effectuées sur le stockage externe, par exemple en utilisant SDCardFS.

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

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

  • 280 dpi ou moins sur les écrans de petite/moyenne taille
  • ldpi ou moins sur les écrans très grands formats
  • mdpi ou moins sur les grands écrans

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

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

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

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

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

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

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

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

  • 280 dpi ou moins sur les écrans de petite/moyenne taille
  • ldpi ou moins sur les écrans très grands formats
  • mdpi ou moins sur les grands écrans

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

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

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

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

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

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

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

Implémentations d'appareils automobiles:

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

Implémentations d'appareils automobiles:

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

Implémentations d'appareils automobiles:

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

2.5.2. Multimédia

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

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

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

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

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

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

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

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

2.5.3. Logiciel

Implémentations d'appareils automobiles:

• [3/A-0-1] Vous DEVEZ 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 à l'aide de android.car.CarPropertyManager avec android.car.VehiclePropertyIds, elles:

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

Implémentations d'appareils automobiles:

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

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

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

• [3.8.3/A-0-1] DOIT afficher les notifications qui utilisent l'API Notification.CarExtender lorsque demandées par des applications tierces.

• [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 Automotive incluent un bouton PTT:

• [3.8.4/A-1-1] L'interaction désignée pour lancer l'application d'assistance sélectionnée par l'utilisateur (autrement dit, l'application qui implémente VoiceInteractionService) DOIT être un appui bref sur le bouton PTT.

Implémentations d'appareils automobiles:

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

Implémentations d'appareils automobiles:

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

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

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

Implémentations d'appareils automobiles:

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

2.5.4. Performances et puissance

Implémentations d'appareils automobiles:

• [8.2/A-0-1] DOIT indiquer le nombre d'octets lus et écrits dans l'espace de stockage non volatile pour chaque UID de processus afin que les statistiques soient disponibles pour les développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence via le module du noyau uid_sys_stats.
• [8.3/A-1-3] DOIT prendre en charge le mode Garage.
• [8.3/A] Le véhicule DOIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf si :
  • La batterie est déchargée.
  • Aucune tâche inactive n'est planifiée.
  • Le conducteur quitte le mode Garage.
• [8.4/A-0-1] DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [8.4/A-0-2] Toutes les valeurs de consommation d'énergie doivent être exprimées 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 Open Source Android répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
• [8.4/A] DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
• [8.4/A-0-4] Le développeur de l'application DOIT pouvoir accéder à cette consommation d'énergie via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

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

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

Implémentations d'appareils automobiles:

• [9.11/A-0-1] L'implémentation du keystore doit être sauvegardée avec un environnement d'exécution isolé.
• [9.11/A-0-2] Le système doit impérativement implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [9.11/A-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/A-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

Implémentations d'appareils automobiles:

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

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

Implémentations d'appareils automobiles:

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

2.6. Conditions requises pour les tablettes

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

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

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

2.6.1. Matériel

Taille de l'écran

• [7.1.1.1/Tab-0-1] L'écran doit mesurer entre 7 et 18 pouces.

Gyroscope

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

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

Mémoire et stockage minimums (section 7.6.1)

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

Mode périphérique USB (section 7.7.1)

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

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

Mode réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

Les exigences liées à la réalité virtuelle ne s'appliquent pas aux tablettes.

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

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

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

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

• [9.5/T-2-1] Les profils restreints NE DOIVENT PAS être pris en charge, mais doivent être conformes à l'implémentation des commandes AOSP pour autoriser ou non d'autres utilisateurs à accéder aux appels vocaux et aux SMS.

2.6.2. Logiciel

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

3. Logiciel

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

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

Implémentations de l'appareil:

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

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

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

• [C-0-4] Les API doivent toujours être 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. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.

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

• [C-0-6] Chaque interface non SDK doit être fournie dans les mêmes listes de restrictions que celles fournies via les indicateurs provisoires et de liste de refus dans le chemin d'accès prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche de niveau d'API appropriée dans l'AOSP.

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

  Toutefois, ils:

  • Si une API masquée est absente ou implémentée différemment sur l'implémentation de l'appareil, vous pouvez la placer sur la liste de blocage ou l'omettre de toutes les listes de restriction (gris clair, gris foncé, noir).
  • Vous pouvez ajouter une API masquée à l'une des listes de restriction (gris clair, gris foncé ou noir) si elle n'existe pas déjà dans l'AOSP.

3.1.1. Extensions Android

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

Implémentations d'appareils Android:

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

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

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

3.1.2. Bibliothèque Android

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

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

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

3.2. Compatibilité des API avec une compatibilité douce

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

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

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

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application courants

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

Implémentations de l'appareil:

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

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

3.2.3.2. Résolution des intents

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

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

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

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

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

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

3.2.3.3. Espaces de noms d'intent

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

3.2.3.4. Intents de diffusion

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

Implémentations de l'appareil:

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

3.2.3.5. Intents d'application conditionnels

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

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

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

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

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

• [C-2-1] DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.

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

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

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

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

• [C-2-5] DOIT fournir à l'utilisateur la possibilité de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.
• [C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW, et fournir une activité pour envoyer/afficher des SMS.
• [C-SR] Il est fortement recommandé de respecter les intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW et android.intent.action.DIAL avec une application de numérotation préchargée pouvant gérer ces intents et fournir l'exécution comme décrit dans le SDK.

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

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

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

• [C-4-1] DOIT respecter 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 pour ces intents, comme décrit dans le SDK.

Si les implémentations de l'appareil sont compatibles avec VoiceInteractionService et qu'elles ont installé plusieurs applications utilisant cette API en même temps, elles:

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

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

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

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

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

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

• [C-7-1] DOIT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des modes de saisie tiers en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

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

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

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

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

Si les implémentations d'appareils fournissent le mode Économiseur de données: * [C-10-1] DOIVENT 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 de les en supprimer.

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

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

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

• [C-12-1] DOIT respecter l'intent android.media.action.STILL_IMAGE_CAMERA et android.media.action.STILL_IMAGE_CAMERA_SECURE, et lancer l'appareil photo en mode photo, comme décrit dans le SDK.
• [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 les intents suivants : MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE et MediaStore.ACTION_VIDEO_CAPTURE, comme décrit dans le document du SDK.

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

• [C-13-1] DOIT respecter l'intent android.app.action.ADD_DEVICE_ADMIN pour appeler une UI permettant à l'utilisateur d'ajouter l'administrateur de l'appareil au système (ou 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, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD et android.app.action.START_ENCRYPTION, et doit disposer d'une activité pour répondre à ces intents, comme décrit dans le SDK ici.

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

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

Si les implémentations de l'appareil incluent une application préinstallée ou si vous souhaitez autoriser des applications tierces à accéder aux statistiques d'utilisation, procédez comme suit:

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

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

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

Si les implémentations 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_SAMPLE_TEXT. Une activité doit être fournie pour répondre à ces intents, comme décrit dans le SDK ici.

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

• DOIT prendre en charge les économiseurs d'écran et fournir une option de paramètres permettant aux utilisateurs de les configurer en réponse à l'intent android.settings.DREAM_SETTINGS.

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

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

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

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

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

3.3. Compatibilité avec les API natives

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

• [SR] Nous vous recommandons vivement d'utiliser les implémentations des bibliothèques listées ci-dessous à partir du projet Open Source Android en amont.

3.3.1. Interfaces binaires d'application

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

Implémentations de l'appareil:

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

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

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

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

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

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

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

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

3.3.2. Compatibilité du code natif ARM 32 bits

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

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

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

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

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

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

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

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

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

• [C-1-1] DOIT signaler android.software.webview.
• [C-1-2] Vous devez utiliser la version du projet Chromium à partir 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 à celle d'android.os.Build.VERSION.RELEASE.
  • La chaîne $(MODEL) PEUT être vide, mais si elle ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
  • "Build/$(BUILD)" peut être omis, mais si cette valeur est présente, la chaîne $(BUILD) DOIT être identique à la valeur d'android.os.Build.ID.
  • La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Open Source Android en amont.
  • Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

• Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il le fait, DOIT respecter la spécification 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 rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter avec un ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès direct au réseau et n'avoir accès qu'aux services système requis au minimum via Binder. L'implémentation AOSP de WebView répond à cette exigence.

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

3.4.2. Compatibilité avec les navigateurs

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

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

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

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

3.5. Compatibilité du comportement des API

Implémentations de l'appareil:

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

Les comportements de chacun des types d'API (géré, soft, natif et Web) doivent être cohérents avec l'implémentation privilégiée du projet Open Source Android en amont. Voici quelques domaines de compatibilité spécifiques:

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

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

3.5.1. Restriction d'application

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

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

3.6. Espaces de noms d'API

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

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

En d'autres termes:

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

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

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

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

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

Si un implémentateur d'appareil propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT accéder à source.android.com et commencer le processus d'envoi de modifications et de code, conformément aux informations disponibles sur ce site.

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

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

Implémentations de l'appareil:

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

• [C-0-2] Vous DEVEZ configurer les environnements d'exécution Dalvik pour qu'ils allouent de la mémoire conformément à la plate-forme Android en amont et comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)

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

• DOIT exécuter des tests de fuzz dans différents modes d'exécution et architectures cibles pour assurer la stabilité de l'environnement d'exécution. Consultez JFuzz et DexFuzz sur le site Web du projet Android Open Source.

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

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

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

Android inclut une application de lanceur (écran d'accueil) et est compatible avec des applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil).

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

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

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

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

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

• [C-3-1] DOIT indiquer 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, elles:

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

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

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

3.8.2. Widgets

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

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

• [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.
• [C-1-2] DOIT inclure une prise en charge intégrée des AppWidgets et exposer des affordances d'interface utilisateur permettant d'ajouter, de configurer, d'afficher et de supprimer des AppWidgets directement dans le lanceur d'applications.
• [C-1-3] DOIT être capable d'afficher des widgets de 4 x 4 dans la taille de grille standard. Pour en savoir plus, consultez les Consignes de conception des widgets d'application dans la documentation du SDK Android.
• PEUT prendre en charge les widgets d'application sur l'écran de verrouillage.

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

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

3.8.3. Notifications

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

3.8.3.1. Présentation des notifications

Si les implémentations d'appareils autorisent les applications tierces à avertir les utilisateurs d'événements notables, elles:

• [C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.
• [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, bien qu'elles PUISSENT offrir une expérience utilisateur différente pour les notifications que celle fournie par l'implémentation Android Open Source de référence.
• [C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API afin de mettre à jour, supprimer et regrouper les notifications.
• [C-1-4] DOIT fournir le comportement complet de l'API NotificationChannel documentée dans le SDK.
• [C-1-5] DOIT fournir une affordance utilisateur permettant de bloquer et de modifier les notifications d'une application tierce par canal et par 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 avec le texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, vous devez afficher toutes les ressources, y compris les icônes fournies via android.app.Person dans une conversation de groupe définie via setGroupConversation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de proposer automatiquement une affordance utilisateur pour bloquer la notification d'une application tierce par canal et par niveau de package d'application après que l'utilisateur a ignoré cette notification plusieurs fois.
• DOIT prendre en charge les notifications enrichies.
• DOIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
• DOIT comporter une affordance permettant à l'utilisateur de répéter les notifications.
• NE DOIT GÉRER QUE la visibilité et le moment où les applications tierces peuvent avertir les utilisateurs d'événements notables afin de réduire les problèmes de sécurité tels que la distraction du conducteur.

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

Implémentations de l'appareil:

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

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

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

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

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

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

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

3.8.3.2. Service de notification de l'auditeur

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

Implémentations de l'appareil:

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

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

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

3.8.3.3. Ne pas déranger

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

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

3.8.4. Recherche

Android inclut des API qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. En général, cette fonctionnalité consiste en une interface utilisateur unique, à l'échelle du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions au fur et à mesure de la saisie et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.

• Les implémentations d'appareils Android DOIVENT inclure une recherche globale, une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de proposer des suggestions en temps réel en réponse à l'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 qui permettent aux applications tierces d'ajouter des suggestions dans le champ de recherche lorsqu'il est exécuté en mode recherche globale.

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

• Le comportement par défaut DOIT être l'affichage des résultats et des suggestions du moteur de recherche sur le Web.

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

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

• [C-2-1] L'utilisateur final doit être informé clairement du moment où le contexte est partagé, par l'un des moyens suivants :
  • Chaque fois que l'application d'assistance accède au contexte, elle affiche une lumière blanche autour des bords de l'écran qui correspond ou dépasse la durée et la luminosité de l'implémentation du projet Android Open Source.
  • Pour l'application d'assistance préinstallée, fournir une affordance utilisateur à moins de deux navigations du menu des paramètres par défaut de l'application d'assistance et de la saisie vocale, et ne partager le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou une saisie de touche de navigation d'assistance.
• [C-2-2] L'interaction désignée pour lancer l'application d'assistance, comme décrit dans la section 7.2.3, DOIT lancer l'application d'assistance sélectionnée par l'utilisateur, c'est-à-dire l'application qui implémente VoiceInteractionService ou une activité qui gère l'intent ACTION_ASSIST.

3.8.5. Alertes et notifications toast

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

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

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

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

3.8.6. Thèmes

Android fournit des "thèmes" 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 reproduire l'apparence du thème Holo tel que défini par le SDK Android.

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

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

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

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

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

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

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

3.8.7. Fonds d'écran animés

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

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment trop de puissance de processeur ou de batterie, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

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

3.8.8. Changement d'activité

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

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

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

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

3.8.9. Gestion des entrées

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

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

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

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

L'API Client de télécommande est obsolète à partir d'Android 5.0 et est remplacée par le modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage.

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

Consultez la section 3.2.3.5 pour connaître l'intent de paramètres permettant de configurer les écrans de veille.

3.8.12. Position

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

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

3.8.13. Unicode et police

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

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

• [C-1-1] La plate-forme DOIT être capable d'afficher ces caractères emoji sous forme de glyphes en couleur.
• [C-1-2] DOIT inclure la prise en charge des éléments suivants :
  • Police Roboto 2 avec différents épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
  • Couverture complète de l'alphabet latin, grec et cyrillique dans Unicode 7.0, y compris les plages Latin Extended A, B, C et D, ainsi que tous les glyphes du bloc des symboles de devises d'Unicode 7.0.
• DOIT être compatible avec les emoji de couleur de peau et de famille variés, comme indiqué dans le rapport technique Unicode 51.

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

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

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

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

* [C-2-1] 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 peuvent afficher plusieurs activités en même temps, elles:

• [C-1-1] DOIT implémenter ces modes multifenêtre conformément aux comportements des applications et aux API décrites dans la documentation de compatibilité 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 la largeur de l'écran est inférieure à 440 dp.
• [C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp dans les modes multifenêtre autres que le mode Picture-in-picture.
• Les implémentations d'appareils avec une taille d'écran de xlarge DOIVENT être compatibles avec le mode Format libre.

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

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

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

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

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

  • Les appareils dont la valeur Configuration.uiMode est différente de UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur et une hauteur minimales de 108 dp.
  • Les appareils dont la valeur Configuration.uiMode est définie sur UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

3.8.15. Encoche

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

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

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

3.8.16. Commandes de contrôle des appareils

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

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

3.9. Gestion de l'appareil

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

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

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

3.9.1 Préparation de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

Si les implémentations d'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] L'application DPC doit être enregistrée en tant qu'application propriétaire de l'appareil si l'appareil déclare la compatibilité avec la technologie NFC (communication en champ proche) via l'indicateur de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de type MIME MIME_TYPE_PROVISIONING_NFC.
  • Lorsque l'implémentation de l'appareil contient des données utilisateur :
    • [C-1-6] DOIT indiquer false pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] Vous ne devez plus enregistrer d'application DPC en tant qu'application propriétaire de l'appareil.
• [C-1-2] L'utilisateur doit impérativement effectuer une action affirmative avant ou pendant le processus de provisionnement pour accepter que l'application soit définie comme propriétaire de l'appareil. Le consentement peut être obtenu par action de l'utilisateur ou par des moyens programmatiques, mais un avis de divulgation approprié (comme indiqué dans l'AOSP) DOIT être affiché avant le début du provisionnement du propriétaire de l'appareil. De plus, le mécanisme de consentement programmatique du propriétaire de l'appareil utilisé (par les entreprises) pour le provisionnement du propriétaire de l'appareil NE DOIT PAS interférer avec l'expérience prête à l'emploi pour une utilisation non professionnelle.
• [C-1-3] LE CONSENTEMENT NE DOIT PAS être encodé en dur ni empêcher l'utilisation d'autres applications appartenant au propriétaire de l'appareil.

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

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

3.9.1.2 Provisionnement de profils gérés

Si les implémentations d'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] L'expérience utilisateur du processus de provisionnement de profil géré (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE) DOIT être conforme à l'implémentation AOSP.

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

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

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] Les API android.app.admin.DevicePolicyManager doivent prendre en charge les profils gérés.
• [C-1-2] Un seul profil géré peut être créé.
• [C-1-3] DOIT utiliser un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, comme "Récents" et "Notifications".
• [C-1-4] DOIT afficher une icône de notification (similaire au badge professionnel en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
• [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se réveille (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, le "sélecteur d'intents" doit afficher une affordance visuelle pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si cette fonctionnalité est activée par le contrôleur de règles d'appareil.
• [C-1-7] Lorsqu'un profil géré existe, il DOIT exposer les affordances utilisateur suivantes à la fois pour l'utilisateur principal et le profil géré :
  • Comptabilisation distincte de l'utilisation de la batterie, de la position, 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 l'utilisateur principal ou le profil géré.
  • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré.
  • Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
• [C-1-8] DOIT s'assurer que les applications préinstallées de numérotation, de contacts et de messagerie peuvent rechercher et consulter les informations sur l'appelant du profil géré (le cas échéant) ainsi que celles du profil principal, si le contrôleur de stratégie de l'appareil l'autorise.
• [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.

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

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

3.9.3 Assistance utilisateur gérée

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

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

3.10. Accessibilité

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

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

• [C-1-1] DOIT fournir une implémentation du framework d'accessibilité Android, comme décrit dans la documentation du SDK sur les API d'accessibilité.
• [C-1-2] DOIT générer des événements d'accessibilité et transmettre le AccessibilityEvent approprié à toutes les implémentations AccessibilityService enregistrées, comme indiqué dans le SDK.
• [C-1-4] DOIT 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 cette exigence n'est pas applicable aux implémentations d'appareils sans barre de navigation système, mais les implémentations d'appareils DOIVENT fournir une affordance utilisateur pour contrôler ces services d'accessibilité.

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

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

3.11. Synthèse vocale

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

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

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

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

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

3.12. TV Input Framework

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

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

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

3.13. Les réglages rapides

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

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

• [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les cartes fournies via les API quicksettings à partir d'une application tierce.
• [C-1-2] NE DOIT PAS ajouter automatiquement une carte d'une application tierce directement aux paramètres rapides.
• [C-1-3] DOIT afficher toutes les cartes ajoutées par l'utilisateur à partir d'applications tierces, ainsi que les cartes de réglages rapides fournies par le système.

3.14. Interface utilisateur multimédia

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

• [C-1-2] DOIT afficher clairement les icônes obtenues via getIconBitmap() ou getIconUri() et les titres obtenus via getTitle(), comme décrit dans MediaDescription. Peut raccourcir les titres pour respecter les règles de sécurité (par exemple, en cas de distraction du conducteur).

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

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

• [C-1-5] Le double appui sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE doit être considéré comme 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 applications instantanées ne doivent être autorisées qu'à utiliser les autorisations pour lesquelles android:protectionLevel est défini sur "instant".
• [C-0-2] Les applications instantanées NE DOIVENT PAS interagir avec les applications installées via des intents implicites, sauf si l'une des conditions suivantes est remplie :
  • Le filtre de modèle d'intent du composant est exposé et comporte CATEGORY_BROWSABLE.
  • L'action est ACTION_SEND, ACTION_SENDTO ou ACTION_SEND_MULTIPLE.
  • La cible est exposée explicitement avec android:visibleToInstantApps
• [C-0-3] Les applications instantanées NE DOIVENT PAS interagir explicitement avec les applications installées, sauf si le composant est exposé via android:visibleToInstantApps.
• [C-0-4] Les applications installées NE DOIVENT PAS voir les informations sur les applications instantanées sur l'appareil, sauf si l'application instantanée se connecte explicitement à l'application installée.

Si les implémentations de l'appareil sont compatibles avec les applications instantanées, elles:

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

3.16. Association d'un appareil associé

Android est compatible avec l'association d'appareils associés pour gérer plus efficacement l'association avec les appareils associés. Il 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 de l'appareil associé, elles:

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

3.17. Applications lourdes

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

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

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

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

3.18. Contacts

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

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

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

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

Implémentations de l'appareil:

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

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

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

4. Compatibilité du packaging des applications

Implémentations des appareils:

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

Implémentations de l'appareil:

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

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

• [C-0-5] Une activité doit gérer l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.

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

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

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

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

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

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

• [C-0-9] DOIT être compatible avec la validation 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 [C-0-8] et [C-0-9] via une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

5. Compatibilité multimédia

Implémentations de l'appareil:

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

Implémentations de l'appareil:

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

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

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

5.1. Codecs multimédias

5.1.1. Encodage audio

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

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

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

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

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

5.1.2. Décodage audio

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

Si les implémentations d'appareils déclarent la prise en charge de la fonctionnalité android.hardware.audio.output, elles doivent prendre en charge le décodage des formats audio suivants:

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

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

• [C-2-1] Le décodage DOIT être effectué sans downmix (par exemple, un flux AAC 5.0 doit être décodé en cinq canaux PCM, un flux AAC 5.1 doit être décodé en six canaux PCM).
• [C-2-2] Les métadonnées de plage dynamique DOIVENT être conformes à la section "Contrôle de la plage dynamique (DRC)" de la norme ISO/CEI 14496-3, ainsi qu'aux clés DRC android.media.MediaFormat pour configurer les comportements liés à la plage dynamique du décodeur audio. Les clés AAC DRC ont été introduites dans l'API 21. Il s'agit de: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL et KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] Il est vivement recommandé que tous les décodeurs audio AAC respectent les exigences C-2-1 et C-2-2 ci-dessus.

Lors du décodage de l'audio USAC, MPEG-D (ISO/IEC 23003-4):

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

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

• PEUT être compatible avec le contrôle du volume et de la plage dynamique à l'aide du profil de contrôle de la plage dynamique ISO/CEI 23003-4.

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

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

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

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

5.1.3. Détails des codecs audio

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

5.1.4. Encodage d'image

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

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

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

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

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

5.1.5. Décodage d'image

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

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

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

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

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

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

5.1.6. Détails des codecs d'image

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

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

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

• [SR] Il est vivement recommandé de prendre en charge le format de couleur RGB888 pour le mode Surface d'entrée.

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

5.1.7. Codecs vidéo

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

Si les implémentations de l'appareil incluent un décodeur ou un encodeur vidéo:

• [C-1-1] Les codecs vidéo DOIVENT prendre en charge des tailles de tampon d'octets de sortie et d'entrée adaptées au plus grand frame compressé et non compressé possible, comme dicté par la norme et la configuration, mais aussi ne pas surallouer.

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

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

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

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

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

• [C-2-1] DOIT prendre en charge l'analyse et la gestion des métadonnées statiques HDR.

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

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

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

• [C-4-1] Le format de couleur optimisé pour l'affichage matériel doit être utilisé par défaut si la sortie est configurée avec Surface.
• [C-4-2] Un format de couleur YUV420 8:8:8 optimisé pour la lecture par le processeur doit être utilisé par défaut si l'application est configurée pour ne pas utiliser la sortie Surface.

5.1.8. Liste des codecs vidéo

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

5.1.9. Sécurité des codecs multimédias

Les implémentations d'appareils DOIVENT respecter les fonctionnalités de sécurité des codecs multimédias, comme décrit ci-dessous.

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

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

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

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

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

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

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

5.1.10. Caractérisation des codecs multimédias

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

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

En particulier :

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

Si les implémentations de l'appareil sont compatibles avec les codecs vidéo:

• [C-2-1] Tous les codecs vidéo DOIVENT publier des données sur la fréquence d'images réalisable pour les tailles suivantes, si elles sont compatibles avec le codec:

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	176 x 144 px (H.263, MPEG-2, MPEG-4) 352 x 288 px (encodeur MPEG4, H263, MPEG2) 320 x 180 px (VP8, VP8) 320 x 240 px (autre)	704 x 576 px (H.263) 640 x 360 px (VP8, VP9) 640 x 480 px (encodeur MPEG4) 720 x 480 px (autre)	1 408 x 1 152 px (H263) 1 280 x 720 px (autre)	1 920 x 1 080 px (autre que MPEG4)	3 840 x 2 160 px (HEVC, VP9)

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

5.2. Encodage vidéo

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

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

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

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

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

• [C-2-1] DOIT prendre en charge les débits configurables dynamiquement.
• DOIT prendre en charge les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son bucket de bits en fonction de cette durée.

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

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

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

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

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et les mettent à la disposition des applications tierces, elles:

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

5.2.2. H.264

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

• [C-1-1] DOIT prendre en charge le profil de référence de niveau 3. Toutefois, la prise en charge de l'ordre des tranches arbitraire (ASO, Arbitrary Slice Ordering), de l'ordre des macroblocs flexible (FMO, Flexible Macroblock Ordering) et des tranches redondantes (RS, Redundant Slices) est FACULTATIVE. De plus, pour assurer la compatibilité avec d'autres appareils Android, il est RECOMMANDÉ que les encodeurs n'utilisent pas ASO, FMO et RS pour le profil de référence.
• [C-1-2] DOIT prendre en charge les profils d'encodage vidéo SD (définition standard) du tableau suivant.
• DOIT prendre en charge le profil principal de niveau 4.
• DOIT prendre en charge les profils d'encodage vidéo HD (haute définition) indiqués dans le tableau suivant.

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

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

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

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

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

5.2.5. H.265

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

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

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

5.3. Décodage vidéo

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

• [C-2-1] DOIT prendre en charge les profils de décodage vidéo HD 720p indiqués dans le tableau suivant.
• [C-2-2] DOIT prendre en charge les profils de décodage vidéo HD 1080p indiqués dans le tableau suivant.

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

5.3.5. H.265 (HEVC)

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

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

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	352 x 288 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30/60 FPS (60 FPS pour les ^téléviseurs avec décodage matériel H.265)	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations de l'appareil prétendent prendre en charge un profil HDR via les API Media:

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

	SD (basse qualité)	SD (haute qualité)	HD – 720p	HD – 1080p	UHD
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 FPS (60 FPS sur les ^téléviseurs avec décodage matériel du format VP9)	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

Si les implémentations de l'appareil prétendent être compatibles avec VP9Profile2 ou VP9Profile3 via les API multimédias CodecProfileLevel:

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

Si les implémentations de l'appareil prétendent prendre en charge un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API multimédias:

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

5.3.8. Dolby Vision

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

• [C-1-1] DOIT fournir un extracteur compatible avec Dolby Vision.
• [C-1-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, (HDMI, par exemple).
• [C-1-3] L'indice de piste de la ou des couches de base rétrocompatibles (le cas échéant) DOIT être identique à celui de la couche Dolby Vision combinée.

5.3.9. AV1

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

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

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient listées comme "RECOMMANDÉ" depuis Android 4.3, la définition de la compatibilité pour les futures versions prévoit de les remplacer par "OBLIGATOIRE". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences listées comme "DOIT", sinon ils ne seront pas compatibles avec Android lors de la mise à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

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

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

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

• DOIT permettre la capture de contenu audio brut avec les caractéristiques suivantes:

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

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

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

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

  • Format: PCM linéaire, 16 bits
  • Taux d'échantillonnage: 22 050, 48 000 Hz
  • Canaux: stéréo
  • [C-1-4] DOIT respecter l'API MicrophoneInfo et renseigner correctement les informations sur les micros disponibles sur l'appareil accessibles aux applications tierces via l'API AudioManager.getMicrophones(), ainsi que les micros actuellement actifs accessibles aux applications tierces via les API AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones(). Si les implémentations d'appareils permettent de capturer des contenus audio bruts en qualité radio AM et DVD, elles:

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

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

5.4.2. Enregistrer pour la reconnaissance vocale

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

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

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

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

5.4.3. Capture pour le redirignement de la lecture

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

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

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

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

5.4.4. Annulation de l'écho acoustique

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

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

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

• [C-SR] Il est FORTEMENT_RECOMMANDÉ de déclarer cela via la méthode d'API AcousticEchoCanceler AcousticEchoCanceler.isAvailable()
• [C-SR] sont FORTEMENT_RECOMMANDÉS pour permettre de contrôler cet effet audio avec l'API AcousticEchoCanceler.
• [C-SR] Il est FORTEMENT_RECOMMANDÉ d'identifier de manière unique chaque implémentation de la technologie AEC via le champ AudioEffect.Descriptor.uuid.

5.4.5. Capture simultanée

Si les implémentations d'appareils déclarent android.hardware.microphone, elles DOIVENT implémenter la capture simultanée, comme décrit dans ce document. Plus spécifiquement :

• [C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité qui capture avec AudioSource.VOICE_RECOGNITION et au moins une application qui capture avec n'importe quel AudioSource.
• [C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application de capture avec n'importe quel AudioSource, à l'exception de AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] DOIT couper le son de la capture audio pour toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application effectue une capture avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application effectue une capture via AudioSource.VOICE_COMMUNICATION, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) disposant de l'autorisation CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Si deux applications ou plus effectuent une capture en même temps et qu'aucune d'elles n'a d'UI en superposition, celle qui a commencé la capture le plus récemment reçoit l'audio.

5.4.6. Niveaux de gain du micro

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

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

5.5. Lecture audio

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

5.5.1. Lecture audio brute

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

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

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

• DOIT autoriser la lecture de contenu audio brut avec 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 d'appareils.

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

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

5.5.3. Volume de sortie audio

Implémentations d'appareils automobiles:

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

5.6. Latence audio

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

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

• latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodé en PCM et le moment où le son correspondant est présenté à l'environnement via un transducteur sur l'appareil ou qu'un signal quitte l'appareil via un port et peut être observé en externe.
• Latence de sortie à froid Latence de sortie pour le premier frame, lorsque le système de sortie audio était inactif et éteint avant la requête.
• latence de sortie continue. La latence de sortie pour les images suivantes, une fois que l'appareil lit de l'audio.
• latence d'entrée ; Intervalle entre le moment où un son est présenté par l'environnement à l'appareil via un transducteur ou un signal qui y entre via un port et le moment où une application lit le frame correspondant de données codées PCM.
• perte d'entrée. Portion initiale d'un signal d'entrée inutilisable ou indisponible.
• Latence d'entrée à froid Somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio était inactif et éteint avant la requête.
• latence d'entrée continue ; Latence d'entrée pour les images suivantes lorsque l'appareil capture l'audio.
• jitter de sortie à froid. Variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
• jitter d'entrée à froid. Variabilité entre les mesures distinctes des valeurs de latence d'entrée à froid.
• latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. La période de tampon permet à l'application de traiter le signal et de réduire la différence de phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android.
• API audio native AAudio Ensemble des API AAudio du NDK Android.
• Code temporel. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.
• glitch. Arrêt temporaire ou valeur d'échantillon incorrecte dans le signal audio, généralement causé par un dépassement de la mémoire tampon pour la sortie, un dépassement de la mémoire tampon pour l'entrée ou toute autre source de bruit numérique ou analogique.

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

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

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

• [C-SR] Latence de sortie à froid de 100 ms ou moins. Il est vivement recommandé que les appareils existants et les nouveaux appareils exécutant cette version d'Android respectent dès maintenant ces exigences. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence de sortie à froid de 200 ms ou moins.
• [C-SR] Latence de sortie continue de 45 millisecondes ou moins.
• [C-SR] Minimisez le jitter de 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 de l'appareil répondent aux exigences ci-dessus, après tout calibrage initial, lorsque vous utilisez à la fois la file d'attente de tampon PCM OpenSL ES et les API audio natives AAudio, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, elles sont les suivantes:

• [C-SR] Il est vivement recommandé de signaler l'audio à faible latence en déclarant le flag de fonctionnalité android.hardware.audio.low_latency.
• [C-SR] Il est vivement recommandé de respecter les exigences concernant l'audio à faible latence via l'API AAudio.
• [C-SR] Nous vous recommandons vivement de vous assurer que, pour les flux qui renvoient AAUDIO_PERFORMANCE_MODE_LOW_LATENCY à partir de AAudioStream_getPerformanceMode(), la valeur renvoyée par AAudioStream_getFramesPerBurst() est inférieure ou égale à celle renvoyée par android.media.AudioManager.getProperty(String) pour la clé de propriété AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER.

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

• [C-2-1] NE DOIT PAS signaler la prise en charge de l'audio à faible latence.

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

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

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

• [C-SR] Latence d'entrée à froid de 100 ms ou moins. Il est vivement recommandé que les appareils existants et les nouveaux appareils exécutant cette version d'Android respectent 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 de 30 millisecondes ou moins.
• [C-SR] Latence aller-retour continue de 50 ms ou moins.
• [C-SR] Minimisez le jitter d'entrée à froid.
• [C-SR] Limitez l'erreur dans les codes temporels d'entrée, tels que 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 de réseau multimédia pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android.

Si les implémentations de l'appareil incluent un décodeur audio ou vidéo, elles:

• [C-1-1] DOIT prendre en charge tous les codecs et formats de conteneur requis de la section 5.1 via HTTP(S).

• [C-1-2] DOIT être compatible avec les formats de segments multimédias indiqués dans le tableau "Formats de segments multimédias" ci-dessous sur le protocole de streaming HLS (HTTP Live Streaming) version 7.

• [C-1-3] DOIT prendre en charge le profil audio/vidéo RTP et les codecs associés suivants dans le tableau RTSP ci-dessous. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau de la section 5.1.

Formats de segments multimédias

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

RTSP (RTP, SDP)

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

5.8. Secure Media

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

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

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

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

Si les implémentations d'appareils déclarent être compatibles avec Display.FLAG_SECURE et avec un écran externe filaire, elles:

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

5.9. MIDI (Musical Instrument Digital Interface)

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

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

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

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

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

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

5.10. Audio professionnel

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

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

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

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

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

• [SR] Nous vous recommandons vivement de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

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

• [C-2-1] La latence audio aller-retour continue doit être de 20 millisecondes ou moins sur le chemin de la prise audio.
• [SR] Nous vous recommandons vivement de respecter la section Spécifications de la prise pour appareil mobile de la spécification des casques audio filaires (v1.1).
• La latence audio aller-retour continue DOIT être inférieure ou égale à 10 millisecondes sur le chemin de la prise audio.

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

• [C-3-1] DOIT implémenter la classe audio USB.
• [C-3-2] La latence audio aller-retour continue doit être de 20 ms ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.
• La latence audio aller-retour continue DOIT être de 10 millisecondes ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à 8 canaux dans chaque sens, un taux d'échantillonnage de 96 kHz et une profondeur de 24 bits ou 32 bits, lorsqu'ils sont utilisés avec des périphériques audio USB qui répondent également à ces exigences.

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

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

5.11. Capturer pour Unprocessed

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

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

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

• [C-1-2] DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates dans la plage de fréquences moyennes: plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.

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

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

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

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

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

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

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

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

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

• [C-2-1] DOIT renvoyer null pour la méthode d'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), afin d'indiquer correctement l'absence de prise en charge.
• [SR] Il est toujours FORTEMENT RECOMMANDÉ de respecter autant que possible les exigences concernant le chemin du signal pour la source d'enregistrement non traitée.

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

6.1. Outils pour les développeurs

Implémentations de l'appareil:

• [C-0-1] DOIT être compatible avec les outils de développement Android fournis dans le SDK Android.

• Android Debug Bridge (adb)

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

  Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, elles:

  • [C-3-1] DOIT implémenter adb via un réseau local (tel qu'Ethernet ou Wi-Fi).
  • [C-3-2] DOIT fournir des pilotes pour Windows 7, 8 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

  Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via Wi-Fi, elles:

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

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

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

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
• Singe
  • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.
• SysTrace
  • [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.
• Perfetto
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation de perfetto.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation de perfetto.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'écrire en sortie une trace protobuf conforme au schéma défini dans la documentation 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 atome LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le Low Memory Killer.
• Mode Test Harness Si les implémentations d'appareils sont compatibles avec la commande shell cmd testharness et exécutent cmd testharness enable, elles :
  • [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DOIT implémenter le mode Atelier de test comme décrit dans la documentation sur le mode Atelier de test.

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

• [C-1-1] Le développeur de l'application DOIT pouvoir activer/désactiver les couches de débogage GPU.
• [C-1-2] Lorsque les couches de débogage du GPU sont activées, le programme doit énumérer les couches dans les bibliothèques fournies par des outils externes (qui ne font pas partie de la plate-forme ou du package d'application) trouvées dans le répertoire de base des applications débogables pour prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().

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

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier qui dispose d'une API correspondante pour les développeurs tiers:

• [C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne dispose pas de ce composant:

• [C-0-2] Les définitions complètes des classes (telles que documentées par le SDK) des API de composant doivent toujours être présentées.
• [C-0-3] Les comportements de l'API DOIVENT être implémentés comme des opérations sans action de manière raisonnable.
• [C-0-4] Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
• [C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• [C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées dans la documentation du SDK.
• [C-0-7] Les implémentations d'appareils DOIVENT systématiquement fournir des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte de compilation.

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

7.1. Écran et graphismes

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

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

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

7.1.1. Configuration de l'écran

7.1.1.1. Taille et forme de l'écran

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

Implémentations de l'appareil:

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

  • Les appareils dont la valeur Configuration.uiMode est définie sur une valeur autre que UI_MODE_TYPE_WATCH et qui indiquent une taille small pour Configuration.screenLayout DOIVENT avoir une taille d'au moins 426 dp x 320 dp.
  • Les appareils qui indiquent une taille normal pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 480 dp x 320 dp.
  • Les appareils qui indiquent une taille large pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 640 dp x 480 dp.
  • Les appareils qui indiquent une taille xlarge pour le Configuration.screenLayout DOIVENT avoir une taille d'au moins 960 dp x 720 dp.

• [C-0-2] DOIT respecter correctement la compatibilité déclarée des applications avec les tailles d'écran via l'attribut <supports-screens> dans le fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.

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

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

• [C-1-1] DOIT s'assurer qu'au moins l'une des exigences suivantes est remplie:
• Le rayon des coins arrondis est inférieur ou égal à 38 dp.

• Lorsqu'un cadre de 15 dp x 15 dp est ancré à chaque coin de l'écran logique, au moins un pixel de chaque cadre est visible à l'écran.

• DOIT inclure une affordance utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou une charnière pliable entre plusieurs panneaux d'affichage et rendent ces écrans disponibles pour afficher des applications tierces, elles:

• [C-2-1] DOIT implémenter la dernière version stable disponible de l'API extensions ou la version stable de l'API sidecar à utiliser par la bibliothèque Jetpack WindowManager.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou une charnière entre plusieurs panneaux d'affichage, et si la charnière ou le pli croise une fenêtre d'application en plein écran, ils:

• [C-3-1] DOIT indiquer à l'application la position, les limites et l'état de la charnière ou du pliage via des extensions ou des API Sidecar.

Pour savoir comment implémenter correctement les API Sidecar ou d'extension, consultez la documentation publique de Jetpack WindowManager.

7.1.1.2. Format d'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour les écrans compatibles avec Android, le format de l'écran logique sur lequel les applications tierces sont affichées, qui peut être dérivé des valeurs de hauteur et de largeur signalées via les API view.Display et les API Configuration, DOIT respecter les exigences suivantes:

• [C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir 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 peut être redimensionnée via l'attribut android:resizeableActivity.
  • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas d'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 une valeur de format égale ou supérieure à 1,3333 (4:3), sauf si l'application peut être agrandie en remplissant l'une des conditions suivantes:

  • L'application déclare qu'elle peut être redimensionnée via l'attribut android:resizeableActivity.
  • L'application déclare un android:minAspectRatio qui limiterait le format autorisé.

• [C-0-3] Les implémentations d'appareils pour lesquels Configuration.uiMode est défini sur UI_MODE_TYPE_WATCH DOIVENT avoir une valeur de format définie sur 1,0 (1:1).

7.1.1.3. Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT ne signaler qu'une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE, et cette valeur NE DOIT PAS changer à tout moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications apportées par l'utilisateur à la configuration de l'écran (taille de l'écran, par exemple) après le démarrage initial.

• Les implémentations d'appareils DOIVENT définir la densité de framework Android standard la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique fait passer la taille d'écran 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 donne une taille d'écran inférieure à la plus petite taille d'écran compatible prise en charge (320 dp de largeur), les implémentations d'appareil DOIVENT indiquer la densité du framework Android standard la plus basse.

Si une affordance permet de modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille de l'écran NE DOIT PAS être redimensionnée à plus de 1,5 fois la densité native ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
• [C-1-2] La taille de l'écran ne doit PAS être réduite à moins de 0,85 fois la densité native.
• Pour assurer une bonne usabilité et des tailles de police cohérentes, nous vous RECOMMANDONS de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus) :
• Petite: 0,85x
• Par défaut: 1x (échelle d'affichage native)
• Grande: 1,15 x
• Plus grand: x 1,3
• Plus grande : x 1,45

7.1.2. Métriques sur le Réseau Display

Si les implémentations d'appareils incluent l'écran ou la sortie vidéo compatible avec Android sur l'écran ou les écrans compatibles avec Android, elles:

• [C-1-1] DOIT indiquer des valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API android.util.DisplayMetrics.

Si les implémentations d'appareils n'incluent pas d'écran intégré ni de sortie vidéo, elles:

• [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible avec Android, comme défini dans l'API android.util.DisplayMetrics pour l'view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations de l'appareil:

• [C-0-1] DOIT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation compatible. Par exemple, un appareil avec un écran en mode paysage dont l'orientation est fixe (téléviseur ou ordinateur portable, par exemple) DOIT uniquement indiquer android.hardware.screen.landscape.
• [C-0-2] DOIT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'il est interrogé via les API android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres.

Si les implémentations de l'appareil sont compatibles avec les deux orientations d'écran, elles:

• [C-1-1] Les applications doivent être compatibles avec l'orientation dynamique en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application concernant une orientation d'écran spécifique.
• [C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran indiquées lorsque l'orientation change.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

7.1.4. Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations de l'appareil:

• [C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode GLES10.getString()) et les API natives.
• [C-0-2] DOIT inclure la prise en charge de toutes les API gérées et API natives correspondantes pour toutes les versions d'OpenGL ES qu'il a identifiées comme compatibles.

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
• DOIT être compatible avec OpenGL ES 3.2.

Si les implémentations de l'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles:

• [C-2-1] DOIT signaler via les API gérées OpenGL ES et les API natives toutes les autres extensions OpenGL ES qu'il a implémentées, et inversement NE DOIT PAS signaler les chaînes d'extension qu'il n'est pas compatible.
• [C-2-2] DOIT prendre en charge les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers.
• [C-SR] Il est vivement recommandé de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
• DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture compatible, qui est généralement spécifique au fournisseur.

Si les implémentations de l'appareil déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles:

• [C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.
• [SR] Nous vous RECOMMANDONS vivement de prendre en charge l'extension OES_EGL_image_external_essl3.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.2, elles:

• [C-4-1] DOIT être compatible avec l'intégralité du pack d'extensions Android OpenGL ES.

Si les implémentations de l'appareil sont entièrement compatibles avec le pack d'extensions Android OpenGL ES, elles:

• [C-5-1] Vous devez indiquer la prise en charge via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils exposent la prise en charge de l'extension EGL_KHR_mutable_render_buffer, elles:

• [C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple d'utilisation pour les graphismes 3D hautes performances.

Si les implémentations de l'appareil sont compatibles avec OpenGL ES 3.1, elles:

• [SR] Nous vous RECOMMANDONS vivement d'inclure la prise en charge de Vulkan 1.1.

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

• DOIT inclure la compatibilité avec Vulkan 1.1.

Les tests dEQP Vulkan sont répartis en plusieurs listes de tests, chacune avec une date/version associée. Ils se trouvent dans l'arborescence source Android à l'emplacement external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un appareil compatible avec Vulkan à un niveau autodéclaré indique qu'il peut réussir les tests dEQP de toutes les listes de tests à partir de ce niveau et avant.

Si les implémentations de l'appareil sont compatibles avec Vulkan 1.0 ou version ultérieure, elles:

• [C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
• [C-1-2] DOIT énumérer au moins un VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] DOIT implémenter entièrement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
• [C-1-4] DOIT énumérer les calques, contenus dans des bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() .
• [C-1-5] NE DOIT PAS énumérer les calques fournis par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de suivre ou d'intercepter l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
• [C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan et, inversement, NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.
• [C-1-7] DOIT être compatible avec les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
• [C-1-8] DOIT indiquer la version maximale des tests dEQP Vulkan compatibles via l'indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-9] DOIT être compatible avec la version 132317953 (à partir du 1er mars 2019), comme indiqué dans le flag de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-10] Tous les tests Vulkan dEQP des listes de tests entre la version 132317953 et la version spécifiée dans le flag de fonctionnalité android.software.vulkan.deqp.level DOIVENT réussir.
• [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 de l'appareil ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer les commutateurs de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations de l'appareil incluent la prise en charge de Vulkan 1.1 et déclarent l'un des commutateurs de fonctionnalité Vulkan, elles:

• [C-3-1] DOIT exposer la prise en charge des types de sémaphores et de poignées externes SYNC_FD, ainsi que de l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT être compatibles avec Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations de l'appareil:

• [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT la désactiver si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API View Android.
• [C-0-2] DOIT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations de l'appareil:

• [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans à large gamme de couleurs

Si les implémentations d'appareils indiquent la prise en charge des écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut() , elles:

• [C-1-1] L'écran doit être calibré en couleur.
• [C-1-2] L'écran doit couvrir entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
• [C-1-3] L'écran doit avoir une gamme dont la surface est d'au moins 90% de la gamme DCI-P3 dans l'espace xyY CIE 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
• [C-1-5] DOIT indiquer la prise en charge des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
• [C-SR] Il est FERMEMENT RECOMMANDÉ de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles:

• [C-2-1] DOIT couvrir au moins 100% de l'espace sRVB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Ancien mode de compatibilité des applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent à une taille d'écran "normale" (largeur de 320 dp) pour les anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran.

7.1.6. Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur un écran compatible avec Android. Les appareils DOIVENT être compatibles avec toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.

Tous les écrans Android compatibles d'une implémentation d'appareil:

• [C-0-1] DOIT être capable de générer des graphiques couleur 16 bits.
• DOIT être compatible avec les écrans capables d'afficher des graphiques couleur 24 bits.
• [C-0-2] DOIT être capable d'afficher des animations.
• [C-0-3] Le format de pixel (PAR) doit être compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires compatibles avec Android pour permettre le partage de contenu multimédia et les API pour les développeurs afin d'accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou intégrée, elles:

• [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 de l'appareil:

• [C-0-1] DOIT inclure un mécanisme de saisie, tel qu'un écran tactile ou une navigation non tactile, pour naviguer entre les éléments de l'interface utilisateur.

7.2.1. Clavier

Si les implémentations d'appareils sont compatibles avec des applications tierces d'éditeur de mode de saisie (IME), elles:

• [C-1-1] Vous devez déclarer le commutateur de fonctionnalité android.software.input_methods.
• [C-1-2] DOIT implémenter entièrement Input Management Framework
• [C-1-3] Un clavier logiciel doit être préinstallé.

Implémentations de l'appareil: * [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches). * DOIT inclure des implémentations de clavier virtuel supplémentaires. * 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 de l'appareil:

• [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

• [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas de commandes de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Recents (Récents) et Back (Retour) sont généralement fournies via une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile. Elles sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils:

• [C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées qui ont une activité avec <intent-filter> défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations d'appareils de télévision. La fonction "Accueil" DOIT être le mécanisme de cette affordance utilisateur.
• DOIT fournir des boutons pour les fonctions "Recents" (Actions récentes) et "Back" (Retour).

Si les fonctions Accueil, Récents ou Retour sont fournies, elles:

• [C-1-1] DOIVENT être accessibles par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) si l'une d'elles est accessible.
• [C-1-2] DOIT indiquer clairement quelle action déclenchera chaque fonction. Une icône visible imprimée sur le bouton, une icône logicielle affichée dans la partie de la barre de navigation de l'écran ou un flux de démonstration guidé par étapes lors de la configuration prête à l'emploi sont des exemples d'indications de ce type.

Implémentations de l'appareil:

• [SR] Il est FORTEMENT RECOMMANDÉ de ne pas fournir le mécanisme d'entrée pour la fonction Menu, car elle est obsolète depuis Android 4.0 et remplacée par la barre d'action.

Si les implémentations d'appareils fournissent la fonction Menu, elles:

• [C-2-1] Le bouton de menu à développer doit s'afficher chaque fois que le pop-up du menu à développer d'action n'est pas vide et que la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position du pop-up à développer d'actions affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher le pop-up à développer d'actions à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils ne fournissent pas la fonction Menu, pour la rétrocompatibilité, elles:

• [C-3-1] DOIT mettre la fonction Menu à la disposition des applications lorsque targetSdkVersion est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils fournissent la fonction d'assistance, elles:

• [C-4-1] La fonction d'assistance doit être accessible en une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont accessibles.
• [SR] Nous vous RECOMMANDONS vivement d'utiliser l'appui prolongé sur la fonction HOME comme interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:

• [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications. Elles NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
• [C-5-2] DOIT mettre à disposition une partie de l'écran pour les applications qui répondent aux exigences définies dans la section 7.1.1.
• [C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (également appelée barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() ne doit être utilisé que pour signaler la zone de reconnaissance gestuelle de Home.
• [C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale, comme indiqué dans la documentation de View#setSystemGestureExclusionRects().
• [C-6-3] DOIT envoyer à l'application de premier plan un événement MotionEvent.ACTION_CANCEL une fois que les gestes tactiles commencent à être interceptés pour un geste système, si l'application de premier plan a déjà reçu un événement MotionEvent.ACTION_DOWN.
• [C-6-4] DOIT fournir une affordance utilisateur permettant de passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
• DOIT fournir la fonction Accueil en balayant l'écran du bas vers le haut dans l'orientation actuelle de l'écran.
• La fonction "Récents" doit être accessible en balayant l'écran vers le haut et en maintenant le geste avant de le relâcher, dans la même zone que le geste "Accueil".
• Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est fournie à partir de n'importe quel bord gauche ou droit de l'orientation actuelle de l'écran:

• [C-7-1] La fonction de navigation DOIT être "Retour" et fournie sous la forme d'un balayage à partir des bords gauche et droit de l'orientation actuelle de l'écran.
• [C-7-2] Si des panneaux système personnalisables à faire glisser sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran, avec une indication visuelle claire et persistante indiquant que le glissement vers l'intérieur appelle les panneaux susmentionnés, et donc pas "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur des bords de l'écran, mais il NE DOIT PAS occuper plus d'un tiers de la longueur 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 de premier plan, les panneaux système personnalisables à balayer DOIVENT être masqués jusqu'à ce que l'utilisateur affiche les barres système (barre de navigation et barre d'état) telles qu'implémentées dans AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée par pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés.

Implémentations de l'appareil:

• DOIT disposer d'un système de saisie par pointeur (souris ou tactile).
• DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante.

Si les implémentations d'appareils incluent un écran tactile (à un ou plusieurs points de contact) sur un écran principal compatible avec Android, elles:

• [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
• [C-1-2] DOIT signaler les indicateurs de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils incluent un écran tactile capable de suivre plusieurs gestes sur un écran principal compatible avec Android, elles:

• [C-2-1] DOIT indiquer les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils s'appuient sur un périphérique d'entrée externe tel qu'une souris ou un trackball (c'est-à-dire qu'ils n'entrent pas en contact direct avec l'écran) pour la saisie sur un écran principal compatible avec Android et qu'ils répondent aux exigences de simulation de contact de la section 7.2.5, ils doivent:

• [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen.
• [C-3-2] DOIT indiquer uniquement android.hardware.faketouch.
• [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

7.2.5. Saisie tactile fictive

Une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui contrôle un curseur à l'écran s'apparente à l'écran tactile, mais l'utilisateur doit d'abord pointer ou sélectionner un élément, puis cliquer. De nombreux périphériques d'entrée, comme la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint, peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'écran tactile.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais un autre système d'entrée par pointeur qu'ils souhaitent mettre à disposition, ils:

• DOIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch, elles:

• [C-1-1] DOIT indiquer les positions X et Y absolues de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• [C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou monte sur l'écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• [C-1-4] DOIT prendre en charge les gestes de pointage vers le bas, de pointage vers le haut, de pointage vers le bas, puis de pointage 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 du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
• [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de pointer vers le haut de l'écran, ce qui leur permet de lancer un objet à l'écran.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct, elles:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT permettre le suivi distinct de deux entrées de pointeur indépendantes ou plus.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand, elles:

• [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-3-2] DOIT prendre en charge le suivi distinct de cinq (suivi d'une main avec cinq doigts) ou de plusieurs entrées de pointeur de manière totalement indépendante.

7.2.6. Compatibilité avec les manettes de jeu

7.2.6.1. Mappages des boutons

Implémentations de l'appareil:

• [C-1-1] DOIT être en mesure de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent un contrôleur ou sont livrées avec un contrôleur distinct dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:

• [C-2-1] Vous devez déclarer l'indicateur de fonctionnalité android.hardware.gamepad.

Bouton	Utilisation de l'HID^2	Bouton Android
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Croix directionnelle vers le haut^1 Croix directionnelle vers le bas^1	0x01 0x0039^3	AXIS_HAT_Y^4
Pavé directionnel vers la gauche1 Pavé directionnel vers la droite^1	0x01 0x0039^3	AXIS_HAT_X^4
Bouton de l'épaule gauche^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic sur le stick droit^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Accueil^1	0x0c 0x0223	KEYCODE_HOME (3)
Retour^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).

3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre, à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".

4 MotionEvent

Commandes analogiques^1	Utilisation des périphériques HID	Bouton Android
Gauche	0x02 0x00C5	AXIS_LTRIGGER
Gauche	0x02 0x00C4	AXIS_RTRIGGER
Stick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Stick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

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

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Open Source Android sur les capteurs.

Implémentations de l'appareil:

• [C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs conformément à la classe android.content.pm.PackageManager.
• [C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via les méthodes SensorManager.getSensorList() et similaires.
• [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant true ou false selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API pour les développeurs tiers, ils:

• [C-1-1] DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android.
• [C-1-2] DOIT signaler les données des capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec une latence maximale demandée de 0 ms lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Une précision de 0 est acceptable pour cet exemple.
• [C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3 %. Le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.
• [C-1-5] Le flux d'événements du capteur DOIT empêcher le processeur de l'appareil d'entrer dans un état de suspension ou de se réveiller d'un état de suspension.
• [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Cette valeur représente l'heure à laquelle l'événement s'est produit et est synchronisée avec l'horloge SystemClock.elapsedRealtimeNano().
• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir l'erreur de synchronisation du code temporel en dessous de 100 millisecondes et DEVRAIT être inférieure à 1 milliseconde.
• Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie indiquée pour chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API pour les développeurs tiers, ils:

• [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler la valeur via la méthode d'API Sensor.getResolution().

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations de l'appareil:

• DOIT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans la section Types de capteurs.

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

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Open Source Android sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers et que le capteur ne renvoie qu'une seule valeur, les implémentations d'appareils:

• [C-3-1] Vous devez définir la résolution sur 1 pour le capteur et enregistrer la valeur via la méthode d'API Sensor.getResolution().

Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, ils:

• [C-4-1] Les données fournies NE DOIVENT PAS inclure de paramètres de calibrage fixes, déterminés en usine.

Si les implémentations de l'appareil incluent une combinaison d'accéléromètre à trois axes, d'un capteur de gyroscope à trois axes ou d'un capteur de magnétomètre, elles sont:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de s'assurer que l'accéléromètre, le gyroscope et le magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes des capteurs restent alignés et cohérents avec le système de coordonnées des capteurs dans tous les états de transformation possibles de l'appareil.

7.3.1. Accéléromètre

Implémentations de l'appareil:

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

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

• [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
• [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
• [C-1-4] DOIT être capable de mesurer la chute libre jusqu'à quatre fois la gravité(4 g) ou plus sur n'importe quel axe.
• [C-1-5] La résolution doit être d'au moins 12 bits.
• [C-1-6] DOIT avoir une déviation standard ne dépassant pas 0,05 m/s^, où la déviation standard doit être calculée par axe sur des échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• [SR] est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
• [SR] Nous vous RECOMMANDONS vivement d'implémenter et de signaler le capteur TYPE_ACCELEROMETER_UNCALIBRATED. Il est vivement recommandé que les appareils Android répondent à cette exigence afin qu'ils puissent passer à la prochaine version de la plate-forme, où cette exigence pourrait devenir OBLIGATOIRE.
• DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.
• DOIT signaler les événements jusqu'à au moins 200 Hz.
• DOIT avoir une résolution d'au moins 16 bits.
• DOIT être calibré pendant l'utilisation si les caractéristiques changent au cours du cycle de vie et être compensé, et doit conserver les paramètres de compensation entre les redémarrages de l'appareil.
• DOIT être compensé en température.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER est implémenté:

• [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:

• [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR] Il est vivement recommandé d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes, un capteur de gyroscope à trois axes et un capteur de magnétomètre, elles:

• [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations de l'appareil:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à trois axes.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, elles:

• [C-1-1] Le capteur TYPE_MAGNETIC_FIELD DOIT être implémenté.
• [C-1-2] DOIT pouvoir générer des rapports sur les événements jusqu'à une fréquence d'au moins 10 Hz et DEVRAIT générer des rapports sur les événements jusqu'à au moins 50 Hz.
• [C-1-3] DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android.
• [C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant de saturer.
• [C-1-5] Le magnétomètre DOIT avoir une valeur de décalage par fer dur inférieure à 700 µT et DEVRAIT avoir une valeur inférieure à 200 µT. Pour ce faire, placez le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par un aimant).
• [C-1-6] La résolution doit être égale ou plus dense que 0,6 µT.
• [C-1-7] DOIT prendre en charge le calibrage et la compensation en ligne du biais de fer dur, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] La compensation du fer doux DOIT être appliquée. L'étalonnage peut être effectué pendant l'utilisation ou lors de la fabrication de l'appareil.
• [C-1-9] L'écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide, DOIT être inférieur à 1,5 µT. L'écart type DOIT être inférieur à 0,5 µT.
• [C-SR] Nous vous RECOMMANDONS vivement d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si les implémentations de l'appareil incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope à trois axes, elles:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

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

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles:

• [C-3-1] DOIT consommer moins de 10 mW.
• DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.

7.3.3. GPS

Implémentations de l'appareil:

• [C-SR] Il est vivement recommandé d'inclure un récepteur GPS/GNSS.

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

• [C-1-1] DOIT prendre en charge les sorties de position à une fréquence d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être en mesure de déterminer la position en conditions de ciel dégagé (signaux forts, multichemin négligeable, HDOP < 2) sous 10 secondes (temps de première correction rapide), lorsqu'il est connecté à une connexion Internet d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une forme de technique GPS/GNSS assistée ou prédictive afin de réduire le temps de verrouillage GPS/GNSS (les données d'assistance incluent l'heure de référence, l'emplacement de référence et l'éphéméride/l'horloge du satellite).
  • [C-1-6] Après avoir effectué un tel calcul de position, les implémentations d'appareils DOIVENT déterminer sa position, en plein air, dans un délai de cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul de position initial, même lorsque la requête ultérieure est effectuée sans connexion de données et/ou après un cycle d'alimentation.

• En plein air, après avoir déterminé l'emplacement, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré:

  • [C-1-3] DOIT pouvoir déterminer la position à 20 mètres près et la vitesse à 0, 5 mètre par seconde près, au moins 95% du temps.
  • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une constellation.
  • DOIT pouvoir suivre simultanément au moins 24 satellites, issus de plusieurs constellations (par exemple, GPS + au moins un de GLONASS, BeiDou ou Galileo).
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des sorties de position GPS/GNSS normales via les API du fournisseur de position GNSS lors d'un appel téléphonique d'urgence.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler l'AGC et la fréquence de mesure GNSS.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler 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 signaler les mesures GNSS dès qu'elles sont détectées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-distances et les taux de pseudo-distance GNSS, qui, dans des conditions d'ensoleillement après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 0,2 m/s², sont suffisants pour calculer la position à 20 m près et la vitesse à 0,2 m/s près, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations de l'appareil:

• [C-SR] Il est vivement recommandé d'inclure un capteur de gyroscope.

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

• [C-1-1] DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz.
• [C-1-2] Vous DEVEZ implémenter le capteur TYPE_GYROSCOPE et nous vous RECOMMANDONS vivement 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é pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-7] La variance ne doit pas dépasser 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais elle DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle NE DOIT PAS dépasser 1e-7 rad^2/s^2.
• [SR] Nous vous recommandons vivement de régler l'erreur de calibrage sur moins de 0,01 rad/s lorsque l'appareil est à l'arrêt à température ambiante.
• DOIT signaler les événements jusqu'à au moins 200 Hz.

Si les implémentations de l'appareil incluent un gyroscope à trois axes, un accéléromètre et un magnétomètre:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les implémentations de l'appareil incluent un accéléromètre à trois axes et un capteur de gyroscope à trois axes, elles:

• [C-3-1] Vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [C-SR] Il est vivement recommandé d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

7.3.5. Le baromètre

Implémentations de l'appareil:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique ambiante).

Si les implémentations d'appareils incluent un baromètre, elles:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT être en mesure de diffuser des événements à 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [SR] Il est vivement recommandé de pouvoir enregistrer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
• DOIT avoir une précision absolue de 1 hPa.
• DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalent à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les implémentations d'appareils incluent un thermomètre ambiant (capteur de température), elles:

• [C-1-1] Le capteur de température ambiante DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE. Le capteur DOIT mesurer la température ambiante (de la pièce/de l'habitacle du véhicule) à partir de laquelle l'utilisateur interagit avec l'appareil en degrés Celsius.

Si les implémentations d'appareils incluent un capteur de thermomètre qui mesure une température autre que la température ambiante, comme la température du processeur, elles:

• [C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

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é, elles:

• [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, il 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é, comme défini dans cette section, et les mettent à la disposition d'applications tierces, elles:

• [C-1-1] Vous devez identifier la fonctionnalité via le flag 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 comporter un capteur TYPE_ACCELEROMETER qui:

  • Doit avoir une plage de mesure d'au moins -8 g à +8 g. Il est vivement recommandé d'avoir une plage de mesure d'au moins -16 g à +16 g.
  • Doit avoir une résolution de mesure d'au moins 2 048 LSB/g.
  • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le canal SensorDirectChannel RATE_VERY_FAST.
  • DOIT avoir un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme de ce capteur sans réveil avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
  • L'accélération doit être inférieure à 30 μg √Hz, testée à température ambiante.
  • Le changement de biais par rapport à la température doit être ≤ +/- 1 mg/°C.
  • La non-linéarité de la ligne d'ajustement doit être inférieure ou égale à 0,5%, et la variation de la sensibilité en fonction de la température doit être inférieure ou égale à 0,03%/°C.
  • La sensibilité croisée doit être inférieure à 2,5 % et la variation de la sensibilité croisée inférieure à 0,2% dans la plage de température de fonctionnement de l'appareil.

• [C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.

• [C-2-3] DOIT comporter un capteur TYPE_GYROSCOPE qui:

  • DOIT avoir une plage de mesure d'au moins -1 000 et +1 000 dps.
  • Doit avoir une résolution de mesure d'au moins 16 LSB/dps.
  • Doit avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT prendre en charge le canal SensorDirectChannel RATE_VERY_FAST.
  • DOIT avoir un bruit de mesure inférieur à 0,014 °/s/√Hz.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir une bande passante de mesure de 3 dB d'au moins 80% de la fréquence de Nyquist et un spectre de bruit blanc dans cette bande passante.
  • La marche aléatoire de la fréquence doit être inférieure à 0,001 °/s √Hz, testée à température ambiante.
  • Le biais doit changer de ≤ +/- 0,05 °/ s / °C par rapport à la température.
  • La sensibilité doit changer de ≤ 0,02% / °C par rapport à la température.
  • La non-linéarité de la droite d'ajustement optimal doit être inférieure ou égale à 0,2%.
  • DOIT avoir une densité de bruit de ≤ 0,007 °/s/√Hz.
  • L'erreur d'étalonnage doit être inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité à la gravité doit être inférieure à 0,1 °/s/g.
  • La sensibilité croisée doit être inférieure à 4 % et la variation de la sensibilité croisée inférieure à 0,3% dans la plage de température de fonctionnement de l'appareil.

• [C-2-4] DOIT avoir un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.

• [C-2-5] DOIT comporter un capteur TYPE_GEOMAGNETIC_FIELD qui:

  • DOIT avoir une plage de mesure d'au moins -900 et +900 μT.
  • Doit avoir une résolution de mesure d'au moins 5 LSB/uT.
  • Doit avoir une fréquence de mesure minimale de 5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
  • Le bruit de mesure doit être inférieur à 0,5 uT.

• [C-2-6] DOIT comporter un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD, et en outre:

  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.

• [C-2-7] DOIT comporter un capteur TYPE_PRESSURE qui:

  • DOIT avoir une plage de mesure d'au moins 300 et 1 100 hPa.
  • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
  • Doit avoir une fréquence de mesure minimale de 1 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
  • Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.
• [C-2-8] DOIT avoir un capteur TYPE_GAME_ROTATION_VECTOR.
• [C-2-9] DOIT comporter un capteur TYPE_SIGNIFICANT_MOTION qui :
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
• [C-2-10] DOIT comporter un capteur TYPE_STEP_DETECTOR qui :
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
• [C-2-11] DOIT comporter un capteur TYPE_STEP_COUNTER qui :
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
• [C-2-12] DOIT comporter un capteur TILT_DETECTOR qui :
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
• [C-2-13] L'horodatage de l'événement physique identique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être compris dans une plage de 2, 5 millisecondes. L'horodatage de l'événement physique identique signalé par l'accéléromètre et le gyroscope DOIT être compris dans une tolérance de 0,25 milliseconde.
• [C-2-14] Les codes temporels des événements du capteur gyroscopique doivent être basés sur la même base temporelle que le sous-système de la caméra et présenter une erreur inférieure à 1 milliseconde.
• [C-2-15] DOIT envoyer des échantillons aux applications dans les cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
• [C-2-16] La consommation d'énergie ne doit PAS dépasser 0,5 mW lorsque l'appareil est statique et 2,0 mW lorsque l'appareil est en mouvement lorsque l'une des combinaisons suivantes de capteurs est activée :
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] Un capteur TYPE_PROXIMITY peut être présent, mais s'il l'est, il doit avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle comprend la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits de support, système de traitement de capteur dédié, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du niveau des taux de rapports directs via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
• [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs pour les capteurs pour tous les capteurs qui déclarent prendre en charge le canal direct pour les capteurs.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DOIT prendre en charge la création de rapports sur les événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations de l'appareil incluent un écran de verrouillage sécurisé, elles:

• DOIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés en classe 3 (anciennement Fort), classe 2 (anciennement Faible) ou classe 1 (anciennement Commodité) en fonction de leurs taux d'acceptation des faux et des imposteurs, et de la sécurité du pipeline biométrique. Cette classification détermine les fonctionnalités du capteur biométrique pour interagir avec la plate-forme et les applications tierces. Par défaut, les capteurs sont classés en classe 1. Ils doivent répondre à des exigences supplémentaires, détaillées ci-dessous, pour être classés en classe 2 ou classe 3. Les biométries de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Si les implémentations de l'appareil mettent un capteur biométrique à la disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elles:

• [C-4-1] DOIT respecter les exigences de la biométrie de classe 3 ou de classe 2, telles que définies dans ce document.
• [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe Authenticators et toutes les combinaisons de celle-ci. À l'inverse, elles NE DOIVENT PAS respecter ni reconnaître les constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de celles-ci.
• [C-4-3] Vous DEVEZ implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils dotés de technologies biométriques de classe 3 ou de classe 2. Cette action DOIT présenter uniquement les points d'entrée d'enregistrement pour les technologies biométriques de classe 3 ou de classe 2.

Si les implémentations de l'appareil sont compatibles avec les données biométriques passives, elles:

• [C-5-1] Une étape de confirmation supplémentaire (par exemple, appuyer sur un bouton) DOIT être requise par défaut.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de disposer d'un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et de toujours exiger une étape de confirmation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation afin qu'un système d'exploitation ou un noyau compromis ne puisse pas la falsifier. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée/sortie à usage général) à usage uniquement en entrée d'un composant sécurisé (SE) qui ne peut être piloté que par une pression sur un bouton physique.
• [C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), que les applications peuvent définir pour les flux de connexion.

Si les implémentations d'appareils comportent plusieurs capteurs biométriques, elles:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule authentification biométrique par authentification (par exemple, si les capteurs d'empreinte digitale et de reconnaissance faciale sont tous deux disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé après la confirmation de l'un d'eux).

Pour que les implémentations d'appareils autorisent l'accès des applications tierces aux clés du keystore, elles doivent:

• [C-6-1] DOIT respecter les exigences de la classe 3, comme défini 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 comme un capteur de classe 1 (anciennement Commodité), elles doivent:

• [C-1-1] Le taux de fausse acceptation doit être inférieur à 0,002%.
• [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe sécurisés, et énumérer clairement les risques de l'activer si les taux d'acceptation des attaques par falsification et d'usurpation d'identité sont supérieurs à 7 %, comme mesuré par les protocoles de test biométriques Android.
• [C-1-3] Le système doit limiter la fréquence des tentatives pendant au moins 30 secondes après cinq tentatives incorrectes pour la validation biométrique. Une tentative incorrecte est une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée.
• [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer les identifiants de l'appareil existants ou d'en ajouter de nouveaux (code/motif/mot de passe) sécurisés par le TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour ce faire.
• [C-1-5] Vous DEVEZ supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris via une réinitialisation d'usine).
• [C-1-6] DOIT respecter l'indicateur individuel pour cette empreinte biométrique (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT , DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-7] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (code, schéma, mot de passe, par exemple) toutes les 24 heures ou moins pour les nouveaux appareils lancés avec Android 10, toutes les 72 heures ou moins pour les appareils qui passent d'une version Android antérieure.

• [C-1-8] L'application DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe) après l'un des événements suivants :

  • un délai d'inactivité de quatre heures ; OU
  • Trois tentatives d'authentification biométrique échouées.
  • Le délai d'inactivité avant expiration et le nombre d'échecs d'authentification sont réinitialisés après toute confirmation réussie des identifiants de l'appareil.

  Les mises à niveau d'appareils à partir d'une version antérieure d'Android peuvent être exemptées de l'exigence C-1-8. * [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils. * [C-SR] Il est FORTEMENT RECOMMANDÉ que le taux de faux rejet soit inférieur à 10%, mesuré sur l'appareil. * [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée à partir du moment où l'identifiant biométrique est détecté jusqu'au déverrouillage de l'écran, pour chaque identifiant biométrique enregistré.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 2 (anciennement faible), elles doivent:

• [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.
• [C-2-2] Le taux d'acceptation des usurpations d'identité et des imposteurs doit être inférieur à 20 %, mesuré par les protocoles de test biométriques Android.
• [C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du kernel Android, tel que l'environnement d'exécution sécurisé (TEE), ou sur une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
• [C-2-4] Toutes les données identifiables doivent être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source.
• [C-2-5] Pour les données biométriques basées sur une caméra, pendant l'authentification ou l'enregistrement biométrique :
  • DOIT utiliser la caméra dans un mode qui empêche la lecture ou la modification des images de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
  • Pour les solutions à caméra unique RVB, les frames de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé afin de prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT PAS être modifiables.
• [C-2-6] Les applications tierces NE DOIVENT PAS être autorisées à distinguer les enregistrements biométriques individuels.
• [C-2-7] Le processeur d'applications NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni à toute donnée dérivée de celles-ci (telles que les représentations vectorielles continues) en dehors du contexte du TEE.

• [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre d'injecter directement des données pour s'authentifier faussement 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 via une mise à jour du logiciel 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 faciale.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme un capteur de classe 3 (anciennement Fort), elles doivent:

• [C-3-1] DOIT respecter toutes les exigences de la classe 2 ci-dessus, à l'exception de [C-1-7] et [C-1-8]. Les mises à niveau d'appareils à partir d'une version Android antérieure ne sont pas exemptées de C-2-7.
• [C-3-2] L'implémentation du keystore doit être basée sur du matériel.
• [C-3-3] Le taux d'acceptation des usurpations d'identité et des imposteurs doit être inférieur à 7 %, mesuré par les protocoles de test biométrique Android.
• [C-3-4] DOIT demander à l'utilisateur de fournir l'authentification primaire recommandée (code, schéma, mot de passe, par exemple) toutes les 72 heures ou moins.

7.3.12. Capteur de position

Implémentations de l'appareil:

• Peut être compatible avec un capteur de position à six degrés de liberté.

Si les implémentations d'appareils sont compatibles avec un capteur de position à six degrés de liberté, elles:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
• [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.13. Capteur d'angle de charnière

Si les implémentations d'appareils sont compatibles avec un capteur d'angle de charnière, elles:

• [C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
• [C-1-2] DOIT prendre en charge au moins deux lectures entre 0 et 360 degrés (inclus, c'est-à-dire 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 dans ce document fait spécifiquement référence au matériel lié à la réalisation d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée sur le même réseau. En d'autres termes, les fonctionnalités et les API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS ne sont pas considérées comme des appareils de téléphonie, que ces appareils utilisent un réseau mobile pour la connectivité de données ou non.

• Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec les appareils autres que les téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles:

• [C-1-1] DOIT déclarer l'option de fonctionnalité android.hardware.telephony et les autres options de sous-fonctionnalités en fonction de la technologie.
• [C-1-2] DOIT implémenter une compatibilité complète avec l'API de cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles:

• [C-2-1] Vous DEVEZ implémenter l'intégralité des API en tant que no-ops.

Si les implémentations d'appareils sont compatibles avec les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant de rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles:

• [C-3-1] DOIT fournir une implémentation complète de EuiccManager API.

7.4.1.1. Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure la fonctionnalité de blocage des numéros
• [C-1-2] DOIT implémenter entièrement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
• [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans "BlockedNumberProvider" sans aucune interaction avec les applications. La seule exception est lorsque le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
• [C-1-4] NE DOIT PAS écrire au fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
• [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
• [C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] Les utilisateurs secondaires NE DOIVENT PAS pouvoir afficher ni modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. L'interface utilisateur liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT toujours être respectée.
• Les numéros bloqués devraient être migrés vers le fournisseur lorsqu'un appareil passe à Android 7.0.

7.4.1.2. API Telecom

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

• [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir à l'utilisateur la possibilité d'accepter ou de refuser l'appel entrant lorsque l'utilisateur est en ligne avec une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
• [C-1-3] Une application doit IMPERATIVEMENT implémenter InCallService.

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à un appel en cours.

  L'implémentation AOSP répond à ces exigences par une notification d'alerte qui indique à l'utilisateur que répondre à un appel entrant entraînera la fin de l'autre appel.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de précharger l'application de numérotation par défaut qui affiche une entrée de journal des appels et le nom d'une application tierce dans son journal des appels lorsque l'application tierce définit la clé d'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 suit :
  • Appelez Connection.onDisconnect() lorsqu'un appui bref sur l'événement de touche est détecté pendant un appel en cours.
  • Appelez Connection.onAnswer() lorsqu'un appui bref sur l'événement de touche est détecté lors d'un appel entrant.
  • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté lors d'un appel entrant.
  • Activez/Désactivez le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations de l'appareil:

• DOIT inclure la prise en charge d'une ou de plusieurs formes de 802.11.

Si les implémentations d'appareils incluent la prise en charge de la norme 802.11 et exposent la fonctionnalité à une application tierce, elles:

• [C-1-1] DOIT implémenter l'API Android correspondante.
• [C-1-2] DOIT signaler l'indicateur de fonctionnalité matérielle android.hardware.wifi.
• [C-1-3] Vous DEVEZ implémenter l'API multicast comme décrit dans la documentation du SDK.
• [C-1-4] DOIT prendre en charge le DNS multicast (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment de l'opération, y compris :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même en mode veille.
• [C-1-5] NE DOIT PAS traiter l'appel de la méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif, qui est utilisé par défaut pour le trafic de l'application et est renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils ne peuvent désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils vérifient que le réseau Wi-Fi fournit un accès à Internet.
• [C-1-6] Il est FORTEMENT RECOMMANDÉ, lorsque la méthode d'API ConnectivityManager.reportNetworkConnectivity() est appelée, de réévaluer l'accès à Internet sur le Network et, une fois que l'évaluation a déterminé que le Network actuel ne fournit plus d'accès à Internet, de passer à un autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source et le numéro de séquence des trames de requête de sonde, une fois au début de chaque analyse, lorsque l'appareil STA est déconnecté.
  • Chaque groupe de trames de requête d'exploration comprenant une analyse doit utiliser une adresse MAC cohérente (L'adresse MAC NE DOIT PAS être générée de manière aléatoire à mi-chemin d'une analyse).
  • Le numéro de séquence de la requête de sonde doit s'itérer normalement (séquentiellement) entre les requêtes de sonde d'une analyse.
  • Le numéro de séquence de la requête de sonde doit être aléatoire entre la dernière requête de sonde d'une analyse et la première requête de sonde de l'analyse suivante.
• [C-SR] Il est FORTEMENT RECOMMANDÉ, lorsque l'appareil STA est déconnecté, de n'autoriser que les éléments suivants dans les trames de requête de sonde :
  • Ensemble de paramètres SSID (0)
  • Ensemble de paramètres DS (3)

Si les implémentations d'appareils incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles:

• [C-3-1] DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert le verrouillage WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire() et que le verrouillage est actif.
• [C-3-2] La latence aller-retour moyenne entre l'appareil et un point d'accès lorsque l'appareil est en mode Verrouillage Wi-Fi à faible latence (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Verrouillage Wi-Fi hautes performances (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR] Ils sont FORTEMENT RECOMMANDÉS pour réduire la latence aller-retour du Wi-Fi chaque fois qu'un verrouillage à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles:

• [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Direct, elles:

• [C-1-1] DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK.
• [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• [C-1-3] DOIT être compatible avec le fonctionnement normal du Wi-Fi.
• [C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.

7.4.2.2. Configuration de la liaison directe en tunnel Wi-Fi

Implémentations de l'appareil:

• DOIT inclure la prise en charge de la configuration du lien direct en tunnel Wi-Fi (TDLS), comme décrit dans la documentation du SDK Android.

Si les implémentations de l'appareil prennent en charge TDLS et que TDLS est activé par l'API WiFiManager, elles:

• [C-1-1] DOIT déclarer la prise en charge de TDLS via WifiManager.isTdlsSupported.
• Vous devez utiliser TDLS uniquement lorsque c'est possible ET avantageux.
• DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles du point d'accès Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Aware.

Si les implémentations de l'appareil sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles:

• [C-1-1] Vous DEVEZ implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
• [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité android.hardware.wifi.aware.
• [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
• [C-1-4] DOIT randomiser l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles de 30 minutes maximum et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure de la portée Aware est en cours ou si un chemin de données Aware est actif (la randomisation n'est pas attendue tant que le chemin de données est actif).

Si les implémentations de l'appareil sont compatibles avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5, et qu'elles exposent ces fonctionnalités aux applications tierces, elles:

• [C-2-1] DOIT implémenter les API de découverte basée sur la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Wi-Fi Passpoint

Si les implémentations de l'appareil sont compatibles avec la norme 802.11 (Wi-Fi), elles:

• DOIT inclure la prise en charge de Wi-Fi Passpoint.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Passpoint, elles:

• [C-1-2] DOIT implémenter les API WifiManager liées à Passpoint comme décrit dans la documentation du SDK.
• [C-1-3] DOIT être compatible avec la norme IEEE 802.11u, en particulier en ce qui concerne la découverte et la sélection de réseaux, tels que le service d'annonces génériques (GAS, Generic Advertisement Service) et le protocole ANQP (Access Network Query Protocol).

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec Wi-Fi Passpoint:

• [C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.

7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi, RTT)

Implémentations de l'appareil:

• DOIT inclure la prise en charge de la position Wi-Fi.

Si les implémentations de l'appareil sont compatibles avec la position Wi-Fi et exposent cette fonctionnalité aux applications tierces, elles:

• [C-1-1] Vous DEVEZ implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
• [C-1-2] Vous DEVEZ déclarer l'option de fonctionnalité android.hardware.wifi.rtt.
• [C-1-3] L'adresse MAC source doit être RANDOMisée pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.

7.4.2.6. Déchargement du keepalive Wi-Fi

Implémentations de l'appareil:

• DOIT inclure la prise en charge de l'externalisation du keepalive Wi-Fi.

Si les implémentations de l'appareil prennent en charge le transfert de keepalive Wi-Fi et exposent la fonctionnalité aux applications tierces, elles:

• [C-1-1] DOIT être compatible avec l'API SocketKeepAlive.

• [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés via le Wi-Fi et au moins un emplacement keepalive via le réseau mobile.

Si les implémentations d'appareils ne sont pas compatibles avec le transfert de keepalive Wi-Fi, elles:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement d'appareils)

Implémentations de l'appareil:

• DOIT inclure la prise en charge de Wi-Fi Easy Connect (DPP).

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

• [C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer true.

7.4.3. Bluetooth

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

• DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations de l'appareil sont compatibles avec HFP, A2DP et AVRCP:

• DOIT être compatible avec au moins cinq appareils connectés au total.

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

• [C-1-1] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations de l'appareil prennent en charge le Bluetooth et le Bluetooth à basse consommation:

• [C-2-1] Vous DEVEZ déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le respectivement) et implémenter les API de la plate-forme.
• DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations de l'appareil sont compatibles avec le Bluetooth à basse consommation (BLE), elles:

• [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• [C-3-2] DOIT activer les API Bluetooth basées sur le GATT (Generic Attribute Profile) comme décrit dans la documentation du SDK et dans android.bluetooth.
• [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() afin d'indiquer si la logique de filtrage des classes d'API ScanFilter est implémentée.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() afin de savoir si la publicité à faible consommation d'énergie est prise en charge.
• [C-3-5] DOIT implémenter un délai avant expiration de l'adresse privée résoluble (RPA) de 15 minutes maximum et faire tourner l'adresse à l'expiration pour protéger la confidentialité des utilisateurs lorsque l'appareil utilise activement le BLE pour la numérisation ou la publicité. Pour éviter les attaques par cassage de délai, les intervalles de délai doivent également être rendus aléatoires entre cinq et 15 minutes.
• DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
• DOIT prendre en charge le transfert de l'analyse groupée vers le chipset Bluetooth.
• DOIT prendre en charge les annonces multiples avec au moins quatre emplacements.

Si les implémentations d'appareils sont compatibles avec le Bluetooth LE et utilisent le Bluetooth LE pour la détection de position, elles:

• [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la prise en charge du Bluetooth LE et du profil d'appareils auditifs, comme décrit dans la section Compatibilité audio avec les appareils auditifs à l'aide du Bluetooth LE, elles:

• [C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Communication en champ proche

Implémentations de l'appareil:

• DOIT inclure un émetteur-récepteur et du matériel associé pour la technologie NFC (communication en champ proche).
• [C-0-1] Les API android.nfc.NdefMessage et android.nfc.NdefRecord DOIVENT être implémentées, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation des données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition d'applications tierces, elles doivent:

• [C-1-1] Vous DEVEZ enregistrer la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes:
• [C-1-2] DOIT être capable de fonctionner comme lecteur/enregistreur NFC Forum (tel que défini par la spécification technique NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le forum NFC)

• [SR] Il est fortement recommandé de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que les normes NFC sont définies comme "FORTEMENT RECOMMANDÉES", mais que la définition de la compatibilité pour une future version prévoit de les remplacer par "OBLIGATOIRE". Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous vous recommandons vivement de respecter ces exigences dès maintenant pour les appareils existants et les nouveaux exécutant cette version d'Android afin qu'ils puissent passer aux futures versions de la plate-forme.

• [C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.

• DOIT être en mode découverte NFC lorsque l'appareil est actif, que l'écran est allumé et que l'écran de verrouillage est déverrouillé.
• DOIT être en mesure de lire le code-barres et l'URL (si encodés) des produits Thinfilm NFC Barcode.

Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.

Android est compatible avec le mode NFC Host Card Emulation (HCE).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage de l'ID d'application (AID), elles:

• [C-2-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hce.
• [C-2-2] DOIT être compatible avec les API NFC HCE telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles:

• [C-3-1] DOIT indiquer la constante de fonctionnalité android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent la compatibilité NFC générale décrite dans cette section et les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/écrivain, elles:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans la documentation du SDK Android.
• [C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas en tant que constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles et API réseau

7.4.5.1. Capacité réseau minimale

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données capable de transmettre 200 kbit/s ou plus. Voici quelques exemples de technologies qui répondent à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et PAN Bluetooth.
• DOIT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (telle qu'Ethernet) est la connexion de données principale.
• PEUT implémenter plusieurs formes de connectivité de données.

7.4.5.2. IPv6

Implémentations de l'appareil:

• [C-0-2] DOIT inclure une pile réseau IPv6 et prendre en charge la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
• [C-0-3] Vous devez activer le protocole IPv6 par défaut.
• DOIT s'assurer que la communication IPv6 est aussi fiable qu'IPv4, par exemple :
  • [C-0-4] Le système DOIT maintenir la connectivité IPv6 en mode veille.
  • [C-0-5] La limitation de débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau conforme à la norme IPv6 qui utilise des durées de vie de RA d'au moins 180 secondes.
• [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort, ainsi que les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port source pour les serveurs Internet (Web).

Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.

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

• [C-1-1] DOIT être compatible avec le fonctionnement en double pile et en IPv6 uniquement sur le Wi-Fi.

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

• [C-2-1] DOIT être compatible avec l'opération à double pile et IPv6 uniquement sur Ethernet.

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

• [C-3-1] DOIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et données mobiles), ils:

• [C-4-1] L'appareil DOIT respecter simultanément les exigences ci-dessus sur chaque réseau lorsqu'il est connecté simultanément à plusieurs types de réseaux.

7.4.5.3. Portails captifs

Un portail captif désigne un réseau qui nécessite une connexion pour accéder à Internet.

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

• [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif, en envoyant cet intent, lors d'un appel à l'API système ConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] DOIT détecter les portails captifs et prendre en charge la connexion via l'application du portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris un réseau mobile/cellulaire, un réseau Wi-Fi, un réseau Ethernet ou un réseau Bluetooth.
• [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide du DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode DNS privé strict.
• [C-1-4] Vous devez utiliser un DNS chiffré conformément à la documentation du SDK pour android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout trafic réseau qui ne communique pas explicitement avec le portail captif.
• [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un portail captif, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback et utilisé par défaut par les API réseau Java telles que java.net.Socket et les API natives telles que connect()) est tout autre réseau disponible qui fournit un accès Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations de l'appareil:

• [C-0-1] Le paramètre de synchronisation automatique maître doit être activé par défaut pour que la méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, elles sont:

• [SR] FORTEMENT RECOMMANDÉ de fournir le mode Économie de données.

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

• [C-1-1] DOIT prendre en charge toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK

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

• [C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Composants sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés compatibles avec l'API Open Mobile et les mettent à la disposition des applications tierces, elles:

• [C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via l'API android.se.omapi.SEService.getReaders().

• [C-1-2] DOIT déclarer les indicateurs de fonctionnalité appropriés via android.hardware.se.omapi.uicc pour l'appareil avec des éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil avec des éléments sécurisés basés sur eSE et android.hardware.se.omapi.sd pour l'appareil avec des éléments sécurisés basés sur SD.

7.5. Caméras

Si les implémentations d'appareils incluent au moins une caméra, elles:

• [C-1-1] Vous DEVEZ déclarer le commutateur de fonctionnalité android.hardware.camera.any.
• [C-1-2] Une application doit pouvoir allouer simultanément trois bitmaps RGBA_8888 égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil, lorsque l'appareil photo est ouvert à des fins d'aperçu de base et de capture d'image.
• [C-1-3] L'application d'appareil photo par défaut préinstallée qui gère les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE doit OBLIGATOIREMENT supprimer la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque l'application destinataire ne dispose pas de ACCESS_FINE_LOCATION.

7.5.1. Caméra arrière

Une caméra arrière est une caméra située sur le côté de l'appareil, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle.

Implémentations de l'appareil:

• DOIT inclure une caméra arrière.

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

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
• [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
• Le pilote de l'appareil photo DOIT implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
• POURRAIENT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
• POURRA inclure un flash.

Si la caméra inclut un flash:

• [C-2-1] Le flash ne doit PAS être allumé lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.

7.5.2. Caméra avant

Une caméra avant est une caméra située du même côté de l'appareil que l'écran. Autrement dit, il s'agit d'une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Implémentations de l'appareil:

• POURRAIENT inclure une caméra avant.

Si les implémentations d'appareils incluent au moins une caméra avant, elles:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• [C-1-2] DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour qu'elle traite une caméra avant comme une caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
• [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque l'application actuelle a explicitement demandé que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application en cours n'exige pas explicitement que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés qui sont renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
• [C-1-6] DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de la caméra.
• PEUVENT inclure des fonctionnalités (comme l'autofocus, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur):

• [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations de l'appareil:

• PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations de l'appareil sont compatibles avec une caméra externe, elles:

• [C-1-1] Vous DEVEZ déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
• [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
• [C-1-3] L'appareil doit réussir les tests CTS de la caméra avec une caméra externe physique connectée. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
• DOIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
• Peut être compatible avec plusieurs caméras.
• Peut prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur l'appareil photo est compatible:

• [C-2-1] Un flux non encodé / MJPEG simultané (résolution VGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. La nouvelle API android.hardware.camera2 expose à l'application un contrôle de l'appareil photo de niveau inférieur, y compris des flux de streaming/rafale sans copie efficaces et des commandes par frame d'exposition, de gain, de gain de balance des blancs, de conversion des couleurs, de suppression du bruit, d'accentuation, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision du mode autofocus doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir la même vitesse ni la même qualité, mais DOIVENT correspondre le plus étroitement possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles. Implémentations de l'appareil:

• [C-0-1] Vous devez utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] Les données doivent également être au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
• [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo pour les caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.)
• [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en sortie via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la fonctionnalité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
• [C-0-5] Vous devez toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "faussés" comme décrit.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe android.hardware.Camera.Parameters et la classe android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters(), sauf celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres d'appareil photo standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR.
• [C-0-7] DOIT indiquer le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et indiquer les options de fonctionnalité du framework appropriées.
• [C-0-8] DOIT également déclarer les fonctionnalités individuelles de la caméra android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les options de fonctionnalité appropriées. DOIT définir l'option de fonctionnalité si l'une de ses caméras connectées est compatible avec la fonctionnalité.
• [C-0-9] DOIT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée au store multimédia.
• [C-0-10] DOIT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au store multimédia.
• [C-0-11] Toutes les caméras doivent être accessibles via l'API android.hardware.Camera obsolète et via l'API android.hardware.camera2.
• [C-0-12] VOUS DEVEZ vous assurer que l'apparence du visage n'est PAS modifiée, y compris, mais sans s'y limiter, en modifiant la géométrie du visage, la couleur de la peau du visage ou l'adoucissement de la peau du visage pour toute API android.hardware.camera2 ou android.hardware.Camera.
• [C-SR] Pour les appareils dotés de plusieurs caméras RGB orientées dans la même direction, il est vivement recommandé de prendre en charge un appareil photo logique qui liste la capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composée de toutes les caméras RGB orientées dans cette direction en tant que sous-appareils physiques.

Si les implémentations d'appareils fournissent une API d'appareil photo propriétaire aux applications tierces, elles:

• [C-1-1] Vous DEVEZ implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
• PEUT fournir des tags et/ou des extensions de fournisseur à l'API android.hardware.camera2.

7.5.5. Orientation de l'appareil photo

Si les implémentations de l'appareil comportent une caméra avant ou arrière, la ou les caméras :

• [C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimums

Implémentations de l'appareil:

• [C-0-1] DOIT inclure un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Elles DOIVENT être capables de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".

7.6.2. Stockage partagé de l'application

Implémentations de l'appareil:

• [C-0-1] DOIT proposer un espace de stockage à partager entre les applications, souvent appelé "stockage externe partagé", "stockage partagé par les applications" ou par le chemin d'accès Linux "/sdcard" sur lequel il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", que le stockage soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un port de carte Secure Digital).
• [C-0-3] DOIT monter le stockage partagé de l'application directement sur le chemin d'accès Linux sdcard ou inclure un lien symbolique Linux de sdcard au point d'installation réel.
• [C-0-4] Vous devez activer 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 Exif GPS, stockées dans des fichiers multimédias lorsque ces fichiers sont accessibles via MediaStore, sauf lorsque l'application appelante dispose de l'autorisation ACCESS_MEDIA_LOCATION.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'une des méthodes suivantes:

• Un espace de stockage amovible accessible à l'utilisateur, tel qu'un port de carte SD (Secure Digital).
• Partie du stockage interne (non amovible) implémentée dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles:

• [C-1-1] L'application DOIT implémenter une interface utilisateur de type "toast" ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le port.
• [C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur la boîte et sur tout autre document disponible au moment de l'achat que le support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:

• DOIT utiliser l'implémentation AOSP de l'espace de stockage partagé de l'application interne.
• PEUT partager l'espace de stockage avec les données privées de l'application.

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

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application à partir d'un ordinateur hôte.
• DOIT exposer le contenu des deux chemins d'accès de stockage de manière transparente via le service d'analyseur multimédia d'Android et android.provider.MediaStore.
• Peut utiliser le stockage de masse USB, mais DOIT utiliser le protocole Media Transfer pour répondre à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole de transfert multimédia, elles:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DOIT indiquer une classe d'appareil USB de 0x00.
• DOIT indiquer un nom d'interface USB de "MTP".

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile, contrairement à la télévision, les implémentations sont les suivantes:

• [SR] Nous vous recommandons vivement d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption de données.

Si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, tel que le compartiment de la batterie ou une autre protection, les implémentations de l'appareil sont les suivantes:

• [SR] Nous vous recommandons vivement d'implémenter le stockage adoptable.

7.7. USB

Si les implémentations d'appareils disposent d'un port USB, elles:

• DOIT être compatible avec le mode périphérique USB et DOIT être compatible avec le mode hôte USB.

7.7.1. Mode périphérique USB

Si les implémentations de l'appareil incluent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
• [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur d'appareil standard USB via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs 1,5 A et 3 A conformément à la norme de résistance Type-C et DOIT détecter les modifications de la publicité s'ils sont compatibles avec l'USB Type-C.
• [SR] Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [SR] Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [SR] LE Contrôleur DOIT être compatible avec le courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• [SR] Il est vivement recommandé de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/récepteur, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cette fonctionnalité soit "FORTEMENT RECOMMANDÉE", nous pourrons exiger que tous les appareils Type-C soient entièrement compatibles avec les chargeurs Type-C standards dans les futures versions d'Android.
• [SR] Il est vivement recommandé de prendre en charge la distribution d'alimentation pour le transfert de données et le changement de rôle d'alimentation lorsqu'ils sont compatibles avec l'USB Type-C et le mode hôte USB.
• DOIT être compatible avec la recharge haute tension et les modes alternatifs tels que la sortie d'écran.
• DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, elles:

• [C-2-1] DOIT déclarer la compatibilité avec la fonctionnalité matérielle android.hardware.usb.accessory.
• [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne iInterface de la description de l'interface 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, elles:

• [C-1-1] DOIT implémenter l'API hôte USB Android comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
• [C-1-2] DOIVENT prendre en charge la connexion de périphériques USB standards. En d'autres termes, ils DOIVENT :
  • être équipé d'un port de type C sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB de type C standard (appareil USB de type C) ;
  • être équipé d'un port de type A sur l'appareil ou être fourni avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB de type A standard ;
  • disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble permettant de le connecter à un port Type-A standard ;
• [C-1-3] NE DOIT PAS être livré avec un adaptateur permettant de convertir les ports USB Type-A ou micro-AB en port Type-C (récepteur).
• [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 de l'appareil périphérique USB connecté en mode hôte, en annonçant un courant de source d'au moins 1,5 A, comme indiqué dans la section "Paramètres de terminaison" de la spécification de la version 1.2 du câble et du connecteur USB Type-C pour les connecteurs USB Type-C ou en utilisant la plage de courant de sortie du port en aval de recharge(CDP) comme indiqué dans les spécifications de recharge de la batterie USB, version 1.2 pour les connecteurs Micro-AB.
• DOIT implémenter et prendre en charge les normes USB Type-C.

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

• [C-2-1] DOIT être compatible avec la classe USB HID.
• [C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la requête d'utilisation des commandes vocales aux constantes KeyEvent comme indiqué ci-dessous :
  • Page d'utilisation (0xC) ID d'utilisation (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Page d'utilisation (0xC) ID d'utilisation (0x0E9): KEYCODE_VOLUME_UP
  • Page d'utilisation (0xC) ID d'utilisation (0x0EA): KEYCODE_VOLUME_DOWN
  • Page d'utilisation (0xC) ID d'utilisation (0x0CF): KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le Storage Access Framework (SAF), elles:

• [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leurs contenus accessibles via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

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

• [C-4-1] DOIT implémenter la fonctionnalité de port à double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3).
• [SR] Il est vivement recommandé de prendre en charge DisplayPort, et de prendre en charge les débits de données USB SuperSpeed. Il est également vivement recommandé de prendre en charge la technologie Power Delivery pour le transfert de données et le transfert de rôle d'alimentation.
• [SR] Nous vous recommandons vivement de NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la spécification de la version 1.2 du câble et du connecteur USB Type-C.
• DOIT implémenter le modèle Try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.8. Audio

7.8.1. Micro

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

• [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio de la section 5.4.
• [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
• [SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement par ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils omettent un micro, elles:

• [C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
• [C-2-2] L'API d'enregistrement audio doit être implémentée au moins en tant que no-ops, conformément à la section 7.

7.8.2. Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles:

• [C-1-1] DOIT indiquer la constante de fonctionnalité android.hardware.audio.output.
• [C-1-2] DOIT respecter les exigences de lecture audio de la section 5.5.
• [C-1-3] DOIT respecter les exigences de latence audio de la section 5.6.
• [SR] Il est vivement recommandé de prendre en charge la lecture proche des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] Les API liées à la sortie audio doivent être implémentées en tant que no-ops au moins.

Aux fins de cette section, un "port de sortie" est une interface physique telle qu'une prise audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que le Bluetooth, le Wi-Fi ou le réseau mobile ne peut pas être considérée comme incluant un "port de sortie".

7.8.2.1. Ports audio analogiques

Pour être compatibles avec les casques et autres accessoires audio utilisant la prise audio 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles doivent:

• [C-SR] Il est FORTEMENT RECOMMANDÉ que l'un des ports audio soit un connecteur audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils sont dotées d'une prise audio 3,5 mm à quatre conducteurs, elles:

• [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro.
• [C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec la séquence de broches CTIA.
• [C-1-3] DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohms: KEYCODE_VOLUME_UP
  • 360-680 ohms: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise.
• [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de tension de sortie sur une impédance d'enceinte de 32 ohms.
• [C-1-6] La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper sur le code de touche la plage d'impédance équivalente suivante entre les conducteurs du micro et de la terre sur la prise audio :
  • 110 à 180 ohms:KEYCODE_VOICE_ASSIST
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec la séquence de broches OMTP.
• [C-SR] Nous vous RECOMMANDONS vivement de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils sont dotées d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent android.intent.action.HEADSET_PLUG avec la valeur supplémentaire du micro définie sur 1, elles:

• [C-2-1] L'appareil DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.2.2. Ports audio numériques

Pour être compatible avec les casques et autres accessoires audio utilisant des connecteurs USB-C et implémentant (classe audio USB) dans l'écosystème Android, comme défini dans la spécification des casques USB Android.

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

7.8.3. Ultrasons proches

L'audio proche des ultrasons correspond à la bande de fréquences de 18,5 kHz à 20 kHz.

Implémentations de l'appareil:

• DOIT indiquer correctement la prise en charge de la fonctionnalité audio à ultrasons via l'API AudioManager.getProperty comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT répondre aux exigences suivantes:

• [C-1-1] La réponse moyenne en puissance du micro dans la bande de fréquences de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
• [C-1-2] Le rapport signal/bruit non pondéré du micro entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true":

• [C-2-1] La réponse moyenne de l'enceinte entre 18,5 kHz et 20 kHz DOIT être supérieure d'au moins 40 dB à la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations d'appareils: * DOIVENT fournir un chemin de signal audio sans glitch pour les flux d'entrée et de sortie sur les appareils portables, comme défini par l'absence de glitchs mesurée lors d'un test d'une minute par chemin. Effectuez un test à l'aide de l'option "Automated Glitch Test" (Test de glitch automatisé) d'[OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester).

Le test nécessite un dongle de retour audio, utilisé directement sur un connecteur 3,5 mm et/ou avec un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester accepte actuellement les chemins AAudio. Par conséquent, les combinaisons suivantes DOIVENT être testées pour détecter les erreurs à l'aide d'AAudio:

Mode Perf	Partage	Taux d'échantillonnage de sortie	Dans Chans	Out Chans
LOW_LATENCY	EXCLUSIVITÉ	NON DÉFINI	1	2
LOW_LATENCY	EXCLUSIVITÉ	NON DÉFINI	2	1
LOW_LATENCY	PARTAGÉ	NON DÉFINI	1	2
LOW_LATENCY	PARTAGÉ	NON DÉFINI	2	1
AUCUNE	PARTAGÉ	48000	1	2
AUCUNE	PARTAGÉ	48000	2	1
AUCUNE	PARTAGÉ	44100	1	2
AUCUNE	PARTAGÉ	44100	2	1
AUCUNE	PARTAGÉ	16000	1	2
AUCUNE	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants pour le rapport signal/bruit (SNR) et le taux de distorsion harmonique totale (THD) pour une sinusoïde à 2 000 Hz.

Transducteur	THD	SNR
Haut-parleur principal intégré, mesuré à l'aide d'un micro de référence externe	< 3,0%	>= 50 dB
Micro intégré principal, mesuré à l'aide d'un haut-parleur de référence externe	< 3,0%	>= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés à l'aide d'un adaptateur de bouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés à l'aide d'un adaptateur de bouclage	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des outils permettant de créer des applications de réalité virtuelle (RV), y compris des expériences de RV mobile de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode réalité virtuelle

Android est compatible avec le mode VR, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'UI système monoculaires lorsqu'une application de RV est en mode plein écran.

7.9.2. Mode Réalité virtuelle : hautes performances

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

• [C-1-1] Le processeur doit comporter au moins deux cœurs physiques.
• [C-1-2] Vous DEVEZ déclarer la fonctionnalité android.hardware.vr.high_performance.
• [C-1-3] DOIT prendre en charge le mode Performances soutenues.
• [C-1-4] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.2.
• [C-1-5] DOIT prendre en charge android.hardware.vulkan.level 0.
• DOIT être compatible avec android.hardware.vulkan.level 1 ou une 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'exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR] Il est FORTEMENT RECOMMANDÉ 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 où flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et où queueCount est au moins égal à 2.
• [C-1-7] Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu alterné des contenus VR à 60 FPS avec deux contextes de rendu soit affiché sans artefacts de déchirure visibles.
• [C-1-9] DOIT prendre en charge les indicateurs AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT de AHardwareBuffer, comme décrit dans le NDK.
• [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, 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] FORTEMENT RECOMMANDÉ pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs calques, ainsi que les indicateurs et les formats spécifiés dans C-1-10.
• [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS-20 Mbit/s).
• [C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressé à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS-20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-5 Mbit/s).
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température de la peau.
• [C-1-14] DOIT comporter un écran intégré dont la résolution DOIT être d'au moins 1 920 x 1 080.
• [C-SR] Nous vous RECOMMANDONS vivement d'utiliser une résolution d'affichage d'au moins 2 560 x 1 440 pixels.
• [C-1-15] L'écran doit se mettre à jour à au moins 60 Hz en mode VR.
• [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance de 5 millisecondes maximum, la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
• [C-1-18] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE (section 7.4.3).
• [C-1-19] DOIT prendre en charge et signaler correctement le type de canal direct pour tous les types de capteurs par défaut suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Nous vous RECOMMANDONS vivement de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
• [C-1-21] DOIT respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors.
• [C-1-22] La latence de mouvement à photon de bout en bout doit être inférieure à 28 millisecondes.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas dépasser 20 millisecondes de latence de mouvement à photon de bout en bout.
• [C-1-23] Le ratio du premier frame, qui correspond au ratio entre la luminosité des pixels du premier frame après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable, doit être d'au moins 85%.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de premier frame d'au moins 90%.
• PEUT fournir un cœur exclusif à l'application de premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer les numéros des cœurs de processeur exclusifs à l'application de premier plan principale.

Si le cœur exclusif est compatible, le cœur:

• [C-2-1] Le kernel DOIT empêcher l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes d'appareils utilisés par l'application), mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.

7.10. Technologie tactile

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

7.11. Classe de performances multimédias

La classe de performances multimédias de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Les exigences concernant la classe de performances multimédias sont définies pour chaque version d'Android à partir de R (version 30). La valeur spéciale 0 indique que l'appareil ne fait pas partie d'une classe de performances multimédias.

Si les implémentations de l'appareil renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles:

• [C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.

• [C-1-2] L'implémentation doit être destinée à un appareil portable.

• [C-1-3] DOIT respecter toutes les exigences de la "classe de performance multimédia" décrites dans la section 2.2.7.

Consultez la section 2.2.7 pour connaître les exigences spécifiques à l'appareil.

8. Performances et puissance

Certains critères de performances et d'alimentation minimaux sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de référence que les développeurs doivent prendre en compte lorsqu'ils développent une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final si certaines conditions minimales sont respectées pour garantir une fréquence d'images et des temps de réponse cohérents pour les applications et les jeux. Selon le type d'appareil, les implémentations peuvent avoir des exigences mesurables concernant la latence de l'interface utilisateur et le changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes sur le stockage de données privées de l'application (partition /data) permet aux développeurs d'applications de définir des attentes appropriées qui faciliteront la conception de leur logiciel. Selon le type d'appareil, les implémentations d'appareil peuvent être soumises à certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes:

• Performances d'écriture séquentielle Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 ko.
• Performances de lecture séquentielle Mesure effectuée en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

Si les implémentations de l'appareil incluent des fonctionnalités d'amélioration de la gestion de l'alimentation de l'appareil qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, Doze) 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 s'écarter de l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de réveil, ainsi que pour l'utilisation des paramètres système globaux des modes d'économie d'énergie App Standby et Doze.
• [C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation de paramètres globaux afin de gérer le débit des tâches, de l'alarme et du réseau pour les applications de chaque bucket en mode veille de l'application.
• [C-1-3] Le nombre de buckets App Standby utilisés pour App Standby NE DOIT PAS différer de l'implémentation AOSP.
• [C-1-4] DOIT implémenter les buckets de mise en veille des applications et le mode Doze 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] Il est FORTEMENT RECOMMANDÉ de fournir à l'utilisateur une affordance lui permettant d'activer et de désactiver la fonctionnalité Économiseur de batterie.
• [C-SR] Il est vivement recommandé de fournir à l'utilisateur la possibilité d'afficher toutes les applications qui sont exemptées des modes d'économie d'énergie App Standby et Doze.

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP et que cette extension applique des restrictions plus strictes que le bucket "Rare" de mise en veille des applications, consultez la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou l'ensemble des quatre états d'alimentation en veille définis par l'interface ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles:

• [C-1-1] L'appareil NE DOIT PAS entrer dans cet état tant que l'utilisateur n'a pas effectué une action explicite pour le mettre en veille (par exemple, en fermant un couvercle qui fait physiquement partie de l'appareil ou en éteignant un véhicule ou un téléviseur) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le couvercle ou en rallumant le véhicule ou le téléviseur).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles:

• [C-2-1] DOIT respecter C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran, le processeur).

  À l'inverse, vous devez quitter l'état S3 lorsque des applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

  Par exemple, lorsque les applications tierces demandent à maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou à maintenir le processeur en cours d'exécution via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS entrer en état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris une mesure explicite pour mettre l'appareil en état inactif. À l'inverse, lorsqu'une tâche implémentée par des applications tierces via JobScheduler est déclenchée ou que Firebase Cloud Messaging est envoyé à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur l'a mis en veille. Il ne s'agit pas d'exemples exhaustifs, et AOSP implémente des signaux de réveil étendus qui déclenchent un réveil à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et une création de rapports plus précises de la consommation d'énergie fournissent au développeur d'applications les incitations et les outils nécessaires pour optimiser le modèle d'utilisation de l'énergie de l'application.

Implémentations de l'appareil:

• [SR] Nous vous recommandons vivement de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Open Source Android.
• [SR] Nous vous recommandons vivement de déclarer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
• [SR] FORTEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur par UID de chaque processus. Le projet Open Source Android répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
• [SR] Il est vivement recommandé de rendre cette consommation d'énergie disponible via la commande shell adb shell dumpsys batterystats pour le développeur de l'application.
• DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.

8.5. Performances cohérentes

Les performances peuvent fluctuer de manière importante pour les applications de longue durée hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison du débit limité du processeur en raison de limites de température. Android inclut des interfaces programmatiques afin que, lorsque l'appareil est compatible, l'application de premier plan puisse demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations de l'appareil:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode d'API PowerManager.isSustainedPerformanceModeSupported().

• DOIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils indiquent la prise en charge du mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan un niveau de performances cohérent pendant au moins 30 minutes, lorsque l'application le demande.
• [C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent deux cœurs de processeur ou plus, elles:

• DOIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan.

Si les implémentations d'appareils permettent de réserver un cœur exclusif pour l'application de premier plan, elles:

• [C-2-1] DOIT indiquer via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs pouvant être réservés par l'application de premier plan supérieure.
• [C-2-2] Le kernel DOIT empêcher l'exécution de tout processus d'espace utilisateur, à l'exception des pilotes d'appareils utilisés par l'application sur les cœurs exclusifs, mais PEUT autoriser l'exécution de certains processus de noyau si nécessaire.

Si les implémentations de l'appareil ne sont pas compatibles avec un cœur exclusif, elles:

• [C-3-1] DOIT renvoyer une liste vide via la méthode d'API Process.getExclusiveCores().

9. Compatibilité des modèles de sécurité

Implémentations de l'appareil:

• [C-0-1] DOIT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API dans la documentation destinée aux développeurs Android.

• [C-0-2] DOIT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers/autorités. 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 de l'appareil:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation destinée aux 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 ou ignorée.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne se trouvent pas dans l'espace de noms android.\*.

• [C-0-2] Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED DOIVENT être accordées uniquement aux applications préinstallées dans le ou les chemins privilégiés de l'image système et dans le sous-ensemble des autorisations explicitement autorisées pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations de la liste d'autorisation pour chaque application à partir des fichiers du chemin 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 targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations de l'appareil:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder les autorisations d'exécution demandées et de fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] Il doit y avoir une seule et unique implémentation des deux interfaces utilisateur.
• [C-0-5] Vous NE DEVEZ PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf si :
  • Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise.
  • Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
• [C-0-6] Vous devez accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage distant hors appareil, équipé de matériel sécurisé offrant une protection équivalente ou plus forte que celle décrite dans le service Google Cloud Key Vault pour éviter les attaques par force brute sur le facteur de connaissance du verrouillage de l'écran.

Implémentations de l'appareil:

• [C-0-7] DOIT respecter les propriétés de l'autorisation d'accéder à la position Android lorsqu'une application demande des données de localisation ou d'activité physique via une API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter, les éléments suivants:

  • Position de l'appareil (latitude et longitude, par exemple)
  • Informations permettant de déterminer ou d'estimer la position de l'appareil (par exemple, SSID, BSSID, ID de cellule ou emplacement du réseau auquel l'appareil est connecté).
  • Activité physique de l'utilisateur ou classification de l'activité physique

Plus précisément, les implémentations d'appareils:

• [C-0-8] Vous DEVEZ obtenir le consentement de l'utilisateur pour autoriser une application à accéder aux données de localisation ou d'activité physique.
• [C-0-9] Vous devez accorder une autorisation d'exécution UNIQUEMENT à l'application disposant d'une autorisation suffisante, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les autorisations peuvent être marquées comme limitées, ce qui modifie leur comportement.

• [C-0-10] Les autorisations marquées avec l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si:

  • Le fichier APK d'une application se trouve dans la partition du système.
  • L'utilisateur attribue un rôle associé aux autorisations hardRestricted à une application.
  • Le programme d'installation accorde le hardRestricted à une application.
  • Une application reçoit l'hardRestricted sur une version antérieure d'Android.

• [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT n'obtenir qu'un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles ne figurent pas sur la liste d'autorisation, comme décrit dans le SDK, où l'accès complet et limité est défini pour chaque autorisation softRestricted (par exemple, READ_EXTERNAL_STORAGE).

Si les implémentations d'appareils permettent à l'utilisateur de choisir quelles applications peuvent dessiner par-dessus d'autres applications avec une activité qui gère l'intent ACTION_MANAGE_OVERLAY_PERMISSION, elles:

• [C-2-1] 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, quelle que soit l'application à l'origine ou les informations qu'elle fournit.

9.2. UID et isolation des processus

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge le modèle de bac à sable d'application Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct.
• [C-0-2] DOIT permettre d'exécuter plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et conçues, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations de l'appareil:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Environnements d'exécution alternatifs

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Autrement dit :

• [C-0-1] Les environnements d'exécution alternatifs DOIVENT être eux-mêmes des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.

• [C-0-2] Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le mécanisme <uses-permission>.

• [C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

• [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.

• [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ni être autorisés à accéder aux bacs à sable correspondant à d'autres applications Android.

• [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec les droits du super-utilisateur (root) ni accorder ces droits à d'autres applications.

• [C-0-7] Lorsque les fichiers .apk d'autres environnements d'exécution sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses avec les implémentations d'appareils.

• [C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.

• [C-0-9] Lorsqu'une application doit utiliser une ressource d'appareil pour laquelle une autorisation Android correspondante est disponible (appareil photo, GPS, etc.), le runtime alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

• [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les fonctionnalités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

• Les 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 utilisent l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et permet une isolation complète des utilisateurs.

• Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer la multi-utilisation si elles utilisent des supports amovibles pour le stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs:

• [C-1-1] DOIT répondre aux exigences suivantes concernant la prise en charge multi-utilisateur.
• [C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API.
• [C-1-3] DOIT disposer de répertoires de stockage d'application partagés (/sdcard) distincts et isolés pour chaque instance utilisateur.
• [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou le même système de fichiers.
• [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque la multi-utilisateur est activée à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations de l'appareil utilisent un support amovible pour les API de stockage externe. Comme les supports multimédias ne seront plus lisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout message SMS surtaxé sortant. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur qui peuvent entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent la compatibilité avec android.hardware.telephony, elles:

• [C-1-1] L'appareil DOIT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle d'accès obligatoire (MAC) de Security-Enhanced Linux (SELinux), le bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. Implémentations de l'appareil:

• [C-0-1] DOIT assurer la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité est implémentée sous le framework Android.
• [C-0-2] Une interface utilisateur ne doit PAS être visible lorsqu'une violation de sécurité est détectée et bloquée par la fonctionnalité de sécurité implémentée sous le framework Android. Toutefois, une interface utilisateur peut être visible lorsqu'une violation de sécurité non bloquée se produit et qu'un exploit est réussi.
• [C-0-3] L'utilisateur ou le développeur d'applications NE DOIT PAS pouvoir configurer SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android.
• [C-0-4] Une application pouvant affecter une autre application via une API (telle qu'une API d'administration d'appareils) NE DOIT PAS être autorisée à configurer une règle qui compromet la compatibilité.
• [C-0-5] Le framework multimédia doit être divisé en plusieurs processus afin de pouvoir accorder un accès plus précis à chaque processus, comme décrit sur le site du projet Open Source Android.
• [C-0-6] DOIT implémenter un mécanisme de bac à sable d'application de kernel qui permet de filtrer les appels système à l'aide d'une stratégie configurable à partir de programmes multithread. Le projet Android Open Source en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de threadgroup (TSYNC), comme décrit dans la section "Configuration du kernel" de source.android.com.

Les fonctionnalités d'intégrité et d'autoprotection du noyau sont essentielles à la sécurité d'Android. Implémentations de l'appareil:

• [C-0-7] Le kernel doit mettre en œuvre des mécanismes de protection contre le débordement de tampon de pile. CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG sont des exemples de tels mécanismes.
• [C-0-8] Le noyau doit mettre en œuvre des protections strictes de la mémoire, 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 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'objets statiques et dynamiques pour les 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 version ultérieure.
• [C-0-10] NE DOIT PAS exécuter de mémoire d'espace utilisateur lors de l'exécution en mode kernel (par exemple, PXN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire d'espace utilisateur dans le noyau en dehors des API d'accès utilisateurcopy normales (par exemple, PAN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur.
• [C-0-12] DOIT implémenter l'isolation de la table des pages du noyau si le matériel est vulnérable à CVE-2017-5754 sur tous les appareils initialement livrés avec le niveau d'API 28 ou version ultérieure (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
• [C-0-13] DOIT implémenter le renforcement de la prédiction de branche si le matériel est vulnérable à CVE-2017-5715 sur tous les appareils livrés à l'origine avec le niveau d'API 28 ou version ultérieure (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
• [SR] Il est vivement recommandé de marquer les données du noyau qui ne sont écrites que lors de l'initialisation comme en lecture seule après l'initialisation (par exemple, __ro_after_init).

• [C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser la mise en page du code et de la mémoire du noyau, et d'éviter les expositions qui pourraient compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR] Nous vous RECOMMANDONS vivement d'activer l'intégrité du flux de contrôle (CFI) dans le noyau afin de renforcer la protection 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 l'intégrité du flux de contrôle (CFI), la pile d'appels fantômes (SCS) ou la suppression des valeurs non valides en cas de débordement d'entier (IntSan) sur les composants où elles sont activées.
• [C-SR] Nous vous RECOMMANDONS vivement d'activer CFI, SCS et IntSan pour tous les composants d'espace utilisateur supplémentaires sensibles à la sécurité, comme expliqué dans CFI et IntSan.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour éviter l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les variables locales.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau pour éviter l'utilisation d'allocations de tas de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Ils NE DOIVENT PAS supposer la valeur utilisée par le noyau pour initialiser ces allocations.

Si les implémentations d'appareils utilisent un noyau Linux, elles:

• [C-1-1] DOIT implémenter SELinux.
• [C-1-2] Vous devez définir SELinux sur le mode d'application forcée global.
• [C-1-3] Vous devez configurer tous les domaines en mode d'application. Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/vendeur.
• [C-1-4] Vous NE DEVEZ PAS modifier, omettre ni remplacer les règles neverallow présentes dans le dossier system/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT compiler avec toutes les règles neverallow présentes, à la fois pour les domaines SELinux AOSP et les domaines spécifiques à l'appareil/au fournisseur.
• [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou version ultérieure dans des bacs à sable SELinux par application avec des restrictions SELinux par application sur le répertoire de données privées de chaque application.
• DOIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Open Source Android en amont et ne l'ajouter qu'à sa 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 [C-1-1] et [C-1-5] via une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Si les implémentations d'appareils utilisent un noyau autre que Linux, elles:

• [C-2-1] Vous DEVEZ utiliser un système de contrôle d'accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui sont essentielles à la sécurité de l'appareil.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et le gère à l'aide de UsageStatsManager.

Implémentations de l'appareil:

• [C-0-1] DOIT conserver cet historique utilisateur pendant une période de conservation raisonnable.
• [SR] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle que configurée par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via l'API système StatsManager et IncidentManager.

Implémentations de l'appareil:

• [C-0-2] Le rapport d'incident créé par la classe d'API système IncidentManager DOIT inclure uniquement les champs marqués de DEST_AUTOMATIC.
• [C-0-3] Vous NE DEVEZ PAS utiliser les identifiants d'événement système pour consigner un événement autre que celui décrit dans les documents du SDK StatsLog. Si des événements système supplémentaires sont consignés, ils PEUVENT utiliser un autre identifiant d'atome compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations de l'appareil:

• [C-0-1] Vous NE DEVEZ PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient les informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran, les rapports de bugs) depuis l'appareil sans l'autorisation de l'utilisateur ni sans notifications claires en cours.
• [C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur permettant de capturer toutes les informations sensibles affichées à l'écran de l'utilisateur chaque fois que la diffusion ou l'enregistrement d'écran est activé via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs une affordance pour désactiver l'affichage futur du consentement de l'utilisateur.
• [C-0-3] L'utilisateur doit recevoir une notification continue lorsque la diffusion ou l'enregistrement d'écran sont activés. AOSP répond à cette exigence en affichant une icône de notification en cours dans la barre d'état.

Si les implémentations d'appareils incluent une fonctionnalité dans le système qui capture les contenus affichés à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou d'autres moyens propriétaires décrits dans la section 9.8.6 Capture de contenu, elles:

• [C-1-1] L'utilisateur doit recevoir une notification continue chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement des données.

Si les implémentations d'appareils incluent un composant activé par défaut, capable d'enregistrer l'audio ambiant et/ou l'audio lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, elles:

• [C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil l'audio brut enregistré ni tout format pouvant être converti en audio d'origine ou en fac-similé proche, sauf avec le consentement explicite de l'utilisateur.

9.8.3. Connectivité

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

• [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations de l'appareil:

• [C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin de l'autorité de certification (CA) approuvée par le système que ceux fournis dans le projet Open Source Android en amont.
• [C-0-2] DOIT être fourni avec un magasin d'autorités de certification racine utilisateur vide.
• [C-0-3] L'utilisateur doit recevoir un avertissement indiquant que le trafic réseau peut être surveillé lorsqu'une autorité de certification racine utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations de l'appareil:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
  • Ce trafic réseau peut être surveillé.
  • Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, précharger un service VPN avec android.permission.CONTROL_VPN accordé), ils:

• [C-2-1] DOIT demander l'autorisation de l'utilisateur avant d'activer ce mécanisme, sauf si ce VPN est activé par le contrôleur de stratégie d'appareil via DevicePolicyManager.setAlwaysOnVpnPackage() , auquel cas l'utilisateur n'a pas besoin de donner un consentement distinct, mais DOIT simplement être informé.

Si les implémentations d'appareils implémentent une affordance utilisateur permettant d'activer la fonction "VPN permanent" d'une application VPN tierce, elles:

• [C-3-1] Vous devez désactiver cette affordance utilisateur pour les applications qui ne sont pas compatibles avec le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.8.5. Identifiants des appareils

Implémentations de l'appareil:

• [C-0-1] Une application DOIT empêcher l'accès au numéro de série de l'appareil et, le cas échéant, au code IMEI/MEID, au numéro de série de la carte SIM et à l'identifiant IMSI (International Mobile Subscriber Identity), sauf si elle répond à l'une des conditions suivantes :
  • est une application opérateur signée et validée par les fabricants d'appareils.
  • a reçu l'autorisation READ_PRIVILEGED_PHONE_STATE.
  • dispose de privilèges d'opérateur, comme défini dans la section Privilèges de l'opérateur sur la carte UICC.
  • est le propriétaire de l'appareil ou du profil auquel l'autorisation READ_PHONE_STATE a été accordée.
  • (Pour le numéro de série de la SIM/l'ICCID uniquement) les réglementations locales exigent que l'application détecte les modifications de l'identité de l'abonné.

9.8.6. Capture de contenu

Android, via l'API système ContentCaptureService ou par d'autres moyens propriétaires, prend en charge un mécanisme permettant aux implémentations d'appareils de capturer les interactions suivantes entre les applications et l'utilisateur.

• Texte et graphiques affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure.
• Données multimédias, telles que des contenus audio ou vidéo, enregistrées ou lues par l'appareil.
• Événements d'entrée (par exemple, touche, souris, geste, voix, vidéo et accessibilité).
• Tous les autres événements qu'une application fournit au système via l'API Content Capture ou une API propriétaire de même capacité.
• Tout texte ou toute autre donnée envoyée via TextClassifier API au System TextClassifier (service système permettant de comprendre le sens du texte et de générer les actions suivantes prévues en fonction du texte).

Si les implémentations d'appareils capturent les données ci-dessus, elles:

• [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées sur l'appareil. Ce chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android ou de l'un des algorithmes de chiffrement listés comme version d'API 26 ou supérieure décrits dans le SDK de chiffrement.
• [C-1-2] NE DOIT PAS sauvegarder de données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ni de toute autre méthode de sauvegarde.
• [C-1-3] DOIT n'envoyer toutes ces données et le journal de l'appareil qu'à l'aide d'un mécanisme protégeant la confidentialité. Un mécanisme protégeant la confidentialité est défini comme "celui qui n'autorise que l'analyse globale et empêche la mise en correspondance des événements consignés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher l'accès aux données par utilisateur (par exemple, implémenté à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
• [C-1-4] NE DOIT PAS associer ces données à une identité utilisateur (telle que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur à chaque fois que les données sont associées.
• [C-1-5] NE DOIT PAS partager ces données avec d'autres applications, sauf avec le consentement explicite de l'utilisateur à chaque partage.
• [C-1-6] DOIT fournir à l'utilisateur la possibilité d'effacer les données collectées par le ContentCaptureService ou les moyens propriétaires si elles sont stockées sous quelque forme que ce soit sur l'appareil.

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, elles:

• [C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer le service de capture de contenu par une application ou un service installable par l'utilisateur, et DOIT n'autoriser que le service préinstallé à capturer ces données.
• [C-2-2] NE DOIT PAS autoriser d'autres applications que le mécanisme de service de capture de contenu préinstallé à pouvoir capturer ces données.
• [C-2-3] DOIT fournir une affordance permettant à l'utilisateur de désactiver le service de capture de contenu.
• [C-2-4] NE DOIT PAS omettre l'affordance utilisateur pour gérer les autorisations Android détenues par le service de capture de contenu et suivre 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 des autres composants système, par exemple en ne liant pas le service ni en ne partageant pas les ID de processus, sauf dans les cas suivants:

  • Téléphonie, Contacts, UI du système et multimédia

9.8.7. Accès au presse-papiers

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS renvoyer de données coupées dans le presse-papiers (par exemple, via l'API ClipboardManager) sauf si l'application est l'IME par défaut ou l'application active.

9.8.8. Position

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS activer/désactiver les paramètres de localisation de l'appareil et les paramètres de recherche Wi-Fi/Bluetooth sans l'autorisation explicite de l'utilisateur ou sans que celui-ci ne l'ait initié.
• [C-0-2] DOIT fournir à l'utilisateur la possibilité d'accéder aux informations liées à la position, y compris les demandes de position récentes, les autorisations au niveau de l'application et l'utilisation de la numérisation Wi-Fi/Bluetooth pour déterminer la position.
• [C-0-3] L'application qui utilise l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] doit impérativement être une session d'urgence déclenchée par l'utilisateur (par exemple, composer le 112 ou envoyer un message au 112). Toutefois, pour les applications automobiles, un véhicule PEUT lancer une session d'urgence sans interaction active de l'utilisateur en cas de détection d'un accident (par exemple, pour répondre aux exigences d'eCall).
• [C-0-4] L'API Emergency Location Bypass doit conserver la possibilité de contourner les paramètres de localisation de l'appareil sans les modifier.
• [C-0-5] Une notification doit être planifiée pour rappeler à l'utilisateur qu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Par défaut, les applications Android ciblant le niveau d'API 30 ou version ultérieure ne peuvent pas voir les informations sur les autres applications installées (voir la section Visibilité du package dans la documentation du SDK Android).

Implémentations de l'appareil:

• [C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou supérieur les détails d'une autre application installée, sauf si l'application peut déjà voir les détails de l'autre application installée via les API gérées. Cela inclut, mais sans s'y limiter, les informations exposées par les API personnalisées ajoutées par l'implémentateur de l'appareil ou accessibles via le système de fichiers.

9.8.10. Rapport de bug sur la connectivité

Si les implémentations d'appareil génèrent des rapports de bug à l'aide de l'API système BUGREPORT_MODE_TELEPHONY avec BugreportManager, elles:

• [C-1-1] DOIT obtenir le consentement de l'utilisateur chaque fois que l'API système BUGREPORT_MODE_TELEPHONY est appelée pour générer un rapport et NE DOIT PAS inviter l'utilisateur à accepter 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 renvoyer le rapport généré à l'application à l'origine de la demande sans le consentement explicite de l'utilisateur.
• [C-1-3] DOIT générer les rapports demandés contenant au moins les informations suivantes :
  • Dump TelephonyDebugService
  • Dump de TelephonyRegistry
  • Dump WifiService
  • Dump ConnectivityService
  • Un dump de l'instance CarrierService du package appelant (si lié)
  • Tampon journal radio
• [C-1-4] Les rapports générés NE DOIVENT PAS inclure les éléments suivants :
  • Tout type d'information sans rapport avec le débogage de la connectivité
  • Tout type de journaux de trafic d'applications installées par l'utilisateur ou de profils détaillés des applications/paquets installés par l'utilisateur (les UID sont acceptés, mais les noms de package ne le sont pas).
• PEUVENT inclure des informations supplémentaires qui ne sont associées à aucune identité utilisateur. (par exemple, les journaux du fournisseur).

Si les implémentations de l'appareil incluent des informations supplémentaires (par exemple, des 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/la mémoire, elles:

• [C-SR] Il est vivement recommandé de définir un paramètre de développement par défaut sur "Désactivé". L'AOSP répond à ce besoin en fournissant l'option Enable verbose vendor logging dans les paramètres pour les développeurs afin d'inclure des journaux du fournisseur 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 fournir des blobs de données au système pour les partager avec un ensemble d'applications sélectionné.

Si les implémentations d'appareils prennent en charge les blobs de données partagés, comme décrit dans la documentation du SDK, elles:

• [C-1-1] NE DOIT PAS partager des blobs de données appartenant à des applications au-delà de ce qu'elles ont l'intention d'autoriser (c'est-à-dire que le champ d'application de l'accès par défaut et les autres modes d'accès pouvant être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess() NE DOIVENT PAS être modifiés). L'implémentation de référence AOSP répond à ces exigences.
• [C-1-2] NE DOIT PAS envoyer depuis l'appareil ni partager avec d'autres applications les hachages sécurisés des blobs de données (qui sont utilisés pour contrôler l'accès).

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT répondre aux exigences de la section 9.9.1. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. Ils DOIVENT plutôt respecter les exigences de la section 9.9 du document de définition de la compatibilité Android correspondant au niveau d'API sur lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations de l'appareil:

• [C-0-1] Les API du mode Démarrage direct doivent être implémentées, même si elles ne sont pas compatibles avec le chiffrement de stockage.

• [C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que les emplacements de stockage chiffré de l'appareil (DE) et chiffré par identifiant (CE) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations de l'appareil:

• [C-0-1] DOIT chiffrer les données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil.
• [C-0-2] Le chiffrement du stockage des données DOIT être activé par défaut lorsque l'utilisateur a terminé la configuration prête à l'emploi.

• [C-0-3] DOIT respecter l'exigence de chiffrement du stockage des données ci-dessus en implémentant l'une des deux méthodes de chiffrement suivantes:

  • Chiffrement basé sur les fichiers (FBE) et chiffrement des métadonnées, comme décrit dans la section 9.9.3.1.
  • Chiffrement au niveau des blocs par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations de l'appareil sont chiffrées, elles:

• [C-1-1] DOIT démarrer sans demander à l'utilisateur de fournir des identifiants et autoriser les applications compatibles avec le Démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DOIT n'autoriser l'accès au stockage chiffré par identifiants (CE) qu'après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (code, code PIN, schéma ou empreinte digitale, par exemple) et que le message ACTION_USER_UNLOCKED a été diffusé.
• [C-1-13] NE DOIT PAS proposer de méthode permettant de déverrouiller le stockage protégé par le contrôle électronique sans les identifiants fournis par l'utilisateur, une clé d'entiercement enregistrée ou une implémentation de la reprise après redémarrage conforme aux exigences de la section 9.9.4.
• [C-1-4] Vous devez utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers avec chiffrement des métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec le chiffrement des métadonnées, elles:

• [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide d'AES-256-XTS ou d'Adiantum. AES-256-XTS fait référence à l'Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme indiqué sur la page https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que la taille des fichiers, la propriété, les modes et les attributs étendus (xattrs).
• [C-1-6] DOIT chiffrer les noms de fichiers à l'aide d'AES-256-CBC-CTS ou d'Adiantum.
• [C-1-12] Si l'appareil dispose d'instructions AES (Advanced Encryption Standard) (telles que les extensions de cryptographie ARMv8 sur les appareils ARM ou AES-NI sur les appareils x86), les options AES ci-dessus pour le nom de fichier, le contenu du fichier et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisées, et non Adiantum.
• [C-1-13] DOIT utiliser une fonction de dérivation de clé cryptographiquement sécurisée et non réversible (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, les clés par fichier) à partir des clés CE et DE. "Cryptographiquement sécurisée et non réversible" signifie que la fonction de dérivation de clé présente une sécurité d'au moins 256 bits et se comporte comme une famille de fonctions pseudo-aléatoires sur ses entrées.

• [C-1-14] NE DOIT PAS utiliser les mêmes clés ou sous-clés de chiffrement basé sur les fichiers (FBE) à des fins cryptographiques différentes (par exemple, à la fois pour le chiffrement et la dérivation de clé, ou pour deux algorithmes de chiffrement différents).

• Les clés protégeant les zones de stockage CE et DE et les métadonnées du système de fichiers:

• [C-1-7] DOIT être lié de manière cryptographique à un Keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine de confiance matérielle de l'appareil.

• [C-1-8] Les clés CE DOIVENT être associées aux identifiants de l'écran de verrouillage de l'utilisateur.
• [C-1-9] Les clés CE DOIVENT être associées à un code secret par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage.
• [C-1-10] DOIT être unique et distinct. Autrement dit, la clé CE ou DE d'un utilisateur ne doit pas correspondre à celle d'un autre utilisateur.

• [C-1-11] DOIT utiliser les algorithmes de chiffrement, les longueurs de clé et les modes pris en charge de manière obligatoire.

• DOIT rendre les applications essentielles préinstallées (Alarme, Téléphone, Messenger, par exemple) compatibles avec le Démarrage direct.

Le projet Open Source Android en amont fournit une implémentation privilégiée du chiffrement basé sur les fichiers basée sur la fonctionnalité de chiffrement "fscrypt" du noyau Linux et du chiffrement des métadonnées basée sur la fonctionnalité "dm-default-key" du noyau Linux.

9.9.3.2. Chiffrement au niveau des blocs par utilisateur

Si les implémentations d'appareils utilisent le chiffrement par blocs par utilisateur, elles:

• [C-1-1] DOIT activer la prise en charge du mode multi-utilisateur, comme décrit dans la section 9.5.
• [C-1-2] DOIT fournir des partitions par utilisateur, à l'aide de partitions brutes ou de volumes logiques.
• [C-1-3] Vous DEVEZ utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des dispositifs de stockage sous-jacents.

• [C-1-4] Vous DEVEZ utiliser AES-256-XTS pour le chiffrement au niveau des blocs des partitions utilisateur.

• Les clés protégeant les appareils chiffrés par bloc par utilisateur:

• [C-1-5] DOIT être lié de manière cryptographique à un Keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et à la racine de confiance matérielle de l'appareil.

• [C-1-6] DOIT être associé aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau des blocs par utilisateur peut être implémenté à l'aide de la fonctionnalité "dm-crypt" du noyau Linux sur les partitions par utilisateur.

9.9.4. Reprendre au redémarrage

La reprise au redémarrage permet de déverrouiller l'espace de stockage CE de toutes les applications, y compris celles qui ne sont pas encore compatibles avec le démarrage direct, après un redémarrage déclenché par une mise à jour OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

Une implémentation de la reprise après redémarrage doit continuer à s'assurer que lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour ce pirate de récupérer les données chiffrées par le chiffrement côté client de l'utilisateur, même si l'appareil est allumé, que le stockage côté client est déverrouillé et que l'utilisateur a déverrouillé l'appareil après avoir reçu une mise à jour OTA. Pour la résistance aux attaques internes, nous supposons également que le pirate informatique accède aux clés de signature cryptographiques de diffusion.

Plus spécifiquement :

• [C-0-1] Le stockage CE NE DOIT PAS être lisible, même par le pirate informatique qui dispose physiquement de l'appareil et dispose alors des fonctionnalités et des limites suivantes:

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • Peut entraîner la réception d'une mise à jour OTA par l'appareil.
  • Peut modifier le fonctionnement de n'importe quel matériel (point d'accès, flash, etc.), sauf comme indiqué ci-dessous. Toutefois, cette modification implique un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.
  • Impossible de modifier le fonctionnement du matériel anti-piratage (par exemple, Titan M).
  • Impossible de lire la RAM de l'appareil en direct.
  • Ne peut pas obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ni les faire saisir.

Par exemple, une implémentation d'appareil qui implémente et respecte toutes les descriptions disponibles ici sera conforme à [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état de l'intégrité de l'appareil. Implémentations de l'appareil:

• [C-0-1] DOIT indiquer correctement via la méthode PersistentDataBlockManager.getFlashLockState() de l'API système si l'état de son bootloader permet le flashage de l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils mises à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

• [C-0-2] L'appareil DOIT prendre en charge le démarrage validé pour l'intégrité de l'appareil.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge le démarrage validé sur une version antérieure d'Android et qu'elles ne peuvent pas prendre en charge cette fonctionnalité avec une mise à jour logicielle du système, elles PEUVENT être exemptées de cette exigence.

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

• [C-1-1] Vous DEVEZ déclarer l'option de fonctionnalité de la plate-forme android.software.verified_boot.
• [C-1-2] Le système DOIT effectuer une validation à chaque séquence de démarrage.
• [C-1-3] La validation doit commencer à partir d'une clé matérielle immuable qui est la racine de confiance et s'étendre jusqu'à la partition système.
• [C-1-4] Vous DEVEZ implémenter chaque étape de vérification pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
• [C-1-5] DOIT utiliser des algorithmes de validation aussi sécurisés que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clé publique (RSA-2048).
• [C-1-6] Le démarrage NE DOIT PAS être autorisé à se terminer lorsque la validation du système échoue, sauf si l'utilisateur accepte de tenter de démarrer de toute façon, auquel cas les données de tous les blocs de stockage non validés NE DOIVENT PAS être utilisées.
• [C-1-7] Le bootloader NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
• [C-SR] Si l'appareil contient plusieurs puces distinctes (par exemple, une radio, un processeur d'image spécialisé), il est FORTEMENT RECOMMANDÉ de vérifier chaque étape du processus de démarrage de chacune de ces puces au démarrage.
• [C-1-8] DOIT utiliser un stockage inviolable: pour stocker l'état de déverrouillage du bootloader. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] L'utilisateur doit être invité à confirmer physiquement la transition du mode bootloader verrouillé au mode bootloader déverrouillé lorsqu'il utilise l'appareil.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (par exemple, les partitions de démarrage et système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale de l'OS autorisée.
• [C-SR] Nous vous RECOMMANDONS vivement de valider tous les fichiers APK d'application privilégiés avec une chaîne de confiance enracinée dans des partitions protégées par le démarrage validé.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier les artefacts exécutables chargés par une application privilégiée en dehors de son fichier APK (tel que le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
• DOIT implémenter une protection contre le rollback pour tout composant doté d'un micrologiciel persistant (modem, appareil photo, etc.) et DOIT utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge les exigences C-1-8 à C-1-10 sur une version antérieure d'Android et qu'elles ne peuvent pas être mises à jour pour prendre en charge ces exigences avec une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégrée au bootloader utilisé pour charger Android.

Implémentations de l'appareil:

• [C-0-3] DOIT permettre de vérifier de manière cryptographique le contenu d'un fichier à l'aide d'une clé approuvée sans lire l'intégralité du fichier.
• [C-0-4] Les requêtes de lecture sur un fichier protégé NE DOIVENT PAS aboutir lorsque le contenu lu ne correspond pas à une clé approuvée.

Si les implémentations d'appareils sont déjà lancées sans possibilité de vérifier le contenu des fichiers à l'aide d'une clé approuvée sur une version antérieure d'Android et qu'elles ne peuvent pas ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle du système, elles PEUVENT être exemptées de cette exigence. Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations de l'appareil:

• [C-R] Il est RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations de l'appareil sont compatibles avec l'API Android Protected Confirmation, elles:

• [C-3-1] DOIT signaler true pour l'API ConfirmationPrompt.isSupported().

• [C-3-2] Le code exécuté dans l'OS Android, y compris son noyau, qu'il soit malveillant ou non, DOIT être conçu pour qu'il ne puisse pas générer de réponse positive sans interaction de l'utilisateur.

• [C-3-3] DOIT s'assurer que l'utilisateur a pu examiner et approuver le message demandé, même si l'OS Android, y compris son noyau, est compromis.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations de l'appareil:

• [C-0-1] DOIT permettre d'importer ou de générer au moins 8 192 clés.
• [C-0-2] L'authentification de l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT comporter un algorithme de délai avant réessai exponentiel. Au-delà de 150 tentatives infructueuses, le délai doit être d'au moins 24 heures par tentative.
• NE DOIT PAS limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle:

• [C-1-1] Vous DEVEZ sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
• [C-1-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre en charge correctement les algorithmes compatibles du système Android Keystore dans une zone isolée de manière sécurisée du code exécuté sur le noyau et au-dessus. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lesquels le code du noyau ou de l'espace utilisateur peut accéder à l'état interne de l'environnement isolé, y compris le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais une autre solution basée sur ARM TrustZone ou une implémentation sécurisée examinée par un tiers d'une isolation basée sur un hyperviseur approprié sont des options alternatives.
• [C-1-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ne permettre qu'à l'environnement d'exécution isolé d'effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [C-1-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature d'attestation est protégée par du matériel sécurisé et que la signature est effectuée sur du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées entre un nombre suffisamment important d'appareils pour éviter qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

• [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour la transition de l'état déverrouillé à l'état verrouillé, avec un délai minimal autorisé de 15 secondes. Les appareils automobiles, qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur change, NE PEUVENT PAS avoir de configuration de délai de mise en veille.

9.11.1. Verrouillage sécurisé de l'écran et authentification

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux, où une authentification primaire basée sur une usine de connaissances peut être étayée par une biométrie secondaire forte ou par des modalités tertiaires plus faibles.

Implémentations de l'appareil:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de ne définir qu'une seule des méthodes d'authentification suivantes comme méthode d'authentification principale :
  • Un code numérique
  • Un mot de passe alphanumérique
  • Un balayage sur une grille de 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont désignées comme méthodes d'authentification principales recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées et utilisent une nouvelle méthode d'authentification pour verrouiller l'écran de manière sécurisée, la nouvelle méthode d'authentification:

• [C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans Exiger l'authentification de l'utilisateur pour l'utilisation des clés.

Si les implémentations de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage si elles sont basées sur un secret connu et qu'elles utilisent une nouvelle méthode d'authentification pour être traitées comme un moyen sécurisé de verrouiller l'écran:

• [C-3-1] L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
• [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
• [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer l'une des méthodes d'authentification principales recommandées (code, schéma, mot de passe) implémentées et fournies dans AOSP.
• [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité des mots 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 soit revenir aux méthodes d'authentification primaires recommandées (code, schéma, mot de passe) toutes les 72 heures ou moins, soit indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de ses données.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie pour être traitée comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode:

• [C-4-1] DOIT respecter toutes les exigences décrites dans la section 7.3.10 pour la classe 1 (anciennement Convenience).
• [C-4-2] DOIT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu.
• [C-4-3] DOIT être désactivé et ne doit autoriser que l'authentification primaire recommandée pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la stratégie de fonctionnalité du clavier de verrouillage en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures() avec l'un des indicateurs biométriques associés (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 stratégie 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é à fournir l'authentification primaire recommandée (par exemple, un code, un schéma ou un mot de passe), comme décrit dans les sections [C-1-7] et [C-1-8] de la section 7.3.10.
• [C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé et DOIVENT respecter les exigences commençant par C-8 dans cette section ci-dessous.

Si les implémentations de l'appareil ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur la position:

• [C-6-1] Ils DOIVENT disposer d'un mécanisme de remplacement permettant d'utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et qui répond aux exigences pour être traité comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et ne doit autoriser qu'une seule des méthodes d'authentification primaires recommandées à déverrouiller l'écran lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la stratégie 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 primaires recommandées (code, schéma, mot de passe, par exemple) au moins une fois toutes les quatre heures.
• [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.

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

• [C-7-1] Le menu des paramètres et l'écran de verrouillage doivent indiquer clairement quand le verrouillage de l'appareil est différé ou peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouiller automatiquement" et "Le bouton Marche/Arrêt verrouille instantanément" dans le menu des paramètres, ainsi qu'une icône distincte sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et implémenter entièrement toutes les API de l'agent de confiance dans la classe DevicePolicyManager, comme la constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] La fonction TrustAgentService.addEscrowToken() NE DOIT PAS être implémentée entièrement sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil portable), mais elle PEUT être implémentée entièrement sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou un appareil automobile).
• [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
• [C-7-5] Vous NE DEVEZ PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui sur lequel la clé est utilisée. Par exemple, une clé stockée sur un téléphone peut être utilisée pour déverrouiller un compte utilisateur sur une télévision. Pour les appareils Automotive, le jeton d'entiercement ne doit pas être stocké sur une partie du véhicule.
• [C-7-6] DOIT informer l'utilisateur des conséquences sur la sécurité avant d'activer le jeton d'entiercement pour déchiffrer le stockage de données.
• [C-7-7] DOIT disposer d'un mécanisme de remplacement pour utiliser l'une des méthodes d'authentification principales recommandées.
• [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les 72 heures, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est en cause.
• [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma, mot de passe) décrites dans [C-1-7] et [C-1-8] de la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est en cause.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.
• [C-7-11] Les TrustAgents ne doivent PAS être autorisés à déverrouiller les appareils personnels principaux (par exemple, les appareils portables). Ils ne peuvent les utiliser que pour maintenir un appareil déjà déverrouillé dans cet état pendant un maximum de quatre heures. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
• [C-7-12] DOIT utiliser un canal de communication cryptographiquement sécurisé (par exemple, UKEY2) pour transmettre le jeton de séquestre de l'appareil de stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller un écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et qu'elles utilisent une nouvelle méthode d'authentification pour déverrouiller le clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité des mots de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] Ils NE DOIVENT PAS réinitialiser les minuteurs d'expiration des mots de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Elles NE DOIVENT PAS exposer une API permettant aux applications tierces de modifier l'état de la serrure.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un processeur sécurisé dédié, ainsi que dans l'environnement d'exécution isolé décrit ci-dessus. Un tel processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre pour être considéré comme une StrongBox.

Implémentations d'appareils avec un processeur sécurisé dédié:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox. StrongBox deviendra probablement obligatoire dans une prochaine version.

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

• [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DOIT fournir du matériel sécurisé dédié qui est utilisé pour prendre en charge le keystore et sécuriser l'authentification des utilisateurs. Le matériel sécurisé dédié peut également être utilisé à d'autres fins.

• [C-1-3] DOIT disposer d'un processeur distinct qui ne partage aucun cache, DRAM, coprocesseur ni autre ressource de base avec le processeur d'application (PA).

• [C-1-4] DOIT s'assurer que les périphériques partagés avec l'AP ne peuvent en aucun cas modifier le traitement de StrongBox ni obtenir des informations de la part de StrongBox. Le point d'accès peut désactiver ou bloquer l'accès à StrongBox.

• [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) qui est insensible à la manipulation par le point d'accès.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit une sortie distribuée uniformément et imprévisible.

• [C-1-7] DOIT être résistant à la falsification, y compris à la pénétration physique et aux glitchs.

• [C-1-8] DOIT être résistant aux canaux auxiliaires, y compris à la fuite d'informations via les canaux auxiliaires d'alimentation, de synchronisation, de rayonnement électromagnétique et de rayonnement thermique.

• [C-1-9] Le stockage doit être sécurisé et garantir la confidentialité, l'intégrité, l'authenticité, la cohérence et la fraîcheur des contenus. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf dans les cas autorisés par les API StrongBox.

• Pour valider la conformité avec [C-1-3] à [C-1-9], les implémentations d'appareils:

  • [C-1-10] DOIT inclure le matériel certifié selon le profil de protection des cartes à puce sécurisées BSI-CC-PP-0084-2014 ou évalué par un laboratoire de test accrédité au niveau national intégrant une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
  • [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire de test accrédité au niveau national, qui intègre une évaluation de la vulnérabilité à haut potentiel d'attaque conformément aux critères communs d'application du potentiel d'attaque aux cartes à puce.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, d'un niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement obligatoire dans une prochaine version.

• [C-SR] sont FORTEMENT RECOMMANDÉS pour assurer la résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature du micrologiciel ne peut pas produire de micrologiciel qui entraîne une fuite de secrets par la StrongBox, pour contourner les exigences de sécurité fonctionnelles ou pour permettre l'accès à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à n'autoriser les mises à jour du micrologiciel que lorsque le mot de passe utilisateur principal est fourni via le HAL IAuthSecret.

9.11.3. Informations d'identité

Le système d'identifiants d'identité est défini et mis en œuvre en implémentant toutes les API du package android.security.identity.*. Ces API permettent aux développeurs d'applications de stocker et de récupérer des documents d'identité des utilisateurs. Implémentations de l'appareil:

• [C-SR] Il est vivement recommandé d'implémenter le système d'identifiants.

Si les implémentations d'appareils implémentent le système d'identifiants, elles:

• [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'identifiants d'identité (par exemple, les API android.security.identity.*) avec du code qui communique 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 le DMA.

• [C-0-3] Les opérations cryptographiques nécessaires à l'implémentation du système d'identifiants (par exemple, les API android.security.identity.*) DOIVENT être entièrement effectuées dans l'application approuvée, et le matériel de clé privée ne DOIT jamais quitter l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par des API de niveau supérieur (par exemple, la méthode createEphemeralKeyPair()).

• [C-0-4] L'application approuvée DOIT être implémentée de manière à ce que ses propriétés de sécurité ne soient pas affectées (par exemple, les données d'identifiants ne sont pas publiées que si les conditions de contrôle des accès sont remplies, les adresses MAC ne peuvent pas être générées pour des données arbitraires), même si Android ne fonctionne pas correctement ou est compromis.

9.12. Suppression des données

Toutes les implémentations d'appareils:

• [C-0-1] DOIT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine.
• [C-0-2] DOIT supprimer toutes les données du système de fichiers userdata.
• [C-0-3] DOIT supprimer les données de manière à respecter les normes du secteur applicables, telles que la norme NIST SP800-88.
• [C-0-4] DOIT déclencher le processus "Réinitialisation des données d'usine" ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
• PEUT fournir une option de suppression rapide des données qui ne s'effectue qu'au niveau logique.

9.13. Mode démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer en mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode Démarrage sécurisé", permet à l'utilisateur de désinstaller des applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

• [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

• [C-1-1] DOIT fournir à l'utilisateur la possibilité de passer en mode Démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf lorsque l'application tierce est un contrôleur de stratégie d'appareil et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

• [C-1-2] L'appareil DOIT permettre à l'utilisateur de désinstaller toutes les applications tierces en mode sans échec.

• DOIT fournir à l'utilisateur la possibilité d'accéder au mode de démarrage sécurisé à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation du système de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec les sous-systèmes critiques du véhicule à l'aide du HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule, tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android pour éviter toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits" désignent les détails du forfait de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils:

• [C-0-1] DOIT renvoyer les forfaits d'abonnement uniquement à l'application du fournisseur de services mobiles qui les a fournis à l'origine.
• [C-0-2] Vous NE DEVEZ PAS sauvegarder ni importer à distance des abonnements.
• [C-0-3] DOIT n'autoriser que les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), provenant de l'application du fournisseur de services mobiles qui propose actuellement des forfaits d'abonnement valides.

9.16. Migration des données d'application

Si les implémentations d'appareils incluent une fonctionnalité permettant de migrer des données d'un appareil vers un autre et ne limitent pas les données d'application qu'elles copient à ce qui est configuré par le développeur de l'application dans le fichier manifeste via l'attribut android:fullBackupContent, elles:

• [C-1-1] NE DOIT PAS lancer de transferts de données d'application à partir d'appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale, comme décrit dans la section 9.11.1 Écran de verrouillage sécurisé et authentification.
• [C-1-2] DOIT confirmer de manière sécurisée l'authentification principale sur l'appareil source et confirmer auprès de l'utilisateur son intention de copier les données sur l'appareil source avant tout transfert de données.
• [C-1-3] Vous DEVEZ utiliser l'attestation de clé de sécurité pour vous assurer que l'appareil source et l'appareil cible de la migration d'un appareil à un autre sont des appareils Android légitimes et qu'ils disposent d'un bootloader verrouillé.
• [C-1-4] Vous devez uniquement migrer les données d'application vers la même application sur l'appareil cible, avec le même nom de package ET le même certificat de signature.
• [C-1-5] Le menu des paramètres doit indiquer que les données de l'appareil source ont été migrées par une migration de données d'appareil à appareil. Un utilisateur NE DOIT PAS pouvoir supprimer cette indication.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils de procéder au minimum de modifications possibles à l'implémentation de référence et privilégiée d'Android disponible sur le Projet Android Open Source. Vous réduirez ainsi le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations de l'appareil:

• [C-0-1] DOIT réussir les tests de la suite de tests de compatibilité Android (CTS) disponible sur le projet Android Open Source, à l'aide du logiciel final installé sur l'appareil.

• [C-0-2] DOIT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. La version du CTS sera indépendante de cette définition de la compatibilité, et plusieurs révisions du CTS peuvent être publiées pour Android 11.

Implémentations de l'appareil:

• [C-0-3] DOIT réussir les tests de la dernière version du CTS disponible au moment de la finalisation du logiciel de l'appareil.

• DOIT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android.

10.2. Validateur CTS

Le vérificateur CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

Implémentations de l'appareil:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans le vérificateur CTS.

Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations de l'appareil:

• [C-0-2] DOIT réussir tous les tests du matériel dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans le vérificateur CTS.

Les cas de test des fonctionnalités indiquées comme facultatives dans ce document de définition de la compatibilité PEUVENT être ignorés ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les implémentateurs d'appareils ne sont pas tenus d'exécuter explicitement le vérificateur CTS sur des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le vérificateur CTS que par l'ensemble de paramètres régionaux inclus, de la marque, etc. PEUVENT omettre le test du vérificateur CTS.

11. Logiciels pouvant être mis à jour

• [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau en temps réel. Autrement dit, 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 OTA (Over The Air) avec mise à jour hors connexion via un redémarrage.
  • Mises à jour "partagée" via USB à partir d'un PC hôte.
  • Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un stockage amovible.

• [C-0-2] Le mécanisme de mise à jour utilisé DOIT permettre les mises à jour sans effacer les données utilisateur. Autrement dit, le mécanisme de mise à jour DOIT préserver les données privées et partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.

• [C-0-3] La mise à jour entière DOIT être signée, et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature à l'aide d'une clé publique stockée sur l'appareil.

• [C-SR] Le mécanisme de signature est FORTEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide d'ECDSA NIST P-256.

Si les implémentations de l'appareil prennent en charge une connexion de données illimitée, telle que le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network), elles:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Pour les implémentations d'appareils lancées avec Android 6.0 ou version ultérieure, le mécanisme de mise à jour DOIT permettre de vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur les blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT prendre en charge les mises à jour système A/B. L'AOSP implémente cette fonctionnalité à l'aide du HAL de contrôle du démarrage.

Si une erreur est détectée dans l'implémentation d'un appareil après sa commercialisation, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces:

• [C-2-1] L'implémentateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme décrit précédemment.

Android inclut des fonctionnalités qui permettent à l'application propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, les appareils:

• [C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de la compatibilité dans cette version:

• Documenter le journal des modifications

Pour obtenir un résumé des modifications apportées aux sections sur les personnes:

1. Introduction
2. Types d'appareils
3. Logiciels
4. Emballage d'application
5. Multimédia
6. Outils et options pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Tests de compatibilité logicielle
11. Logiciels pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils pour afficher le journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications substantielles apportées aux exigences de compatibilité.

• Documentation
  Modifications esthétiques ou liées à la compilation.

Pour une meilleure visibilité, ajoutez les paramètres d'URL pretty=full et no-merges à vos URL de journal des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android et demander des précisions ou signaler les problèmes que vous pensez ne pas être couverts par le document.