Définition de compatibilité Android 12

1. Introduction

Ce document énumère les conditions à remplir pour que les appareils afin d'être compatible avec Android 12.

Les valeurs "DOIT", "NE DOIT PAS", "OBLIGATOIRE", "DEVRAIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT" et "FACULTATIF" conformément à la norme IETF défini dans le document RFC 2119.

Tel qu'il est utilisé dans ce document, ou « équipe de mise en œuvre » est une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 12. Une « implémentation de l'appareil » ou « implémentation » est le solution matérielle/logicielle ainsi développée.

Pour être considéré comme compatible avec Android 12, les implémentations DOIVENT répondre aux exigences présentées dans le présent document Définition, y compris tout document intégré via une référence.

Lorsque cette définition ou les tests logiciels décrits dans section 10 est silencieuse, ambiguë ou incomplètes, il incombe au responsable de la mise en œuvre de l'appareil de s'assurer la compatibilité avec les implémentations existantes.

C'est pourquoi le projet Android Open Source est à la fois la référence et l'implémentation préférée d'Android. Appareil les responsables de la mise en œuvre sont FORTEMENT RECOMMANDÉS de baser leurs implémentations sur le plus possible en "amont" le code source disponible dans Projet Android Open Source. Certains composants peuvent être par d'autres implémentations, il est FORTEMENT RECOMMANDÉ de ne pas respecter cette pratique, car la réussite aux tests logiciels plus difficile. Il incombe à l'équipe chargée de la mise en œuvre de s'assurer la compatibilité comportementale avec l'implémentation Android standard, y compris et au-delà de la suite de tests de compatibilité. Enfin, notez que certains composants les substitutions et les modifications sont explicitement interdites par ce document.

Un grand nombre des ressources mentionnées dans ce document sont issues directement ou indirectement à partir du SDK Android et sera fonctionnellement identique au dans la documentation de ce SDK. Dans tous les cas où cette compatibilité La définition ou la suite de tests de compatibilité n'est pas d'accord avec le SDK documentation, la documentation du SDK est considérée comme faisant autorité. Tous les problèmes techniques et les détails fournis dans les ressources associées de ce document sont considérés par inclusion comme faisant partie de la présente Définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

Toutes les autres exigences qui s'appliquent universellement à tous les appareils Android. mises en œuvre, sont présentées dans les sections après la section 2. Ces exigences sont désignées sous le terme "Configuration requise". dans ce document.

1.1.2. Identifiant du prérequis

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

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

Chaque ID est défini comme suit:

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

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

Les identifiants des exigences de la section 2 se divisent en deux parties. Le premier correspond à un ID de section tel que décrit ci-dessus. La deuxième partie identifie et les exigences spécifiques au facteur de forme.

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

• Dans la section 2, l'ID comprend les éléments suivants : ID de section / ID du type d'appareil – ID de la condition – ID de la condition requise (par exemple, 7.4.3/A-0-1).

2. Types d'appareils

Le projet Android Open Source fournit une pile logicielle pouvant être utilisée pour divers types d'appareils et facteurs de forme. Pour assurer la sécurité des appareils, la pile logicielle, y compris tout OS de remplacement ou un noyau alternatif doit s'exécuter dans un environnement sécurisé, comme décrit dans la section 9 et ailleurs dans le présent CDD. Il existe plusieurs types d'appareils qui disposent d'un écosystème de distribution d'applications relativement bien établi.

Cette section décrit ces types d'appareils, ainsi que les exigences supplémentaires recommandations applicables à chaque type d'appareil.

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des éléments décrits types d'appareils DOIT respecter toutes les exigences décrites dans les autres sections de ce Définition de compatibilité.

2.1 Configurations des appareils

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

2.2. Configuration requise pour les appareils portables

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

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

• Disposer d'une source d'alimentation qui permet la mobilité, telle qu'une batterie.
• La diagonale de l'écran doit être de 3,3 pouces pouces pour les implémentations d'appareils livrées à partir du niveau d'API 29.) à 8 pouces.

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations d'appareils portables

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

2.2.1. Matériel

Implémentations pour les appareils portables:

• [7.1.1.1/H-0-1] DOIT contenir au moins un les écrans compatibles Android qui répondent à toutes les exigences décrites dans ce document document.

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

• [7.1.1.1/H-0-2] DOIT être compatible avec la composition GPU des éléments suivants : la taille de la mémoire tampon du graphique doit être au moins égale à la résolution la plus élevée l'écran.

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

• [7.1.1.1/H-1-1]* DOIT rendre l'écran logique mis à disposition pour des applications tierces doit être d'au moins 2 pouces sur le bord(s) court(s) et 2,7 pouces sur le(s) bord(s) long(s). Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

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

• [7.1.1.1/H-2-1]* DOIT rendre l'écran logique mis à disposition pour des applications tierces doivent être d’au moins 2,7 pouces sur bord(s) court(s). Les appareils expédiés avec le niveau d'API Android 29 ou version antérieure PEUVENT être exemptés de cette exigence.

Si des implémentations d'appareils portables sont compatibles avec la technologie High Dynamic Range s'affiche via Configuration.isScreenHdr() , ils:

• [7.1.4.5/H-1-1] DOIT indiquer que le champ 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 extensions.

Implémentations pour les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables incluent une caméra logique qui liste des fonctionnalités à l'aide CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, ils:

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

Implémentations pour les appareils portables:

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

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

• [7.6.1/H-1-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 416 Mo si l'affichage par défaut utilise un framebuffer jusqu'en qHD (FWVGA, par exemple).

• [7.6.1/H-2-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 592 Mo si l'affichage par défaut utilise la mémoire tampon du frame jusqu'à HD+ (HD, WSVGA, etc.).

• [7.6.1/H-3-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'affichage par défaut utilise un framebuffer jusqu'à FHD (WSXGA+, par exemple).

• [7.6.1/H-4-1] 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 jusqu'en QHD (QWXGA, par exemple).

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

• [7.6.1/H-5-1] Mémoire disponible pour le noyau et l'espace utilisateur DOIT avoir une taille d'au moins 816 Mo si l'écran par défaut utilise une résolution supérieure de framebuffer en qHD (par exemple, FWVGA).

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

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

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

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

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

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

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

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

Si les configurations d'appareils portables incluent une capacité supérieure ou égale à 2 Go et moins de 4 Go de mémoire disponible pour le noyau et l’espace utilisateur, ils:

• [7.6.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge uniquement un espace utilisateur 32 bits (applications et code système)

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

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

Implémentations pour les appareils portables:

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

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

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

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

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

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables sont capables d'atteindre toutes les performances pour prendre en charge le mode RV et que ce mode soit compatible, ils:

• [7.9.1/H-1-1] DOIT déclarer Indicateur de fonctionnalité android.hardware.vr.high_performance.
• [7.9.1/H-1-2] DOIT inclure une application Implémentation de android.service.vr.VrListenerService pouvant être activée par RV applications via android.app.Activity#setVrModeEnabled.

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

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

Fonction	Mappages	Contexte	Comportement
A	Page d'utilisation de HID: 0x0C Utilisation de HID: 0x0CD Clé de kernel: KEY_PLAYPAUSE Clé Android: KEYCODE_MEDIA_PLAY_PAUSE	Lecture des contenus multimédias	Entrée: appui court Résultat : "Lire" ou "Mettre en pause"
			Entrée: appui de manière prolongée Résultat: Lancer la commande vocale Envois: android.speech.action.VOICE_SEARCH_HANDS_FREE si l'appareil est verrouillé ou que son écran est éteint. Envois android.speech.RecognizerIntent.ACTION_WEB_SEARCH dans les autres cas
		Appel entrant	Entrée: appui court Résultat: accepter l'appel
			Entrée: appui de manière prolongée Résultat: refuser l'appel
		Appel en cours	Entrée: appui court Sortie: mettre fin à l'appel
			Entrée: appui de manière prolongée Sortie: couper ou réactiver le micro
B	Page d'utilisation de HID: 0x0C Utilisation de HID: 0x0E9 Clé de kernel: 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 des écouteurs
C	Page d'utilisation de HID: 0x0C Utilisation de HID: 0x0EA Clé de kernel: KEY_VOLUMEDOWN Clé Android: VOLUME_DOWN	Lecture de contenus multimédias, appel en cours	Entrée: appui court ou long Sortie: réduit le volume du système ou des écouteurs
D	Page d'utilisation de HID: 0x0C Utilisation de HID: 0x0CF Clé de kernel: KEY_VOICECOMMAND Clé Android: KEYCODE_VOICE_ASSIST	Tous. Peut être déclenché dans n'importe quelle instance.	Entrée: appui court ou long Résultat: lance la commande vocale

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.6(#56_audio-Latency)/H-1-1] DOIT avoir un aller-retour moyen continu de latence inférieure ou égale à 800 millisecondes sur cinq mesures, avec une Écart absolu inférieur à 100 ms sur au moins un chemin pris en charge.

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

• [7,10/H]* NE DOIT PAS utiliser de masse rotative excentrique (ERM) actionneur haptique (vibreur).
• [7,10/H]* DEVRAIT positionner l'actionneur près de l'endroit où l'appareil est généralement tenu ou touché avec vos mains.
• [7.10/H]* DEVRAIT implémenter toutes les constantes publiques pour effacer le retour haptique 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]* DEVRAIT implémenter toutes les constantes publiques pour effacer le retour haptique dans android.os.VibrationEffect à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK) et toutes les constantes publiques pour un retour haptique enrichi dans android.os.VibrationEffect.Composition à savoir (PRIMITIVE_CLICK et PRIMITIVE_TICK).
• [7.10/H]* DEVRAIT utiliser ces constantes haptiques associées mappages
• [7,10/H]* DEVRAIT suivre évaluation de la qualité pour createOneShot() et createWaveform() API.
• [7.10/H]* DEVRAIT vérifier les capacités d'amplitude et d'évolutivité en exécutant android.os.Vibrator.hasAmplitudeControl()

Un actionneur à résonateur linéaire (LRA) est un système à ressorts à masse unique dont le fréquence de résonance dominante où la masse se traduit le mouvement souhaité.

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

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

Si les mises en œuvre d'appareils portables disposent d'un actionneur haptique sur l'axe X actionneur à résonateur linéaire (LRA, linear Resonant actionator),

• [7,10/H]* DEVRAIT avoir la fréquence de résonance de l'axe X LRA doit être inférieure à 200 Hz.

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

• [7.10/H]* DEVRAIT vérifier l'état de l'implémentation en exécutant android.os.Vibrator.areAllEffectsSupported() et android.os.Vibrator.arePrimitvesSupported() API.
• [7,10/H]* DEVRAIT effectuer une évaluation de la qualité pour les constantes haptiques.
• [7.10/H]* DEVRAIT fournir une assistance de remplacement pour atténuer le risque d'échec, comme décrit ici.

2.2.2. Multimédia

Les implémentations d'appareils portables DOIVENT prendre en charge les types d'encodage audio suivants : les formats de décodage et les rendre disponibles pour des applications tierces:

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

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

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

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

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

2.2.3. Logiciel

Implémentations pour les appareils portables:

• [3.2.3.1/H-0-1] DOIT comporter un application qui gère ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, et ACTION_CREATE_DOCUMENT tels que décrits dans les documents du SDK, et fournissent à l'utilisateur les affordances pour accéder aux données du fournisseur de documents via l'API DocumentsProvider.
• [3.2.3.1/H-0-2]* DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, tous les formats de filtres d'intent public définis par l'application suivante : les intents répertoriés sur cette page.
• [3.2.3.1/H-SR-1] Sont VIVEMENT RECOMMANDÉ de précharger une application de messagerie capable de gérer ACTION_SENDTO. ou ACTION_SEND ou ACTION_SEND_MULTIPLE des intents à l'envoi d'un e-mail.
• [3.4.1/H-0-1] DOIT fournir une réponse complète l'implémentation de l'API android.webkit.Webview.
• [3.4.2/H-0-1] DOIT inclure un navigateur autonome. pour naviguer sur le Web.
• [3.8.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un lanceur d'applications par défaut qui prend en charge l'épinglage des raccourcis dans l'application, widgets et widgetFeatures.
• [3.8.1/H-SR-2] SONT FORTEMENT RECOMMANDÉS pour implémenter un lanceur d'applications par défaut qui permet d'accéder rapidement raccourcis fournis par les applications tierces via ShortcutManager API.
• [3.8.1/H-SR-3] SONT FORTEMENT RECOMMANDÉS pour inclure un lanceur d'applications par défaut qui affiche les badges pour les icônes de l'application.
• [3.8.2/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge les widgets d'application tiers.
• [3.8.3/H-0-1] DOIT autoriser les applications tierces applications pour informer les utilisateurs d'événements importants via les Notification et NotificationManager les classes d'API.
• [3.8.3/H-0-2] DOIT prendre en charge des contenus enrichis les notifications.
• [3.8.3/H-0-3] DOIT prendre en charge les messages prioritaires les notifications.
• [3.8.3/H-0-4] DOIT inclure un volet des notifications, ce qui permet à l'utilisateur de contrôler directement répondre, mettre en attente, ignorer, bloquer) les notifications par le biais des affordances de l'utilisateur telles que boutons d'action ou le panneau de configuration comme implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications.
• [3.8.3/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour afficher le premier choix fourni via RemoteInput.Builder setChoices() dans le volet des notifications sans action supplémentaire de l'utilisateur.
• [3.8.3/H-SR-2] SONT FORTEMENT RECOMMANDÉS pour afficher tous les choix fournis via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans le volet des notifications.
• [3.8.3.1/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour afficher les actions pour lesquelles Notification.Action.Builder.setContextual est défini sur true dans la ligne des réponses affichées par Notification.Remoteinput.Builder.setChoices
• [3.8.4/H-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un assistant sur l'appareil afin de gérer l'action d'assistance.

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

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

Si les implémentations d'appareils portables sont compatibles avec conversation notifications et les regrouper dans une section distincte, celle des alertes notifications, ils:

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

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

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

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

• [3.9/H-1-1] DOIT implémenter la gamme complète administration des appareils définies dans la documentation du SDK Android.

Si les implémentations d'appareils portables incluent la prise en charge de ControlsProviderService et Control et autorisent les applications tierces à publier des commandes de contrôle des appareils:

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

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

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

Implémentations pour les appareils portables:

• [3.10/H-0-1] DOIT prendre en charge l'accessibilité par un tiers services.
• [3.10/H-SR-1] Sont FORTEMENT RECOMMANDÉS-1 pour le préchargement services d'accessibilité sur l'appareil comparables ou supérieurs aux fonctionnalités de Switch Access et TalkBack (pour les langues compatibles avec la moteur de synthèse vocale) tels qu'ils sont fournis dans l'API Talkback ouverte projet source.
• [3.11/H-0-1] DOIT prendre en charge l'installation des moteurs de synthèse vocale tiers.
• [3.11/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un Moteur de synthèse vocale compatible avec les langues disponibles sur l'appareil.
• [3.13/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un Composant d'interface utilisateur "Réglages rapides".

Si les implémentations d'appareils portables Android déclarent FEATURE_BLUETOOTH ou FEATURE_WIFI, ils:

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

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

• [7.2.3/H] Zone de reconnaissance de gestes pour la maison NE DOIT PAS être supérieure à 32 dp de hauteur à partir du bas l'écran.

Si les implémentations d'appareils portables fournissent une fonction de navigation sous forme de geste depuis les bords gauche et droit de l'écran:

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

Si les implémentations d'appareils portables sont compatibles avec un écran de verrouillage sécurisé et ont une supérieure ou égale à 2 Go de mémoire disponible pour le noyau et l'espace utilisateur, elles:

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

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

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

Performances et puissance

• [8.1/H-0-1] Latence cohérente des frames. Une latence de trame incohérente ou un délai d'affichage des images NE DOIT PAS se produire davantage souvent plus de 5 images par seconde, et DOIT être inférieure à 1 images par seconde.
• [8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler un Liste de 10 000 entrées de liste, telles que définies par la suite de tests de compatibilité Android (CTS) en moins de 36 secondes.
• [8.1/H-0-3] Changement de tâches Quand ? plusieurs applications ont été lancées, relançant ainsi une application déjà exécutée application après son lancement DOIT prendre moins d'une seconde.

Implémentations pour les appareils portables:

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

Si les implémentations d'appareils portables incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

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

Implémentations pour les appareils portables:

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

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

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

Modèle de sécurité

Implémentations pour les appareils portables:

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

Implémentations pour les appareils portables:

• [9.11/H-0-2] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/H-0-3] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
• [9.11/H-0-4] DOIT activer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/H-0-5] DOIT prendre en charge l'attestation des clés lorsque le d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.
• [9/H-0-1] DOIT déclarer la classe android.hardware.security.model.compatible .

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

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

• [9.11/H-1-1] DOIT permettre à l'utilisateur de choisir la version la plus courte délai de mise en veille, c'est-à-dire la durée de transition entre en 15 secondes ou moins.
• [9.11/H-1-2] DOIT fournir une affordance à l'utilisateur pour masquer les notifications et désactiver toutes les formes d'authentification, à l'exception l'authentification principale décrite dans 9.11.1 Écran de verrouillage sécurisé. L'AOSP répond aux comme mode de verrouillage.

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

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

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

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

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

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

• [9.8/H-1-1] DOIT s'assurer que le service de détection de mots clés ne transmet vers le service System ou ContentCaptureService
• [9.8/H-1-2] DOIT s'assurer que le service de détection de mots clés ne peut transmettre les données audio du micro ou les données dérivées de celui-ci au serveur système via l'API HotwordDetectionService, ou à ContentCaptureService via ContentCaptureManager.
• [9.8/H-1-3] NE DOIT PAS fournir d'audio du micro de plus de 30 secondes pendant une une requête individuelle déclenchée par le matériel au service de détection de mots clés.
• [9.8/H-1-4] NE DOIT PAS fournir de micro mis en mémoire tampon de plus de 8 secondes pour une une requête individuelle au service de détection de mots clés.
• [9.8/H-1-5] NE DOIT PAS fournir à l'appareil un micro mis en mémoire tampon de plus de 30 secondes un service d'interaction vocale ou une entité similaire.
• [9.8/H-1-6] NE DOIT PAS autoriser la transmission de plus de 100 octets de données du service de détection de mot clé pour chaque résultat réussi de mot clé.
• [9.8/H-1-7] NE DOIT PAS permettre la transmission de plus de cinq bits de données. du service de détection de mot clé sur chaque résultat négatif de mot clé.
• [9.8/H-1-8] NE DOIT autoriser la transmission de données qu'à partir du mot clé service de détection sur une requête de validation de mot clé du serveur système.
• [9.8/H-1-9] NE DOIT PAS permettre à une application installable par l'utilisateur de fournir de détection de mots clés.
• [9.8/H-1-10] NE DOIT PAS faire apparaître des données quantitatives sur l'utilisation du micro dans l'interface utilisateur le service de détection de mots clés.
• [9.8/H-1-11] DOIT consigner le nombre d'octets inclus dans chaque transmission du service de détection de mots clés pour permettre l'inspection à des fins de sécurité chercheurs.
• [9.8/H-1-12] DOIT prendre en charge un mode de débogage qui enregistre le contenu brut de chaque du service de détection de mots clés pour permettre l'inspection chercheurs en sécurité.
• [9.8/H-1-13] DOIT redémarrer le processus hébergeant le service de détection de mots clés au moins une fois toutes les heures ou tous les 30 événements de type déclencheur matériel, selon est la priorité.
• [9.8/H-1-14] DOIT afficher l'indicateur du micro, comme décrit dans la section 9.8.2, lorsqu'un résultat de mot clé réussi est transmis à la voix ou d'une entité similaire.
• [9.8/H-SR-1] Il est FORTEMENT RECOMMANDÉ d'avertir les utilisateurs avant de définir en tant que fournisseur du service de détection de mots clés.
• [9.8/H-SR-2] SONT FORTEMENT RECOMMANDÉS d'interdire la transmission le service de détection de mots clés.

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

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

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

• [9.8.2/H-4-1] DOIT afficher l'indicateur du micro lorsque une application accède aux données audio du micro, mais pas lorsque le le micro n'est accessible que par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService ou des applications détenant les rôles décrits dans section 9.1 avec l'identifiant CDD [C-4-X]. .
• [9.8.2/H-4-2] DOIT afficher la liste des listes "Récentes" et "Actifs" les applications utilisant le micro comme renvoyées par PermissionManager.getIndicatorAppOpUsageData(), ainsi que toute attribution messages qui leur sont associés.
• [9.8.2/H-4-3] NE DOIT pas masquer l'indicateur de micro les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.
• [9.8.2/H-4-4] DOIT afficher la liste des listes "Récentes" et "Actifs" les applications utilisant le micro comme renvoyé par PermissionManager.getIndicatorAppOpUsageData() ; ainsi que tous les messages d'attribution qui leur sont associés.

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

• [9.8.2/H-5-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'un accède aux données en direct de la caméra, mais pas lorsqu'elle est uniquement auxquelles les applications détenant les rôles indiqués dans section 9.1 avec l'identifiant CDD [C-4-X].
• [9.8.2/H-5-2] DOIT afficher les applications récentes et actives utilisant appareil photo renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.
• [9.8.2/H-5-3] NE DOIT pas masquer l'indicateur de l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* DOIT exposer un /system/bin/perfetto binaire à l'utilisateur shell auquel la cmdline est conforme la documentation perfetto.
  • [6.1/H-0-3]* Le binaire Perfetto DOIT accepter comme saisissez une configuration protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/H-0-4]* Le binaire Perfetto DOIT écrire sous la forme générer une trace protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/H-0-5]* DOIT fournir, via le perfetto binaire, au moins les sources de données décrites dans la documentation de Perfetto.
  • [6.1/H-0-6]* Le daemon tracé par Perfetto DOIT être activée par défaut (propriété système persist.traced.enable).

2.2.7. Classe de performance des médias portables

Consultez la section 7.11 pour connaître la définition des termes "multimédias". classe de performance.

Contenus multimédias

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

• DOIT respecter les exigences multimédias indiquées dans le CDD Android 11 section 2.2.7.1

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

• [5.1/H-1-1] DOIT indiquer le nombre maximal de décodeurs vidéo matériels qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-2] DOIT prendre en charge six instances de sessions de décodeur vidéo matérielle (AVC, HEVC, VP9* ou version ultérieure) dans toute combinaison de codec exécutée simultanément avec une résolution 720p à 30 FPS. *Seules deux instances sont requises si Le codec VP9 est présent.
• [5.1/H-1-3] DOIT indiquer le nombre maximal d'encodeurs vidéo matériels qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-4] DOIT prendre en charge six instances d'encodeur vidéo matériel (AVC, HEVC, VP9* ou versions ultérieures) dans n'importe quelle combinaison de codecs exécutée simultanément avec une résolution de 720p à 30 images par seconde. *Seules deux instances sont requises si le codec VP9 est présent.
• [5.1/H-1-5] DOIT indiquer le nombre maximal d'encodeurs vidéo matériels de décodeur qui peuvent être exécutées simultanément dans n'importe quelle combinaison de codecs via l'/le/la CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
• [5.1/H-1-6] DOIT prendre en charge six instances de décodeur vidéo matériel et de matériel Sessions d'encodeur vidéo (AVC, HEVC, VP9* ou version ultérieure) dans n'importe quel codec s'exécutant simultanément à une résolution de 720p à 30 images par seconde. *Seules deux instances sont requises en présence du codec VP9.
• [5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 50 ms ou moins pour une Session d'encodage vidéo 1080p ou moins pour tous les encodeurs vidéo matériels (autre que le codec Dolby Vision) en cas de charge élevée. "Charger ici" est défini comme Session de transcodage vidéo 1080p à 720p simultanée avec du matériel vidéo avec l'initialisation de l'enregistrement audio-vidéo 1080p.
• [5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 40 ms ou moins pour une Session d'encodage audio de 128 kbit/s ou débit inférieur pour tous les encodeurs audio lorsque avec une charge élevée. La valeur "Charger ici" désigne les vidéos simultanées de 1080p à 720p uniquement de transcodage à l'aide de codecs vidéo matériels et de la résolution 1080p l'initialisation de l'enregistrement audio-vidéo.
• [5.3/H-1-1] NE DOIT PAS supprimer plus de deux images en 10 secondes (c'est-à-dire une chute d'image inférieure à 0,333 %) pour une session vidéo 1080p à 60 FPS avec une charge élevée. La charge désigne les vidéos simultanées de 1080p à 720p uniquement de transcodage à l'aide de codecs vidéo matériels Lecture audio AAC 128 kbit/s.
• [5.3/H-1-2] NE DOIT PAS perdre plus de 2 images en 10 secondes pendant la lecture d'une vidéo changement de résolution lors d'une session vidéo de 60 ips sous charge. La charge est définie comme Session de transcodage vidéo 1080p à 720p simultanée à l'aide de matériel les codecs vidéo et la lecture audio AAC à 128 kbit/s.
• [5.6/H-1-1] DOIT avoir une latence tapo-to-ton inférieure à 100 millisecondes à l'aide des tests Tap-to-tone d'OboeTester ou de CTS Verifier.

Appareil photo

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

• DOIT respecter les exigences concernant l'appareil photo indiquées dans le CDD Android 11 section 2.2.7.2

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

• [7.5/H-1-1] DOIT disposer d'une caméra arrière principale d'une résolution de avec une résolution d'au moins 12 mégapixels compatible avec la capture vidéo à 4K à 30 images par seconde. L'instance principale la caméra arrière est la caméra arrière dont l'identifiant de caméra est le plus bas.
• [7.5/H-1-2] DOIT disposer d'une caméra frontale principale d'une résolution de d'au moins 5 mégapixels et prend en charge la capture vidéo à 1080p à 30 images par seconde. L'instance principale la caméra frontale est la caméra frontale qui possède l'ID d'appareil photo le plus bas.
• [7.5/H-1-3] DOIT prendre en charge la propriété android.info.supportedHardwareLevel comme FULL ou plus pour l'instance principale principale et LIMITED ou supérieure pour l'instance principale principale caméra.
• [7.5/H-1-4] DOIT prendre en charge CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME pour les deux primaires caméras.
• [7.5/H-1-5] DOIT avoir une latence de capture JPEG de camera2 < 1 000 ms pour Résolution de 1080p mesurée par le test PerformanceTest de la caméra CTS dans le cadre du programme ITS les conditions d'éclairage (3 000 K) des deux caméras principales.
• [7.5/H-1-6] DOIT avoir une latence de démarrage de l'appareil photo 2 (ouvrez l'appareil photo pour afficher le premier aperçu) cadre) < 600 ms, mesurés par le test PerformanceTest de la caméra CTS dans le cadre du service ITS les conditions d'éclairage (3 000 K) des deux caméras principales.
• [7.5/H-1-8] DOIT prendre en charge CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW et android.graphics.ImageFormat.RAW_SENSOR pour la caméra arrière principale.

Matériel

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

• DOIT respecter la configuration matérielle requise indiquée dans le CDD Android 11 section 2.2.7.3

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

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

Performances

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

• DOIT respecter les exigences de performances indiquées dans le CDD Android 11 section 2.2.7.4

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

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

2.3. Configuration requise pour la télévision

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

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

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

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations de téléviseurs

Matériel

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

Si les implémentations de téléviseurs comprennent un port USB prenant en charge le mode hôte, ils:

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

Pour les téléviseurs 32 bits:

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

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

Pour les téléviseurs 64 bits:

• [7.6.1/T-2-1] 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és:

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

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

Implémentations pour les téléviseurs:

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

2.3.2. Multimédia

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

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

Les intégrations de téléviseurs DOIVENT prendre en charge l'encodage vidéo suivant et les mettre à la disposition d'applications tierces:

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

Implémentations pour les téléviseurs:

• [5.2.2/T-SR-1] SONT FORTEMENT RECOMMANDÉS de fournir une assistance Encodage H.264 de vidéos 720p et 1080p avec une fréquence de 30 images par seconde.

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

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

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

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

Les implémentations de téléviseurs DOIVENT prendre en charge le décodage H.264, comme détaillé dans Section 5.3.4, aux fréquences d'images et résolutions vidéo standards jusqu'à y compris:

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

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

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

Si les implémentations de téléviseurs dotées de décodeurs matériels H.265 sont compatibles Le décodage H.265 et le profil de décodage UHD, ils:

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

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

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

Les téléviseurs équipés de décodeurs matériels VP9 DOIVENT être compatibles avec ce format le décodage, comme détaillé dans la section 5.3.7, aux fréquences d'images vidéo et de résolution pouvant aller jusqu'à:

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

Si les téléviseurs équipés de décodeurs matériels VP9 sont compatibles avec le codec VP9 et le profil de décodage UHD, ils:

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

Implémentations pour les téléviseurs:

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

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

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

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

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

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

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

Logiciel

Implémentations pour les téléviseurs:

• [3/T-0-1] DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television.
• [3.2.3.1/T-0-1] DOIT précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.
• [3.4.1/T-0-1] DOIT fournir un formulaire l'implémentation de l'API android.webkit.Webview.

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

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

Implémentations pour les téléviseurs:

• [3.8.14/T-SR-1] SONT FORTEMENT RECOMMANDÉS pour prendre en charge le mode multifenêtre Picture-in-picture (PIP).
• [3.10/T-0-1] DOIT prendre en charge l'accessibilité par un tiers services.
• [3.10/T-SR-1] SONT FORTEMENT RECOMMANDÉS les services d'accessibilité sur l'appareil qui sont comparables ou supérieurs les fonctionnalités de Switch Access et TalkBack (pour les langues compatibles avec le moteur de synthèse vocale préinstallé) tels qu'ils sont fournis dans le projet Open Source TalkBack.

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

• [3.11/T-SR-1] 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 des moteurs de synthèse vocale tiers.

Implémentations pour les téléviseurs:

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

Performances et puissance

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

Si les implémentations de téléviseurs incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

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

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

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

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

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

Implémentations pour les téléviseurs:

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

Modèle de sécurité

Implémentations pour les téléviseurs:

• [9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/T-0-2] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
• [9.11/T-0-3] DOIT effectuer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/T-0-4] DOIT prendre en charge l'attestation des clés lorsque le d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.
• [9/T-0-1] DOIT déclarer la classe android.hardware.security.model.compatible .

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

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

• [9.11/T-1-1] DOIT permettre à l'utilisateur de choisir le mode Sommeil délai avant expiration de la transition de l'état déverrouillé à l'état verrouillé, avec une délai d'expiration minimal autorisé jusqu'à 15 secondes ou moins.

Si les implémentations de télévision comprennent plusieurs utilisateurs et ne déclarent pas le flag de fonctionnalité android.hardware.telephony:

• [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 de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

Si les implémentations de télévision comprennent plusieurs utilisateurs et déclarer l'indicateur de fonctionnalité android.hardware.telephony:

• [9.5/T-3-1] NE DOIT PAS prendre en charge profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

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

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

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

• [9.8.2/T-5-1] DOIT afficher l'indicateur de l'appareil photo lorsqu'un accède aux données en direct de la caméra, mais pas lorsque celle-ci auxquelles accèdent les applications détenant les rôles décrits à la section 9.1. Autorisations avec identifiant CDD [C-3-X].
• [9.8.2/T-5-2] NE DOIT pas masquer l'indicateur de l'appareil photo pour les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

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

Implémentations pour les téléviseurs:

• Perfetto
  • [6.1/T-0-1] DOIT exposer un /system/bin/perfetto binaire à l'utilisateur shell auquel la cmdline est conforme la documentation perfetto.
  • [6.1/T-0-2] Le binaire Perfetto DOIT accepter comme saisissez une configuration protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/T-0-3] Le binaire Perfetto DOIT écrire en tant que générer une trace protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/T-0-4] DOIT fournir ces informations via le Perfetto binaire, au moins les sources de données décrites dans la documentation de Perfetto.

2.4. Configuration requise pour la montre

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

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

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

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations sur les montres

Matériel

Implémentations sur les montres:

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

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

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

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

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

• [7.3.3/W-1-1] DOIT indiquer les mesures GNSS dès qu'elles même si la position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [7.3.3/W-1-2] DOIT signaler les pseudo-plages et pseudo-plages GNSS en ciel ouvert, après avoir déterminé l'emplacement, immobile ou se déplaçant à moins de 0,2 mètre par seconde au carré de accélération, sont suffisantes pour calculer la position à 20 mètres près et la vitesse à une distance de 0,2 mètre par seconde, au moins 95% du temps.

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

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

Implémentations sur les montres:

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

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

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

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

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

Multimédia

Aucune exigence supplémentaire.

Logiciel

Implémentations sur les montres:

• [3/W-0-1] DOIT déclarer la fonctionnalité android.hardware.type.watch
• [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH :
• [3.2.3.1/W-0-1] DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, tous les formats de filtres d'intent public définis par l'application suivante : les intents répertoriés sur cette page.

Implémentations sur les montres:

• [3.8.4/W-SR-1] SONT FORTEMENT RECOMMANDÉS pour implémenter un assistant sur l'appareil afin de gérer l'action d'assistance.

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

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

Si les implémentations de la montre indiquent la fonctionnalité android.hardware.audio.output, ils:

• [3.11/W-SR-1] 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 des moteurs de synthèse vocale tiers.

Performances et puissance

Si les implémentations de la montre incluent des fonctionnalités visant à améliorer la puissance de l'appareil de gestion intégrée à l'AOSP ou étendent les fonctionnalités incluses dans AOSP:

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

Implémentations sur les montres:

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

Modèle de sécurité

Implémentations sur les montres:

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

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

• [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 de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

Si les implémentations des montres incluent plusieurs utilisateurs et déclarer l'indicateur de fonctionnalité android.hardware.telephony:

• [9.5/W-2-1] NE DOIT PAS être compatible avec profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

2.5. Exigences concernant l'automobile

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

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

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

Les exigences supplémentaires figurant dans le reste de cette section sont spécifiques à Android. Implémentations d'appareils automobiles

Matériel

Implémentations pour les appareils automobiles:

• [7.1.1.1/A-0-1] DOIT disposer d'un écran d'au moins 6 de centimètres en diagonale physique.

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

• [7.2.3/A-0-1] DOIT fournir la fonction Home et MAY fournissent les fonctions Retour et Récent.

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

• [7.3/A-0-1] DOIT implémenter et signaler GEAR_SELECTION NIGHT_MODE, PERF_VEHICLE_SPEED et PARKING_BRAKE_ON.

• [7.3/A-0-2] La valeur du paramètre NIGHT_MODE l'indicateur DOIT être cohérent avec le mode Jour/Nuit du tableau de bord et DOIT être basé sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même photomètre.

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

• [7.3/A-0-1] PEUT être en mesure de reconnaître un lieu en fusionnant le GPS/GNSS avec d'autres capteurs. Si Emplacement il est FORTEMENT RECOMMANDÉ de mettre en œuvre et de signaler Capteur correspondant types et/ou ID de propriété de véhicule utilisé.

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

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

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

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

• [7.3.1/A-1-1] DOIT pouvoir signaler des événements d'une durée maximale de d'au moins 100 Hz.
• [7.3.1/A-1-2] DOIT se conformer aux système de coordonnées du capteur de voiture.

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

• [7.3.4/A-2-1] DOIT pouvoir signaler des événements d'une durée maximale de d'au moins 100 Hz.
• [7.3.4/A-2-3] DOIT pouvoir mesurer les changements d'orientation jusqu'à 250 degrés par seconde.
• [7.3.4/A-SR-1] EST FORTEMENT RECOMMANDÉ de configurer la plage de mesure du gyroscope à +/-250 dps afin d'optimiser la résolution. possible

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

• [7.3.3/A-3-1] DOIT déterminer la position la toute première fois que le récepteur GPS/GNSS est allumé ou après au moins 4 jours en 60 secondes.
• [7.3.3/A-3-2] DOIT respecter les critères concernant le délai avant la première correction tels que décrites dans 7.3.3/C-1-2 et 7.3.3/C-1-6 pour toutes les autres demandes de localisation (c'est-à-dire les requêtes qui ne sont pas ou après plus de 4 jours). L'exigence 7.3.3/C-1-2 est généralement utilisés dans les véhicules sans connectivité de données basée sur le réseau cellulaire, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant le la dernière position connue d'un véhicule et de pouvoir compter sur au moins 60 secondes, et dont la précision de la position est satisfaisante 7.3.3/C-1-3 ou une combinaison des deux.

Implémentations pour les appareils automobiles:

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

• [7.4.3/A-SR-1] SONT FORTEMENT RECOMMANDÉS Profil d'accès aux messages (MAP).

• [7.4.5/A] DEVRAIT inclure la prise en charge des réseaux la connectivité des données basée sur le réseau.

• [7.4.5/A] PEUT utiliser l'API System Constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID pour qui devraient être disponibles pour les applications système.

Une caméra d'extérieur est une caméra qui capture les scènes à l'extérieur de l'appareil. mise en œuvre, comme une caméra embarquée.

Implémentations pour les appareils automobiles:

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

Si les implémentations d'appareils automobiles incluent une caméra de vue extérieure, par exemple une caméra, ils:

• [7.5/A-1-1] NE DOIT PAS être accessible via les caméras extérieures via les API Android Camera, à moins qu'elles ne soient avec les conditions de base requises pour l'appareil photo.
• [7.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ de ne pas alterner dupliquer horizontalement l'aperçu de l'appareil photo.
• [7.5.5/A-SR-1] Il est FORTEMENT RECOMMANDÉ d'être orienté afin que la dimension longue de l'appareil photo est alignée sur l'horizon.
• [7.5/A-SR-2] Il est FORTEMENT RECOMMANDÉ de trouver une solution. d'au moins 1,3 mégapixel.
• DEVRAIT utiliser du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• DEVRAIT être compatible avec le framework de synchronisation Android.
• PEUVENT intégrer un autofocus matériel ou logiciel dans le pilote de la caméra.

Implémentations pour les appareils automobiles:

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

• [7.6.1/A] DEVRAIT formater la partition de données afin d'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 espace de stockage externe partagé via un de la mémoire de stockage interne non amovible, ils:

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

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

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

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

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

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

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

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

• [7.6.1/A-1-4] 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és:

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

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

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

2.5.2. Multimédia

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

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

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

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

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

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

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

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

Logiciel

Implémentations pour les appareils automobiles:

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

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

• [3/A-0-3] DOIT être compatible avec toutes les API publiques du android.car.* espace de noms.

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

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

Implémentations pour les appareils automobiles:

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

• [3.2.3.1/A-0-1] DOIT précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.

• [3.4.1/A-0-1] DOIT fournir un formulaire l'implémentation de l'API android.webkit.Webview.

• [3.8.3/A-0-1] DOIT afficher des notifications qui utilisent le Notification.CarExtender API lorsque des applications tierces le demandent.

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

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

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

Implémentations pour les appareils automobiles:

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

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

• [3.9.3/A-1-1] DOIT implémenter toutes les Propriétés du cycle de vie des utilisateurs
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

Implémentations pour les appareils automobiles:

• [3.14/A-0-1] DOIT inclure un framework d'interface utilisateur pour prendre en charge applications tierces utilisant les API multimédias, comme décrit dans la section 3.14.
• [3.14/A-0-2] DOIT permettre à l'utilisateur d'interagir de façon sécurisée avec les applications multimédias tout en conduisant.
• [3.14/A-0-3] DOIT être compatible avec la CAR_INTENT_ACTION_MEDIA_TEMPLATE action d'intent implicite avec CAR_EXTRA_MEDIA_PACKAGE supplémentaires.
• [3.14/A-0-4] DOIT fournir une affordance pour accéder à d'une application multimédia préférence l'activité, mais DOIT l'activer uniquement lorsque les Restrictions relatives à l'expérience utilisateur de la voiture ne sont pas en vigueur.
• [3.14/A-0-5] DOIT afficher messages d'erreur défini par les applications multimédias et DOIT prendre en charge les éléments supplémentaires facultatifs. ERROR_RESOLUTION_ACTION_LABEL et ERROR_RESOLUTION_ACTION_INTENT.
• [3.14/A-0-6] DOIT prendre en charge une affordance de recherche dans l'application pour d'applications compatibles avec la recherche.
• [3.14/A-0-7] DOIT respecter CONTENT_STYLE_BROWSABLE_HINT et CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de MediaBrowser la hiérarchie.

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

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

Implémentations pour les appareils automobiles:

• [3.8/A] PEUT restreindre l'application les requêtes de passage en mode plein écran, comme décrit dans immersive documentation.
• [3.8/A] PEUVENT conserver la barre d'état et la barre de navigation visible en permanence.
• [3.8/A] PEUT restreindre l'application les demandes de modification des couleurs derrière les éléments de l'interface utilisateur du système, afin de garantir ces éléments sont clairement visibles à tout moment.

Performances et puissance

Implémentations pour les appareils automobiles:

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

2.5.5. Modèle de sécurité

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

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

Implémentations pour les appareils automobiles:

• [9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore dans un environnement d'exécution isolé.
• [9.11/A-0-2] DOIT comporter des implémentations RSA, AES, Algorithmes cryptographiques ECDSA et HMAC, et famille MD5, SHA1 et SHA-2 fonctions de hachage pour prendre en charge correctement des algorithmes dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques. Android Open Source en amont Le projet (AOSP) répond à cette exigence en utilisant l'implémentation Trusty, mais une autre Solution basée sur ARM TrustZone ou sécurisée par un tiers la mise en œuvre d'une isolation basée sur l'hyperviseur appropriée sont des alternatives options.
• [9.11/A-0-3] DOIT activer le verrouillage de l'écran l'authentification dans l'environnement d'exécution isolé et uniquement lorsque réussi, autorisez l'utilisation des clés liées à l'authentification. Écran de verrouillage les identifiants DOIVENT être stockés de manière à ne permettre que l'exécution isolée d'authentification pour l'authentification sur l'écran de verrouillage. L'application Android en amont Open Source Project offre Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [9.11/A-0-4] DOIT prendre en charge l'attestation des clés lorsque d'attestation est protégée par du matériel sécurisé, et la signature est effectuées sur du matériel sécurisé. Les clés de signature des attestations DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés ; en tant qu'identifiants d'appareil. Pour répondre à cette exigence, vous pouvez la même clé d'attestation,sauf si au moins 100 000 unités d'un SKU donné sont produits. Si plus de 100 000 unités d'un SKU sont produites, une autre PEUT être utilisée pour chaque tranche de 100 000 unités.
• [9/A-0-1] DOIT déclarer la classe android.hardware.security.model.compatible .

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

Implémentations pour les appareils automobiles:

• [9.14/A-0-1] DOIT envoyer des messages de contrôle d'accès provenant de sous-systèmes de véhicule du framework Android (par exemple, ajout de messages autorisés à la liste d'autorisation) et les sources des messages.
• [9.14/A-0-2] DOIT surveiller et surveiller attaques par déni de service à partir du framework Android ou d'applications tierces. Ce des protections contre les logiciels malveillants inondant le réseau du véhicule de trafic, ce qui peut entraîner des dysfonctionnements des sous-systèmes du véhicule.

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

Implémentations pour les appareils automobiles:

• Perfetto
  • [6.1/A-0-1] DOIT exposer un /system/bin/perfetto binaire à l'utilisateur shell auquel la cmdline est conforme la documentation perfetto.
  • [6.1/A-0-2] Le binaire Perfetto DOIT accepter comme saisissez une configuration protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/A-0-3] Le binaire Perfetto DOIT écrire en tant que générer une trace protobuf conforme au schéma défini dans la documentation perfetto.
  • [6.1/A-0-4] DOIT fournir ces informations via le perfetto (au moins les sources de données décrites dans la documentation de Perfetto).

2.6. Configuration requise pour les tablettes

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

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

Les implémentations de tablettes ont des exigences similaires à celles des appareils portables mises en œuvre. Les exceptions sont signalées par un * dans cette section. et données à titre indicatif dans cette section.

Matériel

Gyroscope

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

• [7.3.4/Tab-1-1] DOIT pouvoir mesurer l'orientation peut atteindre 1 000 degrés par seconde.

Mémoire et stockage minimaux (section 7.6.1)

Densités d'écran indiquées pour les écrans de petite taille ou de taille normale sur l'appareil portable ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

Si les tablettes comprennent un port USB compatible avec les périphériques ils:

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

Mode de réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

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

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

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

• [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 de l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent configurer rapidement des environnements distincts dans lesquels d'autres utilisateurs peuvent travailler, avec la possibilité de gérer des restrictions plus précises dans les applications sont disponibles dans ces environnements.

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

• [9.5/T-2-1] NE DOIT PAS prendre en charge profils, mais DOIT s'aligner sur la mise en œuvre des contrôles AOSP pour activer /désactiver l'accès des autres utilisateurs aux appels vocaux et aux SMS.

2.6.2. Logiciel

• [3.2.3.1/Tab-0-1] DOIT en précharger un ou plus d'applications ou de composants de service avec un gestionnaire d'intents, pour toutes les Schémas de filtre d'intent public définis par les intents d'application suivants disponibles ici.

3. Logiciel

3.1. Compatibilité des API gérées

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

Implémentations pour les appareils:

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

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

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

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

• [C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, car celles-ci sont définis comme des méthodes et des champs dans les packages de langage Java qui sont dans le classpath de démarrage d'AOSP, et qui ne font pas partie SDK. Cela inclut les API décorées avec l'annotation @hide, mais pas avec un @SystemAPI, comme décrit dans les documents du SDK ; et les membres des classes privées et privées de packages.

• [C-0-6] DOIT être livré avec chaque interface non SDK basée sur la même fournies via les options provisoires et de blocage dans prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche de niveau d'API appropriée dans AOSP.

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

  Cependant, ils:

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

3.1.1. Extensions Android

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

Implémentations pour les appareils Android:

• [C-0-1] DOIT précharger l'implémentation AOSP des deux bibliothèques partagées ExtShared et les services ExtServices dont la version est supérieure ou égale à les versions minimales autorisées par niveau d'API. Par exemple, Android 7.0 implémentations d'appareils, l'exécution du niveau d'API 24 DOIT inclure au moins version 1.

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

• [C-0-3] DOIT prendre en charge toutes les API définies par les versions d'extension renvoyé 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 indiquées dans la section 3.1.

3.1.2. Bibliothèque Android

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

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

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

3.2. Compatibilité avec les API soft

En plus des API gérées de la section 3.1, Android inclut également une API "soft" significative uniquement à l'environnement d'exécution, sous la forme d'une des éléments tels que les intents, les autorisations et d'autres aspects des applications Android qui ne peut pas être appliquée au moment de la compilation de l'application.

3.2.1. Autorisations

• [C-0-1] Les responsables de la mise en œuvre des appareils DOIVENT prendre en charge et appliquer toutes les autorisations telles qu'indiquées sur la page de référence des autorisations. Notez que la section 9 répertorie d'autres 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 Classe android.os.Build qui décrivent l'appareil actuel.

• [C-0-1] Fournir des valeurs cohérentes et significatives sur tous les appareils mises en œuvre, le tableau ci-dessous inclut des restrictions supplémentaires concernant les formats que les implémentations d'appareils DOIVENT respecter.

Paramètre	Détails
VERSION.VERSION	Version lisible par l'humain du système Android en cours d'exécution . Ce champ DOIT contenir l'une des valeurs de chaîne définies dans Chaînes de version autorisées pour Android 12.
VERSION.SDK	Version du système Android en cours d'exécution, dans un format accessibles au code de l'application tierce. Pour Android 12, ce champ DOIT avoir la valeur entière 12_INT.
VERSION.SDK_INT	Version du système Android en cours d'exécution, dans un format accessibles au code de l'application tierce. Pour Android 12, ce champ DOIT avoir la valeur entière 12_INT.
VERSION SUPPLÉMENTAIRE	Une valeur choisie par le responsable de l'implémentation de l'appareil qui désigne le build spécifique du système Android en cours d'exécution, dans un format lisible par l'humain. Ce la valeur NE DOIT PAS être réutilisée pour différentes versions mises à la disposition des utilisateurs finaux. A ce champ est généralement utilisé pour indiquer le numéro ou l'identifiant de modification du contrôle des sources a été utilisé pour générer la compilation. La valeur de ce champ DOIT être encodable en tant que code ASCII 7 bits imprimable et correspondre à la l'expression régulière "^[^ :\/~]+$".
JEUX DE SOCIÉTÉ	Une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant matériel interne utilisé par l'appareil, dans un format intelligible. Une ce champ permet d'indiquer la révision spécifique de la source d'alimentation de la carte l'appareil. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE	Valeur reflétant la marque associée à l'appareil, connue pour les utilisateurs finaux. DOIT être dans un format lisible et représenter fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisés. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre L'expression régulière "^[a-zA-Z0-9_-]+$".
ABI_COMPATIBLES	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
ABI_PRIS EN CHARGE_32_BIT	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
SUPPORTED_64_BIT_ABIS	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) de du code natif. Consultez la section 3.3. Format natif Compatibilité de l'API :
ABI_CPU	Nom de l'ensemble d'instructions (type de processeur + convention d'ABI) de l'API native du code source. Consultez la section 3.3. API native Compatibilité :
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) de du code natif. Consultez la section 3.3. Format natif Compatibilité de l'API :
APPAREIL	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du développement ou un nom de code identifiant la configuration des caractéristiques matérielles de conception industrielle. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Le nom de cet appareil NE DOIT PAS changer pendant la durée de vie du produit.
Empreinte	Chaîne qui identifie cette compilation de manière unique. Cela DOIT être raisonnablement lisibles par l'humain. Il DOIT suivre ce modèle: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.Release)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemple : acme/monproduit/ mydevice:12/LMYXX/3359:userdebug/clé-test L'empreinte NE DOIT PAS inclure d'espaces blancs. La valeur ce champ DOIT être encodable au format ASCII 7 bits.
MATÉRIEL	Nom du matériel (depuis la ligne de commande du noyau ou /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondant à l'expression régulière "^[a-zA-Z0-9_-]+$".
HÉBERGEUR	Chaîne qui identifie de manière unique l'hôte sur lequel la compilation a été créée, dans dans un format lisible par l'humain. Il n'existe aucune exigence concernant le format spécifique ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID	Un identifiant choisi par le responsable de la mise en œuvre de l'appareil pour faire référence à dans un format lisible par l'humain. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment élevée. significatif pour les utilisateurs finaux de faire la distinction entre les versions logicielles. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre aux l'expression "^[a-zA-Z0-9._-]+$".
FABRICANT	Dénomination commerciale du fabricant d'équipement d'origine (OEM) produit. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'elle NE DOIT PAS être nulle ou chaîne vide (""). Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
FABRICANT_DE_SOC	Nom commercial du fabricant du système principal sur (SOC) utilisée dans le produit. Appareils du même fabricant SOC doit utiliser la même valeur constante. Demandez au fabricant de votre SOC la constante correcte à utiliser. La valeur de ce champ DOIT être encodable au format ASCII sur 7 bits, DOIT correspondre à l'expression régulière "^([0-9A-Za-z ]+)", NE DOIT PAS commencer ni se terminer par un espace blanc. et NE DOIT PAS être égal à "inconnu". Ce champ NE DOIT PAS changer au cours de la durée de vie du produit.
MODÈLE SOC	Nom de modèle du système principal sur une puce (SOC) utilisé dans le produit. Les appareils ayant le même modèle de SOC doivent utiliser la même constante . Demandez au fabricant de votre SOC la constante à utiliser. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au l'expression régulière "^([0-9A-Za-z ._/+-]+)$", NE DOIT PAS commencer ni se terminer par un espace et NE DOIT PAS être égal à "inconnu". Ce champ NE DOIT PAS changer pendant la durée de vie du produit.
MODÈLE	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du appareil tel qu'il est connu de l'utilisateur final. Il DOIT être le même nom sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Il n'existe aucune exigence concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni le Chaîne vide (""). Ce champ NE DOIT PAS changer au cours de la durée de vie du produit.
PRODUIT	Valeur choisie par l'outil de mise en œuvre de l'appareil contenant le nom du développement ou le nom de code du produit spécifique (SKU) qui DOIT être unique dans le d'une même marque. DOIT être lisible, mais n'est pas nécessairement destiné à la vue par les utilisateurs finaux. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$". Ce produit le nom NE DOIT PAS changer pendant la durée de vie du produit.
SKU_ODM	Une valeur facultative choisie par le responsable de la mise en œuvre de l'appareil qui contient SKU (Stock Keeping Unit, unité de gestion des stocks) permettant de suivre des configurations spécifiques des (par exemple, tous les périphériques inclus avec l'appareil lorsqu'il est vendu). La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au Expression régulière ^([0-9A-Za-z.,_-]+)$.
SÉRIE	DOIT renvoyer la valeur "UNKNOWN".
TAGS	Une liste de tags séparés par une virgule, choisis par le responsable de l'implémentation de l'appareil, permet de distinguer davantage la compilation. Les tags DOIVENT être encodables au format ASCII 7 bits. et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+" et DOIT avoir l'une des valeurs correspondant aux trois plates-formes Android classiques ; configurations de signature: clés de publication, clés de développement et clés de test.
DURÉE	Valeur représentant l'horodatage du moment où la compilation s'est produite.
MACH	Valeur choisie par le responsable de la mise en œuvre de l'appareil spécifiant l'environnement d'exécution la configuration de la compilation. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations d'exécution standards d'Android: user, userdebug ou eng.
UTILISATEUR	Nom ou ID de l'utilisateur (ou de l'utilisateur automatisé) ayant généré la créer. Il n'y a aucune exigence sur le format spécifique de ce champ, sauf qu'elle NE DOIT PAS être nulle ou chaîne vide ("").
SÉCURITÉ_PATCH	Valeur indiquant le niveau du correctif de sécurité d'un build. Cela DOIT signifier que la compilation n'est en aucune façon vulnérable aux problèmes décrits via le bulletin de sécurité publique d'Android désigné. Il DOIT se trouver dans au format [AAAA-MM-JJ], correspondant à une chaîne définie documentée dans le Bulletin de sécurité publique Android ou dans Avis de sécurité Android, par exemple "2015-11-01".
OS DE BASE	Valeur représentant le paramètre FINGERPRINT de la compilation qui est autrement identique à ce build, à l'exception des correctifs fournis dans Bulletin de sécurité publique d'Android Il DOIT indiquer la valeur correcte et si une telle compilation n'existe pas, signalez une chaîne vide ("").
CHARGEUR DE CHARGEMENT	Une valeur choisie par le responsable de la mise en œuvre de l'appareil identifiant version interne du bootloader utilisé dans l’appareil, dans un format intelligible. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondre au l'expression régulière "^[a-zA-Z0-9._-]+$".
getRadioVersion()	DOIT (être ou renvoyer) une valeur choisie par l'outil de mise en œuvre de l'appareil identifiant la version radio/modem interne spécifique utilisée dans l’appareil, dans un format lisible par l'humain. Si un appareil ne dispose pas radio/modem, il DOIT renvoyer NULL. La valeur de ce champ DOIT être encodable au format ASCII 7 bits et correspondant à l'expression régulière "^[a-zA-Z0-9._-,]+$".
getSerial()	DOIT être (être ou renvoyer) un numéro de série du matériel, qui DOIT être disponible et unique pour tous les appareils avec le même MODEL et le même MANUFACTURER. La valeur ce champ DOIT être encodable au format ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-,]+$".

Compatibilité des intents

Intents d'application courants

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

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger une ou plusieurs applications ou les composants de service avec un gestionnaire d'intents, pour tous les filtres d'intent publics ; Modèles définis par les intents d'application suivants, qui sont répertoriés ici et assurer le traitement, c'est-à-dire répondre aux attentes des développeurs les intents d'application décrits dans le SDK.

Veuillez consulter la section 2 pour en savoir plus sur les intents d'application obligatoires. pour chaque type d'appareil.

Résolution d'intent

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

• [C-0-2] Les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS accorder de privilèges spéciaux au système des applications l'utilisation de ces modèles d'intent ou empêcher les applications tierces de lier et de prendre le contrôle de ces modèles. Cette interdiction Elle inclut, sans s'y limiter, la désactivation de l'utilisateur "Sélecteur". qui permet à l'utilisateur de choisir parmi plusieurs applications gèrent le même modèle d'intent.

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

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

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

• [C-0-4] DOIT essayer de valider les filtres d'intent en effectuant l' les étapes de validation définies dans la spécification Digital Asset Links. tel qu'il est implémenté par le gestionnaire de packages dans le package Android Open Source en amont Projet.
• [C-0-5] DOIT tenter de valider les filtres d'intent pendant l'installation de l'application et définir tous les filtres d'intent d'URI correctement validés en tant que des gestionnaires d'application par défaut pour leurs URI.
• PEUT définir des filtres d'intent d'URI spécifiques comme gestionnaires d'application par défaut pour leurs URI, s'ils sont validés, mais que les autres filtres d'URI des candidats échouent. la validation. Si une implémentation d'appareil le fait, elle DOIT indiquer la remplacements de format par URI appropriés à l'utilisateur dans le menu des paramètres.
• DOIT fournir à l'utilisateur des commandes de liens vers une application par application dans les paramètres, ce qui suit:
  • [C-0-6] L'utilisateur DOIT pouvoir ignorer de manière globale l'application par défaut comportement des liens pour qu'une application soit toujours ouverte, toujours demander ou ne jamais ouvrir, qui doit s'appliquer de manière égale à tous les filtres d'intent d'URI candidats.
  • [C-0-7] L'utilisateur DOIT pouvoir voir la liste de l'intent d'URI candidat des filtres.
  • L'implémentation de l'appareil PEUT donner à l'utilisateur la possibilité de remplacer les filtres d'intents d'URI candidats spécifiques qui ont bien été vérifiés, par filtre d'intent.
  • [C-0-8] L'implémentation d'un appareil DOIT donner aux utilisateurs la possibilité de afficher et remplacer des filtres d'intent d'URI candidats spécifiques si l'appareil permet à certains filtres d'intent d'URI candidats de réussir la validation, tandis que d'autres peuvent échouer.

Espaces de noms des intents

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

Intents de diffusion

Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents les informer des changements dans l’environnement matériel ou logiciel.

Implémentations pour les appareils:

• [C-0-1] DOIT diffuser les intents de diffusion publique répertoriés ici en réponse à des événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'entre pas en conflit avec la section 3.5, car les pour les applications en arrière-plan sont également décrites dans le SDK dans la documentation Google Cloud. Par ailleurs, certains intents de diffusion dépendent du matériel. prise en charge. Si l'appareil prend en charge le matériel nécessaire, il DOIT diffuser le et fournir le comportement conformément à la documentation du SDK.

Intents d'application conditionnels

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

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

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

• [C-1-1] DOIT respecter les android.settings.HOME_SETTINGS intention d'afficher un menu de paramètres de l'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 la méthode android.provider.Telephony.ACTION_CHANGE_DEFAULT intent pour afficher une boîte de dialogue permettant de modifier l'application SMS par défaut.

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

  • 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 les appels sortants, à l'exception des appels d'urgence, l'application Téléphone préinstallée.

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

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

• [C-2-5] DOIT fournir à l'utilisateur l' affordance de choisir une application contenant le android.app.role.CALL_REDIRECTION rôle de ressource.

• [C-2-6] DOIT respecter l'autorisation android.intent.action.SENDTO et android.intent.action.VIEW et fournissent une activité permettant d'envoyer/afficher des SMS.

• [C-SR-1] EST VIVEMENT RECOMMANDÉ de respecter android.intent.action.ANSWER, android.intent.action.CALL android.intent.action.CALL_BUTTON android.intent.action.VIEW &amp; android.intent.action.DIAL avec une application de téléphonie préchargée capable de gérer ces intents et un traitement tel que décrit dans le SDK.

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

• [C-3-1] DOIT respecter les android.settings.NFC_PAYMENT_SETTINGS Intention d'afficher un menu de paramètres par défaut de l'application pour le paiement sans contact.
• [C-3-2] DOIT respecter android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT pour afficher une activité qui ouvre une boîte de dialogue pour demander à l'utilisateur de modifier 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 &amp; android.nfc.action.TECH_DISCOVERED pour afficher une activité qui répond aux attentes des développeurs concernant ces intents, décrites dans le SDK.

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

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

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

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

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

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

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

• [C-8-1] DOIT respecter les android.settings.ACCESSIBILITY_SETTINGS fournir un mécanisme accessible à l'utilisateur permettant d'activer et de désactiver des services d'accessibilité tiers parallèlement aux fonctionnalités d'accessibilité préchargées services.

Si les implémentations d'appareils incluent la prise en charge de la fonctionnalité Wi-Fi Easy Connect et exposent le à des applications tierces, ils:

• [C-9-1] DOIT implémenter l'élément Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent, comme décrit dans la documentation du SDK.

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

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

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

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

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

• [C-12-3] DOIT respecter uniquement la gestion des applications Android préinstallées les intents suivants MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, et MediaStore.ACTION_VIDEO_CAPTURE comme décrit dans le document relatif au SDK.

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

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

• [C-13-2] DOIT respecter les intents android.app.action.PROVISION_MANAGED_PROFILE android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD android.app.action.SET_NEW_PASSWORD &amp; android.app.action.START_ENCRYPTION et disposer d'une activité permettant le traitement de ces intents, comme décrit dans le SDK ici.

Si les intégrations d'appareils déclarent le android.software.autofill de fonctionnalité, ils:

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

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

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

Si les mises en œuvre de l'appareil visent à interdire certaines applications, y compris celles préinstallées applications, d'accéder aux statistiques d'utilisation, elles:

• [C-15-1] DOIT toujours disposer d'une activité qui gère android.settings.ACTION_USAGE_ACCESS_SETTINGS mais il DOIT l'implémenter en tant que no-op, c'est-à-dire avoir un équivalent comme lorsque l'accès de l'utilisateur est refusé.

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

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

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

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

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

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de respecter android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et Les intents android.speech.tts.engine.GET_Sample_TEXT ont une activité à fournir pour ces intents, comme décrit dans le SDK ici.

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

• DEVRAIT inclure la prise en charge des économiseurs d'écran et fournir une option de paramétrage pour aux utilisateurs de configurer les économiseurs d'écran Intent android.settings.DREAM_SETTINGS.

Activités sur des écrans secondaires ou multiples

Si les implémentations d'appareils permettent le lancement d'activités Android normales sur plus de un seul écran, ils:

• [C-1-1] DOIT définir le paramètre android.software.activities_on_secondary_displays flag de fonctionnalité.
• [C-1-2] DOIT garantir une compatibilité d'API semblable à celle d'une activité exécutée sur l'écran principal.
• [C-1-3] DOIT envoyer la nouvelle activité sur le même écran que l'activité lorsque la nouvelle activité est lancée sans spécifier de cible afficher via ActivityOptions.setLaunchDisplayId() API.
• [C-1-4] DOIT détruire toutes les activités lorsqu'un écran avec Display.FLAG_PRIVATE est supprimé.
• [C-1-5] DOIT masquer de façon 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 accepte de s'afficher en haut de la serrure écran avec Activity#setShowWhenLocked() API.
• DEVRAIT inclure android.content.res.Configuration correspondant à cet affichage, utilisez correctement et maintenir la compatibilité si une activité est lancée sur l'écran secondaire.

Si les implémentations d'appareils permettent le lancement d'activités Android normales sur des applications secondaires écrans, tandis qu'un écran secondaire dispose de l'autorisation android.view.Display.FLAG_PRIVATE. :

• [C-3-1] Seul le propriétaire de l'écran, du système et des activités déjà sur cet écran DOIT pouvoir y être lancé. Tout le monde peut lancer vers un écran comportant android.view.Display.FLAG_PUBLIC ; .

3.3. Compatibilité avec les API natives

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

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

3.3.1. Interfaces binaires d'application

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

Implémentations pour les appareils:

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

• [C-0-6] DOIT signaler, à l'aide des paramètres ci-dessus, un sous-ensemble des liste d'ABI et NE DOIT PAS indiquer d'ABI qui ne figure pas sur cette liste.

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

• [C-0-7] DOIT créer toutes les bibliothèques suivantes, en fournissant des API natives, disponibles pour les applications qui incluent du code natif:

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

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

• [C-0-9] DOIT répertorier des bibliothèques supplémentaires non-AOSP exposées directement à applications tierces dans le pays suivant : /vendor/etc/public.libraries.txt.

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

• [C-0-11] DOIT exporter tous les éléments OpenGL ES 3.1 et Android Extension Pack symboles de fonction, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que si tous les symboles DOIVENT être présents, la section 7.1.4.1 décrit les exigences liées à la mise en œuvre complète les fonctions correspondantes sont attendues.

• [C-0-12] DOIT exporter les symboles de fonction pour la fonction principale Vulkan 1.0 ainsi que VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et les extensions VK_KHR_get_physical_device_properties2 via la libvulkan.so. Notez que même si tous les symboles DOIVENT être présents, la section 7.1.4.2 décrit plus en détail les exigences liées aux l'implémentation de chaque fonction correspondante est attendue.

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

Notez que les prochaines versions d'Android pourront inclure d'autres ABI.

3.3.2. Compatibilité avec le code natif ARM 32 bits

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

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

Si les implémentations d'appareils indiquent la prise en charge de l'ABI armeabi-v7a, pour les applications à l'aide de cette ABI:

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

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

• [C-2-2] DOIT toujours assurer la disponibilité des opérations suivantes, même dans le dans lequel l'ABI est implémentée sur une architecture ARMv8, compatible avec les processeurs natifs ou via l'émulation logicielle:

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

• [C-2-3] DOIT inclure la prise en charge du module Advanced SIMD (ou NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

• [C-1-1] DOIT signaler android.software.webview.
• [C-1-2] DOIT utiliser la version du projet Chromium du projet Android Open Source en amont sur le pour la mise en œuvre du android.webkit.WebView API.

• [C-1-3] La chaîne user-agent signalée par la WebView DOIT être au format suivant:

  Mozilla/5.0 (Linux ; Android $(VERSION) ; [$(MODEL)] [Build/$(Build)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • La valeur de la chaîne $(VERSION) DOIT être identique à la valeur de android.os.Build.VERSION.Release.
  • La chaîne $(MODEL) PEUT être vide, mais si elle n'est pas vide, elle DOIT avoir la même valeur que android.os.Build.MODEL.
  • "Build/$(CRÉER)" PEUT être omis, mais si elle est présente, l'élément $(Build) La chaîne DOIT être identique à la valeur d'android.os.Build.ID.
  • La valeur de la chaîne $(CHROMIUM_VER) DOIT être la version de Chromium dans le projet Open Source Android en amont.
  • Il est possible que les implémentations d'appareils omettent "Mobile" dans la chaîne de l'agent utilisateur.

• Le composant WebView DOIT inclure un maximum de fonctionnalités HTML5 possible et, s'il prend en charge, la fonctionnalité DOIT être conforme au Spécification HTML5

• [C-1-4] DOIT rendre le contenu fourni ou le contenu de l'URL distante au cours d'un processus distincte de l'application qui instancie la WebView. Plus précisément, le processus du moteur de rendu distinct DOIT disposer d'un privilège inférieur, exécutez en tant qu'ID utilisateur distinct, n'ont pas accès au répertoire de données de l'application, n'ont pas d'accès direct au réseau et n'ont accès qu'aux ressources minimales des services système via Binder. L'implémentation AOSP de WebView répond aux cette exigence.

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

Compatibilité du navigateur

Si les implémentations d'appareils incluent une application de navigateur autonome sur le Web, ils:

• [C-1-1] DOIT prendre en charge chacune des API associées HTML5:
  • Cache d'application/opération hors connexion
  • <vidéo> d'entraînement
  • géolocalisation
• [C-1-2] DOIT prendre en charge les formats HTML5/W3C webstorage et DOIT prendre en charge les formats HTML5/W3C API IndexedDB : Notez que comme le Web les organismes de normalisation de développement opèrent une transition pour favoriser IndexedDB. Webstorage, IndexedDB devrait devenir un composant obligatoire dans un la prochaine version d'Android.
• PEUT envoyer une chaîne user-agent personnalisée dans l'application de navigateur autonome.
• DEVRAIT mettre en œuvre la prise en charge d'autant de HTML5 dans la version autonome Application de navigateur (basée sur le navigateur WebKit en amont) application de remplacement ou la solution de remplacement tierce).

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

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

3.5. Compatibilité comportementale de l'API

Implémentations pour les appareils:

• [C-0-9] DOIT s'assurer que la compatibilité comportementale de l'API est appliquée à toutes les applications installées, à moins qu'elles ne soient soumises aux restrictions décrites dans la section Section 3.5.1.
• [C-0-10] NE DOIT PAS implémenter l'approche d'ajout à la liste d'autorisation qui garantit compatibilité comportementale uniquement pour les applis sélectionnées par appareil les responsables de la mise en œuvre.

Le comportement de chacun des types d'API (gérées, logicielles, natives et Web) doit être conforme à l'implémentation préférée de l'infrastructure en amont Projet Android Open Source Certaines zones spécifiques de compatibilité sont les suivants:

• [C-0-1] Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un l'intent standard.
• [C-0-2] Les appareils NE DOIVENT PAS modifier la sémantique du cycle de vie 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. En particulier, pour les applications en arrière-plan:
  • [C-0-4], ils DOIVENT cesser d'exécuter des rappels enregistrés par le service 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 le LocationManager classe d'API ou WifiManager.startScan() .
  • [C-0-6] Si l'application cible le niveau d'API 25 ou supérieur, elle NE DOIT PAS permettent d'enregistrer des broadcast receivers pour les diffusions implicites des intents Android standards dans le fichier manifeste de l'application, sauf si la diffusion l'intent requiert un "signature" ou un "signatureOrSystem" protectionLevel ou figurent sur la liste des exemptions.
  • [C-0-7] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT s'arrêter services d'arrière-plan de l'application, comme si l'application avait appelé servicesstopSelf() , à moins que l'application ne soit placée sur une liste d'autorisation temporaire pour gérer visible par l'utilisateur.
  • [C-0-8] Si l'application cible le niveau d'API 25 ou supérieur, elle DOIT pour libérer les wakelocks que l'application contient.
• [C-0-11] Les appareils DOIVENT renvoyer les fournisseurs de sécurité suivants en premier sept valeurs de tableau issues de Security.getProviders() , dans l'ordre indiqué et avec les noms donnés (tels que renvoyés par Provider.getName()) et ses classes, sauf si l'application a modifié la liste via insertProviderAt() ou removeProvider(). Appareils PEUT renvoyer des fournisseurs supplémentaires après la liste de fournisseurs spécifiée ci-dessous.
  1. AndroidNSSP – android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL : com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider : sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCSolution : android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC – com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE – com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore – android.security.keystore.AndroidKeyStoreProvider

La liste ci-dessus n'est pas exhaustive. Tests de la suite de tests de compatibilité (CTS) une partie importante de la plate-forme pour la compatibilité comportementale, mais pas toutes. Il est de la responsabilité de l'outil d'implémentation de s'assurer de la compatibilité du comportement avec le projet Android Open Source. Pour cette raison, les responsables de la mise en œuvre DEVRAIT utiliser le code source disponible via le projet Android Open Source où au lieu de réimplémenter des parties importantes du système.

3.5.1. Restriction d'application

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

• [C-1-1] DOIT indiquer l' affordance de l'utilisateur où celui-ci peut voir la liste des applications dont l'accès est limité.
• [C-1-2] DOIT fournir une affordance à l'utilisateur pour activer / désactiver les restrictions. sur chaque application.
• [C-1-3] NE DOIT PAS appliquer automatiquement des restrictions en l'absence de preuves du comportement de l'état du système, mais PEUVENT appliquer les restrictions sur les applications lors de la détection de mauvais comportements liés à l'état du système, comme les wakelocks figés, les services de longue durée d'autres critères. Les critères PEUVENT être déterminés par les responsables de la mise en œuvre de l'appareil, mais DOIVENT être à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas uniquement en lien avec l'état du système, comme le manque de popularité de l'application dans du marché, NE DOIVENT PAS être utilisés comme critères.
• [C-1-4] NE DOIT PAS appliquer automatiquement des restrictions aux applications lorsqu'un utilisateur a désactivé manuellement les restrictions d'application et PEUT suggérer à l'utilisateur d'appliquer les restrictions de l'application.
• [C-1-5] DOIT informer les utilisateurs si des restrictions sont appliquées à une application automatiquement. Ces informations DOIVENT être fournies dans les 24 heures suivant la date les restrictions s'appliquent.
• [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 au premier plan qui est explicitement utilisée par l'utilisateur.
• [C-1-8] DOIT suspendre les restrictions sur une application qui devient le premier plan supérieur application lorsque l'utilisateur commence explicitement à utiliser l'application qui était auparavant utilisée restreintes.
• [C-1-10] NE DOIT PAS permettre à une application d'être automatiquement placée dans la catégorie dans les 2 heures suivant sa dernière utilisation par un utilisateur.

Si les implémentations d'appareils étendent les restrictions des applications mises en œuvre dans AOSP:

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

3.5.2. Hibernation des applications

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

• [C-1-1] DOIT respecter toutes les exigences de la section 3.5.1, à l'exception des [C-1-6] et [C-1-3].
• [C-1-2] DOIT appliquer la restriction sur l'application uniquement pour un utilisateur la preuve que l'utilisateur n'a pas utilisé l'application depuis un certain temps. Ce il est FORTEMENT RECOMMANDÉ de durer un mois ou plus. L'utilisation DOIT être défini par une interaction explicite de l'utilisateur via la méthode UsageStats#getLastTimeVisible() ou tout autre élément qui pousserait une application à quitter l'état d'arrêt forcé, y compris les liaisons de service, de fournisseur de contenu, de diffusions explicites, etc. qui sera suivi par une nouvelle API UsageStats#getLastTimeAnyComponentUsed().
• [C-1-3] DOIT appliquer uniquement des restrictions affectant tous les utilisateurs de l'appareil est la preuve que le package n'a été utilisé par AUCUN utilisateur depuis un certain temps en temps réel. Il est FORTEMENT RECOMMANDÉ de choisir une durée d'au moins un mois.
• [C-1-4] NE DOIT PAS rendre l'application incapable de répondre aux intents d'activité, les liaisons de service, les requêtes de fournisseurs de contenu ou les diffusions explicites.

L'hibernation des applications dans AOSP répond aux exigences ci-dessus.

3.6. Espaces de noms de l'API

Android suit les conventions d'espace de noms des packages et des classes définies par le code Java langage de programmation. Pour assurer la compatibilité avec les applications tierces, les responsables de la mise en œuvre de l'appareil NE DOIVENT PAS apporter de modifications interdites (voir ci-dessous) aux ces espaces de noms de package:

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

En d'autres termes, ils:

• [C-0-1] NE DOIT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant une méthode ou une signature de classe, ou en supprimant des classes ou des classes .
• [C-0-2] NE DOIT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, des champs ou des méthodes à des classes ou des interfaces existantes), ou des tests ou les API système aux API dans les espaces de noms ci-dessus. Une application « publiquement exposée " correspond à toute construction qui n'est pas ornée du symbole "@hide" marquer comme utilisés dans le code source Android en amont.

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

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

Cependant, les responsables de la mise en œuvre d'appareils PEUVENT ajouter des API personnalisées en dehors de la version standard d'Android mais les API personnalisées:

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

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

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

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

Notez que les restrictions ci-dessus correspondent aux conventions standards de dénomination les API en langage de programmation Java ; Cette section vise simplement à renforcer ces conventions et les lieront par leur inclusion dans ce tableau de compatibilité Définition.

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

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le format Dalvik Executable (DEX) complet et la spécification et la sémantique du bytecode Dalvik.

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

• DEVRAIT utiliser Android RunTime (ART), la référence en amont du format exécutable Dalvik et la référence de gestion des packages de votre implémentation.

• DEVRAIT exécuter des tests à données aléatoires dans différents modes d'exécution et les 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 les implémentations d'appareils PEUVENT allouer plus de mémoire par application.

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

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

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

Si les implémentations d'appareils autorisent des applications tierces à le remplacer l'écran d'accueil, ils:

• [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.home_screen.
• [C-1-2] DOIT renvoyer le code AdaptiveIconDrawable lorsque l'application tierce utilise le tag <adaptive-icon> pour fournir leur icône, et le PackageManager de récupération d'icônes.

Si les implémentations de l'appareil incluent un lanceur d'applications par défaut compatible avec les applications épinglage des raccourcis, ils:

• [C-2-1] DOIT signaler true pour ShortcutManager.isRequestPinShortcutSupported()
• [C-2-2] DOIT disposer d'une affordance de l'utilisateur qui demande à l'utilisateur avant d'ajouter un raccourci demandé par les applications via le 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 Raccourcis d'application.

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

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

Si les implémentations d'appareils implémentent un lanceur par défaut qui fournit des l'accès aux raccourcis supplémentaires fournis par des applications tierces via les Gestionnaire de raccourcis API, ils:

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

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

• [C-5-1] DOIT respecter les NotificationChannel.setShowBadge() . En d'autres termes, affichez une affordance visuelle associée à l'icône d'application si l' est définie sur true et n'affiche aucun schéma de badge d'icône d'application lorsque toutes des canaux de notification de l'application ont défini la valeur sur false.
• PEUT remplacer les badges des icônes d'applications par leur système de badges propriétaire lorsque Les applications tierces indiquent la compatibilité avec le système de badges propriétaires. via l'utilisation d'API propriétaires, mais DEVRAIT utiliser les ressources et les valeurs fournies par le biais des API de badges de notification décrites dans le SDK, comme Notification.Builder.setNumber() et la Notification.Builder.setBadgeIconType() API.

Widgets

Android prend en charge les widgets d'application tiers en définissant un type de composant et et le cycle de vie correspondants permettant aux applications d'exposer "AppWidget" à l'utilisateur final.

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

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

Si les implémentations d'appareils sont compatibles avec les widgets d'application tiers et les applications intégrées épinglage des raccourcis, ils:

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

3.8.3. Notifications

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

Présentation des notifications

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

• [C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et, dans la mesure du possible, via l'implémentation matériel. Par exemple, si l'implémentation d'un appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibreur. Si l'implémentation d'un appareil manque les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est plus en détail dans la section 7.
• [C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournis dans les API ou dans le Guide de style des icônes de la barre d'état/système bien qu'elles PEUVENT fournir une expérience utilisateur alternative pour les notifications que celui fourni par l'implémentation de référence Android Open Source.
• [C-1-3] DOIT respecter et mettre en œuvre correctement les comportements décrits pour les API pour mettre à jour, supprimer et regrouper les notifications.
• [C-1-4] DOIT fournir le comportement complet de NotificationChannel documentée dans le SDK.
• [C-1-5] DOIT fournir une affordance d'utilisateur pour bloquer et modifier une certaine des notifications de l'application tierce pour chaque canal et niveau de package d'application.
• [C-1-6] DOIT également fournir une affordance d'utilisateur pour afficher les notifications supprimées canaux de distribution.
• [C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) via Notification.MessagingStyle à côté du texte de la notification sans action supplémentaire de l'utilisateur. Pour exemple, DOIT afficher toutes les ressources, y compris les icônes fournies via android.app.Person dans une conversation de groupe définie via setGroupConversation.
• [C-SR-1] SONT FORTEMENT RECOMMANDÉS de mettre automatiquement en avant une affordance de l'utilisateur. pour bloquer les notifications d'une application tierce spécifique pour chaque canal et application au niveau du package après que l'utilisateur a ignoré cette notification plusieurs fois.
• [C-SR-2] sont VIVEMENT RECOMMANDÉS de fournir une affordance à l'utilisateur pour contrôler les notifications exposées aux applications qui ont été accordées l'autorisation "Écouteur de notifications". La précision DOIT être telle que l'utilisateur peut contrôler, pour chacun de ces écouteurs, quelles notifications sont associés à cet écouteur. Les types DOIVENT inclure "conversations", "alertes", "silencieux" et "important en cours" les notifications.
• [C-SR-3] sont VIVEMENT RECOMMANDÉS de fournir une affordance aux utilisateurs de spécifier les applications à exclure de l'envoi de notification à un écouteur de notifications spécifique.
• DEVRAIT prendre en charge les notifications enrichies.
• DEVRAIT présenter certaines notifications de priorité plus élevée sous forme de notifications prioritaires.
• DEVRAIT avoir une affordance utilisateur pour mettre en attente les notifications.
• PEUVENT gérer uniquement la visibilité et les délais de notification des applications tierces les utilisateurs d'événements notables afin d'atténuer les problèmes de sécurité tels que la distraction du conducteur.

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

Implémentations pour les appareils:

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

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

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

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

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

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

• [C-3-1] DOIT utiliser la vue de notification prioritaire et les ressources comme décrit dans la section Notification.Builder classe d'API lors de l'affichage de notifications prioritaires.
• [C-3-2] DOIT afficher les actions fournies dans Notification.Builder.addAction() avec le contenu de la notification sans action supplémentaire de la part de l'utilisateur comme décrit dans le SDK.

Service d'écoute des notifications

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

Implémentations pour les appareils:

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

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

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

Ne pas déranger

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

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

3.8.4. API Assist

Android inclut les API Assist pour permettre aux applications de choisir la quantité d'informations dans le contexte actuel partagé avec l'Assistant sur l'appareil.

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

• [C-2-1] DOIT indiquer clairement à l'utilisateur final lorsque le contexte est partagé soit:
  • Chaque fois que l'application d'assistance accède au contexte, autour des bords de l'écran qui atteignent ou dépassent la durée définie luminosité de l'implémentation du projet Android Open Source.
  • Pour l'application d'assistance préinstallée, fournir une affordance à l'utilisateur moins à moins de deux navigations le menu des paramètres de la saisie vocale et de l'Assistant Google par défaut et ne partage le contexte que lorsque l'application d'assistance est explicitement appelée par l'utilisateur via un mot clé ou la saisie d'une touche d'assistance à la navigation.
• [C-2-2] L'interaction désignée pour lancer l'application d'assistance, comme décrit section 7.2.3 DOIT lancer les applications sélectionnées par l'utilisateur l'application d'assistance, c'est-à-dire l'application qui implémente VoiceInteractionService, ou une activité qui gère l'intent ACTION_ASSIST.

Alertes et toasts

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

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

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

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

3.8.6. Thèmes

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

Android inclut les commandes "Holo" et "Material" famille de thèmes comme un ensemble de styles définis aux développeurs d'applications s'ils souhaitent faire correspondre Apparence du thème Holo comme défini par le SDK Android.

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

• [C-1-1] NE DOIT PAS modifier les attributs du thème Holo exposés applications.
• [C-1-2] DOIT prendre en charge la famille de thèmes "Material" et NE DOIT PAS modifier les éléments Attributs de thème Material ou leurs éléments exposés aux applications.
• [C-1-3] DOIT définir la valeur "sans-serif" famille de polices pour Roboto version 2.x pour les langues compatibles avec Roboto, ou fournissent une affordance à l'utilisateur pour modifier la police utilisée pour "sans-serif" famille de polices vers Roboto version 2.x pour les langues prises en charge par Roboto.

Android inclut également une famille de thèmes "Par défaut de l'appareil" comme ensemble de styles définis. permettant aux développeurs d'applications de s'adapter à l'interface Thème de l'appareil tel que défini par le responsable de la mise en œuvre de l'appareil.

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

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

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

• [C-2-1] DOIT utiliser le blanc pour les icônes d'état système (intensité du signal, le niveau de la batterie) et les notifications du système, sauf si l'icône est indiquant un état problématique ou si une application demande l'affichage d'une barre d'état lumineuse en utilisant WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS .
• [C-2-2] Les implémentations d'appareils Android DOIVENT modifier la couleur du système deviennent noirs (pour en savoir plus, consultez la section R.style) lorsqu'une application demande l'affichage d'une barre d'état de voyant.

3.8.7. Fonds d'écran animés

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

Le matériel est considéré comme capable d'exécuter des fonds d'écran animés de manière fiable s'il peut s'exécuter Tous les fonds d'écran animés, sans limitation de fonctionnalité, dans un cadre raisonnable sans aucun effet négatif sur les autres applications. Si les limites du champ qui provoque le plantage, le dysfonctionnement ou l'utilisation des fonds d'écran et/ou applications une autonomie excessive du processeur ou de la batterie, ou qui fonctionne à une fréquence d'images trop faible, le le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certaines Les fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécutera pas de manière fiable sur un matériel non compatible Contextes OpenGL, car l'utilisation du fond d'écran animé d'un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

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

3.8.8. Changement d'activité

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

Implémentations sur les appareils y compris la touche de navigation de la fonction "Recents", comme détaillé dans section 7.2.3 PEUT modifier l'interface.

Si les implémentations d'appareils, y compris la touche de navigation de la fonction "Recents", comme détaillé dans la section section 7.2.3 modifient l'interface, ils:

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

3.8.9. Gestion des entrées

Android prend en charge Gestion des entrées et la compatibilité avec les éditeurs de mode de saisie tiers.

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

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

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

L'API Remote Control Client a été abandonnée dans la version 5.0 d'Android au profit de Modèle de notification multimédia qui permet aux applications multimédias de s'intégrer aux commandes de lecture affiché sur l'écran de verrouillage.

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

Consultez la section 3.2.3.5 pour les paramètres. pour encombrer les économiseurs d'écran.

3.8.12. Position

Si les configurations de l'appareil incluent un capteur matériel (par exemple, un GPS) compatible avec de fournir les coordonnées de l'emplacement,

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

3.8.13. Unicode et police

Android prend en charge les caractères emoji définis dans Unicode 10.0 :

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

• [C-1-1] DOIT pouvoir afficher ces caractères emoji avec un glyphe de couleur.
• [C-1-2] DOIT inclure les éléments suivants:
  • Police Roboto 2 avec différentes épaisseurs : sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light pour les langues disponibles sur l'appareil.
  • Compatibilité totale avec Unicode 7.0 des caractères latins, grecs et cyrilliques, y compris les Plages A, B, C et D du latin étendu, et tous les glyphes dans la devise d'Unicode 7.0.
• [C-1-3] NE DOIT PAS supprimer ni modifier le fichier NotoColorEmoji.tff dans l'image système. Il est possible d'ajouter une police d'emoji pour remplacer les emoji dans NotoColorEmoji.tff).
• DEVRAIT prendre en charge la carnation et les différents emoji familiaux, comme indiqué dans les Rapport technique Unicode n° 51

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

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

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

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

• [C-2-1] DOIT afficher le texte avec une police compatible Unicode par défaut. une police non compatible avec Unicode NE DOIT PAS être définie comme police par défaut, sauf si l'utilisateur la sélectionne dans l'outil de sélection de langue.
• [C-2-2] DOIT prendre en charge une police Unicode et une police non compatible avec Unicode non compatible avec Unicode est pris en charge par l'appareil. Non Unicode conforme à la norme SSL NE DOIT PAS supprimer ni remplacer la police Unicode.
• [C-2-3] DOIT afficher le texte avec une police non conforme à Unicode UNIQUEMENT SI un code de langue avec Qaag du code de script est spécifiée (par exemple, my-Qaag). Aucun autre code de langue ou de région ISO (que ce soit attribuée, non attribuée ou réservée) peuvent être utilisées pour faire référence à des compatible avec le Myanmar. Les développeurs d'applications et les auteurs de pages Web peuvent spécifier "my-Qaag" comme code de langue, comme pour toute dans une autre langue.

3.8.14. Multifenêtre

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

• [C-1-1] DOIT implémenter ce ou ces modes multifenêtres conformément aux les comportements d'application et les API décrits dans le SDK Android documentation d'assistance concernant le mode multifenêtre et 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 les modes É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. dp.
• [C-1-4] Une activité NE DOIT PAS être redimensionnée à une taille inférieure à 220 dp les modes multifenêtre autres que Picture-in-picture.
• Les implémentations d'appareils avec une taille d'écran xlarge DEVRAIT prendre en charge le format libre .

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

• [C-2-2] DOIT recadrer l'activité ancrée d'un écran partagé multifenêtre, mais DEVRAIT afficher un contenu de celui-ci si le lanceur d'applications est la fenêtre sélectionnée.
• [C-2-3] DOIT respecter la AndroidManifestLayout_minWidth déclarée et AndroidManifestLayout_minHeight de l'application de lancement tierce et ne les remplacent pas. au cours de l'affichage du contenu de l'activité ancrée.

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

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

  • Ciblage du niveau d'API 26 ou supérieur, et déclare android:supportsPictureInPicture
  • Ciblage du niveau d'API 25 ou inférieur, et déclare à la fois android:resizeableActivity et android:supportsPictureInPicture.

• [C-3-2] DOIT exposer les actions dans leur SystemUI spécifié par l'activité PIP en cours via la setActions() API.

• [C-3-3] DOIT accepter les formats supérieurs ou égaux à 1:2.39 et inférieures ou égales à 2.39:1, comme spécifié par l'activité PIP via le setAspectRatio() API.

• [C-3-4] DOIT utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP, si le mode PIP n'est pas implémenté, la clé DOIT être disponibles pour l'activité de premier plan.

• [C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher dans Mode PIP l'implémentation AOSP répond à cette exigence en ayant dans le volet des notifications.

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

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

3.8.15. Découpe de l'écran

Android prend en charge une découpe d'écran comme décrit dans le document du SDK. L'API DisplayCutout définit Une zone située sur le bord de l'écran qui n'est peut-être pas fonctionnelle pour une application en raison d'une encoche ou d'un écran incurvé sur les bords.

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

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

3.8.16. Commandes de contrôle des appareils

Android inclut ControlsProviderService et Control API permettant à des applications tierces de publier des commandes de contrôle des appareils l'état et l'action des utilisateurs.

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

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications fonctions d'administration des appareils au niveau du système, telles que l'application forcée de mots de passe ou en effaçant les données à distance, API Android Device Administration :

Si les implémentations d'appareils implémentent toutes les fonctionnalités d'administration des appareils définies dans la documentation du SDK Android, elles:

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

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

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

• [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant que Application Propriétaire de l'appareil comme décrit ci-dessous:
  • Lorsque aucune donnée utilisateur n'est encore configurée pour l'implémentation de l'appareil, celle-ci:
    • [C-1-5] DOIT enregistrer l'application DPC en tant qu'application "Device Owner" (Propriétaire de l'appareil) si l'appareil déclare être compatible avec la technologie NFC (communication en champ proche) via la fonctionnalité l'indicateur android.hardware.nfc et reçoit un message NFC contenant un avec le type MIME MIME_TYPE_PROVISIONING_NFC.
    • [C-1-8] DOIT envoyer ACTION_GET_PROVISIONING_MODE suivant le déclenchement du provisionnement du propriétaire de l'appareil, afin que L'application DPC peut choisir de devenir propriétaire de l'appareil ou profil propriétaire, sauf s'il est possible de déterminer à partir du contexte qu'il n'y a une option valide (par exemple, pour le provisionnement par NFC où le profil le provisionnement du propriétaire n'est pas pris en charge).
    • [C-1-9] DOIT envoyer la déclaration ACTION_ADMIN_POLICY_COMPLIANCE intent vers l'application Propriétaire de l'appareil si un propriétaire de l'appareil est établi quelle que soit la méthode de provisionnement utilisée. La l'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que L'application Device Owner se termine.
  • Lorsque l'implémentation de l'appareil contient des données utilisateur:
    • [C-1-7] NE DOIT PAS enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil plus tard.
• [C-1-2] DOIT exiger une action affirmative avant ou pendant processus de provisionnement pour que l'application soit définie comme propriétaire de l'appareil. Il peut s'agir d'une action de l'utilisateur ou d'une méthode programmatique, l'avis de divulgation (tel qu'indiqué dans l'AOSP) DOIT être affiché avant le propriétaire de l'appareil le provisionnement est lancé. De plus, le propriétaire de l'appareil programmatique le mécanisme utilisé (par les entreprises) pour le provisionnement des propriétaires d'appareils NE DOIT PAS interfère avec l'expérience prête à l'emploi pour une utilisation en dehors de l'entreprise.
• [C-1-3] NE DOIT PAS coder en dur le consentement ni empêcher l'utilisation d'un autre appareil propriétaires.

Si les implémentations de l'appareil déclarent android.software.device_admin, mais aussi incluent une solution propriétaire de gestion des propriétaires d'appareils et fournissent un mécanisme pour promouvoir une application configurée dans sa solution en tant que "Device Owner équivalent" au profil standard "Propriétaire de l'appareil" conformément à la norme Android Gestionnaire de règles d'appareil API, ils:

• [C-2-1] DOIT mettre en place une procédure permettant de vérifier que l'application concernée l'objet de la promotion relève d'une gestion légitime des appareils d'entreprise déjà configurée dans la solution propriétaire, disposer des droits équivalents en tant que "Propriétaire de l'appareil".
• [C-2-2] DOIT afficher la même mention de consentement du propriétaire de l'appareil AOSP que flux lancé par android.app.action.PROVISION_MANAGED_DEVICE avant d'enregistrer l'application DPC en tant que "Device Owner" (Propriétaire de l'appareil).
• PEUT disposer de données utilisateur sur l'appareil avant l'enregistrement de l'application DPC. "Propriétaire de l'appareil".

3.9.1.2 Provisionnement des profils gérés

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

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

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

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

  • Une icône cohérente ou toute autre affordance de l'utilisateur (par exemple, l'élément en amont l'icône d'information AOSP) pour indiquer quand un paramètre spécifique est limité par un administrateur de périphériques.
  • Brève explication fournie par l'administrateur de l'appareil via le setShortSupportMessage
  • Icône de l'application DPC.

• [C-1-4] DOIT lancer le gestionnaire pour ACTION_PROVISIONING_SUCCÈS dans le profil professionnel si un propriétaire de profil est établi le provisionnement est lancé par android.app.action.PROVISION_MANAGED_PROFILE. intent et que le DPC a implémenté le gestionnaire.

• [C-1-5] DOIT envoyer ACTION_PROFILE_PROVISIONING_COMPLETE diffuser au DPC du profil professionnel lorsque le provisionnement est initié par android.app.action.PROVISION_MANAGED_PROFILE l'intention.

• [C-1-6] DOIT envoyer ACTION_GET_PROVISIONING_MODE après le déclenchement du provisionnement du propriétaire du profil, afin que l'application DPC pouvez choisir de devenir propriétaire de l'appareil ou administrateur de profil le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE.

• [C-1-7] DOIT envoyer la déclaration ACTION_ADMIN_POLICY_COMPLIANCE vers le profil professionnel lorsqu'un propriétaire de profil est défini quelle que soit la méthode utilisée, sauf lorsque le provisionnement est déclenché par l'intent android.app.action.PROVISION_MANAGED_PROFILE. L'utilisateur ne doit pas pouvoir continuer dans l'assistant de configuration tant que le profil L'application du propriétaire est terminée.

• [C-1-8] DOIT envoyer ACTION_MANAGED_PROFILE_PROVISIONED diffuser au DPC du profil personnel lorsqu'un propriétaire de profil est établi, quelle que soit la méthode de provisionnement utilisée.

3.9.2 Prise en charge des profils gérés

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

• [C-1-1] DOIT prendre en charge les profils gérés via le android.app.admin.DevicePolicyManager API.
• [C-1-2] DOIT autoriser la création d'un seul profil géré.
• [C-1-3] DOIT utiliser un badge d'icône (semblable au badge de travail en amont AOSP) pour représentent les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur dotés d'un badge. comme "Récents" et Notifications.
• [C-1-4] DOIT afficher une icône de notification (similaire aux tâches AOSP en amont) ) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
• [C-1-6] Lorsqu'un profil géré existe, DOIT afficher une affordance visuelle dans le Intent "Sélecteur" pour permettre à l'utilisateur de transférer l'intent à partir du à l'utilisateur principal, et inversement, si la règle Manette de jeu.
• [C-1-7] Lorsqu'un profil géré existe, DOIT exposer l'utilisateur suivant affordances pour l'utilisateur principal et le profil géré:
  • Données distinctes pour l'utilisation de la batterie, de l'emplacement, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées utilisateur ou un profil géré.
  • Gestion indépendante des applications installées chez l'utilisateur principal ou un profil géré.
  • Gestion indépendante des comptes au sein de l'utilisateur principal ou gérés profil.
• [C-1-8] DOIT s'assurer que le clavier, les contacts et la messagerie sont préinstallés peuvent rechercher des informations sur l'appelant dans le profil (s'il en existe) en plus de ceux du profil principal, si les L'outil de contrôle des règles relatives aux appareils le permet.
• [C-1-9] DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicable à un appareil sur lequel plusieurs utilisateurs sont activés (voir section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.

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

• [C-2-1] DOIT prendre en charge la possibilité de spécifier une réunion distincte sur l'écran de verrouillage les exigences suivantes pour accorder l'accès aux applications exécutées dans un environnement profil uniquement.
  • Les implémentations d'appareils DOIVENT respecter les DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface pour configurer un écran de verrouillage distinct à l'aide d'identifiants associés au profil géré.
  • Les identifiants d'écran de verrouillage du profil géré DOIVENT utiliser les mêmes le stockage et la gestion des identifiants en tant que profil parent, comme indiqué sur le Site du projet Android Open Source
  • Les règles de mot de passe de l'outil DPC DOIT s'appliquer uniquement aux identifiants d'écran de verrouillage du profil géré, sauf appelé sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
• Affichage des contacts du profil géré dans le journal d'appels préinstallé, l'interface utilisateur de l'appel en cours, les appels en cours et les appels manqués des notifications, des contacts et des applications de chat, ils DOIVENT disposer de la mention même badge utilisé pour indiquer les applications de profils gérés.

3.9.3 Assistance aux utilisateurs gérés

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

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

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

• [C-SR-1] Sont FORTEMENT RECOMMANDÉS affichent le même consentement "Propriétaire de l'appareil AOSP" qui ont été divulguées lors du processus initié par android.app.action.PROVISION_MANAGED_DEVICE avant d'autoriser l'ajout de comptes dans le nouvel utilisateur secondaire, afin que les utilisateurs comprennent que l'appareil est géré.

3.10. Accessibilité

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

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

• [C-1-1] DOIT fournir une implémentation de la fonctionnalité d'accessibilité Android tel que décrit dans le API d'accessibilité Documentation du SDK.
• [C-1-2] DOIT générer des événements d'accessibilité et fournir les AccessibilityEvent à tous les enregistrements AccessibilityService comme indiqué dans le SDK.
• [C-1-4] DOIT fournir une affordance à l'utilisateur pour contrôler l'accessibilité services qui déclarent le AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BOUTON pour en savoir plus. Notez que pour les implémentations d'appareil dotées d'une barre de navigation système, elles DEVRAIT permettre à l'utilisateur d'avoir la possibilité d'utiliser un bouton dans le barre de navigation pour contrôler ces services.

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

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

3.11. Synthèse vocale

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

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

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

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

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

3.12. Framework d'entrée TV

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

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

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

3.13. Réglages rapides

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

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

• [C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les vignettes fournies via le quicksettings les API d'une application tierce.
• [C-1-2] NE DOIT PAS ajouter automatiquement une carte depuis une application tierce directement accédez aux Réglages rapides.
• [C-1-3] DOIT afficher toutes les vignettes ajoutées par l'utilisateur depuis des applications tierces en plus des blocs de configuration rapide fournis par le système.

3.14. Interface utilisateur multimédia

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

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

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

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

• [C-1-5] DOIT prendre en compte le fait d'appuyer deux fois sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE en tant que KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

Si les implémentations d'appareils sont compatibles avec les applis instantanées, celles-ci DOIVENT respecter les conditions suivantes configuration requise:

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

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

  • [C-1-5] DOIT fournir une affordance utilisateur pour afficher et supprimer les applis instantanées mis en cache localement pour chaque package d'application individuel.
  • [C-1-6] DOIT fournir une notification persistante à l'utilisateur réduit lorsqu'une appli instantanée est exécutée au premier plan. Cet utilisateur DOIT inclure la notification indiquant que les applis instantanées ne nécessitent pas d'installation et fournissent une affordance de l'utilisateur qui le dirige vers l'application dans les paramètres. Pour les applis instantanées lancées via des intents Web, comme défini à l'aide d'un intent avec l'action définie sur Intent.ACTION_VIEW et avec un schéma "http" ou "https", une affordance pour l'utilisateur DEVRAIT permettre à l'utilisateur de ne pas lancer l'appli instantanée et lancer le lien associé au navigateur Web configuré, si un navigateur est disponible sur l'appareil.
  • [C-1-7] DOIT autoriser l'accès aux applis instantanées en cours d'exécution depuis l'application si la fonction Récents est disponible sur l'appareil.

• [C-1-8] DOIT précharger un ou plusieurs composants d'applications ou de services Avec un gestionnaire d'intents pour les intents répertoriés dans le SDK, cliquez ici. et rendre les intents visibles pour les applis instantanées.

3.16. Association d'un appareil associé

Android prend en charge l'association d'appareils associés pour une gestion plus efficace associée à des appareils associés et fournit le CompanionDeviceManager API permettant aux applis d'accéder à cette fonctionnalité.

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

• [C-1-1] DOIT déclarer le flag de fonctionnalité FEATURE_COMPANION_DEVICE_SETUP pour en savoir plus.
• [C-1-2] DOIT s'assurer que les API du android.companion package soit entièrement implémenté.
• [C-1-3] DOIT fournir des affordances à l'utilisateur pour sélectionner/confirmer une annonce associée est présent et opérationnel.

3.17. Applications lourdes

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

• [C-1-1] DOIT disposer d'une seule application installée spécifiant cantSaveState exécutées dans le système à un moment donné. Si l'utilisateur quitte une application sans la quitter explicitement (par exemple, en appuyant sur tout en laissant une activité active dans le système, au lieu d'appuyer sur et qu'il ne reste aucune activité active dans le système), les implémentations d'appareils DOIVENT donner la priorité à cette application dans la RAM, comme c'est le cas pour les autres éléments qui doivent rester en cours d'exécution, tels que les services de premier plan. Lorsqu'une application de ce type est exécutée en arrière-plan, le système peut quand même mettre l'appareil sous tension des fonctionnalités de gestion, comme la limitation de l'accès au CPU et au réseau.
• [C-1-2] DOIT fournir une affordance d'UI pour choisir l'application qui ne participer au mécanisme normal d'enregistrement/restauration de l'état une fois que l'utilisateur lance une deuxième application déclarée avec cantSaveState. .
• [C-1-3] NE DOIT PAS appliquer d'autres modifications du règlement aux applications qui spécifient cantSaveState, comme la modification des performances du processeur ou la modification de la hiérarchisation de la planification.

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

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

3.18. Contacts

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

RawContacts sont "associés à" ; ou "stocké dans" une Compte lorsque ACCOUNT_NAME, et ACCOUNT_TYPE, les colonnes des contacts bruts correspondent aux Nom.du.compte et Type.compte du compte.

Default local account (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ées à un compte dans le AccountManager, qui sont créé avec des valeurs null ACCOUNT_NAME, et ACCOUNT_TYPE, colonnes.

Compte local personnalisé: compte pour les contacts bruts qui ne sont stockés que sur le appareil et non associées à un compte dans le gestionnaire de comptes, qui sont créé avec au moins une valeur non nulle pour le paramètre ACCOUNT_NAME, et ACCOUNT_TYPE, colonnes.

Implémentations pour les appareils:

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

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

• [C-1-1] Le ACCOUNT_NAME, du compte local personnalisé DOIT être renvoyé avant le ContactsContract.RawContacts.getLocalAccountName
• [C-1-2] Le ACCOUNT_TYPE, du compte local personnalisé DOIT être renvoyé avant le ContactsContract.RawContacts.getLocalAccountType
• [C-1-3] 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 la requête locale personnalisée compte.
• [C-1-4] Les contacts bruts insérés dans le compte local personnalisé NE DOIVENT pas être supprimés lors de l'ajout ou de la suppression de comptes.
• [C-1-5] Supprimer les opérations effectuées sur le compte local personnalisé DOIT entraîner la suppression immédiate et définitive des contacts bruts (comme si CALLER_IS_SYNCADAPTER a été défini sur "true"), même si le paramètre CALLER\_IS\_SYNCADAPTER a été défini. sur "false" ou non spécifié.

4. Compatibilité avec les packages d'applications

Implémentations pour les appareils:

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

Implémentations pour les appareils:

• [C-0-2] DOIT prendre en charge la validation des fichiers ".apk" à l'aide de la propriété APK Signature Scheme v3 , APK Signature Scheme v2 et la signature JAR.
• [C-0-3] NE DOIT PAS étendre la .apk Fichier manifeste Android, bytecode Dalvik ; ou les formats de bytecode RenderScript d'une manière qui empêche ces fichiers installée et fonctionnant correctement sur d'autres appareils compatibles.

• [C-0-4] NE DOIT PAS autoriser d'applications autres que la version actuelle "programme d'installation de l'enregistrement" pour que le package désinstalle l'application sans notification Confirmation de l'utilisateur, comme indiqué dans le SDK pour la DELETE_PACKAGE l'autorisation. Les seules exceptions sont la gestion par l'application de l'outil de vérification des packages système PACKAGE_NEEDS_VERIFICATION et l'application de gestionnaire d'espace de stockage qui gère ACTION_MANAGE_STORAGE l'intention.

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

• [C-0-6] NE DOIT PAS installer de packages d'applis inconnus sources, sauf si l'application qui demande l'installation remplit toutes les conditions suivantes:

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

• DEVRAIT fournir une affordance à un utilisateur pour accorder/révoquer l'autorisation de d'installer par application des applications provenant de sources inconnues, mais PEUVENT choisir de les implémenter comme no-op et renvoyer RESULT_CANCELED pour startActivityForResult(). si l'implémentation de l'appareil ne veut pas permettre aux utilisateurs d'avoir ce choix. Cependant, même dans de tels cas, elles DOIVENT indiquer à l'utilisateur pourquoi il n'y a pas ce choix présenté.

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

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

• [C-0-8] DOIT mettre en œuvre la prise en charge du système de fichiers incrémentiel, tel que documenté cliquez ici.

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

Remarque :Implémentations d'appareils livrées sur Android 10 ou version antérieure qui ne peuvent pas répondre aux exigences du [C-0-8] et du [C-0-9] par le biais d'un logiciel système. mise à jour PEUVENT être exemptées de ces exigences.

5. Compatibilité multimédia

Implémentations pour les appareils:

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

Implémentations pour les appareils:

• DEVRAIT avoir une latence minimale du codec. En d'autres termes,
  • NE DEVRAIT PAS consommer ni stocker des tampons d'entrée, et renvoyer uniquement des tampons d'entrée une fois le traitement effectué.
  • NE DEVRAIT PAS conserver sur les tampons décodés plus longtemps que spécifié par le standard (SPS, par exemple).
  • NE DOIT PAS conserver sur les tampons encodés plus longtemps que requis par le GOP structure.

Tous les codecs répertoriés dans la section ci-dessous sont fournis en tant que logiciels dans l'implémentation Android préférée d'Android Open Projet source.

Notez que ni Google ni l'Open Handset Alliance ne que ces codecs sont dépourvus de brevets tiers. Ces si l'on a l'intention d'utiliser ce code source dans des produits matériels ou logiciels, que les implémentations de ce code, y compris dans les logiciels Open Source ou shareware, peut exiger des licences de brevet des détenteurs de brevets concernés.

5.1. Codecs multimédias

5.1.1. Encodage audio

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

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

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

Tous les encodeurs audio DOIVENT prendre en charge:

• [C-3-1] Trames audio PCM natives ordonnées en 16 bits via android.media.MediaCodec API.

5.1.2. Décodage audio

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

Si les implémentations d'appareils déclarent la prise en charge du android.hardware.audio.output, ils doivent être compatibles avec le décodage formats audio suivants:

• [C-1-1] Profil MPEG-4 AAC (AAC LC)
• [C-1-2] Profil MPEG-4 HE AAC (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
• [C-1-4] AAC ELD (AAC à faible décalage amélioré)
• [C-1-11] Profil xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile), qui comprend : le profil de référence de l'USAC et la plage dynamique ISO/IEC 23003-4 profil de contrôle)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE avec audio haute résolution jusqu'à 24 bits, un 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é à sous-échantillonner et à réduire le mixage pendant la phase de lecture.
• [C-1-10] Opus

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

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

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

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

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

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

Si la norme ISO/IEC 23003-4 est acceptée, et si ISO/IEC 23003-4 et Les métadonnées ISO/IEC 14496-3 sont présentes dans un flux de bits décodé, alors:

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

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

• [C-6-1] Trames audio PCM natives classées en fonction des octets 16 bits via le android.media.MediaCodec API.

5.1.3. Détails des codecs audio

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

5.1.4. Encodage d'image

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

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

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

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

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

5.1.5. Décodage d'images

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

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

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

Si les implémentations d'appareils sont compatibles avec le décodage vidéo HEVC, elles:

• [C-1-1] DOIT être compatible avec le décodage d'image HEIF (HEIC).

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

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

5.1.6. Détails des codecs image

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

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

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

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

• [C-1-3] DOIT prendre en charge au moins l'un des types planaires ou semi-planaires Format de couleurs YUV420 8:8:8: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Ils sont FORTEMENT RECOMMANDÉS les deux.

5.1.7. Codecs vidéo

• Qualité acceptable pour le streaming vidéo Web et la visioconférence services, les implémentations d'appareils DOIVENT utiliser un codec matériel VP8 conforme au exigences.

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

• [C-1-1] Les codecs vidéo DOIVENT prendre en charge les tailles de mémoire tampon d'octets de sortie et d'entrée pour prendre en charge la plus grande trame compressée et non compressée possible, par le standard et la configuration, mais sans surallouer non plus.

• [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge la couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) à CodecCapabilities.

• [C-1-3] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge au moins l'un des types de plans format de couleurs YUV420 semi-plan 8:8:8: COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ de les accepter dans les deux cas.

• [SR-1] Les encodeurs et décodeurs vidéo SONT FORTEMENT RECOMMANDÉS au moins un format YUV420 planaire ou semi-plan optimisé pour le matériel, couleur 8:8:8 (YV12, NV12, NV21 ou un format équivalent optimisé par les fournisseurs).

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

Si les implémentations d'appareils font la publicité de la prise en charge des profils HDR via Display.HdrCapabilities, ils:

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

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

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

Sauf indication contraire de l'application, utiliser KEY_COLOR_FORMAT clé de formatage, implémentations de décodeur vidéo:

• [C-4-1] DOIT utiliser par défaut le format de couleur optimisé pour l'affichage matériel si elle est configurée à l'aide de la sortie de la surface.
• [C-4-2] DOIT utiliser par défaut un format de couleurs YUV420 8:8:8 optimisé pour le processeur si elle est configurée pour ne pas utiliser la sortie de la surface.

5.1.8. Liste des codecs vidéo

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

5.1.9. Sécurité du codec multimédia

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

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

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

• [C-1-1] DOIT prendre en charge les codecs multimédias via OMX ou Codec 2.0 (ou les deux), comme dans le projet Android Open Source, et qui ne peuvent pas désactiver contournent les protections de sécurité. Cela ne signifie pas nécessairement le codec DOIT utiliser l'API OMX ou Codec 2.0, uniquement pour prendre en charge au moins l'une de ces API DOIT être disponible, et la prise en charge de ces API DOIT être disponible inclure les protections de sécurité existantes.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de l'API Codec 2.0.

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

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

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

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

5.1.10. Caractérisation du codec multimédia

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

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

En particulier :

• [C-1-2] Codecs dont le nom commence par "OMX". OBLIGATOIRE D'utiliser les API OMX et dont les noms sont conformes aux directives OMX IL.
• [C-1-3] Codecs dont le nom commence par "c2". DOIT utiliser l'API Codec 2.0 et ont des noms conformes aux directives de dénomination du Codec 2.0 pour Android.
• [C-1-4] Codecs dont le nom commence par "OMX.google" ou "c2.android". OBLIGATOIRE Ne doit PAS être caractérisé par un fournisseur ou une accélération matérielle.
• [C-1-5] Les codecs qui s'exécutent dans un processus de codec (fournisseur ou système) l'accès aux pilotes de matériel autres que les outils d'allocation de mémoire et les mappeurs NE DOIT PAS être qualifiées uniquement de logiciels.
• [C-1-6] Codecs absents ou non du projet Android Open Source sur le code source de ce projet DOIT être défini comme fournisseur.
• [C-1-7] Les codecs qui utilisent l'accélération matérielle DOIVENT être caractérisés avec l'accélération matérielle.
• [C-1-8] Les noms de codec NE DOIVENT PAS être trompeurs. Par exemple, les codecs nommés "décodeurs" DOIT prendre en charge le décodage, et ceux nommés "encodeurs" DOIT prendre en charge l'encodage. Les codecs dont les noms contiennent des formats multimédias DOIVENT prendre en charge ces .

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

• [C-2-1] Tous les codecs vidéo DOIVENT publier des données de fréquence d'images atteignables pour les tailles suivantes si le codec le permet:

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

• [C-2-2] Les codecs vidéo caractérisés par une accélération matérielle DOIVENT publier des informations sur les points de performance. Chacune doit OBLIGATOIREMENT être listée points de performance standards (répertoriés dans PerformancePoint) API), sauf si elles sont couvertes par un autre point de performance standard pris en charge.
• De plus, ils DOIVENT publier des points de performance étendus s'ils d'enregistrer des performances vidéo durables autres que celles standards répertoriées.

5.2. Encodage vidéo

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

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

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

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

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

• [C-2-1] DOIT être compatible avec les débits configurables dynamiquement.
• DEVRAIT prendre en charge des fréquences d'images variables, où l'encodeur vidéo DOIT déterminer une durée de frame instantanée en fonction des codes temporels des tampons d'entrée alloue son bucket de bits en fonction de cette durée de trame.

Si les implémentations d'appareils prennent en charge l'encodeur vidéo MPEG-4 SP et l'envoient disponibles pour les applications tierces:

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

Si les implémentations d'appareils fournissent des encodeurs vidéo ou d'image avec accélération matérielle, et prendre en charge une ou plusieurs caméras branchées ou branchées 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 à partir des caméras matérielles.
• DEVRAIT prendre en charge l'encodage des images de la ou des caméras matérielles tout au long de la vidéo ou encodeurs d'images.

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

• [C-SR-1] est VIVEMENT RECOMMANDÉ de fournir un plug-in pour API de transcodage transparente pour la conversion du format HDR au format SDR.

5.2.1. H.263

Si les implémentations d'appareils sont compatibles avec les encodeurs H.263 et le rendent disponible à des applications tierces:

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

5.2.2. H.264

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

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

Si les configurations d'appareils indiquent que l'encodage H.264 est compatible avec les formats 720p ou 1080p de résolution vidéo via les API multimédias, ils:

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

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

5.2.3. VP8

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

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

Si les configurations d'appareils indiquent que l'encodage VP8 est compatible avec 720p ou 1080p de résolution vidéo via les API multimédias, ils:

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

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

5.2.4. VP9

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

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

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

Si des mises en œuvre d'appareils prétendent être compatibles avec le Profil 2 ou le Profil 3 via le API multimédias:

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

5.2.5. H265

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

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

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

5.3. Décodage vidéo

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

• [C-2-1] DOIT être compatible avec les profils de décodage vidéo HD 720p dans les éléments suivants : tableau.
• [C-2-2] DOIT être compatible avec les profils de décodage vidéo HD 1080p dans les éléments suivants : tableau.

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

5.3.5. H.265 (HEVC)

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

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

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

• [C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec au moins une norme H.265 ou VP9 décodage des profils 720, 1080 et UHD.

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

Si des appareils affirment être compatibles avec un profil HDR via le support API:

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

5.3.6. VP8

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

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

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

• [C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec les profils 720p dans le tableau suivant.
• [C-2-2] Les implémentations d'appareils DOIVENT être compatibles avec les profils 1080p dans le tableau suivant.

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

5.3.7. VP9

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

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

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

• [C-2-1] DOIT être compatible avec les profils de décodage HD, comme indiqué ci-dessous tableau.

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

• [C-3-1] Les implémentations d'appareils DOIVENT être compatibles avec au moins un code VP9 ou H.265 le décodage des profils 720, 1080 et UHD.

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

Si des intégrations d'appareils affirment être compatibles avec VP9Profile2 ou VP9Profile3 via l'élément "CodecProfileLevel" API multimédias:

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

Si des appareils sont compatibles avec un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via la 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) depuis 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 l'écran d'un appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

Si les implémentations d'appareils déclarent prendre en charge le décodeur Dolby Vision via HDR_TYPE_DOLBY_VISION , ils:

• [C-1-1] DOIT fournir un extracteur compatible Dolby Vision.
• [C-1-2] DOIT afficher correctement le contenu Dolby Vision sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).
• [C-1-3] DOIT définir l'index de piste de la ou des couches de base rétrocompatibles (si présent) doit être identique à l'index de suivi combiné de la couche Dolby Vision.

5.3.9. AV1

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

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

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient énumérées comme DEVRAIT. depuis Android 4.3, la définition de compatibilité pour les versions futures pour les remplacer par OBLIGATOIRE. Les appareils Android nouveaux et existants sont fortement RECOMMANDÉ de répondre aux exigences listées comme DEVRAIT, ou ne pourront pas assurer la compatibilité avec Android lors de leur mise à niveau. version.

5.4.1. Capture audio brute et informations sur le micro

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

• [C-1-1] DOIT autoriser la capture de contenu audio brut avec les éléments suivants : caractéristiques:

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

• DEVRAIT permettre de capturer du contenu audio brut avec les éléments suivants : caractéristiques:

  • 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, 48000 Hz
  • Canaux: il y a autant de canaux que de micros sur la appareil

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

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

• DEVRAIT autoriser la capture radio AM et DVD de qualité audio brute, ce qui désigne les caractéristiques suivantes:

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

• [C-1-4] DOIT respecter l'API MicrophoneInfo et indiquer correctement les informations concernant les micros disponibles sur l'appareil accessibles aux applications tierces AudioManager.getMicrophones() et les micros actifs qui sont accessibles au troisième applications tierces via le AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones() API. Si les configurations d'appareils permettent une capture radio AM et DVD de qualité audio brute contenu, elles:

• [C-2-1] DOIT enregistrer sans suréchantillonnage à un ratio supérieur que 16000:22050 ou 44100:48000.

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

5.4.2. Capturer pour la reconnaissance vocale

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

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

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

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

5.4.3. Capturer pour réacheminer la lecture

La classe android.media.MediaRecorder.AudioSource inclut l'élément REMOTE_SUBMIX. source audio.

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

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

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

5.4.4. Annulateur d'écho acoustique

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

• DEVRAIT implémenter un annulant d'écho acoustique (AEC) calibrée pour la communication vocale et appliquée au chemin de capture lors de la capture avec AudioSource.VOICE_COMMUNICATION

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

• Les [C-SR-1] doivent le déclarer via AcousticEchoCanceler. Méthode API AcousticEchoCanceler.isAvailable()
• [C-SR-2] sont STRONGLY_RECOMMENDED pour que cet effet audio soit pouvoir être contrôlées à l'aide de la classe AcousticEchoCanceler. API.
• Les [C-SR-3] ont pour vocation d'identifier de façon unique chaque technologie AEC. via la classe AudioEffect.Descriptor.uuid .

5.4.5. Capture simultanée

Si les intégrations d'appareils déclarent android.hardware.microphone,ils 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é la capture de service avec AudioSource.VOICE_RECOGNITION et au moins un la capture d'application avec n'importe quel AudioSource.
• [C-1-2] DOIT autoriser l'accès simultané au micro par un appareil application ayant un rôle d'Assistant et au moins une application la capture avec n'importe quel élément AudioSource, sauf AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
• [C-1-3] DOIT couper le son de la capture audio pour toute autre application, sauf un service d'accessibilité, tandis qu'une application capture AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsque une application capture via AudioSource.VOICE_COMMUNICATION, puis une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec autorisation CAPTURE_AUDIO_OUTPUT.
• [C-1-4] Si plusieurs applications capturent simultanément aucune des deux applications n'a d'interface utilisateur, celle qui a commencé à capturer la dernière fois reçoit le son.

5.4.6. Niveaux de gain du micro

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

• DEVRAIT présenter une amplitude-fréquence approximativement plate caractéristiques moyennes dans la plage de fréquences moyennes: ±3 dB à partir de 100 à 4 000 Hz pour chacun des micros utilisés pour enregistrer la voix. source audio de reconnaissance.
• DEVRAIT régler la sensibilité d'entrée audio de sorte qu'une sinusoïdale de 1 000 Hz la source de tonalité lue à un niveau de pression acoustique (SPL) de 90 dB génère une réponse avec un RMS de 2 500 pour les échantillons de 16 bits (ou une valeur réelle de -22,35 dB pour le trafic flottant) échantillon de points/de précision à double précision) pour chaque micro utilisé pour pour enregistrer la source audio utilisée pour la reconnaissance vocale.
• Il est FORTEMENT RECOMMANDÉ d'utiliser [C-SR-1] pour montrer des niveaux d'amplitude dans les basses plage de fréquences: spécifiquement de ±20 dB de 5 Hz à 100 Hz, à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.
• Il est FORTEMENT RECOMMANDÉ d'utiliser les [C-SR-2] pour montrer des niveaux d'amplitude dans le Plage haute fréquence: spécifiquement de ±30 dB de 4 000 Hz à 22 kHz par rapport à la plage de fréquences moyennes pour chaque micro utilisé pour enregistrer la source audio de reconnaissance vocale.

5.5. Lecture audio

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

5.5.1. Lecture audio brute

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

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

  • Formats sources: PCM linéaire, 16 bits, 8 bits, float
  • Canaux: configurations mono, stéréo et multicanaux valides avec jusqu'à huit chaînes
  • Taux d'échantillonnage (en Hz):
    • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 au niveau du canal configurations listées ci-dessus
    • 96 000 en mono et stéréo

5.5.2. Effets audio

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

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

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

5.5.3. Volume de sortie audio

Implémentations pour les appareils automobiles:

• DEVRAIT permettre de régler le volume audio séparément pour chaque flux audio, en fonction du type ou de l'utilisation de contenu définis par AudioAttributes et l'utilisation de l'audio dans les voitures, telle que définie publiquement dans android.car.CarAudioManager.

5.5.4. Déchargement audio

Si les appareils sont compatibles avec la lecture de déchargement audio, ils:

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

5.6. Latence audio

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

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

• latence de sortie. L'intervalle entre le moment où une application écrit un frame des données codées PCM et le moment où le son correspondant est présenté à l'environnement sur un transducteur de l'appareil ou un signal quitte l'appareil via un port et peut être observées en externe.
• latence de sortie à froid. Délai entre le démarrage d'un flux de sortie et le temps de présentation de la première image en fonction des codes temporels, lorsque la sortie audio le système a été inactif et éteint avant la demande.
• latence de sortie continue. la latence de sortie des frames suivants après que l'appareil lit du contenu audio.
• la latence d'entrée. L'intervalle entre le moment où un son est présenté par l'environnement à l'appareil au niveau d'un transducteur intégré ou le signal entre dans l'appareil via un port et lorsqu’une application lit la trame correspondante de données codées PCM.
• perd input. La partie initiale d'un signal d'entrée inutilisable ou indisponible.
• latence d'entrée à froid. Délai entre le démarrage de la diffusion et le moment où la première trame valide est reçue, lorsque le système d'entrée audio est inactif et mis hors tension avant la requête.
• latence d'entrée continue. La latence d'entrée pour les frames suivants pendant la capture audio.
• gigue de sortie à froid. La variabilité entre les différentes mesures du froid les valeurs de latence de sortie.
• gigue d'entrée à froid. La variabilité entre les différentes mesures du froid les valeurs de latence d'entrée.
• la latence aller-retour continue. La somme de la latence d'entrée continue plus une latence de sortie continue plus une période de tampon. La période tampon permet temps nécessaire à l'application pour traiter le signal et temps nécessaire pour atténuer la phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon OpenSL ES PCM L'ensemble des mesures liées à la protection contre la perte de données OpenSL ES API dans le NDK Android
• API audio native AAudio : L'ensemble des API AAudio dans Android NDK.
• Code temporel : Paire composée d'une position de cadre relative dans une et l'heure estimée à laquelle cette image rejoint ou quitte le flux de traitement audio sur le point de terminaison associé. Voir aussi AudioTimestamp :
• glitch. Une interruption temporaire ou une valeur d'échantillon incorrecte dans le signal audio généralement causée par sous-exécution de la mémoire tampon pour la sortie, une surcharge de la mémoire tampon pour les entrées ou toute autre source de bruit numérique ou analogique.
• écart absolu moyen. La moyenne de la valeur absolue de des écarts par rapport à la moyenne d'un ensemble de valeurs.
• latence "appuyer sur ton". Délai entre le moment où l'utilisateur appuie sur l'écran et celui où une tonalité générée à la suite de cet appui est entendue sur l'enceinte.

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

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

Si les implémentations d'appareils déclarent android.hardware.audio.output, elles sont VIVEMENT RECOMMANDÉ pour répondre aux exigences suivantes, voire les dépasser:

• [C-SR-1] Latence de sortie à froid de 100 millisecondes ou moins sur les données du locuteur chemin d'accès. Les appareils nouveaux et existants qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉ de répondre à ces exigences dès maintenant. Sur une future plate-forme nous exigeons une latence de sortie à froid de 200 ms ou moins comme OBLIGATOIRE.
• [C-SR-2] Latence maximale de 80 millisecondes au maximum.
• [C-SR-3] Minimiser la gigue à la sortie à froid
• [C-SR-4] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp a une précision de +/- 1 ms.

Si les implémentations d'appareils répondent aux exigences ci-dessus, calibrage, lors de l'utilisation de l'API audio native AAudio, pour une sortie continue et la latence de sortie à froid sur au moins un fichier audio compatible périphérique de sortie:

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

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

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

Si les implémentations d'appareils incluent android.hardware.microphone, ils DOIT respecter ces exigences audio d'entrée:

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

Si les implémentations d'appareils incluent android.hardware.microphone, elles sont VIVEMENT RECOMMANDÉ pour répondre à ces exigences audio d'entrée:

• [C-SR-8] Latence d'entrée froide de 100 millisecondes ou moins au-dessus du micro chemin d'accès aux données. Les appareils nouveaux et existants qui exécutent cette version d'Android sont TRÈS FORTEMENT RECOMMANDÉ de répondre à ces exigences dès maintenant. Dans un futur version de la plate-forme, nous exigerons une latence d'entrée à froid de 200 ms ou moins, car C'est un OBLIGATOIRE.
• [C-SR-9] Latence d'entrée continue inférieure ou égale à 30 millisecondes.
• [C-SR-10] Réduisez la gigue de l'entrée à froid.
• [C-SR-11] Limite l'erreur dans les horodatages d'entrée renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

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

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

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT être compatibles avec médias réseau pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android.

Pour chaque codec et format de conteneur qu'une implémentation d'appareil est requise pour l'implémentation de l'appareil:

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

• [C-1-2] DOIT prendre en charge les formats de segments multimédias correspondants, dans le tableau des formats des segments multimédias ci-dessous Brouillon de protocole HTTP Live Streaming, version 7

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

Formats des segments média

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

RTSP (RTP, SDP)

Nom du profil	Référence(s)	Compatibilité avec le codec requise
H264 AVC	RFC 6184	Voir la section 5.1.8 pour en savoir plus sur H264 AVC
MP4A-LATM	RFC 6416	Voir la section 5.1.3. pour en savoir plus sur AAC et ses variantes
H263-1998	RFC 3551 RFC 4629 RFC 2190	Voir la section 5.1.8 pour en savoir plus sur l'algorithme H263
H263-2000	RFC 4629	Voir la section 5.1.8 pour en savoir plus sur l'algorithme H263
AMR	RFC 4867	Voir la section 5.1.3. pour en savoir plus sur AMR-NB
AMR-WB	RFC 4867	Voir la section 5.1.3. pour en savoir plus sur AMR-WB
MP4V-ES	RFC 6416	Voir la section 5.1.8 pour en savoir plus sur MPEG-4 SP
mpeg4 générique	RFC 3640	Voir la section 5.1.3. pour en savoir plus sur AAC et ses variantes
MP2T	RFC 2250	Pour en savoir plus, consultez la section Flux de transport MPEG-2 sous la diffusion HTTP en direct.

5.8. Secure Media

Si les implémentations d'appareils prennent en charge la sortie vidéo sécurisée et sont capables de des surfaces sécurisées:

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

Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE et de l'assistance protocole d'affichage sans fil, ils:

• [C-2-1] DOIT sécuriser le lien au moyen d'un mécanisme cryptographiquement sécurisé, comme HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil comme Miracast.

Si les implémentations d'appareils déclarent la prise en charge de Display.FLAG_SECURE et sont compatibles avec les écrans externes filaires:

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

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

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

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

  • Mode hôte USB, section 7.7
  • MIDI via Bluetooth LE agissant en tant que rôle central, section 7.4.3

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

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

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

5.10. Audio professionnel

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

• [C-1-1] DOIT signaler la prise en charge de la fonctionnalité android.hardware.audio.low_latency
• [C-1-2] DOIT disposer d'une latence audio aller-retour continue, telle que définie dans Section 5.6 Audio Latency, DOIT être inférieure ou égale à 20 millisecondes et DOIT être de 10 millisecondes ou moins sur au moins un chemin pris en charge.
• [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et mode périphérique.
• [C-1-4] DOIT signaler la prise en charge de la fonctionnalité android.software.midi.
• [C-1-5] DOIT respecter les latences et les exigences audio USB Audio natif AAudio API.
• [C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
• [C-1-7] DOIT avoir une latence d'entrée à froid de 200 millisecondes ou moins.
• [C-SR-1] Sont FORTEMENT RECOMMANDÉS pour respecter les latences telles que définies dans la section 5.6 Latence audio, de 20 millisecondes ou inférieur, plus de 5 mesures avec un écart absolu moyen inférieur à 5 de millisecondes sur le chemin du haut-parleur jusqu'au micro.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de respecter les exigences concernant l'audio Pro pour latence audio aller-retour continue, latence d'entrée à froid et sortie à froid et les exigences audio USB via l'API AAudio native audio sur le chemin d'accès MMAP.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de fournir un niveau de processeur constant les performances lorsque l'audio est actif et que la charge du processeur varie. Cela doit être testé à l'aide de l'application Android SynthMark. SynthMark utilise un synthétiseur logiciel qui s'exécute sur un framework audio simulé qui mesure les performances du système. L'application SynthMark doit être exécutée à l'aide du "Test automatisé" et obtenir les résultats suivants:
  • voicemark.90 >= 32 voix
  • latencemark.Fix.little <= 15 ms
  • latencemark.dynamic.little <= 50 ms

Consultez la documentation SynthMark pour en savoir plus sur les benchmarks.

• DOIT minimiser les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.
• DEVRAIT minimiser la dérive de l'horloge audio par rapport au CPU CLOCK_MONOTONIC lorsque les deux sont actifs.
• DEVRAIT minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil.
• DEVRAIT minimiser la latence audio sur l'audio numérique USB.
• DEVRAIT documenter les mesures de latence audio sur tous les chemins.
• DEVRAIT réduire la gigue des temps d'entrée du rappel d'achèvement du tampon audio, car cela affecte le pourcentage utilisable de la bande passante totale du processeur par le rappel.
• DEVRAIT ne fournir aucun problème audio dans des conditions d'utilisation normale et avec une latence signalée.
• DEVRAIT ne fournir aucune différence de latence entre les canaux.
• DEVRAIT minimiser la latence moyenne MIDI sur tous les transports.
• DEVRAIT minimiser la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.
• DEVRAIT fournir des horodatages MIDI précis pour tous les transports.
• DOIT minimiser le bruit du signal audio sur les transducteurs intégrés à l'appareil, y compris les juste après le démarrage à froid.
• DEVRAIT ne fournir aucune différence d'horloge audio entre les côtés d'entrée et de sortie de les points de terminaison correspondants, quand les deux sont actifs. Exemples de messages comme le micro et le haut-parleur de l'appareil, ou l'entrée du connecteur audio et la sortie.
• DEVRAIT gérer les rappels de complétion du tampon audio pour les côtés entrée et sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et saisissez le rappel de sortie juste après le retour du rappel d'entrée. Ou s'il n'est pas possible de gérer les rappels sur le même thread, saisissez rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à une temporisation cohérente des côtés d'entrée et de sortie.
• DOIT minimiser la différence de phase entre la mise en mémoire tampon de l'audio HAL pour l'entrée et de sortie des points de terminaison correspondants.
• DEVRAIT minimiser la latence tactile.
• DEVRAIT minimiser la variabilité de la latence tactile en cas de charge (gigue).
• DEVRAIT avoir une latence entre l'entrée tactile et la sortie audio inférieure ou égale à égale à 40 ms.

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

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

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

• [C-2-1] DOIT avoir une latence audio aller-retour continue moyenne, telle que définie dans Section 5.6 Audio Latency, de 20 millisecondes ou moins, sur cinq mesures avec une écart absolue moyenne inférieure à 5 millisecondes le chemin du connecteur audio.
• [C-SR-5] VIVEMENT RECOMMANDÉ de respecter les Section Caractéristiques de l'appareil mobile (connecteur) de la spécification de la version 1.1 du casque audio filaire.

Si les appareils ne comprennent pas de connecteur audio 3,5 mm à 4 conducteurs et comprennent un ou plusieurs ports USB compatibles avec le mode hôte USB, ils:

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

Si les appareils incluent un port HDMI, ils:

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

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

Android prend en charge l'enregistrement de contenu audio non traité via le android.media.MediaRecorder.AudioSource.UNPROCESSED source audio. Dans OpenSL ES, il est accessible avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED

Si les implémentations d'appareils ont l'intention de prendre en charge une source audio non traitée pour les applications tierces, celles-ci:

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

• [C-1-2] DOIT présenter une valeur amplitude-fréquence approximativement plate dans la plage des fréquences moyennes: ±10 dB du 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer le contenu non traité source audio.

• [C-1-3] DOIT présenter des niveaux d'amplitude en basse fréquence de ±20 dB de 5 z à 100 Hz, dans une plage de fréquences moyennes pour chaque micro utilisé pour enregistrer source audio non traitée.

• [C-1-4] DOIT présenter des niveaux d'amplitude en fréquence élevée de ±30 dB de 7 000 Hz à 22 kHz, dans une plage de fréquences moyennes pour chaque micro utilisé pour enregistrer source audio non traitée.

• [C-1-5] DOIT définir la sensibilité de l'entrée audio de sorte qu'une courbe sinusoïdale de 1 000 Hz source de tonalités lue à un niveau de pression acoustique (SPL) de 94 dB génère une réponse composée de RMS de 520 pour les échantillons de 16 bits (ou valeur complète de -36 dB pour les valeurs à virgule flottante/double) échantillons de précision) pour chaque micro utilisé pour enregistrer les données non traitées source audio.

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

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

• [C-1-8] Ne doit PAS comporter d'autre traitement de signal (par exemple, (contrôle, filtre passe-haut ou annulation de l'écho) dans un chemin autre qu'un pour atteindre la plage souhaitée. Autrement dit :

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

Toutes les mesures SPL sont effectuées directement à côté du micro testé. Si vous utilisez plusieurs micros, ces exigences s'appliquent aux appareils suivants : chaque micro.

Si les implémentations de l'appareil déclarent android.hardware.microphone, mais ne le faites pas sont compatibles avec les sources audio non traitées:

• [C-2-1] DOIT renvoyer null pour AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) méthode API, pour indiquer correctement l'absence de prise en charge.
• [C-SR-1] est toujours VIVEMENT RECOMMANDÉ de satisfaire à un maximum d'exigences pour le chemin de signal de la source d'enregistrement non traitée.

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

6.1. Outils pour les développeurs

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans SDK.

• Android Debug Bridge (adb)

  • [C-0-2] DOIT prendre en charge adb, comme indiqué dans le SDK Android et le shell. fournies dans AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys cmd stats
  • [C-0-11] DOIT prendre en charge la commande shell cmd testharness. Mise à niveau... des implémentations d'appareils à partir d'une version antérieure d'Android le bloc de données persistant PEUT être exempté de l'instruction C-0-11.
  • [C-0-3] NE DOIT PAS modifier le format ni le contenu du système de l'appareil les événements (batterystats , diskstats, fingerprint, graphicstats, netstats, notification, procstats) consignés via la commande dumpsys.
  • [C-0-10] DOIT enregistrer, sans omission, et faire en sorte que les événements suivants accessible et disponible pour la commande shell cmd stats et Classe d'API système StatsManager.
    • État de premier plan de l'activité modifié
    • Anomalie détectée
    • Fil d'Ariane signalé
    • AppCrashOccured
    • AppStartOccurred (Démarrage de l'application)
    • Niveau de batterie modifié
    • État du mode d'économie de batterie modifié
    • BleScanResultReceived (Résultat reçu)
    • BleScanStateChanged
    • État de facturation modifié
    • DeviceIdleModeStateChanged
    • État du service de premier plan modifié
    • GpsScanStateChanged
    • État du job modifié
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • État de l'écran modifié
    • SyncStateChanged (État de synchronisation modifié)
    • SystèmeElapsedRealtime
    • UidProcessStateChanged
    • État du wakelock modifié
    • Alarme du réveilSure
    • État du verrouillage du Wi-Fi modifié
    • État du verrouillage WifiMulticast modifié
    • État du Wi-Fi modifié
  • [C-0-4] DOIT faire en sorte que le daemon adb côté appareil soit inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer le débogage Android Pont.
  • [C-0-5] DOIT être compatible avec adb sécurisé. Android permet de sécuriser adb. Le service adb sécurisé active adb sur des hôtes authentifiés connus.
  • [C-0-6] DOIT fournir un mécanisme permettant à adb d'être connecté à partir d'un la machine hôte. Plus spécifiquement :

  Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, celles-ci:

  • [C-3-1] DOIT implémenter adb via un réseau local (comme 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, ils:

  • [C-4-1] DOIT comporter la méthode AdbManager#isAdbWifiSupported() renvoient true.

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

  • [C-5-1] DOIT comporter la méthode AdbManager#isAdbWifiQrSupported() renvoient true.

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être pris 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 rendre disponible pour applications à utiliser.

• SysTrace

  • [C-0-9] DOIT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir une couche accessible par l'utilisateur pour activer Systrace.

• Perfetto

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

• Tueur de mémoire faible

  • [C-0-10] DOIT écrire un code Atom LMK_KILL_OCCURRED_FIELD_NUMBER dans le journal statsd lorsqu'une application est arrêtée par le tueur de mémoire faible.

• Tester le mode Harness Si les implémentations de l'appareil sont compatibles avec la commande shell cmd testharness et s'exécute cmd testharness enable, il:

  • [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
  • [C-2-2] DOIT implémenter le mode harnais de test tel que décrit dans Documentation sur le mode Harness de test

Si les implémentations d'appareils indiquent la prise en charge de Vulkan 1.0 ou version ultérieure via le android.hardware.vulkan.version indicateurs de fonctionnalité:

• [C-1-1] DOIT fournir une affordance aux développeurs d'applications pour pouvoir activer/désactiver Couches de débogage GPU
• [C-1-2] DOIT énumérer les couches de débogage GPU dans des bibliothèques fournies par des outils externes (c'est-à-dire qui ne font pas partie de la plate-forme ni package d'application) détecté dans les applications débogables le répertoire de base en acceptent vkEnumerateInstanceLayerProperties(). et vkCreateInstance() méthodes d'API Google Cloud.

6.2. Options pour les développeurs

Android permet aux développeurs de configurer des applications liés au développement.

Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour Options pour les développeurs:

• [C-0-1] DOIT respecter les android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'application Android en amont masque le menu Options du développeur par défaut et permet aux utilisateurs de lancer les Options pour les développeurs après avoir appuyé sept (7) fois dans la section Paramètres > À propos de l'appareil > Élément de menu Build Number (Numéro de version).
• [C-0-2] DOIT masquer les options pour les développeurs par défaut.
• [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas de à une application tierce plutôt qu'à une autre pour permettre aux développeurs Options. DOIT fournir un document ou un site Web visible par le public expliquant comment activer les Options pour les développeurs. Ce document ou ce site Web DOIT pouvoir être référencé sous forme de lien depuis les documents du SDK Android.
• DEVRAIT avoir une notification visuelle continue à l'utilisateur lorsque le développeur Les options sont activées, et la sécurité de l'utilisateur est préoccupante.
• PEUVENT limiter temporairement l'accès au menu d'options pour les développeurs, en en masquant ou en désactivant le menu, afin d'éviter toute distraction dans les cas où le la sécurité de l'utilisateur se préoccupe.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier qui a un API pour les développeurs tiers:

• [C-0-1] La mise en œuvre de l'appareil DOIT mettre en œuvre ce comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel qui est désigné comme facultatif et la mise en œuvre sur l'appareil ne possède pas ce composant:

• [C-0-2] Définitions de classe complètes (telles que documentées par le SDK) pour le composant Les API DOIVENT encore être présentées.
• [C-0-3] Les comportements de l'API DOIVENT être implémentés en tant que no-ops de manière raisonnable mode.
• [C-0-4] Les méthodes API DOIVENT renvoyer des valeurs nulles lorsque le SDK le permet dans la documentation Google Cloud.
• [C-0-5] Les méthodes API DOIVENT renvoyer des implémentations no-op de classes dans lesquelles des valeurs nulles ne sont pas autorisés par la documentation sur les SDK.
• [C-0-6] Les méthodes API NE DOIVENT PAS générer d'exceptions non documentées par le SDK dans la documentation Google Cloud.
• [C-0-7] Les implémentations d'appareils DOIVENT indiquer de manière cohérente la fiabilité du matériel les informations de configuration via getSystemAvailableFeatures() et hasSystemFeature(String) sur le android.content.pm.PackageManager pour la même empreinte de build.

Un exemple type de scénario dans lequel ces exigences s'appliquent est le service API: même sur les appareils autres que des téléphones, la mise en œuvre de ces API doit être raisonnable no-ops.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les éléments et l'UI de l'application. adaptées à l'appareil pour garantir que les applications tierces fonctionnent correctement sur différentes configurations matérielles. sur les écrans compatibles Android sur lesquels tous les appareils peuvent fonctionner, les implémentations d'appareils DOIVENT implémenter ces API correctement et les comportements, comme détaillé dans cette section.

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

• taille physique en diagonale. La distance en pouces entre deux deux opposés les coins de la partie éclairée de l'écran.
• points par pouce (PPP). Nombre de pixels entourés par un tracé linéaire. étendue horizontale ou verticale de 2,5 cm. Lorsque les valeurs PPP sont indiquées, les valeurs horizontales et la résolution verticale (PPP) doivent être comprises dans la plage.
• format. Le rapport entre les pixels de la dimension la plus longue et une plus courte dimension de l’écran. Par exemple, un écran de 480 x 854 pixels 854/480 = 1,779, soit environ "16:9".
• pixel indépendant de la densité (dp). Unité de pixel virtuel normalisée en Écran de 160 ppp, calculé comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

Taille et forme de l'écran

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

Implémentations pour les appareils:

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

  • Appareils pour lesquels Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_WATCH et une taille de small pour la Configuration.screenLayout, DOIT mesurer au moins 426 dp x 320 dp.
  • Appareils indiquant une taille de normal pour le Configuration.screenLayout DOIT être d'au moins 480 dp x 320 dp.
  • Appareils indiquant une taille de large pour le Configuration.screenLayout DOIT comporter au moins 640 dp x 480 dp.
  • Appareils indiquant une taille de xlarge pour le Configuration.screenLayout DOIT être d'au moins 960 dp x 720 dp.

• [C-0-2] DOIT respecter correctement les a déclaré la prise en charge des tailles d'écran via <supports-screens> dans le fichier AndroidManifest.xml, comme dans la documentation du SDK Android.

• PEUVENT disposer d'un ou plusieurs écrans compatibles avec Android aux angles arrondis.

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

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

  • Le rayon des angles arrondis est inférieur ou égal à 38 dp.
  • Lorsqu'une zone de 15 dp par 15 dp est ancrée à chaque angle de la logique au moins un pixel de chaque zone est visible à l'écran.

• DEVRAIT inclure l' affordance de l'utilisateur pour passer au mode d'affichage avec et des coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android qui sont d'écran pliable, ou comporte une charnière pliable entre plusieurs écrans les écrans disponibles pour le rendu d'applications tierces:

• [C-2-1] DOIT implémenter la dernière version stable disponible du API extensions ou la version stable de l'API side-car. à utiliser par la bibliothèque Window Manager Jetpack.

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android qui sont ou qu'il comporte une charnière pliable entre plusieurs écrans. que la charnière ou le pli traverse une fenêtre d'application en plein écran, ils:

• [C-3-1] DOIT indiquer la position, les limites et l'état de la charnière ou du pli ou des API side-car à l'application.

Pour savoir comment implémenter correctement les API side-car ou d'extension, consultez à la documentation publique de Window Manager Jetpack.

Format de l'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour Le ou les écrans compatibles avec Android, ainsi que le format de l'écran logique d'affichage des applications tierces. Cette valeur est déterminée en fonction de la hauteur les valeurs de largeur indiquées via le view.Display API et configuration API, DOIT respecter les exigences suivantes:

• [C-0-1] Implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIT avoir un format inférieur ou égal à à 1.86 (environ 16:9), à moins que l'application ne réponde à l'un des critères suivants conditions:

  • L'appli a déclaré qu'elle était compatible avec un format d'écran plus grand via le android.max_aspect valeur de métadonnées.
  • L'application déclare qu'elle est redimensionnable via android:resizeableActivity .
  • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de android:maxAspectRatio qui limiterait le format autorisé.

• [C-0-3] Implémentations d'appareils avec Configuration.uiMode défini sur Le format de UI_MODE_TYPE_WATCH DOIT être défini sur 1.0 (1:1).

Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour vous aider les développeurs d'applications ciblent les ressources d'application.

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT indiquer une seule des options Densités du framework Android répertoriées DisplayMetrics via l'API DENSITY_DEVICE_STABLE et cette valeur NE DOIT PAS changer à aucun moment ; Toutefois, l'appareil PEUT signaler une densité arbitraire différente selon la configuration de l'affichage les modifications apportées par l'utilisateur (par exemple, la taille d'affichage) après la première démarrer.

• Les implémentations d'appareils DOIVENT définir la densité standard du framework Android numériquement la plus proche de la densité physique de l'écran, sauf si pousse la taille d'écran signalée en dessous de la densité minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement la densité physique se traduit par une taille d’écran plus petite que la plus petite taille d'écran compatible (320 dp), implémentations d'appareils DEVRAIT indiquent la deuxième densité de framework Android standard la plus basse.

S'il existe une affordance pour modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille de l'écran NE DOIT PAS être mise à l'échelle au-delà de 1,5 fois la densité native doivent produire une dimension d'écran minimale efficace inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première échéance atteinte.
• [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle en dessous de 0,85 fois la densité native.
• Pour garantir la facilité d'utilisation et la cohérence des tailles de police, il est RECOMMANDÉ que que les options d'annonces display natives soient adaptées (tout en respectant les limites comme indiqué ci-dessus)
  • S: x 0,85
  • Par défaut: 1x (échelle d'affichage natif)
  • Grande: x 1,15
  • Plus grande: x1,3
  • Plus grande x 1,45

Métriques sur le Réseau Display

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles Android ou sur un ou plusieurs écrans compatibles Android:

• [C-1-1] DOIT indiquer des valeurs correctes pour tous les écrans compatibles avec Android les métriques définies dans API android.util.DisplayMetrics.

Si les implémentations d'appareils n'incluent pas d'écran intégré ou de sortie vidéo, ils:

• [C-2-1] DOIT indiquer les valeurs correctes de l'écran compatible Android comme défini dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer les orientations d'écran compatibles (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins un élément l'orientation. Par exemple, un appareil avec une orientation fixe en mode paysage un écran, tel qu'un téléviseur ou un ordinateur portable, DEVRAIT uniquement signaler android.hardware.screen.landscape.
• [C-0-2] DOIT indiquer la valeur correcte pour la valeur chaque fois qu'une requête est émise via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Si les implémentations d'appareils sont compatibles avec les deux orientations d'écran:

• [C-1-1] DOIT prendre en charge l'orientation dynamique des applications sur un écran en mode portrait ou paysage. l'orientation. Autrement dit, l'appareil doit respecter la requête de l'application pour un écran spécifique. l'orientation.
• [C-1-2] NE DOIT PAS modifier la taille ni la densité d'écran indiquées lors du changement d'orientation.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations pour les appareils:

• [C-0-1] DOIT identifier correctement les versions d'OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via le GLES10.getString()) et les API natives.
• [C-0-2] DOIT inclure la prise en charge de toutes les API gérées correspondantes et des API natives pour chaque version d'OpenGL ES qu'elle a jugée compatible.

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, tels qu'ils sont incarnés et détaillés dans la documentation du SDK Android.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
• DEVRAIT prendre en charge OpenGL ES 3.2.

Les tests dEQP d'OpenGL ES sont divisés en plusieurs listes de test, chacune avec une date/un numéro de version associé. Ils se trouvent dans l'arborescence source Android, à l'adresse external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt Un appareil qui "Compatible avec OpenGL ES". Selon les auto-déclarations, il est possible de transmettre le dEQP. dans toutes les listes de test à partir de ce niveau.

Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

• [C-2-1] DOIT générer des rapports via les API gérées et les API natives d'OpenGL ES autres extensions OpenGL ES qu'ils ont implémentées, et DOIVENT IMPÉRATIVEMENT NE signalent PAS les chaînes d'extension qu'ils ne prennent pas en charge.
• [C-2-2] DOIT prendre en charge les éléments 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 extensions.
• [C-2-3] DOIT indiquer la version maximale des tests dEQP d'OpenGL ES compatible avec le flag de fonctionnalité android.software.opengles.deqp.level.
• [C-2-4] DOIT prendre en charge au moins la version 132383489 (à partir du 1er mars 2020), signalé dans le flag de fonctionnalité android.software.opengles.deqp.level.
• [C-2-5] DOIT réussir tous les tests dEQP d'OpenGL ES dans les listes de tests entre les versions 132383489 et la version spécifiée dans le Indicateur de fonctionnalité android.software.opengles.deqp.level pour chaque option compatible Version d'OpenGL ES.
• [C-SR-2] Sont FORTEMENT RECOMMANDÉS de prendre en charge les EGL_KHR_partial_update et Extensions OES_EGL_image_external.
• DEVRAIT générer un rapport précis via la méthode getString(), toute texture format de compression pris en charge, qui est généralement propre au fournisseur.

Si les implémentations d'appareils déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles:

• [C-3-1] DOIT exporter les symboles de fonction correspondants à cette version dans en plus des symboles de fonction OpenGL ES 2.0 de la bibliothèque libGLESv2.so.
• [C-SR-3] SONT FORTEMENT RECOMMANDÉS de soutenir OES_EGL_image_external_essl3 .

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.2, celles-ci:

• [C-4-1] DOIT prendre en charge le pack d'extensions Android OpenGL ES dans son intégralité.

Si les implémentations d'appareils sont compatibles avec le pack d'extensions Android OpenGL ES dans ses dans son intégralité:

• [C-5-1] DOIT identifier l'assistance via l'android.hardware.opengles.aep flag de fonctionnalité.

Si les implémentations d'appareils exposent la compatibilité avec EGL_KHR_mutable_render_buffer extension, ils:

• [C-6-1] DOIT également prendre en charge le protocole EGL_ANDROID_front_buffer_auto_refresh .

7.1.4.2 Vulkan

Android est compatible avec Vulkan. , une API multiplate-forme simple pour des graphismes 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, celles-ci:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.1.

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

• DEVRAIT inclure la prise en charge de Vulkan 1.1.

Les tests dEQP de Vulkan sont partitionnés en plusieurs listes de test, chacune avec une la date et la version associées. Ils se trouvent dans l'arborescence source Android, à l'adresse external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt Un appareil qui Prise en charge de Vulkan à un niveau auto-déclaré indique qu'il peut transmettre le dEQP dans toutes les listes de test à partir de ce niveau.

Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, elles:

• [C-1-1] DOIT indiquer la valeur entière correcte avec le paramètre android.hardware.vulkan.level et android.hardware.vulkan.version et les flags de fonctionnalité.
• [C-1-2] DOIT énumérer au moins un élément VkPhysicalDevice pour Vulkan API native vkEnumeratePhysicalDevices() pour en savoir plus.
• [C-1-3] DOIT implémenter complètement les API Vulkan 1.0 pour chaque liste énumérée VkPhysicalDevice
• [C-1-4] DOIT énumérer les calques contenus dans les bibliothèques natives portant le nom libVkLayer*.so dans le répertoire de bibliothèque natif du package d'application via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() pour en savoir plus.
• [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques situées en dehors de package d'application, ni proposer d'autres moyens de tracer ou d'intercepter API Vulkan, sauf si l'application possède l'attribut android:debuggable définie sur true.
• [C-1-6] DOIT indiquer toutes les chaînes d'extension qu'ils prennent en charge via l'attribut Les API natives Vulkan, et, à l'inverse, NE DOIVENT PAS signaler les chaînes d'extension qu'ils ne prennent pas correctement en charge.
• [C-1-7] DOIT prendre en charge la surface VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
• [C-1-8] DOIT indiquer la version maximale des tests Vulkan dEQP compatible avec le flag de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-9] DOIT prendre en charge au moins la version 132317953 (à partir du 1er mars 2019), indiqué dans le flag de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-10] DOIT réussir tous les tests dEQP Vulkan dans les listes de tests entre version 132317953 et la version spécifiée dans le Indicateur de fonctionnalité android.software.vulkan.deqp.level.
• [C-1-11] NE DOIT PAS énumérer la compatibilité avec la file d'attente "VK_KHR_video_queue", VK_KHR_video_decode_queue ou VK_KHR_video_encode_queue.
• [C-SR-2] EST FORTEMENT RECOMMANDÉ de prendre en charge les propriétés VK_KHR_driver_properties et VK_GOOGLE_display_timing :

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer d'indicateur de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
• [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices()

Si les implémentations d'appareils sont compatibles avec Vulkan 1.1 et déclarez l'un des Les indicateurs de fonctionnalité Vulkan:

• [C-3-1] DOIT exposer la prise en charge du sémaphore et du handle externes SYNC_FD et l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT prendre en charge Android RenderScript, comme expliqué 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 veulent activer l'accélération matérielle pour les graphismes 2D au niveau de l'application, de l'activité, Fenêtre ou au niveau de la vue via l'utilisation d'une balise de fichier manifeste android:hardwareAccelerated ou des appels d'API directs.

Implémentations pour les appareils:

• [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT activer désactiver l'accélération matérielle si le développeur le demande en définissant android:hardwareAccelerated="false" ou désactivation de l'accélération matérielle directement via les API Android View.
• [C-0-2] DOIT présenter un comportement conforme aux 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 textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'interface utilisateur.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans larges

Si les implémentations d'appareils revendiquent la compatibilité avec les écrans larges via Configuration.isScreenWideColorGamut() , ils:

• [C-1-1] DOIT disposer d'un écran calibré pour les couleurs.
• [C-1-2] DOIT disposer d'un écran dont la gamme couvre la gamme de couleurs sRVB entièrement dans l'espace xyY de la CIE de 1931.
• [C-1-3] DOIT disposer d'un écran dont la surface couvre au moins 90% des DCI-P3 dans un espace xyY CIE de 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et les signaler correctement.
• [C-1-5] DOIT faire la promotion de EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, et EGL_EXT_gl_colorspace_display_p3_passthrough .
• [C-SR-1] EST VIVEMENT RECOMMANDÉ d'utiliser GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans larges, ils:

• [C-2-1] DEVRAIT couvrir 100% ou plus du format sRVB dans l'espace xyY de la CIE 1931, bien que la gamme de couleurs de l'écran n'est pas définie.

Mode de compatibilité des anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un 'normal' mode de taille d'écran équivalente (320 dp) pour profiter des avantages applications non développées pour les anciennes versions d'Android une indépendance par rapport à la taille de l'écran.

Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications de s'enrichir sur un écran compatible Android. Les appareils DOIVENT être compatibles avec tous ces telles que définies par le SDK Android, sauf autorisation spécifique stipulée dans le présent document.

Tous les écrans compatibles avec Android d'une implémentation d'appareil:

• [C-0-1] DOIT être capable d'afficher des images en couleurs 16 bits.
• DEVRAIT prendre en charge les écrans compatibles avec des graphismes en couleurs 24 bits.
• [C-0-2] DOIT être capable d'afficher des animations.
• [C-0-3] DOIT avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

Écrans secondaires

Android prend en charge les écrans secondaires compatibles Android pour activer de partage multimédia et des API de développement pour accéder à des écrans externes.

Si les implémentations d'appareils prennent en charge un écran externe via un câble, sans fil ou d'une connexion d'affichage supplémentaire intégrée, ils:

• [C-1-1] DOIT implémenter la DisplayManager le service système et l'API, comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un mécanisme d'entrée tel qu'un écran tactile ou navigation non tactile, pour naviguer entre les éléments de l'interface utilisateur.

7.2.1. Clavier

Si les implémentations d'appareils incluent la compatibilité aux applications de l'éditeur de mode de saisie (IME) :

• [C-1-1] DOIT déclarer l'élément android.software.input_methods flag de fonctionnalité.
• [C-1-2] DOIT implémenter intégralement Input Management Framework
• [C-1-3] DOIT disposer d'un clavier virtuel préinstallé.

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard. (QWERTY ou 12 touches).
• DEVRAIT inclure des implémentations de clavier virtuel supplémentaires.
• PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android prend en charge le pavé directionnel, le trackball et la molette comme mécanismes pour la navigation non tactile.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

• [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour sélection et modification de texte, compatible avec les moteurs de gestion des entrées La L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection convient à une utilisation avec des appareils dépourvus d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

La page Accueil, Récents, et Retour fonctions généralement fournies par une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentiels pour de navigation et, par conséquent, les implémentations d'appareils:

• [C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées comportant une activité dont le <intent-filter> est défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour un téléviseur mises en œuvre. La fonction Accueil DOIT être le mécanisme de cette affordance utilisateur.
• DEVRAIT fournir des boutons pour les fonctions "Récents" et "Retour".

Si les fonctions "Accueil", "Récents" ou "Retour" sont fournies, elles:

• [C-1-1] DOIT être accessible en une seule action (appuyer, double-cliquer, geste) lorsque l'un d'entre eux est accessible.
• [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Une icône visible est imprimée sur le bouton, indiquant qu’un logiciel dans la barre de navigation de l'écran ou guider l'utilisateur à travers une étape par étape de la procédure de démonstration lors de la configuration prête à l'emploi sont des exemples de ce type d'indications.

Implémentations pour les appareils:

• [C-SR-1] est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme d'entrée pour Fonction de menu car elle a été abandonnée au profit de la barre d'action depuis Android 4.0.

Si les implémentations d'appareils intègrent la fonction Menu, celles-ci:

• [C-2-1] DOIT afficher le bouton à développer d'actions chaque fois que l'action le pop-up du menu à développer n'est pas vide et la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position de la fenêtre pop-up de dépassement d'action en sélectionnant le bouton à développer dans la barre d'action, mais PEUT s'afficher. le pop-up de dépassement d'action à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils ne fournissent pas la fonction Menu, pour les étapes précédentes la compatibilité, ils:

• [C-3-1] DOIT mettre la fonction Menu à la disposition des applications targetSdkVersion est inférieur à 10, soit pour un bouton physique, soit pour une clé logicielle ou des gestes. Cette fonction Menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si la fonction d'assistance est disponible dans les implémentations d'appareils, ils:

• [C-4-1] DOIT rendre la fonction Assist accessible en une seule action (appuyer, double-cliquer ou faire un geste, par exemple) lorsque d'autres touches de navigation sont accessibles.
• [C-SR-2] FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction HOME, une interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les de navigation, ils:

• [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, et non disponibles pour les applications, et NE DOIVENT PAS masquer ni perturber la partie de l'écran disponible pour les applications.
• [C-5-2] DOIT mettre une partie de l'écran à la disposition des applications respecte les exigences définies dans la section 7.1.1 ;
• [C-5-3] DOIT respecter les indicateurs définis par l'application via le View.setSystemUiVisibility() méthode API afin que cette partie distincte de l'écran (la barre de navigation) est correctement masquée, comme indiqué dans le SDK.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() NE DOIT être utilisé que pour signaler la zone de reconnaissance des gestes de l'accueil.
• [C-6-2] Gestes qui commencent dans un rectangle d'exclusion, tel que fourni par application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIT PAS être interceptée pour la fonction de navigation tant que l'exclusion rect est autorisé dans la limite maximale d'exclusion spécifiée dans les documentation pour View#setSystemGestureExclusionRects()
• [C-6-3] DOIT envoyer à l'application de premier plan une MotionEvent.ACTION_CANCEL une fois que les gestes commencent à être interceptés pour un geste système, si l'application de premier plan a déjà reçu une MotionEvent.ACTION_DOWN .
• [C-6-4] DOIT fournir une affordance à l'utilisateur pour passer à un écran à l'écran, basée sur des boutons (par exemple, dans les paramètres).
• DEVRAIT fournir la fonction d'accueil en balayant l'écran de bas en haut l'orientation actuelle de l'écran.
• DEVRAIT fournir la fonction Récents comme un balayage vers le haut et de la pression avant de relâcher, de dans la même zone que le geste Accueil.
• Gestes qui commencent à l'intérieur WindowInsets#getMandatorySystemGestureInsets() NE DOIT PAS être affectés par les rectangles d'exclusion fournis par le premier plan application via View#setSystemGestureExclusionRects()

Si une fonction de navigation est fournie depuis n'importe quel emplacement sur les bords gauche et droit de l'orientation actuelle de l'écran:

• [C-7-1] La fonction de navigation DOIT être "Retour" et être présentée sous la forme d'un balayage les bords gauche et droit de l’orientation actuelle de l’écran.
• [C-7-2] Si des panneaux système personnalisés à faire glisser sont fournis sur la gauche ou bord droit, ils DOIVENT être placés dans le tiers supérieur de l'écran une indication visuelle claire et persistante que le fait de glisser entraînerait l'appel aux panneaux susmentionnés, et donc pas Retour. Un panneau système PEUT être configuré par un utilisateur de sorte qu'il s'affiche en dessous du tiers supérieur de l'écran mais le panneau système NE DOIT PAS utiliser plus d'un tiers de ces bords.
• [C-7-3] Lorsque l'application au premier plan dispose de l'élément View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE définis. le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, ce qui décrites dans le SDK.
• [C-7-4] Lorsque l'application au premier plan dispose de l'élément View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT ou WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE définis. les panneaux système à faire glisser personnalisés DOIVENT être masqués jusqu'à ce que l'utilisateur y introduise ou annule la luminosité des barres système (barre de navigation et d'état) tel que implémenté dans AOSP.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes d'entrée de pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques de saisie tactile. Implémentations des appareils à écran tactile sont associés à un écran de sorte que l'utilisateur ait l'impression en manipulant des éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune affordance supplémentaire pour indiquer les objets manipulé.

Implémentations pour les appareils:

• DEVRAIT disposer d'un système d'entrée de pointeur (comme une souris ou un écran tactile).
• DEVRAIT prendre en charge les pointeurs suivis de manière totalement indépendante.

Si les implémentations d'appareils comprennent un écran tactile (simple ou mieux) sur un principal compatible avec Android:

• [C-1-1] DOIT signaler TOUCHSCREEN_FINGER pour Configuration.touchscreen API.
• [C-1-2] DOIT signaler l'erreur android.hardware.touchscreen et Indicateurs de fonctionnalité android.hardware.faketouch.

Si les implémentations des appareils comprennent un écran tactile capable de suivre plus de d'un simple geste sur un écran principal compatible avec Android:

• [C-2-1] DOIT signaler les flags de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique sur l'appareil.

Si les implémentations de périphériques reposent sur un périphérique d'entrée externe tel qu'une souris ou la trackball (c'est-à-dire si elle ne touche pas directement l'écran) pour l'entrée un écran compatible avec Android et répondre aux exigences de l'écran tactile simulé section 7.2.5, elles:

• [C-3-1] NE DOIT PAS signaler de drapeau de fonctionnalité commençant par android.hardware.touchscreen
• [C-3-2] DOIT signaler uniquement android.hardware.faketouch.
• [C-3-3] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ Configuration.touchscreen API.

Saisie tactile simulée

L'interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble de l'écran tactile. Par exemple, une souris ou une télécommande qui entraîne Un curseur à l'écran ressemble à un toucher tactile, mais l'utilisateur doit d'abord pointer ou sélectionner, puis cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile et le gyroscope la souris, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge des interactions tactiles. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à une image non tactile haute fidélité (basé sur un pointeur), comme une souris ou un pavé tactile, qui peut émule la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil prend en charge un sous-ensemble émulé de fonctionnalités tactiles.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais en incluent un autre qu'elle souhaite mettre à disposition, elle:

• DEVRAIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareils déclarent la prise en charge de android.hardware.faketouch, ils:

• [C-1-1] DOIT indiquer les positions X et Y absolues de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• [C-1-2] DOIT signaler l'événement tactile avec le code d'action spécifiant changement d'état qui se produit sur le pointeur en descendant ou en remontant sur le écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le haut et vers le bas sur un objet affiché à l'écran, permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• [C-1-4] DOIT prendre en charge les pointeurs vers le bas, vers le haut, vers le bas, puis vers le haut au même endroit sur un objet à l'écran dans un délai imparti, 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 pointeur vers un autre point arbitraire à l'écran, suivi d'un pointeur ce qui permet aux utilisateurs d'émuler un déplacement tactile.
• [C-1-6] DOIT prendre en charge le pointeur vers le bas pour permettre aux utilisateurs de déplacer rapidement l'objet à une autre position sur l'écran, puis pointer vers le haut sur l'écran, qui permet aux utilisateurs de lancer un objet sur l'écran.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.distinct:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT prendre en charge le suivi distinct d'au moins deux pointeurs indépendants d'entrée.

Si les implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.jazzhand:

• [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 5 (suivi d'une main des doigts) ou plus d'entrées de pointeur indépendamment.

Compatibilité avec les manettes de jeu

Mappages de boutons

Implémentations pour les appareils:

• [C-1-1] DOIT être capable de mapper les événements HID aux constantes InputEvent correspondantes, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont répond à cette exigence.

Si les implémentations d'appareils intègrent une manette ou sont livrées avec une manette distincte dans la boîte permettant de saisir tous les événements listés dans les tableaux ci-dessous, elles:

• [C-2-1] DOIT déclarer le flag de fonctionnalité android.hardware.gamepad

Bouton	Utilisation HID^2	Bouton Android
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0 x 09, 0 x 0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
O^1	0x09 0x0005	KEYCODE_BOUTON_Y (100)
Pavé directionnel dessus^1 Pavé directionnel vers le bas^1	0x01 0x0039^3	AXIS_HAT_Y^4
Pavé directionnel gauche1 Pavé directionnel droit^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_BOUTON_R1 (103)
Clic gauche^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Effectuer un clic avec le stick droit^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Retour^1	0x0c 0x0224	KEYCODE_BACK (4)

1 Événement clé

2 Les utilisations de HID ci-dessus doivent être déclarées dans un Jeu pad CA (0x01 0x0005).

3 Cette utilisation doit avoir un minimum logique de 0, Maximum logique de 7, minimum physique de 0, maximum physique de 315, unités en degrés, et une taille de rapport de 4. La valeur logique est définie comme étant la une rotation dans le sens des aiguilles d'une montre loin de l'axe vertical ; par exemple, une valeur logique de 0 représente l'absence de rotation et l'appui sur le bouton vers le haut, tandis qu'une valeur logique 1 représente une rotation de 45 degrés, et les touches haut et gauche étant est maintenue enfoncée.

4 MotionEvent

Commandes analogiques^1	Utilisation HID	Bouton Android
Gâchette gauche	0x02, 0x00C5	AXIS_LTRIGGER
Déclencheur droit	0x02, 0x00C4	AXIS_RTRIGGER
Joystick gauche	0x01 0x0030 0 x 01, 0 x 0031	AXIS_X AXIS_Y
Joystick droit	0x01 0x0032 0 x 01, 0 x 0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier doté d'un pour les développeurs tiers, l'implémentation des appareils DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Android Open Source sur les capteurs.

Implémentations pour les appareils:

• [C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs conformément aux android.content.pm.PackageManager .
• [C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via le SensorManager.getSensorList() et des méthodes similaires.
• [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de détection (par exemple, Affichage de true ou false, selon le cas, lorsque les applications tentent de s'inscrire les écouteurs de capteur, et non lorsqu'ils ne sont pas présent ; etc.).

Si les implémentations d'appareils incluent un type de capteur particulier doté d'un API correspondante pour les développeurs tiers, ils:

• [C-1-1] DOIT signaler toutes les mesures des capteurs en utilisant les valeurs du système international d'unités (métriques) pertinentes pour chaque tel que défini dans la documentation du SDK Android.
• [C-1-2] DOIT transmettre les données de capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec latence maximale demandée de 0 ms lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT signaler le premier échantillon du capteur en 400 millisecondes + 2 * sample_time du capteur en cours d'activation. Il est acceptable que cet échantillon ont une justesse de 0.
• [C-1-4] Pour toute API indiquée dans la documentation du SDK Android comme étant capteur continu, les implémentations d'appareils DOIVENT fournir en permanence échantillons de données périodiques qui DOIVENT présenter une gigue inférieure à 3%, où la gigue est définie comme l'écart type de la différence les valeurs de code temporel entre des événements consécutifs.
• [C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en mode suspendu ou de se réactiver de l'état "suspendu".
• [C-1-6] DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android, représentant l'heure à laquelle l'événement s'est produit et synchronisé avec Horloge SystemClock.elapsedRealtimeNano().
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir des erreurs de synchronisation de l'horodatage inférieures à 100 millisecondes, et DOIT comporter une erreur de synchronisation du code temporel inférieure à 1 de l'ordre de la milliseconde.
• Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie signalée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. le comportement documenté du SDK Android et les documentations Android Open Source sensors doivent être pris en compte faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier doté d'un API correspondante pour les développeurs tiers, ils:

• [C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et indiquer la valeur via le Sensor.getResolution() .

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations pour les appareils:

• DEVRAIT mettre en œuvre ces types de capteurs les capteurs physiques prérequis, comme décrit pour les types de capteurs.

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

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Android Open Source documentation sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier doté d'un l'API correspondante pour les développeurs tiers, et le capteur n'en signale qu'un puis les implémentations d'appareils:

• [C-3-1] DOIT définir la résolution du capteur sur 1 et indiquer la valeur via le Sensor.getResolution() .

Si les implémentations d'appareils incluent un type de capteur particulier qui prend en charge SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, ceux-ci:

• [C-4-1] NE DOIT PAS inclure d'étalonnage fixe défini en usine dans les données fournies.

Si les implémentations d'appareils comprennent une combinaison d'accéléromètres à 3 axes, un d'un gyroscope à trois axes ou d'un magnétomètre, ce sont:

• [C-SR-2] VIVEMENT RECOMMANDÉ de vérifier que l'accéléromètre, le gyroscope et magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformables (par exemple, pliables), les axes des capteurs restent alignés et cohérents avec le système de coordonnées du capteur de transformation.

7.3.1. Accéléromètre

Implémentations pour les appareils:

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

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

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter et signaler l'TYPE_ACCELEROMETER capteur vidéo.
• [C-1-3] DOIT respecter le système de coordonnées du capteur Android comme indiqué dans les API Android.
• [C-1-4] DOIT pouvoir mesurer de la chute libre jusqu'à quatre fois gravité(4g) ou plus sur n'importe quel axe.
• [C-1-5] DOIT avoir une résolution d'au moins 12 bits.
• [C-1-6] DOIT avoir un écart type inférieur ou égal à 0,05 m/s^, où l'écart type doit être calculé par axe à partir d'échantillons collectées sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• [C-SR-2] sont VIVEMENT RECOMMANDÉS d'implémenter TYPE_SIGNIFICANT_MOTION. à l'aide d'un capteur composite.
• Il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler TYPE_ACCELEROMETER_UNCALIBRATED pour les [C-SR-3]. capteur vidéo. Il est FORTEMENT RECOMMANDÉ de disposer d'appareils Android pour répondre à cette exigence. ils pourront effectuer une mise à niveau vers la prochaine version de la plate-forme, deviennent OBLIGATOIRES.
• DEVRAIT implémenter TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER, capteurs composites, comme décrit ici dans le document du SDK Android.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DEVRAIT avoir une résolution d'au moins 16 bits.
• DEVRAIT être calibré pendant l'utilisation si les caractéristiques du cycle de vie et des compensations, et préservent les paramètres de compensation entre les redémarrages de l'appareil.
• DEVRAIT être compensé en température.

Si les appareils sont équipés d'un accéléromètre à 3 axes et de l'un des TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR Les capteurs composites TYPE_STEP_COUNTER sont implémentés:

• [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DEVRAIT être inférieure à 2 mW et à 0,5 mW lorsque l'appareil est en mode dynamique ou statique.

Si les implémentations d'appareils comprennent un accéléromètre à 3 axes et un capteur de gyroscope à 3 axes, ils:

• [C-3-1] DOIT implémenter les éléments TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION capteurs composites.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'implémenter le TYPE_GAME_ROTATION_VECTOR à l'aide d'un capteur composite.

Si les implémentations d'appareils comprennent un accéléromètre à 3 axes, un gyroscope à 3 axes, et un magnétomètre, elles:

• [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre (boussole) à 3 axes.

Si les implémentations d'appareils incluent un magnétomètre à 3 axes, ils:

• [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
• [C-1-2] DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 50 Hz.
• [C-1-3] DOIT respecter le système de coordonnées du capteur Android comme indiqué dans le API Android.
• [C-1-4] DOIT pouvoir mesurer entre -900 μT et +900 μT sur chaque avant de saturer.
• [C-1-5] DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et DOIT avoir une valeur inférieure à 200 μT, en plaçant le magnétomètre à distance les champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
• [C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 μT.
• [C-1-7] DOIT prendre en charge l'étalonnage et la compensation en ligne du fer dur et préservent les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] DOIT appliquer la compensation du fer doux. Le calibrage peut être pendant l'utilisation ou la production de l'appareil.
• [C-1-9] DOIT comporter un écart type, calculé par axe, en fonction échantillons collectés sur une période d'au moins trois secondes lors de l'échantillonnage le plus rapide ne doit pas dépasser 1, 5 μT ; DEVRAIT avoir un écart type inférieur à 0,5 μT.
• [C-1-10] DOIT mettre en œuvre TYPE_MAGNETIC_FIELD_UNCALIBRATED capteur vidéo.

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes, un accéléromètre et un gyroscope à 3 axes, ils:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils comprennent un magnétomètre à 3 axes (un accéléromètre), ils:

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes, un accéléromètre et 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 de traitement par lot à 10 Hz.

7.3.3. GPS

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un récepteur GPS/GNSS.

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

• [C-1-1] DOIT prendre en charge les sorties de localisation à une fréquence d'au moins 1 Hz lorsque demandée par LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être capable de déterminer la position en ciel ouvert. (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (rapide délai avant la première correction), lorsque vous êtes connecté à un débit de données d'au moins 0,5 Mbit/s de votre connexion Internet. Cette exigence est généralement satisfaite technique de technique GPS/GNSS assistée ou prévue pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance comprennent le temps de référence, Emplacement de référence et Éphémères du satellite/Horloge).
  • [C-1-6] Après ce calcul de localisation, DOIT déterminer son emplacement, en ciel ouvert, dans 5 secondes, lorsque les demandes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de l'emplacement, même lorsque la requête suivante est sans connexion de données et/ou après un redémarrage.

• En ciel ouvert après avoir déterminé la position, lorsque vous êtes à l'arrêt ou se déplacer avec moins de 1 mètre par seconde carré d'accélération:

  • [C-1-3] DOIT pouvoir déterminer la position dans un rayon de 20 mètres et la vitesse à une distance de 0,5 mètre par seconde, au moins 95% du temps.
  • [C-1-4] DOIT suivre et créer simultanément des rapports via GnssStatus.Callback d'au moins huit satellites d'une constellation.
  • DEVRAIT pouvoir suivre simultanément au moins 24 satellites, à partir plusieurs constellations (par exemple, GPS + au moins l'une des images Glonass, Beidou, Galilée).

• [C-SR-2] EST FORTEMENT RECOMMANDÉ de continuer à fournir un GPS/GNSS normal les résultats de localisation via l'API GNSS Location Provider lors d'un appel d'urgence ; .

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de tous les constellations suivies (tel qu'indiqué dans les messages GnssStatus), à l'exception des des SBA.

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de signaler les erreurs AGC et la fréquence du GNSS. les mesures.

• [C-SR-5] 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-6] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès que même si la position calculée à partir du GPS/GNSS n'est pas encore signalées.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ de signaler les pseudo-plages GNSS et de pseudo-plage, qui, dans des conditions de ciel ouvert après avoir déterminé l'emplacement, lorsque vous êtes immobile ou que vous vous déplacez à moins de 0,2 mètre par seconde au carré accélération, sont suffisantes pour calculer la position à 20 mètres près et la vitesse à une distance de 0,2 mètre par seconde, au moins 95% du temps.

7.3.4. Gyroscope

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscope.

Si les implémentations d'appareils comprennent un gyroscope à 3 axes, ils:

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter le capteur TYPE_GYROSCOPE.
• [C-1-4] DOIT avoir une résolution de 12 bits ou plus.
• [C-1-5] DOIT être compensé en température.
• [C-1-6] DOIT être calibré et compensé en cours d'utilisation, et préserver entre les redémarrages de l'appareil.
• [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du d'échantillonnage, mais DOIT être contraint par cette valeur. En d'autres termes, si vous mesurer la variance du gyroscope à un taux d'échantillonnage de 1 Hz, elle DOIT ne pas être supérieure à que 1e-7 rad^2/s^2.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile et à température ambiante.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'implémenter TYPE_GYROSCOPE_UNCALIBRATED capteur vidéo.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution de 16 bits ou plus.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

Si les implémentations d'appareils comprennent un gyroscope à 3 axes, un capteur d'accéléromètre et un magnétomètre, elles:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils sont équipés d'un accéléromètre à 3 axes et d'un gyroscope à 3 axes capteur, elles:

• [C-3-1] DOIT implémenter les TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION capteurs composites.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de mettre en œuvre TYPE_GAME_ROTATION_VECTOR d'un capteur composite.

Le baromètre

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (pression de l'air ambiant) capteur).

Si les implémentations d'appareils comprennent un baromètre, celles-ci:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT pouvoir diffuser des événements avec une fréquence de 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [C-SR-2] FORTEMENT RECOMMANDÉ de pouvoir signaler les mesures de pression dans le de 300 hPa à 1 100 hPa.
• DEVRAIT avoir une précision absolue de 1 hPa.
• DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (soit une précision d'environ 1 m pour une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les appareils sont équipés d'un thermomètre ambiant (capteur de température), ils:

• [C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE du capteur de température ambiante, qui DOIT mesurer la température ambiante la température (de la chambre/cabine du véhicule) à partir de laquelle l'utilisateur interagit avec en degrés Celsius.

Si les appareils sont équipés d'un capteur thermomètre mesurant autre que la température ambiante, comme la température du processeur, ils:

• [C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

Si les implémentations des appareils incluent un capteur pour surveiller la température cutanée, ils:

• [C-SR-1] SONT FORTEMENT RECOMMANDÉS de soutenir le PowerManager.getThermalHeadroom API.

7.3.7. Photomètre

• Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

• Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité et qu'ils ne signalent qu'une la lecture binaire « proche » ou « large », ils:

• [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que la l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter des objets. à proximité de l'écran, car l'objectif principal de ce type de capteur détecter un téléphone en cours d'utilisation par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité dans une autre orientation, il NE DOIT PAS être accessible via cette API.
• [C-1-2] DOIT avoir une précision d'au moins 1 bit.
• [C-1-3] DOIT utiliser 0 centimètre pour la lecture proche et 5 centimètres pour la lecture de loin.
• [C-1-4] DOIT indiquer une plage maximale et une résolution de 5.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité, tels que définis dans cette section et les mettent à la disposition d'applications tierces, ils:

• [C-1-1] DOIT identifier la capacité à l'aide de la propriété Indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

Si les implémentations d'appareils déclarent android.hardware.sensor.hifi_sensors, ils:

• [C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui:

  • DOIT avoir une plage de mesure comprise entre -8 g et +8 g, et est VIVEMENT RECOMMANDÉ d'avoir une plage de mesure comprise entre -16 g ou plus et +16 g.
  • DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus. DEVRAIT est compatible avec SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 3 000 événements de capteurs.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 3 mW.
  • [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'utiliser une bande passante de 3 dB pour les mesures au moins 80% de la fréquence de Nyquist et du spectre du bruit blanc dans cette la bande passante réseau.
  • DEVRAIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg/°C.
  • DEVRAIT présenter une non-linéarité de la courbe la plus adaptée de ≤ 0,5 %, et une variation de la sensibilité par rapport à la température de ≤ 0,5 % 0,03%/C°.
  • DEVRAIT avoir une sensibilité interaxe < 2,5 % et une variation de Sensibilité transversale < 0,2% de la plage de températures de fonctionnement de l'appareil.

• [C-2-2] DOIT avoir un élément TYPE_ACCELEROMETER_UNCALIBRATED ayant le même aux exigences de qualité en tant que TYPE_ACCELEROMETER.

• [C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui:

  • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps.
  • DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus. DEVRAIT est compatible avec SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser une bande passante de 3 dB pour les mesures au moins 80% de la fréquence de Nyquist et du spectre du bruit blanc dans cette la bande passante réseau.
  • DEVRAIT avoir un taux de marche aléatoire inférieur à 0,001 °/s √Hz testé dans une pièce température.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
  • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
  • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
  • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
  • DEVRAIT avoir une erreur de calibrage inférieure à 0,002 rad/s dans de 10 à 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité g DOIT être inférieure à 0,1°/s/g.
  • DEVRAIT avoir une sensibilité interaxe < Sensibilité à 4,0 % et sensibilité transversale variation < 0,3% de la plage de températures de fonctionnement de l'appareil.

• [C-2-4] DOIT disposer d'un TYPE_GYROSCOPE_UNCALIBRATED de même qualité les conditions requises TYPE_GYROSCOPE.

• [C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui:

  • DOIT avoir une plage de mesure comprise entre -900 et +900 μT.
  • DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
  • DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
  • DOIT présenter un bruit de mesure inférieur à 0,5 uT.

• [C-2-6] DOIT disposer d'un TYPE_MAGNETIC_FIELD_UNCALIBRATED de même qualité exigences que TYPE_GEOMAGNETIC_FIELD et en plus:

  • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 600 événements de capteurs.
  • [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'avoir un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence du rapport est de 50 Hz ou plus.

• [C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui:

  • La plage de mesure DOIT être comprise entre 300 et 1 100 hPa au minimum.
  • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
  • DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 300 événements de capteurs.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 2 mW.

• [C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.

• [C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui:

  • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui:

  • DOIT implémenter une forme non activée de ce capteur avec mise en mémoire tampon d'au moins 100 événements de capteurs.
  • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.

• [C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui:

  • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui:

  • La consommation d'énergie ne doit PAS être inférieure à 0,5 mW lorsque l'appareil statique et de 1,5 mW lorsque l'appareil est en mouvement.

• [C-2-13] Le code temporel du même événement physique signalé par L'accéléromètre, le gyroscope et le magnétomètre DOIVENT se situer dans un rayon de 2, 5 millisecondes les uns des autres. Le code temporel du même événement physique signalé par l'accéléromètre et le gyroscope DOIVENT se trouver à une distance de 0,25 milliseconde chacun autre.

• [C-2-14] Les codes temporels des événements du capteur du gyroscope DOIVENT être associés au même moment. de base que le sous-système de l'appareil photo et en 1 milliseconde d'erreur.

• [C-2-15] DOIT fournir des échantillons aux applications dans un délai de 5 millisecondes Le moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus à l'application.

• [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW Lorsque l'appareil est statique et de 2 mW lorsqu'il est en mouvement lorsque n'importe quelle combinaison des capteurs suivants est activée:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] PEUT avoir un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que les exigences de consommation d'énergie de cette section n'incluent pas les composants la consommation d'énergie du processeur d'application. Elle inclut le pouvoir par l'ensemble de la chaîne de capteurs : le capteur, les circuits associés, un système dédié au traitement de capteurs, etc.

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, celles-ci:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs des taux de rapports via le isDirectChannelTypeSupported et getHighestDirectReportRateLevel API.
• [C-3-2] DOIT prendre en charge au moins l'un des deux types de canaux directs des capteurs pour tous les capteurs qui déclarent la prise en charge du canal direct du capteur.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVRAIT prendre en charge les rapports d'événements via le canal direct de capteur (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 Documentation sur la mesure de la sécurité biométrique

Si les implémentations d'appareils comprennent un écran de verrouillage sécurisé:

• DEVRAIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés dans la classe 3 (anciennement Strong), Classe 2 (anciennement Faible) ou Classe 1 (anciennement Commodité) en fonction de leurs taux d'acceptation par les imposteurs et par les parasites, ainsi que par la sécurité un pipeline biométrique. Cette classification détermine les capacités le capteur biométrique doit communiquer avec la plate-forme et avec des tiers applications. Par défaut, les capteurs sont classés dans la classe 1 et doivent de répondre aux exigences supplémentaires détaillées ci-dessous s'ils souhaitent être classés en tant que classe 2 ou classe 3. Cours 2 et Cours 3 la biométrie obtiennent des fonctionnalités supplémentaires comme détaillé ci-dessous.

Si des mises en œuvre d'appareils mettent un capteur biométrique à la disposition d'un tiers d'applications via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, ils:

• [C-4-1] DOIT respecter les exigences concernant les données biométriques de classe 3 ou 2 tel que défini dans ce document.
• [C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans la section Authenticators et toutes les combinaisons de celles-ci. Inversement, NE DOIT PAS respecter ni reconnaître des constantes entières transmises au canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques Authentificateurs et toutes les combinaisons de celles-ci.
• [C-4-3] DOIT implémenter l'instruction ACTION_BIOMETRIC_ENROLL sur les appareils utilisant la biométrie de classe 3 ou de classe 2. Cette action DOIT présenter uniquement les points d'entrée d'inscription pour la classe 3 ou la biométrie de classe 2.

Si les implémentations d'appareils prennent en charge la biométrie passive, elles:

• [C-5-1] DOIT exiger par défaut une étape de confirmation supplémentaire (par exemple, en appuyant sur un bouton).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir un paramètre permettant aux utilisateurs de ignorer les préférences de l'application et exiger toujours qu'un accompagnement l'étape de confirmation.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ que l'opération de confirmation soit effectuée de sorte qu’un système d’exploitation ou un noyau compromis ne puisse pas en usurper. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée uniquement) un composant sécurisé (SE) qui ne peut être piloté par aucun autre moyen qu'un l'appui physique sur le bouton.
• [C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), les applications pouvant être configurées pour les flux de connexion.

Si les appareils disposent de plusieurs capteurs biométriques, ils:

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule validation biométrique par authentification (par exemple, si les capteurs d'empreinte digitale et du visage sont disponibles) onAuthenticationSucceeded sur l'appareil doit être envoyé après la confirmation de l'une d'entre elles).

Pour que les implémentations d'appareils autorisent l'accès aux clés de keystore pour applications tierces, ils:

• [C-6-1] DOIT respecter les exigences de la classe 3, telles que définies 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 l'authentification est appelée avec un CryptoObject.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 1 (anciennement Convenience), elles:

• [C-1-1] DOIT avoir un taux de faux acceptations inférieur à 0,002%.
• [C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code PIN sécurisé. schéma ou mot de passe, et énumérez clairement les risques liés à son activation, les taux d’acceptation de spoofing et d’imposteurs sont supérieurs à 7 %, selon les mesures Protocoles de test biométrique Android
• [C-1-9] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) après un maximum de vingt faux essais et de moins de 90 secondes pour la vérification biométrique, lorsqu'un un faux essai doit offrir une qualité de capture adéquate. (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond à aucune donnée biométrique enregistrée.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de réduire le nombre total de faux essais. pour la vérification biométrique spécifiée dans [C-1-9] si le spoofing et l'imposteur les taux d'acceptation sont supérieurs à 7 %, selon l'indicateur biométrique d'Android Protocoles de test.
• [C-1-3] DOIT limiter le nombre de tentatives de validation biométrique un faux essai doit offrir une qualité de capture adéquate. (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une biométrie enregistrée.
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ de limiter le débit des tentatives pendant au moins 30 secondes après cinq faux essais de vérification biométrique pour le nombre maximal de faux essais par [C-1-9] - où un faux essai correspond à un avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une l'enregistrement biométrique.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'intégrer toute la logique de limitation du débit dans le TEE.
• [C-1-10] DOIT désactiver la biométrie une fois que l'intervalle d'authentification principal déclenché pour la première fois comme décrit dans l'article [C-0-2] de la section 9.11.
• [C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans avoir préalablement établi de confiance en demandant à l'utilisateur de confirmer l'existence ou d'ajouter un nouvel appareil identifiant (code/schéma/mot de passe) sécurisé par TEE ; l'application Android Open L’implémentation du projet source fournit le mécanisme dans le cadre pour faire donc.
• [C-1-5] DOIT supprimer complètement toutes les données biométriques permettant d'identifier l'utilisateur Lorsque le compte de l'utilisateur est supprimé (y compris en cas de rétablissement de la configuration d'usine).
• [C-1-6] DOIT respecter l'indicateur individuel de cette biométrie (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] DOIT inviter l'utilisateur à procéder à l'authentification principale recommandée (par exemple, code, schéma ou mot de passe): a) une fois toutes les 24 heures au maximum pour les appareils Android 9 ou version ultérieure, b) une fois toutes les 72 heures ou moins pour les appareils mis à jour à partir d'Android 8 ou version antérieure.

• [C-1-8] DOIT inviter l'utilisateur à procéder à l'authentification principale recommandée (par exemple, code, schéma ou mot de passe) ou une biométrie de classe 3 (FORT) après l'une des suivantes:

  • un délai d'inactivité de quatre heures, OU

  • 3 tentatives d'authentification biométrique ayant échoué.

    • Le délai d'inactivité et le nombre d'échecs d'authentification DOIVENT être : réinitialisée après confirmation des identifiants de l'appareil.
    • Implémentations d'appareils livrées sur Android 8 ou version antérieure PEUVENT être exemptés de l'obligation de contrôle C-1-8.

• [C-SR-7] EST FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils.

• [C-SR-8] Il est FORTEMENT RECOMMANDÉ d'avoir un taux de faux refus inférieur à 10%, comme mesuré sur l’appareil.

• [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'avoir une latence mesurée en dessous de 1 seconde entre la détection biométrique et le déverrouillage de l'écran, pour chaque l'enregistrement biométrique.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 2 (anciennement Weak), elles:

• [C-2-1] DOIT respecter toutes les exigences de la classe 1 ci-dessus.
• [C-2-2] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 20% selon les mesures effectuées par les protocoles de test biométrique Android.
• [C-2-3] DOIT exécuter correspondance biométrique dans un environnement d'exécution isolé en dehors d'Android un espace utilisateur ou de noyau, 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] DOIT avoir toutes les données identifiables chiffrées et cryptographiques authentifiés de sorte qu'ils ne puissent pas être acquis, lus ou modifiés en dehors l'environnement d'exécution isolé ou une puce dotée d'un canal sécurisé un environnement d'exécution isolé, comme indiqué dans le Guide de mise en œuvre consignes sur le site du projet Android Open Source.
• [C-2-5] Pour la biométrie par caméra, et l'authentification biométrique ou un enregistrement est en cours:
  • DOIT utiliser l'appareil photo dans un mode qui empêche les images en cours de lecture ou de modification en dehors de l'environnement d'exécution isolé ou d'une puce un canal sécurisé vers l'environnement d'exécution isolé.
  • Pour les solutions RVB à caméra unique, les cadres PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour permettre comme l'aperçu pour l'inscription, mais il NE DOIT PAS être modifiable.
• [C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction les enregistrements biométriques individuels.
• [C-2-7] NE DOIT PAS autoriser un accès non chiffré aux données données biométriques ou toute donnée dérivée de celles-ci (telles que des représentations vectorielles continues) pour le processeur d'application en dehors du contexte du TEE. Mise à niveau des appareils lancées sur Android version 9 ou antérieure ne sont pas exemptées de C-2-7.

• [C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'un système d'exploitation une compromission du système ou du noyau ne peut pas permettre l’injection directe de données s'authentifier à tort comme l'utilisateur.

  Remarque :Les implémentations d'appareils livrées à partir du niveau d'API 27 et qui ne peuvent pas respecter l'exigence C-2-8 via une mise à jour logicielle système, PEUVENT être exemptés de cette exigence.

• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de l'activité physique pour tous les modalités biométriques et la détection de l'attention pour la biométrie des visages.

• [C-2-9] DOIT mettre le capteur biométrique à la disposition d'un tiers applications.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique en tant que classe 3 (anciennement Strong), elles:

• [C-3-1] DOIT respecter toutes les exigences de la classe 2 ci-dessus, à l'exception des [C-1-7] et [C-1-8].
• [C-3-2] DOIT disposer d'une implémentation de keystore intégré au matériel.
• [C-3-3] DOIT avoir un taux d'acceptation de spoofing et d'imposteurs ne dépassant pas 7% selon les mesures effectuées par les protocoles de test biométrique Android.
• [C-3-4] DOIT inviter l'utilisateur à la question principale recommandée (par code, schéma ou mot de passe, par exemple) toutes les 72 heures ou moins.
• [C-3-5] DOIT générer à nouveau un ID d'authentificateur pour toutes les données biométriques de classe 3 prises en charge sur l'appareil, si l'une d'entre elles est réinscrit.
• [C-3-6] Vous devez activer les clés de keystore basées sur la biométrie pour les clés tierces. applications.

Si les implémentations d'appareils comportent un lecteur d'empreinte digitale sous l'écran (UDFPS), ils:

• [C-SR-11] Sont FORTEMENT RECOMMANDÉS pour empêcher la zone tactile de l'UDFPS (lecteur d'empreinte digitale sous l'écran) d'interférer avec la navigation à trois boutons( que certains utilisateurs peuvent avoir à des fins d'accessibilité).

7.3.12. Capteur de postures

Implémentations pour les appareils:

• PEUT prendre en charge les capteurs de position avec 6 degrés de liberté.

Si les implémentations d'appareils prennent en charge les capteurs de position à 6 degrés de liberté, ils:

• [C-1-1] DOIT implémenter et signaler l'TYPE_POSE_6DOF capteur vidéo.
• [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.13. Capteur d'angle de charnière

Si les appareils sont compatibles avec un capteur d'angle de charnière:

• [C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
• [C-1-2] DOIT prendre en charge au moins deux relevés compris entre 0 et 360 degrés (incluses, c'est-à-dire comprises entre 0 et 360 degrés).
• [C-1-3] DOIT renvoyer un réveil capteur pour getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Connectivité des données

7.4.1. Téléphonie

le terme "téléphonie" utilisé par les API Android et ce document fait spécifiquement référence ; au matériel permettant de passer des appels vocaux et d'envoyer des SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être commutés de paquets ou non, aux fins d'Android, elles sont considérées comme indépendantes la connectivité qui peut être mise en œuvre à l'aide du même réseau. Autrement dit, la fonctionnalité de téléphonie et les API Android se rapportent spécifiquement les appels et les SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ou envoyer/recevoir des SMS ne sont pas considérés comme des appareils de téléphonie, quel que soit le s'ils utilisent un réseau cellulaire pour la connectivité des données.

• Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel téléphonique. Cela est qu'Android est compatible avec les appareils qui ne sont pas des téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, ils:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony. d'autres indicateurs de sous-fonctionnalité, en fonction de la technologie utilisée.
• [C-1-2] DOIT mettre en œuvre la compatibilité totale de l'API avec cette technologie.
• DEVRAIT autoriser tous les types de services mobiles disponibles (2G, 3G, 4G, 5G, etc.) pendant les appels d'urgence (quels que soient les types de réseau définis par SetAllowedNetworkTypeBitmap()).

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie:

• [C-2-1] DOIT implémenter les API complètes en tant que no-ops.

Si les implémentations d'appareils sont compatibles avec les eUICC ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire permettant de mettre la fonctionnalité eSIM à la disposition des développeurs, ils:

• [C-3-1] DOIT fournir une implémentation complète de EuiccManager API.

Si les implémentations d'appareils ne définissent pas la propriété système ro.telephony.iwlan\_operation\_mode sur "legacy" :

• [C-4-1] NE DOIT PAS signaler NETWORK_TYPE_IWLAN. via NetworkRegistrationInfo#getAccessNetworkTechnology() lorsque NetworkRegistrationInfo#getTransportType() est signalée comme TRANSPORT_TYPE_WWAN pour la même instance NetworkRegistrationInfo.

Si les implémentations d'appareils sont compatibles avec un sous-système multimédia (IMS) unique IP l'enregistrement au service de téléphonie multimédia (MMTEL) et de services de communication enrichis (RCS) et doivent respecter aux exigences de l'opérateur mobile concernant l'utilisation d'un seul L'enregistrement IMS pour tout le trafic IMS signalant le trafic:

• [C-5-1] DOIT déclarer l'élément android.hardware.telephony.ims et fournissent une implémentation complète API ImsService pour MMTEL et RCS API User Capability Exchange.
• [C-5-2] DOIT déclarer l'élément android.hardware.telephony.ims.singlereg et fournissent une implémentation complète de l'API SipTransport, l'API GbaService, les indications de support dédiées à l'aide de l'IRadio 1.6 HAL et le provisionnement via un serveur de configuration automatique (ACS, Auto Configuration Server) ou un autre provisionnement propriétaire à l'aide de l'API IMS Configuration.

Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure une fonctionnalité de blocage de numéros
• [C-1-2] DOIT implémenter intégralement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
• [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone figurant dans "BloquéNumberProvider" sans aucune interaction avec les applications. La seule exception se produit lorsque le blocage de numéros est temporairement levé, comme décrit dans le SDK. dans la documentation Google Cloud.
• [C-1-4] NE DOIT PAS écrire dans le fournisseur de journaux d'appels de la plate-forme en cas d'appel bloqué.
• [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie en cas de message bloqué.
• [C-1-6] DOIT implémenter une interface utilisateur de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par TelecomManager.createManageBlockedNumbersIntent() .
• [C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à afficher ou modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal dispose le contrôle des services de téléphonie, une seule instance, sur l'appareil. Tout l'interface utilisateur associée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste de blocage DOIT être masquée tout en respectant les règles en vigueur.
• DEVRAIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil sera mis à jour vers Android 7.0.

API Telecom

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

• [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir une affordance à l'utilisateur accepter ou refuser l'appel entrant lorsqu'un utilisateur est en cours d'appel ; généré par une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifié via CAPABILITY_SUPPORT_HOLD
• [C-1-3] DOIT disposer d'une application qui met en œuvre InCallService :

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que le fait de répondre à une l'appel entrant interrompt l'appel en cours.

  L'implémentation d'AOSP répond à ces exigences grâce à une notification prioritaire ce qui indique à l'utilisateur que répondre à un appel entrant entraînera ou un autre appel à abandonner.

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de précharger l'application de téléphonie par défaut affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels. lorsque l'application tierce définit EXTRA_LOG_SELF_MANAGED_CALLS Extras sur son PhoneAccount pour true.

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de manipuler le casque audio Événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK pour android.telecom API comme ci-dessous:

  • Appeler Connection.onDisconnect() Lorsqu'un appui court sur l'événement touche est détecté au cours d'un appel.
  • Appeler Connection.onAnswer() Lorsqu'un appui court sur l'événement touche est détecté pendant un appel entrant.
  • Appeler Connection.onReject() Lorsqu'un appui prolongé sur un événement de touche est détecté pendant un appel entrant.
  • Activer/Désactiver le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils sont compatibles avec la norme 802.11 et exposent le à une application tierce, ils:

• [C-1-1] DOIT implémenter l'API Android correspondante.
• [C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.wifi.
• [C-1-3] DOIT implémenter l'API de multidiffusion comme décrit dans la documentation du SDK.
• [C-1-4] DOIT prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment, y compris:
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même en veille et des états d'alimentation.
• [C-1-5] NE DOIT PAS traiter l'élément WifiManager.enableNetwork() appel de méthode API comme indication suffisante pour changer la méthode Network, utilisé par défaut pour le trafic de l'application et renvoyé de ConnectivityManager Méthodes d'API telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils PEUVENT désactiver uniquement l'accès Internet fourni par d'un autre opérateur (par exemple, les données mobiles) s'il valide que le réseau Wi-Fi fournit un accès à Internet.
• [C-1-6] Sont FORTEMENT RECOMMANDÉS lorsque le ConnectivityManager.reportNetworkConnectivity() la méthode API est appelée, réévaluez l'accès Internet sur le Network, puis une fois que l'évaluation détermine que le Network actuel ne fournit plus Accès Internet, utilisez un autre réseau disponible (par exemple, un réseau mobile qui fournit un accès à Internet.
• [C-1-7] DOIT appliquer de manière aléatoire l'adresse MAC source et le numéro de séquence de la vérification une fois au début de chaque recherche, tandis que STA est déconnectés.
• [C-1-8] DOIT utiliser une seule adresse MAC cohérente (NE DEVRAIT PAS afficher les adresses MAC dans un ordre aléatoire) à mi-parcours de la recherche).
• [C-1-9] DOIT itérer le numéro de séquence de la requête de vérification normalement (de manière séquentielle) entre les requêtes de vérification dans une analyse.
• [C-1-10] DOIT appliquer de manière aléatoire le numéro de séquence de la requête de vérification entre le dernier résultat de vérification requête d'analyse et la première requête de vérification de l'analyse suivante.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source utilisée pour toutes les communications STA vers un point d'accès, tout en associant et associées.
  • L'appareil DOIT utiliser une adresse MAC aléatoire différente pour chaque SSID. (FQDN pour Passpoint) avec lequel il communique.
  • L'appareil DOIT fournir à l'utilisateur la possibilité de contrôler randomisation par SSID (FQDN pour Passpoint) avec des valeurs non aléatoires et des options aléatoires et DOIT définir le mode par défaut pour le nouveau réseau Wi-Fi de manière aléatoire.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'utiliser un BSSID aléatoire pour tous les points d'accès créer.
  • L'adresse MAC DOIT être aléatoire et conservée par SSID utilisé par le AP.
  • L'APPAREIL PEUT Donner à l'utilisateur la possibilité de désactiver cette fonctionnalité. Si une telle option est fournie, la randomisation DOIT être activée par défaut.

Si les implémentations d'appareils prennent en charge le mode Économie d'énergie Wi-Fi tel que défini conformément à la norme IEEE 802.11, ils:

• DEVRAIT désactiver le mode Économie d'énergie Wi-Fi chaque fois qu'une application acquiert Serrure WIFI_MODE_FULL_HIGH_PERF ou WIFI_MODE_FULL_LOW_LATENCY par WifiManager.createWifiLock() et WifiManager.WifiLock.acquire() API et le verrou est actif.
• [C-3-2] La latence moyenne aller-retour entre les appareils et un point d'accès lorsque l'appareil est verrouillé en mode Wi-Fi à faible latence (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la valeur la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
• [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrou à faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis. et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour rechercher la position, ils:

• [C-2-1] DOIT fournir une affordance d'utilisateur pour activer/désactiver la lecture de valeur via le WifiManager.isScanAlwaysAvailable .

Wi-Fi Direct

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les appareils sont compatibles avec le Wi-Fi Direct, ils:

• [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
• [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• [C-1-3] DOIT être compatible avec le fonctionnement Wi-Fi standard.
• [C-1-4] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Direct simultanément.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source pour tous des connexions Wi-Fi Direct nouvellement créées.

7.4.2.2. Configuration du lien direct par tunneling en Wi-Fi

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de Configuration TDLS (Wi-Fi Tunneled Direct Link Setup) comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils incluent la prise en charge du TDLS et que celui-ci est activé par le API WiFiManager, ils:

• [C-1-1] DOIT déclarer la prise en charge du TDLS via WifiManager.isTdlsSupported.
• DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
• DEVRAIT avoir une heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pire que de passer par le point d'accès Wi-Fi.

Wi-Fi Aware

Implémentations pour les appareils:

• DEVRAIT inclure la compatibilité avec Wi-Fi Aware.

Si les implémentations d'appareils incluent la compatibilité Wi-Fi Aware et exposent le à des applications tierces, ils:

• [C-1-1] DOIT implémenter les API WifiAwareManager, comme décrit dans le Documentation du SDK
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.aware.
• [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
• [C-1-4] DOIT attribuer de manière aléatoire à intervalles réguliers l'adresse de l'interface de gestion Wi-Fi Aware ne dépasse pas 30 minutes et chaque fois que Wi-Fi Aware est activé, à moins qu'un l'opération de mesure des distances est en cours ou un chemin de données Aware est actif (la randomisation n'est pas attendu tant que le chemin de données est actif).

Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5 et expose ces fonctionnalités à des applications tierces:

• [C-2-1] DOIT implémenter les API de découverte avec détection de la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Si les appareils sont compatibles avec la norme 802.11 (Wi-Fi), ils:

• [C-1-1] DOIT inclure la compatibilité avec Wi-Fi Passpoint.
• [C-1-2] DOIT implémenter les API WifiManager liées à Passpoint comme décrites dans la documentation du SDK.
• [C-1-3] DOIT être compatible avec la norme IEEE 802.11u, spécifiquement associée à la découverte et à la sélection du réseau, comme la publicité générique Service (GAS) et le protocole ANQP (Access Network Query Protocol).
• [C-1-4] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.passpoint.
• [C-1-5] DOIT suivre l'implémentation AOSP pour découvrir, mettre en correspondance et associer aux réseaux Passpoint.
• [C-1-6] DOIT prendre en charge au moins le sous-ensemble suivant de provisionnement d'appareils tels que définis dans le contrat Wi-Fi Alliance Passpoint R2: EAP-TTLS l'authentification et les données SOAP-XML.
• [C-1-7] DOIT traiter le certificat du serveur AAA tel que décrit dans Spécification du point d'accès 2.0 R3.
• [C-1-8] DOIT prendre en charge le contrôle utilisateur du provisionnement via le sélecteur Wi-Fi.
• [C-1-9] DOIT garder les configurations Passpoint persistantes lors des redémarrages.
• [C-SR-1] EST FORTEMENT RECOMMANDÉ de respecter les conditions d'utilisation la fonctionnalité d'acceptation.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge la fonctionnalité d'informations sur le lieu.

Inversement, si les implémentations d'appareils n'incluent pas la prise en charge du Wi-Fi Passpoint:

• [C-2-1] L'implémentation de l'WifiManager lié à Passpoint Les API DOIVENT générer une exception UnsupportedOperationException.

Si un bouton de désactivation global des commandes utilisateur pour Passpoint est fourni, les implémentations suivantes:

• [C-3-1] DOIT activer Passpoint par défaut.

Emplacement du Wi-Fi (délai aller-retour Wi-Fi - DAR)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la localisation Wi-Fi.

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent le à des applications tierces, ils:

• [C-1-1] DOIT implémenter les API WifiRttManager, comme décrit dans le Documentation du SDK
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
• [C-1-3] DOIT appliquer de manière aléatoire l'adresse MAC source pour chaque rafale DAR qui s'exécute alors que l'interface Wi-Fi sur laquelle le texte en temps réel est en cours d'exécution n'est associé à aucun point d'accès.
• [C-1-4] DOIT être précis à 2 mètres près pour une bande passante de 80 MHz au 68e centile (calculé à l'aide du calcul de la fonction de distribution).

7.4.2.6. Déchargement Wi-Fi Keepalive

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du déchargement Wi-Fi keepalive.

Si les implémentations d'appareils incluent la prise en charge du déchargement Wi-Fi keepalive et exposent la fonctionnalité à des applications tierces, celles-ci:

• [C-1-1] DOIT prendre en charge les l'API SocketKeepAlive.

• [C-1-2] DOIT prendre en charge au moins trois emplacements keepalive simultanés sur le Wi-Fi et au moins un emplacement keepalive sur le réseau mobile.

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement Wi-Fi keepalive, ils:

• [C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de provisionnement des appareils)

Implémentations pour les appareils:

• DEVRAIT être compatible avec Wi-Fi Easy Connect (DPP).

Si les implémentations d'appareils incluent la prise en charge de la fonctionnalité Wi-Fi Easy Connect et exposent le à des applications tierces, ils:

• [C-1-1] DOIT disposer de la fonction WifiManager#isEasyConnectSupported() renvoie true.

7.4.2.8. Validation du certificat du serveur Wi-Fi d'entreprise

Si le certificat du serveur Wi-Fi n'est pas validé ou si le serveur Wi-Fi nom de domaine non défini, implémentations d'appareils:

• [C-SR-1] est FORTEMENT RECOMMANDÉ de ne pas proposer d'option à l'utilisateur pour ajouter manuellement le réseau Wi-Fi d'entreprise dans l'application Paramètres.

7.4.3. Bluetooth

Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

• DEVRAIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec les protocoles HFP, A2DP et AVRCP:

• DEVRAIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareils déclarent android.hardware.vr.high_performance fonctionnalité, ils:

• [C-1-1] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations de l'appareil incluent la prise en charge du Bluetooth et du Bluetooth Low Energy, ils:

• [C-2-1] DOIT déclarer les fonctionnalités pertinentes de la plate-forme (android.hardware.bluetooth et android.hardware.bluetooth_le respectivement) et implémenter les API de la plate-forme.
• DEVRAIT implémenter des profils Bluetooth pertinents, tels que A2DP, AVRCP, OBEX, HFP, etc. en fonction de l'appareil.

Si les implémentations d'appareils sont compatibles avec la technologie BLE (Bluetooth basse consommation), elles:

• [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• [C-3-2] DOIT activer le Bluetooth basé sur le profil d'attribut générique (GATT) telles que décrites dans la documentation du SDK android.bluetooth.
• [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() pour indiquer si le logique de filtrage pour ScanFilter est implémentée.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() pour indiquer si la publicité à faible consommation d'énergie est prise en charge.
• [C-3-5] DOIT implémenter un délai avant expiration d'une adresse privée pouvant être résolue (RPA, Resolvable Private Address) de plus de 15 minutes et alterner les adresses une fois le délai expiré afin de protéger la confidentialité des utilisateurs. lorsque l'appareil utilise activement la technologie BLE pour l'analyse ou la publicité. Pour éviter les attaques chronophages, les intervalles de temporisation DOIVENT également être aléatoires entre 5 et 15 minutes.
• DEVRAIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de la mise en œuvre de l'API ScanFilter.
• DEVRAIT permettre le déchargement de la recherche par lot sur le chipset Bluetooth.
• DEVRAIT prendre en charge les annonces multiples comportant au moins 4 emplacements.

Si les implémentations d'appareils sont compatibles avec la technologie Bluetooth LE et utilisez-la pour de la localisation, ils:

• [C-4-1] DOIT fournir une affordance d'utilisateur pour activer/désactiver la lecture de valeur via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la compatibilité avec la technologie Bluetooth LE et les appareils auditifs Profil, tel que décrit à la section Compatibilité des appareils auditifs avec Bluetooth LE:

• [C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, Listen, BluetoothProfile.HEARING_AID).

Si les implémentations de l'appareil prennent en charge le Bluetooth ou le Bluetooth basse consommation, ils:

• [C-6-1] DOIT restreindre l'accès aux métadonnées Bluetooth (comme les résultats) qui pourrait être utilisée pour déterminer la position de l'appareil, sauf si l'application à l'origine de la demande transmet un android.permission.ACCESS_FINE_LOCATION ; vérification des autorisations en fonction de son état actuel de premier plan/arrière-plan.

Si les implémentations de l'appareil sont compatibles avec le Bluetooth ou le Bluetooth à basse consommation et que le fichier manifeste de l'application n'inclut pas de déclaration du développeur indiquant qu'ils ne dérivent pas la localisation à l'aide du Bluetooth, puis:

• [C-6-2] DOIT activer l'accès Bluetooth derrière le android.permission.ACCESS_FINE_LOCATION.

7.4.4. Communication en champ proche

Implémentations pour les appareils:

• DEVRAIT inclure un émetteur-récepteur et le matériel associé pour la fonctionnalité NFC. (NFC).
• [C-0-1] DOIT implémenter android.nfc.NdefMessage et android.nfc.NdefRecord même si elles n'incluent pas la compatibilité NFC ou déclarez la caractéristique android.hardware.nfc, car les classes représentent de représentation de données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition des applications tierces, elles:

• [C-1-1] DOIT signaler la fonctionnalité android.hardware.nfc à partir du Méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via le protocole NFC suivant : standard comme indiqué ci-dessous:
• [C-1-2] DOIT être capable d'agir en tant que lecteur/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • ISO Dep (ISO 14443-4)
  • Types de tags du forum NFC 1, 2, 3, 4, 5 (définis par le forum NFC)

• [C-SR-1] VIVEMENT RECOMMANDÉ pour être capable de lire et d'écrire des données NDEF de messages et de données brutes via les normes NFC suivantes. Notez que alors que les normes NFC sont citées comme FORTEMENT RECOMMANDÉES, les la définition de compatibilité d'une version future va modifier ces à DOIT. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les prochaines versions. Appareils nouveaux et existants exécutant cette version de Nous encourageons vivement Android à respecter ces exigences dès maintenant. ils pourront passer aux futures versions de la plate-forme.

• [C-1-13] DOIT interroger toutes les technologies compatibles lors de la détection NFC .

• DOIT être en mode de détection NFC lorsque l'appareil est activé avec l'écran est actif et l'écran de verrouillage est déverrouillé.

• DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) Code-barres NFC Thinfilm produits.

Notez que les liens accessibles au public ne sont pas disponibles pour les normes JIS, ISO et NFC. Spécifications du forum mentionnées ci-dessus.

Android est compatible avec le mode HCE (émulation de carte hôte NFC).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage des ID d'application (AID), ils:

• [C-2-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hce.
• [C-2-2] DOIT être compatible avec les API NFC HCE 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 la NFC et implémenter cette fonctionnalité pour les applications tierces, ils:

• [C-3-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de cartes NfcF comme défini dans le SDK Android.

Si les implémentations d'appareils sont compatibles avec la technologie NFC générale comme décrit dans ce document, et prendre en charge les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/rédacteur:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le document le SDK Android.
• [C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare android.content.pm.PackageManager.hasSystemFeature() . Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et que, par conséquent, apparaissent comme une constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles de mise en réseau et API

Capacité réseau minimale

Implémentations pour les appareils:

• [C-0-1] DOIT inclure la prise en charge d'une ou plusieurs formes de la mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT inclure la prise en charge des au moins une norme de données capable de 200 Kbit/s ou plus. Exemples de technologies répondant à cette exigence incluent EDGE, HSPA, EV-DO, 802.11g, réseau Ethernet et Bluetooth PAN.
• DEVRAIT également prendre en charge au moins un service de données sans fil courant standard, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (comme Ethernet) est la connexion de données principale.
• PEUT mettre en œuvre plusieurs formes de connectivité de données.

IPv6

Implémentations pour les appareils:

• [C-0-2] DOIT inclure une pile réseau IPv6 et être compatible avec le protocole IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que les API natives, telles que AF_INET6 sockets.
• [C-0-3] DOIT activer IPv6 par défaut.
  • DOIT s'assurer que la communication IPv6 est aussi fiable que l'IPv4, par exemple:
    • [C-0-4] DOIT maintenir la connectivité IPv6 en mode Sommeil.
    • [C-0-5] La limitation du débit NE DOIT PAS entraîner la perte d'adresses IPv6 sur l'appareil sur tout réseau compatible IPv6 qui utilise des durées de vie RA de d'au moins 180 secondes.
• [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'ils sont connectés à un réseau IPv6, sans aucune forme d'adresse ou la traduction de port qui s'effectue localement sur l'appareil. Les API gérées, telles que Socket#getLocalAddress ou Socket#getLocalPort) et les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP adresse et le port qui sont réellement utilisés pour envoyer et recevoir des paquets sur le réseau et est visible en tant qu'adresse IP et port sources pour les serveurs Internet (Web).

Le niveau requis de compatibilité IPv6 dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les appareils sont compatibles avec le Wi-Fi, ils:

• [C-1-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, ils:

• [C-2-1] DOIT prendre en charge les opérations à double pile et IPv6 uniquement sur Ethernet.

Si les appareils sont compatibles avec les données mobiles, ils:

• [C-3-1] DOIT prendre en charge les opérations IPv6 (IPv6 uniquement et éventuellement double pile) sur mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, Wi-Fi et les données mobiles), elles:

• [C-4-1] DOIT respecter simultanément les exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

Portails captifs

Un portail captif est un réseau qui nécessite une connexion afin de obtenir un accès à Internet.

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

• [C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion au portail captif, en envoyant cette intention, sur à l'API System ConnectivityManager#startCaptivePortalApp(Network, Bundle)
• [C-1-2] DOIT détecter les portails captifs et accepter la connexion via l'application de portail captif lorsque l'appareil est connecté à n'importe quel type de réseau, y compris les réseaux mobiles/cellulaires, Wi-Fi, Ethernet ou Bluetooth.
• [C-1-3] DOIT prendre en charge la connexion aux portails captifs à l'aide d'un DNS en texte clair Lorsque l'appareil est configuré pour utiliser le mode DNS strict privé.
• [C-1-4] DOIT utiliser un DNS chiffré conformément à la documentation du SDK android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout le trafic réseau qui ne communique pas explicitement avec un portail captif.
• [C-1-5] DOIT s'assurer que, lorsque l'utilisateur se connecte à un appareil réseau, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback, et utilisé par défaut par les API de 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 pour les appareils:

• [C-0-1] DOIT activer par défaut le paramètre de synchronisation automatique du maître 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, voici les types de connexions:

• [C-SR-1] FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

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

• [C-1-1] DOIT prendre en charge toutes les API du ConnectivityManager comme décrit dans la documentation du SDK

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

• [C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
• [C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

7.4.8. Éléments sécurisés

Si les implémentations d'appareils sont compatibles avec Open Mobile API des éléments sécurisés et les mettent à la disposition d'applications tierces, ils:

• [C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via API android.se.omapi.SEService.getReaders().

• [C-1-2] DOIT déclarer les flags de fonctionnalité appropriés via android.hardware.se.omapi.uicc 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 android.hardware.se.omapi.sd pour l'appareil avec des éléments sécurisés en SD.

7.5. Caméras

Si les implémentations d'appareils incluent au moins une caméra:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
• [C-1-2] DOIT être possible pour qu'une application puisse allouer simultanément 3 bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur ayant la résolution la plus élevée de l'appareil, alors que l'appareil photo est ouvert l'objectif de l'aperçu de base et capturez tout de même.
• [C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée Gestion des intents MediaStore.ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE_SECURE, ou MediaStore.ACTION_VIDEO_CAPTURE, est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant en l'envoyant à l'application réceptrice lorsque celle-ci ne ont 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é l'appareil opposé à l'écran ; c'est-à-dire des scènes situées de l'autre côté l'appareil, comme un appareil photo traditionnel.

Implémentations pour les appareils:

• DEVRAIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière:

• [C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera et android.hardware.camera.any
• [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
• DEVRAIT mettre en œuvre un autofocus matériel ou logiciel. dans le pilote de l'appareil photo (transparent pour les logiciels de l'application).
• PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• PEUT inclure un flash.

Si la caméra dispose d'un flash:

• [C-2-1], la lampe du flash NE DOIT PAS être allumée tant qu'un android.hardware.Camera.PreviewCallback instance a été enregistrée sur une surface d'aperçu de l'appareil photo, à moins que l'application n'ait explicitement activé Flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas l'application de caméra système intégrée à l'appareil, mais uniquement pour des applications à l'aide de Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil comme écran. c'est-à-dire un appareil photo généralement utilisé pour filmer l'utilisateur, que pour la visioconférence et d'autres applications similaires.

Implémentations pour les appareils:

• PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra avant:

• [C-1-1] DOIT signaler le flag de fonctionnalité android.hardware.camera.any et android.hardware.camera.front
• [C-1-2] DOIT avoir une résolution VGA d'au moins (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra frontale par défaut pour le API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme l'appareil photo arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
• [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à spécifiée par l'application lorsque celle-ci a a explicitement demandé à l'appareil photo faire pivoter l'écran via un appel à la fonction android.hardware.Camera.setDisplayOrientation() . À l'inverse, l'aperçu DOIT être dupliqué avec l'aperçu par défaut de l'appareil sur l'axe horizontal lorsque l'application actuelle ne demande pas explicitement faire pivoter l'écran de la caméra via un appel à android.hardware.Camera.setDisplayOrientation() .
• [C-1-5] NE DOIT PAS dupliquer l'image fixe ou le flux vidéo finaux capturés renvoyées aux rappels de l'application ou validée dans le stockage multimédia.
• [C-1-6] DOIT mettre en miroir l'image affichée par la vue post-View de la même manière. en tant que flux d'image d'aperçu de la caméra.
• PEUT inclure des fonctionnalités (autofocus, flash, etc.) à la disposition de caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être alternées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via l'entrée utilisateur):

• [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations pour les appareils:

• PEUT inclure la prise en charge d'une caméra externe qui n'est pas nécessairement connectés en permanence.

Si les implémentations d'appareils prennent en charge une caméra externe, celles-ci:

• [C-1-1] DOIT déclarer le flag 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 le câble la caméra se connecte via le port hôte USB.
• [C-1-3] DOIT réussir les tests CTS de la caméra avec une caméra externe physique connectés. Pour en savoir plus sur le test CTS de la caméra, consultez source.android.com.
• DEVRAIT prendre en charge les compressions vidéo telles que MJPEG pour permettre le transfert flux non codés de haute qualité (images brutes ou compressées indépendamment) flux).
• PEUT prendre en charge plusieurs appareils photo.
• PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est compatible:

• [C-2-1] Une conversation non codé / flux MJPEG (QVGA ou résolution supérieure) DOIT être accessible aux 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 : le plus récent L'API android.hardware.camera2 expose les commandes de niveau inférieur de l'appareil photo à l'application, y compris des flux efficaces d'utilisation intensive ou par flux sans copie, et des contrôles par image exposition, gain, gains de balance des blancs, conversion des couleurs, suppression du bruit, accentuation et plus encore.

L'ancien package d'API,android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais qui devrait toujours être disponible pour les applications à utiliser. Appareil Android les mises en œuvre DOIVENT garantir la continuité de la prise en charge de l'API, comme décrit dans dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes à la classe obsolète android.hardware.Camera et le package android.hardware.camera2 plus récent DOIT avoir des performances équivalentes. et la qualité des deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être identique doit être identique. Caractéristiques qui dépendent de la sémantique différente des deux API ne sont pas obligatoires, mais DOIVENT être aussi proches que possible. que possible.

Les implémentations d'appareils DOIVENT mettre en œuvre les comportements suivants pour les pour tous les appareils photo disponibles. Implémentations pour les appareils:

• [C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour l'aperçu Données fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int)
• [C-0-2] DOIT être en outre au format d'encodage NV21 lorsqu'une application enregistre un android.hardware.Camera.PreviewCallback instance, et le système appelle la méthode onPreviewFrame() et l'aperçu est YCbCr_420_SP, les données de l'octet [] sont transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
• [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué dans le constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo pour les deux caméras avant et arrière pour android.hardware.Camera. (Le matériel l'encodeur vidéo et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais l'appareil la mise en œuvre DOIT être compatible avec la conversion vers YV12.)
• [C-0-4] DOIT prendre en charge les android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via API android.media.ImageReader pour android.hardware.camera2 appareils qui diffuser des annonces REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
• [C-0-5] DOIT quand même implémenter la version complète de l'API Camera dans la documentation du SDK Android, que l'appareil inclut un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo sans autofocus DOIT quand même appeler n'importe quelle android.hardware.Camera.AutoFocusCallback instances (même si aucune instance par rapport à un appareil sans autofocus). Notez que cela s'applique aux images caméras ; Par exemple, même si la plupart des caméras avant ne prennent pas en charge l'autofocus, les rappels de l'API doivent toujours être "falsifiés" comme décrit ici.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre définie comme une constante android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. Inversement, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître des constantes de chaîne transmis à la méthode android.hardware.Camera.setParameters(), à l'exception de documentées en tant que constantes sur android.hardware.Camera.Parameters. En d'autres termes, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel autorise, et NE DOIT PAS être compatible avec les types de paramètres Appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'image utilisant des techniques d'imagerie HDR (High Dynamic Range) DOIT être compatible avec les paramètres de l'appareil photo Camera.SCENE_MODE_HDR
• [C-0-7] DOIT indiquer le niveau d'assistance approprié concernant le android.info.supportedHardwareLevel telle que décrite dans le SDK Android et signaler la options de fonctionnalité du framework.
• [C-0-8] DOIT également déclarer les capacités de chaque caméra android.hardware.camera2 via le Propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés ; DOIT définir le flag de fonctionnalité si l'une des caméras associées prend en charge cette fonctionnalité.
• [C-0-9] DOIT diffuser l'Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée a été ajoutée à Media Store.
• [C-0-10] DOIT diffuser l'Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de a été ajoutée à Media Store.
• [C-0-11] DOIT disposer de toutes les caméras accessibles via le android.hardware.Camera API également accessible via le android.hardware.camera2 API.
• [C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS altérée, y compris (sans s'y limiter la modification de la géométrie du visage, de la carnation ou lissage de la peau android.hardware.camera2 ou android.hardware.Camera API.
• [C-SR-1] Pour les appareils équipés de plusieurs caméras RVB orientées dans la même direction, sont VIVEMENT RECOMMANDÉES pour prendre en charge un appareil photo logique qui liste capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, se composant de toutes les caméras RVB orientées dans cette direction comme des sous-périphériques physiques.

Si les implémentations d'appareils fournissent une API d'appareil photo propriétaire à des applications tierces, ils:

• [C-1-1] DOIT implémenter une telle API d'appareil photo à l'aide de android.hardware.camera2 API.
• PEUT fournir des balises et/ou des extensions de fournisseurs à android.hardware.camera2. API.

7.5.5. Orientation de l'appareil photo

Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

• [C-1-1] DOIT être orienté de sorte que la dimension longue de la caméra soit alignée avec la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage les appareils photo DOIVENT enregistrer les images en mode paysage. Ce s'applique quelle que soit l'orientation naturelle de l'appareil ; c'est-à-dire qu'elle s'applique en mode paysage et en mode portrait.

Les appareils qui répondent à tous les critères suivants sont exemptés de l'exigence ci-dessus:

• L'appareil intègre des écrans à géométrie variable, tels que des écrans pliables ou à charnière s'affiche.
• Lorsque l'état de pliage ou de charnière de l'appareil change, l'appareil passe l'orientation portrait-principal à l'orientation paysage-principal (ou inversement).

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un Gestionnaire de téléchargement que des applications PEUVENT utiliser pour télécharger des fichiers de données et qu'elles DOIVENT être capables de télécharger des fichiers individuels d'une taille minimale de 100 Mo par défaut ; "cache" l'emplacement.

7.6.2. Stockage partagé des applications

Implémentations pour les appareils:

• [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent désigné "stockage externe partagé" ou "stockage partagé d'application" ou par le système chemin d'accès "/sdcard" où il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, "prêt à l'emploi", que le stockage soit implémenté ou non un composant de stockage interne ou un support de stockage amovible (par exemple, Secure (emplacement pour carte numérique).
• [C-0-3] DOIT installer le stockage partagé de l'application directement sur le chemin d'accès Linux sdcard ou inclure un lien symbolique Linux entre sdcard et l'installation réelle point d'accès.
• [C-0-4] DOIT activer espace de stockage cloisonné par défaut pour tous Applications ciblant le niveau d'API 29 ou supérieur, sauf dans les cas suivants:
  • Lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans leur fichier manifeste.
• [C-0-5] DOIT masquer les métadonnées de localisation, telles que les balises GPS Exif, stockées dans des fichiers multimédias lorsque vous accédez à ces fichiers via MediaStore, sauf si l'application appelante détient l'autorisation ACCESS_MEDIA_LOCATION.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'un des suivantes:

• Stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital).
• Une partie de la mémoire de stockage interne (non amovible) mise en œuvre dans le Projet Android Open Source (AOSP)

Si les implémentations d'appareils utilisent un espace de stockage amovible pour satisfaire aux exigences ci-dessus à ces exigences:

• [C-1-1] DOIT implémenter une interface utilisateur toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans l'emplacement.
• [C-1-2] DOIT inclure un support de stockage au format FAT (une carte SD, par exemple) ou montrer sur la boîte et sur tout autre matériel disponible au moment de l'achat. support s'achète séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour satisfaire les exigences ci-dessus, ils:

• DEVRAIT utiliser l'implémentation AOSP de l'application interne partagée stockage.
• PEUT partager l'espace de stockage avec les données privées de l'application.

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

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données de l'application le stockage partagé à partir d'un ordinateur hôte.
• DEVRAIT exposer le contenu des deux chemins de stockage de manière transparente Service d'analyse multimédia d'Android et android.provider.MediaStore.
• PEUT utiliser le stockage de masse USB, mais DEVRAIT utiliser le protocole de transfert multimédia pour satisfaire cette exigence.

Si les appareils disposent d'un port USB avec mode périphérique USB et prise en charge Media Transfer Protocol, ils:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer (Transfert de fichiers Android).
• DEVRAIT signaler une classe de périphérique USB de 0x00.
• DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile par nature, contrairement à la télévision, les implémentations d'appareils sont les suivantes:

• [C-SR-1] VIVEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable sur le long terme, car toute déconnexion accidentelle peut causer une perte ou une corruption de données.

Si le port du périphérique de stockage amovible est dans un emplacement stable à long terme, par exemple dans le compartiment à piles ou un autre couvercle de protection, les implémentations d'appareils sont les suivantes:

• [C-SR-2] VIVEMENT RECOMMANDÉ d'implémenter stockage adoptable.

7.7. USB

Si les appareils disposent d'un port USB, ils:

• DEVRAIT prendre en charge le mode périphérique USB et le mode hôte USB.
• DEVRAIT prendre en charge la désactivation du signal de données via USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils comprennent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT pouvoir être connecté à un hôte USB doté d'un câble d'un port USB Type-A ou Type-C.
• [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber en standard USB descripteur d'appareil via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs 1,5 A et 3 A par résistance de type C standard et DOIT détecter les modifications apportées à l'annonce si elles prennent en charge USB Type-C.
• [C-SR-1] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Les appareils Android, nouveaux et existants, sont VIVEMENT RECOMMANDÉS pour répondre à ces exigences requises pour pouvoir passer aux versions futures de la plate-forme.
• [C-SR-2] Le port DOIT se trouver en bas de l'appareil (en fonction de l'orientation naturelle) ou activez la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement l'appareil est orienté avec le port situé en bas. Android (existant et nouveau) il est VIVEMENT RECOMMANDÉ de répondre à ces exigences afin qu'ils puissent vous pourrez effectuer une mise à niveau vers les futures versions de la plate-forme.
• [C-SR-3] DEVRAIT implémenter la prise en charge de la consommation d'un courant de 1,5 A pendant le bip HS et le trafic, comme indiqué dans la version 1.2 des spécifications relatives à la recharge de la batterie via USB. Les appareils Android, nouveaux et existants, sont VIVEMENT RECOMMANDÉS pour répondre à ces exigences requises pour pouvoir passer aux versions futures de la plate-forme.
• [C-SR-4] FORTEMENT RECOMMANDÉ de ne pas prendre en charge de recharge qui modifient la tension Vbus au-delà des niveaux par défaut ou altèrent les rôles récepteur/source en tant que tels peuvent entraîner des problèmes d'interopérabilité avec chargeurs ou appareils compatibles avec les modes USB Power Delivery standard. Alors que cette fonctionnalité est qualifiée de « VENTEMENT RECOMMANDÉ ». Dans les futures versions d'Android, nous peut EXIGER tous les appareils de type C pour assurer une interopérabilité totale avec les de type C.
• [C-SR-5] FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour les données et le changement de rôle d’alimentation lorsqu’ils prennent en charge les modes USB Type-C et hôte USB.
• DEVRAIT prendre en charge Power Delivery pour la charge haute tension et prendre en charge pour Modes alternatifs tels que l'affichage extérieur.
• DEVRAIT implémenter l'API et la spécification Android Open Accessory (AOA) en tant que dans la documentation du SDK Android.

Si les implémentations d'appareils comprennent un port USB et mettent en œuvre l'AOA ils:

• [C-2-1] DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory
• [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android". au fin de la description de l'interface iInterface chaîne de la mémoire de stockage de masse USB

7.7.2. Mode hôte USB

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

• [C-1-1] DOIT implémenter l'API hôte USB Android, comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host
• [C-1-2] DOIT implémenter la connexion de périphériques USB standards en d'autres termes, ils DOIVENT:
  • Disposer d'un port de type C sur l'appareil ou expédier les produits avec un ou plusieurs câbles adaptés à un appareil port propriétaire vers un port USB type-C standard (appareil USB Type-C).
  • être munis d'un appareil de type A ou livrés avec un ou plusieurs câbles adaptés à l'appareil ; port propriétaire à un port USB type-A standard.
  • disposer d'un port micro-AB intégré, qui DOIT être livré avec un câble adapté vers un port standard de type A.
• [C-1-3] NE DOIT PAS être expédié avec un adaptateur USB de type A ou micro-AB vers un port de type C (réceptacle).
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB. comme indiqué dans la documentation du SDK Android.
• DEVRAIT prendre en charge le chargement du périphérique USB connecté sur l'hôte mode; annonce une source avec un courant d'au moins 1,5 A, comme spécifié dans le la section "Paramètres de résiliation" Version 1.2 des spécifications concernant le câble et le connecteur USB Type-C pour l'USB Type-C ou l'utilisation de la plage de courant de sortie du port de recharge en aval(CDP) comme indiqué dans les spécifications relatives à la recharge de la batterie via USB, révision 1.2 pour les connecteurs micro-AB.
• DEVRAIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et un câble USB en classe audio, ils:

• [C-2-1] DOIT être compatible avec la classe USB HID.
• [C-2-2] DOIT prendre en charge la détection et la mise en correspondance des données HID suivantes spécifiés dans les tableaux d'utilisation USB HID et la demande d'utilisation des commandes vocales vers le KeyEvent constantes comme ci-dessous:
  .
  • ID d'utilisation (0x0CD) de la page d'utilisation (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID d'utilisation (0x0E9) de la page d'utilisation (0xC): KEYCODE_VOLUME_UP
  • ID d'utilisation de la page d'utilisation (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID d'utilisation (0x0CF) de la page d'utilisation (0xC): KEYCODE_VOICE_ASSIST

Si les implémentations d’appareils comprennent un port USB prenant en charge le mode hôte et Storage Access Framework (SAF), elles:

• [C-3-1] DOIT reconnaître tout protocole MTP (Media Transfer Protocol) connecté à distance. appareils et rendre leur contenu accessible via ACTION_GET_CONTENT, Intents ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et un port USB Type-C, ils:

• [C-4-1] DOIT implémenter la fonctionnalité de port double rôle telle que définie par la clé USB Spécification Type-C (section 4.5.1.3.3).
• [C-SR-2] FORTEMENT RECOMMANDÉ pour la compatibilité avec DisplayPort, DEVRAIT prendre en charge USB tarifs de données SuperSpeed et sont VIVEMENT RECOMMANDÉES pour prendre en charge Power Delivery. pour l'échange des rôles des données et du pouvoir.
• [C-SR-3] FORTEMENT RECOMMANDÉ DE NE PAS prendre en charge le mode accessoire de l'adaptateur audio décrits dans l'annexe A du Version 1.2 des spécifications concernant le câble USB Type-C et le connecteur
• DEVRAIT implémenter le modèle try.* le plus approprié pour la facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter la le modèle try.SNK.

7.8. Audio

Micro

Si les implémentations d'appareils incluent un micro, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio des section 5.4.
• [C-1-3] DOIT respecter les exigences de latence audio de section 5.6.
• [C-SR-1] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'enregistrement par ultrasons, comme décrit ici. comme indiqué dans la section 7.8.3.

Si l'intégration d'un appareil n'inclut pas de micro:

• [C-2-1] NE DOIT PAS signaler la constante de caractéristique android.hardware.microphone.
• [C-2-2] DOIT implémenter l'API d'enregistrement audio au moins comme no-ops, conformément section 7.

Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou une sortie audio/multimédia d'un périphérique de sortie audio, comme un connecteur audio 3,5 mm à 4 conducteurs ou Port en mode hôte USB à l'aide de la classe audio USB:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.audio.output.
• [C-1-2] DOIT répondre aux exigences de lecture audio des section 5.5.
• [C-1-3] DOIT respecter les exigences de latence audio de section 5.6.
• [C-SR-1] FORTEMENT RECOMMANDÉ de prendre en charge la lecture par ultrasons, comme décrit dans la description comme indiqué dans la section 7.8.3.

Si les appareils ne comprennent pas de haut-parleur ni de port de sortie audio:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] DOIT implémenter les API liées à la sortie audio au moins comme no-ops.

Dans le cadre de cette section, un "port de sortie" est un interface physique comme un connecteur audio 3, 5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. Prise en charge de la sortie audio sur des protocoles basés sur la radio tels que Bluetooth, Le réseau Wi-Fi ou mobile ne peut pas inclure de "port de sortie".

Ports audio analogiques

Afin d'être compatible avec les casques et autres accessoires audio en utilisant la prise audio 3, 5 mm dans l'écosystème Android. incluent un ou plusieurs ports audio analogiques, qui:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'inclure au moins l'un des Assurez-vous que le ou les ports audio sont un connecteur audio de 3,5 mm à 4 conducteurs.

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

• [C-1-1] DOIT prendre en charge la lecture audio sur des casques stéréo et stéréo avec un micro.
• [C-1-2] DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA.
• [C-1-3] DOIT prendre en charge la détection et le mappage avec les codes de clavier pour en suivant trois plages d'impédance équivalente entre le micro et le sol conducteurs sur la prise audio:
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une fiche, mais que lorsque tous les contacts de la prise ont touché les segments appropriés. sur le connecteur.
• [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 ohms.
• [C-1-6] DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper le code de clavier pour plage d'impédance équivalente entre le micro et les conducteurs de terre sur la prise audio:
  • 110-180 ohm:KEYCODE_VOICE_ASSIST
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de prendre en charge les prises audio avec le module OMTP. l'ordre de épinglage.
• [C-SR-3] Sont FORTEMENT RECOMMANDÉS pour les enregistrements audio stéréo. casques avec micro.

Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs et acceptent un micro, et diffusez le android.intent.action.HEADSET_PLUG avec le valeur supplémentaire du micro définie sur 1, il:

• [C-2-1] DOIT prendre en charge la détection du micro sur l'audio branché accessoire.

Ports audio numériques

Pour être compatibles avec les casques et autres accessoires audio utilisant Connecteurs USB-C et implémentation (classe audio USB) dans l'écosystème Android comme défini dans les spécifications des casques USB Android.

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

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz.

Implémentations pour les appareils:

• DOIT indiquer correctement la prise en charge une fonctionnalité audio proche ultrasons via la classe AudioManager.getProperty API comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est "true", les conditions suivantes DOIVENT être satisfaites Sources audio VOICE_RECOGNITION et UNPROCESSED:

• [C-1-1] La puissance moyenne du micro dans la bande 18,5 kHz-20 kHz Ne doit PAS être inférieure de plus de 15 dB à la réponse à 2 kHz.
• [C-1-2] Rapport signal/bruit non pondéré du micro sur une plage de 18,5 kHz à 20 kHz pour un ton de 19 kHz à -26 dBFS NE DOIT PAS être inférieur à 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true" :

• [C-2-1] La réponse moyenne du haut-parleur sur la plage de 18,5 kHz à 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations pour les appareils:

• DEVRAIT fournir un chemin de signal audio sans faille pour les deux entrées et aux flux de sortie sur les appareils portables, tels que définis lors d'un test d'une minute par chemin. Effectuer un test avec OboeTester "Test de glitch automatisé".

Le test nécessite un dongle de bouclage audio, directement dans un connecteur 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. Tous les ports de sortie audio DOIVENT être testés.

OboeTester accepte actuellement les chemins d'accès AAudio. Par conséquent, le Les combinaisons suivantes DOIVENT être testées pour détecter les problèmes avec AAudio:

Mode Performances	Partage	Taux d'échantillonnage sortant	En chan	Chans.
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	1	2
FAIBLE_LATENCY	EXCLUSIF	NON DÉFINI	2	1
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	1	2
FAIBLE_LATENCY	PARTAGÉ	NON DÉFINI	2	1
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 en matière de signal sur bruit Ratio (SNR) et distorsion harmonique totale (THD) pour le sinus de 2 000 Hz.

Transducteur	THD	Numéro SNR
haut-parleur intégré principal, mesuré à l'aide d'un micro de référence externe	< 3,0%	>= 50 dB
microphone intégré principal, mesuré à l'aide d'un haut-parleur de référence externe	< 3,0%	>= 50 dB
Connecteurs analogiques 3,5 mm intégrés, testés avec l'adaptateur de rebouclage	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés avec l'adaptateur de rebouclage	< 1,0%	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de "réalité virtuelle" (RV) y compris des expériences RV de haute qualité sur mobile. Appareil les implémentations DOIVENT implémenter ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android prend en charge Mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'UI d'un système monoculaire, tandis qu'une application de RV est axée sur l'utilisateur.

7.9.2. Mode Réalité virtuelle - Hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, ils:

• [C-1-1] DOIT comporter au moins deux cœurs physiques.
• [C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
• [C-1-3] DOIT prendre en charge le mode Performances soutenues.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.2.
• [C-1-5] DOIT accepter android.hardware.vulkan.level 0.
• DEVRAIT prendre en charge android.hardware.vulkan.level 1 ou version ultérieure.
• [C-1-6] DOIT mettre en œuvre 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 mettre en œuvre GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, et exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, et exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de prendre en charge Vulkan 1.1.
• [C-SR-3] Sont FORTEMENT RECOMMANDÉS d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, et l'exposer dans la liste des extensions Vulkan disponibles.
• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan dans laquelle flags contiennent à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et queueCount est supérieur ou égal à 2.
• [C-1-7] Le GPU et l'écran DOIVENT pouvoir synchroniser l'accès à l'instance de sorte qu'un rendu visuel en alternance, à 60 ips, avec deux les contextes de rendu seront affichés sans artefact de déchirure visible.
• [C-1-9] DOIT implémenter la prise en charge de AHardwareBuffer les indicateurs AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT comme décrit dans le NDK.
• [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec tout combinaison des options d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
• [C-SR-5] Sont FORTEMENT RECOMMANDÉS pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs couches et indicateurs et formats spécifiés dans C-1-10.
• [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 images par seconde compressé à une vitesse moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS - 10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 FPS - 20 Mbit/s).
• [C-1-12] DOIT être compatible avec HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressé à une moyenne de 10 Mbit/s et DEVRAIT être capable de décoder 3 840 x 2 160 pixels à une fréquence de 30 FPS à 20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 pixels à 30 FPS-5 Mbit/s).
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises de température cutanée.
• [C-1-14] DOIT disposer d'un écran intégré et sa résolution DOIT être au moins 1920 x 1080.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'avoir une résolution d'écran d'au moins 2560 x 1440.
• [C-1-15] L'écran DOIT mettre à jour une fréquence d'au moins 60 Hz en mode RV.
• [C-1-17] L'écran DOIT accepter un mode à faible persistance avec une durée de ≤ 5 millisecondes la persistance étant définie comme la durée nécessaire qu'un pixel émet de la lumière.
• [C-1-18] DOIT prendre en charge le Bluetooth 4.2 et l'extension de longueur de données Bluetooth LE section 7.4.3.
• [C-1-19] DOIT soutenir et signaler correctement Type de canal direct pour tous les types de capteurs par défaut suivants:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] SONT FORTEMENT RECOMMANDÉS de soutenir le TYPE_HARDWARE_BUFFER type de canal direct pour tous les types de canaux directs répertoriés ci-dessus.
• [C-1-21] DOIT respecter les consignes relatives au gyroscope, à l'accéléromètre et au magnétomètre exigences pour android.hardware.hifi_sensors, comme indiqué dans section 7.3.9.
• [C-SR-8] SONT FORTEMENT RECOMMANDÉS de soutenir le android.hardware.sensor.hifi_sensors.
• [C-1-22] DOIT avoir une latence du mouvement de bout en bout du photon qui ne doit pas être supérieure à 28 millisecondes.
• [C-SR-9] Il est FORTEMENT RECOMMANDÉ d'avoir une latence entre le mouvement et le photon de bout en bout pas plus de 20 millisecondes.
• [C-1-23] DOIT avoir un ratio de première image, c'est-à-dire le ratio entre les luminosité des pixels sur la première image après une transition du noir au le blanc et la luminosité des pixels blancs, dans un état stable, d'au moins 85%.
• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de première image d'au moins 90%.
• PEUT fournir un cœur exclusif au premier plan application et PEUVENT prendre en charge l'API Process.getExclusiveCores pour renvoyer Nombre de cœurs de processeur réservés au premier plan supérieur application.

Si un cœur exclusif est pris en charge, le noyau:

• [C-2-1] NE DOIT pas autoriser l'exécution d'autres processus d'espace utilisateur sur celui-ci (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUT autoriser certains noyaux des processus à exécuter si nécessaire.

7.10. Technologie tactile

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

7.11. Classe Media Performance

La classe de performance multimédia de l'implémentation de l'appareil peut être obtenue à partir de le android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS. Conditions requises pour sont définies pour chaque version d'Android R (version 30). La valeur spéciale 0 indique que l'appareil n'est pas la classe de performance multimédia.

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

• [C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.

• [C-1-2] DOIT être une implémentation d'appareil portable.

• [C-1-3] DOIT respecter toutes les conditions requises pour la "classe de performance multimédia" décrits comme indiqué dans la section 2.2.7.

Reportez-vous à la section 2.2.7 pour les informations spécifiques à chaque appareil. exigences.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur. et un impact sur les hypothèses de base que les développeurs auraient l'application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final s'il y a certains afin de garantir la cohérence d'une fréquence d'images et de temps de réponse des applications et des jeux. Les implémentations d'appareils, selon le type d'appareil, PEUVENT avoir des exigences mesurables en termes de latence de l'interface utilisateur et de tâche comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Il fournit une référence commune pour garantir des performances d'accès aux fichiers cohérentes sur le le stockage de données privées des applications (partition /data) permet aux développeurs d'applis pour définir une attente appropriée qui aiderait à concevoir son logiciel. Appareil selon le type d'appareil, elles PEUVENT être soumises à certaines exigences décrites dans la section 2 pour en savoir plus et d'écriture:

• Performances d'écriture séquentielle. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec Tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire. Mesure effectuée à partir de l'écriture d'un fichier de 256 Mo en 4 Ko un tampon d'écriture.
• Performances de lecture séquentielle. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo avec Tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo en 4 Ko un tampon d'écriture.

8.3. Modes d'économie d'énergie

Si les implémentations d'appareils incluent des fonctionnalités permettant d'améliorer la gestion de l'alimentation de l'appareil inclus dans AOSP (par exemple, App Standby Bucket ou Sommeil) ou étendent les fonctionnalités pour appliquer des restrictions plus strictes que le bucket de mise en veille des applications LIMITÉ:

• [C-1-1] NE DOIT PAS vous écarter de l'implémentation AOSP pour le déclenchement. la maintenance, les algorithmes de wakeup et l'utilisation de paramètres système globaux ou DeviceConfig de mise en veille des applications et d'économie d'énergie.
• [C-1-2] NE DOIT PAS déroger à l'implémentation AOSP pour l'utilisation ou DeviceConfig pour gérer la limitation des tâches, les alarmes pour les applications de chaque bucket en mode Mise en veille des applications.
• [C-1-3] NE DOIT PAS vous écarter de l'implémentation AOSP pour le nombre Buckets App Standby utilisés pour les applications Prêt.
• [C-1-4] DOIT implémenter les buckets de mise en veille des applications et la fonctionnalité Sommeil décrites dans la section Gestion de l'alimentation.
• [C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
• [C-1-6] DOIT fournir une affordance utilisateur pour afficher toutes les applications exemptées de mise en veille des applications et d'économie d'énergie, ou d'optimisations de la batterie, et DOIT mettre en œuvre les ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intention de demander à l'utilisateur d'autoriser une application à ignorer la batterie et des optimisations.
• [C-SR-1] SONT FORTEMENT RECOMMANDÉS de fournir une affordance à l'utilisateur pour activer et désactiver l'économiseur de batterie.
• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de fournir à l'utilisateur l' affordance d'afficher tous les Applications exemptées des modes d'économie d'énergie Sommeil et Mise en veille des applications

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP, et cette extension applique des restrictions plus strictes bucket de mise en veille des applications rares, consultez section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT mettre en œuvre tout ou partie des quatre états de veille, tels que définis par la Configuration and Power Interface (ACPI).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par le ACPI, ils:

• [C-1-1] NE DOIT entrer dans cet état qu'après une action explicite de l'utilisateur mettre l'appareil en mode inactif (par exemple, en fermant un couvercle qui est physiquement partie de l'appareil ou éteindre un véhicule ou une télévision) et avant que l'utilisateur réactive l'appareil (par exemple, en ouvrant le capot ou en tournant le véhicule). ou la télévision).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par le ACPI, ils:

• [C-2-1] DOIT respecter l'état C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque l'état les applications n'ont pas besoin des ressources système (écran ou processeur, par exemple).

  Inversement, il DOIT quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

  Par exemple, alors que les applications tierces demandent à conserver l'écran via FLAG_KEEP_SCREEN_ON ou maintenir le processeur en fonctionnement PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer en mode S3, sauf dans les cas décrits ci-après. dans C-1-1, l'utilisateur a effectué une action explicite pour placer l'appareil l'état inactif. À l'inverse, lorsqu'une tâche qu'une application tierce via JobScheduler ou Firebase Cloud Messaging à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a désactivé l'appareil. Ces informations ne sont pas exhaustives et AOSP implémente de nombreux signaux de wakeup qui déclenchent un wakeup. à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et des rapports plus précis de la consommation d'énergie offrent les avantages et les outils permettant d'optimiser la consommation de l'application.

Implémentations pour les appareils:

• [C-SR-1] FORTEMENT RECOMMANDÉ de fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel, ainsi que la décharge approximative de la batterie causée par composants au fil du temps, comme indiqué sur le site du projet Android Open Source.
• [C-SR-2] VIVEMENT RECOMMANDÉ de consigner toutes les valeurs de consommation d'énergie en milliampères heures (mAh).
• [C-SR-3] VIVEMENT RECOMMANDÉ de signaler la consommation d'énergie du processeur par UID de chaque processus. Le projet Android Open Source répond aux exigences définies dans le Implémentation du module de noyau uid_cputime.
• [C-SR-4] FORTEMENT RECOMMANDÉ de rendre cette consommation électrique disponible via le adb shell dumpsys batterystats au développeur de l'application.
• DOIT être attribué au composant matériel lui-même s'il n'est pas en mesure de attribuer la consommation d'énergie des composants matériels à une application.

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée, soit à cause des autres applications s'exécutant en arrière-plan, soit en raison de la limitation du processeur en raison des limites de température. Android inclut des interfaces de programmation de sorte que, lorsque si l'appareil en est capable, l'application au premier plan peut demander que pour optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via le PowerManager.isSustainedPerformanceModeSupported() .

• DEVRAIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils sont compatibles avec le mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan supérieure un niveau cohérent pendant au moins 30 minutes, lorsque l'application le demande.
• [C-1-2] DOIT respecter les Window.setSustainedPerformanceMode() et d'autres API associées.

Si les implémentations d'appareils incluent au moins deux cœurs de processeur:

• DEVRAIT fournir au moins un cœur exclusif pouvant être réservé application de premier plan.

Si les implémentations d'appareils permettent de réserver un cœur exclusif au principal application de premier plan, ils:

• [C-2-1] DOIT le signaler via le Process.getExclusiveCores() Méthode API : numéros d'identification des cœurs exclusifs pouvant être réservés par l'application de premier plan.
• [C-2-2] NE DOIT PAS autoriser de processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application pour s'exécuter sur les cœurs exclusifs, mais PEUVENT permettre à certaines les processus du noyau pour s’exécuter selon les besoins.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, celles-ci:

• [C-3-1] DOIT renvoyer une liste vide via la propriété Process.getExclusiveCores() .

9. Compatibilité des modèles de sécurité

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans Document de référence sur la sécurité et les autorisations dans les API de la documentation pour les développeurs Android.

• [C-0-2] DOIT prendre en charge l'installation d'appareils autosignés sans avoir besoin d'autorisations/certificats supplémentaires à des tiers/autorités.

Si les implémentations d'appareils déclarent android.hardware.security.model.compatible fonctionnalité, ils:

• [C-1-1] DOIT respecter les exigences indiquées dans les sous-sections suivantes.

9.1. Autorisations

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations Android et le modèle de rôle Android tel que défini dans la documentation pour les développeurs Android. Plus précisément, ils doivent DOIT appliquer chaque autorisation et chaque rôle définis comme décrit dans les la documentation sur les SDK ; aucune autorisation, et aucun rôle ne peut être omis, modifié ou ignorées.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d’identifiant d’autorisation ne se trouvent pas dans l'espace de noms android.\*.

• [C-0-2] Autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED DOIT être accordée uniquement aux applications préinstallées dans le ou les chemins privilégiés du système. et dans le sous-ensemble des autorisations explicitement ajoutées à la liste d'autorisation pour chaque l'application. La mise en œuvre AOSP répond à cette exigence en lisant et en respectant les autorisations figurant sur la liste d'autorisation pour chaque application à partir des fichiers du chemin 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. Applications avec targetSdkVersion > 22 lors de l'exécution.

Implémentations pour les appareils:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider accorder ou non les autorisations d'exécution demandées une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] DOIT comporter une seule et même implémentation des deux de commande.
• [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux appareils applications, sauf si:
  • Le consentement de l'utilisateur peut être obtenu avant l'application l'utilise.
  • Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
• [C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement pour les applications système qui enregistrent un agent de récupération correctement sécurisé. A 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 à distance hors appareil, qui est équipé du matériel sécurisé avec une protection équivalente ou supérieure à celle décrits dans Service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations pour les appareils:

• [C-0-7] DOIT respecter les propriétés de l'autorisation d'accéder à la position Android lorsqu'une application demande les données de localisation ou d'activité physique via l'API Android standard ou un mécanisme propriétaire. Ces données incluent, sans s'y limiter:

  • la position de l'appareil (latitude et longitude, par exemple), comme décrit dans les section 9.8.8.
  • Informations permettant de déterminer ou d'estimer l'état (SSID, BSSID, ID de cellule GSM ou emplacement du réseau auquel l'appareil auquel il est connecté).
  • Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils:

• [C-0-8] DOIT obtenir le consentement de l'utilisateur pour permettre à une application d'accéder les données de localisation ou d'activité physique.
• [C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application qui détient une autorisation suffisante, comme décrit sur le SDK. Par exemple : TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les seules exceptions aux propriétés de l'autorisation d'accéder à la position Android ci-dessus concernent les Applications qui n'accèdent pas à la position pour déterminer ou identifier la position de l'utilisateur en particulier:

• Lorsque les applis détiennent l'autorisation RADIO_SCAN_WITHOUT_LOCATION.
• Pour les besoins de configuration de l'appareil, lorsque les applications système contiennent Autorisation NETWORK_SETTINGS ou NETWORK_SETUP_WIZARD.

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

• [C-0-10] Les autorisations comportant l'indicateur hardRestricted NE DOIVENT PAS être accordé à une application, sauf dans les cas suivants:

  • Un fichier APK d'application se trouve dans la partition du système.
  • L'utilisateur attribue un rôle associé à hardRestricted des autorisations à une application.
  • Le programme d'installation accorde le hardRestricted à une application.
  • Une application se voit attribuer le hardRestricted sur une version antérieure d'Android.

• [C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT être limitées un accès complet et NE DOIT PAS bénéficier d'un accès complet tant qu'il ne figure pas sur la liste d'autorisation, comme décrit dans les SDK, où un accès complet et limité est défini pour chaque softRestricted (par exemple, READ_EXTERNAL_STORAGE).

• [C-0-12] NE DOIT PAS fournir de fonctions ni d'API personnalisées permettant de contourner les restrictions d'autorisation définies dans setPermissionPolicy et setPermissionGrantState API.

• [C-0-13] DOIT utiliser les API AppOpsManager pour enregistrer et suivre chaque tout accès par programmation à des données protégées par des autorisations dangereuses Activités et services Android

• [C-0-14] NE DOIT attribuer des rôles qu'aux applications dotées de fonctionnalités répondent aux exigences du poste.

• [C-0-15] NE DOIT pas définir de rôles correspondant à des fonctionnalités en double ou sur-ensemble de rôles définis par la plate-forme.

Si les appareils signalent android.software.managed_users:

• [C-1-1] NE DOIT PAS disposer des autorisations suivantes, accordées silencieusement par le admin:
  • Emplacement (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • Caméra (CAMERA)
  • Micro (RECORD_AUDIO)
  • Capteur corporel (BODY_SENSORS)
  • Activité physique (ACTIVITÉ_RECOGNITION)

Si les implémentations d'appareils permettent à l'utilisateur de choisir les applications pouvant pour se superposer aux autres applications avec une activité qui gère ACTION_MANAGE_OVERLAY_PERMISSION l'intention, ils:

• [C-2-1] DOIT s'assurer que toutes les activités comportant des filtres d'intent pour ACTION_MANAGE_OVERLAY_PERMISSION ont le même écran d'UI, quelle que soit l'application les informations qu'il fournit.

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

• [C-3-1] DOIT afficher une clause de non-responsabilité lors de la configuration de l'appareil entièrement géré (configuration du propriétaire de l'appareil) indiquant que l'administrateur informatique sera en mesure de autoriser les applications à contrôler les paramètres du téléphone, y compris le micro, l'appareil photo et emplacement, avec des options permettant à l'utilisateur de poursuivre ou de quitter la configuration SAUF si le l'administrateur a désactivé le contrôle des autorisations sur l'appareil.

Si les implémentations d'appareils préinstallent les packages qui possèdent l'un des rôles System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence ou System Visual Intelligence, les packages:

• [C-4-1] DOIT respecter toutes les exigences décrites dans la section "9.8.6 Capture de contenu" pour les mises en œuvre d'appareils.
• [C-4-2] NE DOIT PAS disposer de l'autorisation android.permission.INTERNET. Cette valeur est plus stricte que les recommandations FORTEMENT RECOMMANDÉES figurant dans la section 9.8.6.
• [C-4-3] NE DOIT PAS être associé à d'autres applications, à l'exception des applications système suivantes: Bluetooth, Contacts, Multimédia, Téléphonie, SystemUI et composants fournissant des API Internet.Cette option est plus stricte que les recommandations FORTEMENT RECOMMANDÉES figurant dans la section 9.8.6.

9.2. UID et isolation de processus

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge l'application Android modèle de bac à sable, dans lequel chaque application s'exécute sous la forme d'un UID de style Unix unique et dans un processus distinct.
• [C-0-2] DOIT prendre en charge l'exécution de plusieurs applications sous le même identifiant utilisateur Linux, à condition que les applications soient correctement signées et construit, comme défini dans le Documentation de référence sur la sécurité et les autorisations

9.3. Autorisations du système de fichiers

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge l'accès aux fichiers Android du modèle d'autorisations, comme défini dans Documentation de référence sur la sécurité et les autorisations

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT assurer la cohérence des mesures de sécurité et modèle d'autorisation, même s'ils incluent des environnements d'exécution qui exécutent des applications utilisant d'autres logiciels ou technologies que l'exécutable Dalvik Format ou 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, tel que décrit dans d'autres sections comme indiqué dans la section 9.

• [C-0-2] Les autres environnements d'exécution NE DOIVENT PAS être autorisés à accéder aux ressources protégée par des autorisations non demandées dans le AndroidManifest.xml de l'environnement d'exécution via l'élément <uses-permission> sur le mécanisme d'attention.

• [C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS permettre aux applications d'utiliser fonctionnalités protégées par des autorisations Android limitées aux applications système.

• [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android et les applications installées utilisant un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable de toute autre application installée sur l'appareil, sauf via les mécanismes Android standard du partage d’un ID utilisateur et d’un certificat de signature.

• [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ou être accordés l'accès aux bacs à sable correspondant à d'autres applications Android.

• [C-0-6] D'autres environnements d'exécution NE DOIVENT PAS être lancés, accordés ni accordés à d'autres applications tout droit de super-utilisateur (racine) ou de toute autre ID utilisateur.

• [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans le fichier image système des implémentations de l'appareil, elle DOIT être signée avec une clé distincte à partir de la clé utilisée pour signer les autres applications incluses dans l'appareil mises en œuvre.

• [C-0-8] Lors de l'installation d'applications, d'autres environnements d'exécution 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 qui dispose d'une autorisation Android correspondante (comme Appareil photo, GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

• [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les applications de cette manière, l'environnement d'exécution DOIT répertorier toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement.

• D'autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

• D'autres environnements d'exécution PEUVENT fournir un seul bac à sable Android partagé par tous des applications utilisant un autre environnement d'exécution.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs. Il permet l'isolation complète et permet de cloner des profils utilisateur isolement partiel(c'est-à-dire un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE).

• Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur s'ils utilisent support amovible pour le stockage externe principal.

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

• [C-1-2] DOIT, pour chaque utilisateur, mettre en œuvre cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans Document de référence sur la sécurité et les autorisations dans les API.
• [C-1-3] DOIT disposer d'un espace de stockage d'application partagé séparé et isolé (également appelés /sdcard) pour chaque instance d'utilisateur.
• [C-1-4] DOIT s'assurer que les applications détenues et exécutées pour le compte ne peut pas répertorier, lire ou écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
• [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système les implémentations d'appareils utilisent des supports amovibles pour les API de stockage externe. Comme cela rend le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes les aux données de l'utilisateur actuel.

Si les implémentations d'appareils prennent en charge plusieurs utilisateurs, alors pour tous les utilisateurs, à l'exception de ceux créés spécialement pour exécuter des instances doubles d'une même application:

• [C-2-1] DOIT disposer d'un espace de stockage d'application partagé séparé et isolé (également appelés /sdcard) pour chaque instance d'utilisateur.
• [C-2-2] DOIT s'assurer que les applications appartenant à et exécutées sur ne peut ni répertorier, ni lire, ni écrire dans les fichiers dont le propriétaire est par un autre utilisateur, même si les données de ces deux utilisateurs sont stockées sur le même le volume ou le système de fichiers.

Les mises en œuvre d'appareils PEUVENT créer un seul profil utilisateur supplémentaire de type android.os.usertype.profile.CLONE par rapport à l'utilisateur principal (et uniquement à l'utilisateur principal) afin d'exécuter deux instances de la même application. Ces instances doubles partagent un stockage partiellement isolé, sont présentées utilisateur final dans le lanceur d’applications en même temps et apparaissent dans la même vue récentes. Par exemple, cela peut permettre à l'utilisateur d'installer deux instances d'une seule application sur un appareil avec double carte SIM.

Si les mises en œuvre de l’appareil créent le profil utilisateur supplémentaire mentionné ci-dessus, ils:

• [C-3-1] DOIT fournir uniquement un accès à l'espace de stockage ou aux données accessible au profil utilisateur parent ou dont il est le propriétaire direct profil utilisateur supplémentaire.
• [C-3-2] NE DOIT PAS avoir ceci comme profil professionnel.
• [C-3-3] DOIT avoir des répertoires de données d'application privés isolés du parent compte utilisateur.
• [C-3-4] NE DOIT PAS permettre la création d'un profil utilisateur supplémentaire est un propriétaire d'appareil provisionné (voir la section 3.9.1) ou autorise un propriétaire de l'appareil ; sans supprimer le profil utilisateur supplémentaire au préalable.

9.6. Avertissement relatif aux SMS premium

Android permet d'avertir les utilisateurs en cas de SMS premium. SMS premium messages sont des SMS envoyés à un service enregistré auprès d'un opérateur qui peut entraîner des frais pour l'utilisateur.

Si les implémentations d'appareils déclarent la prise en charge de android.hardware.telephony, ils:

• [C-1-1] DOIT avertir les utilisateurs avant d'envoyer un SMS à un numéro identifié par des expressions régulières définies dans /data/misc/sms/codes.xml sur l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le framework (SELinux), système de contrôle des accès obligatoire (MAC), système de bac à sable seccomp, etc. les fonctionnalités de sécurité dans le noyau Linux. Implémentations pour les appareils:

• [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité sont implémentées en dessous de d'infrastructure.
• [C-0-2] NE DOIT PAS avoir d'interface utilisateur visible violation a été détectée et bloquée par la fonctionnalité de sécurité implémentées sous le framework Android, mais PEUVENT disposer d'une interface utilisateur visible lorsqu'une violation de sécurité débloquée entraîne un exploit réussi.
• [C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android, configurable pour l'utilisateur ou le développeur de l'application.
• [C-0-4] NE DOIT PAS autoriser une application pouvant affecter une autre via une API (telle qu'une API Device Administration) pour configurer une stratégie qui rompt la compatibilité.
• [C-0-5] DOIT diviser le framework multimédia en plusieurs processus est possible d'accorder l'accès à chaque processus de manière plus précise, décrit sur le site du projet Android Open Source.
• [C-0-6] DOIT implémenter un mécanisme de bac à sable pour l'application du noyau qui permet de filtrer les appels système à l'aide d'une règle configurable les programmes multithread. Le projet Android Open Source en amont répond à cette en activant seccomp-BPF avec threadgroup (TSYNC) comme décrit ici, dans la section "Configuration du noyau" de source.android.com.

Les fonctionnalités d'intégrité du noyau et d'auto-protection font partie intégrante d'Android la sécurité. Implémentations pour les appareils:

• [C-0-7] DOIT implémenter des mécanismes de protection contre le débordement de la mémoire tampon de la pile du noyau. Exemples : CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG
• [C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau lorsque les fichiers exécutables le code est en lecture seule, les données en lecture seule ne sont pas exécutables et non accessibles en écriture ; et des données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DOIT implémenter des tailles d'objets statiques et dynamiques vérification des limites des copies entre espace utilisateur et espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec un niveau d'API 28 ou version ultérieure.
• [C-0-10] NE DOIT PAS exécuter la mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, avec un PXN matériel ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils était livré avec le niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire espace utilisateur dans le noyau en dehors des API d'accès usercopy normales (par exemple, PAN matériel ou émulée via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-12] DOIT implémenter l'isolation des tables de pages du noyau si le matériel est vulnérable à la faille CVE-2017-5754 sur tous les appareils livrés avec le niveau d'API à l'origine 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 à la faille CVE-2017-5715 sur tous les appareils livrés à l'origine avec ce niveau d'API 28 ou version ultérieure (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR)
• [C-SR-1] VIVEMENT RECOMMANDÉ de conserver les données du noyau qui est écrit uniquement lors de l'initialisation et est marqué en lecture seule après l'initialisation (par exemple, __ro_after_init).

• [C-SR-2] SONT FORTEMENT RECOMMANDÉS de randomiser la disposition du code du noyau et mémoire, et d'éviter les expositions qui pourraient compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec entropie du bootloader via le /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans du noyau pour fournir une protection supplémentaire contre les attaques de réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI), Shadow Call Stack (SCS) ou Integer Overflow Sanitization (IntSan) activé composants sur lesquels il est activé.

• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour d'autres composants d'espace utilisateur sensibles, comme expliqué dans CFI et IntSan.

• [C-SR-6] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour empêcher l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer que la valeur utilisée par le compilateur pour initialiser les paramètres locaux.

• [C-SR-7] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas de mémoire dans le noyau pour empêcher l'utilisation d'allocations de segments de mémoire non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON), et 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 capable de prendre en charge SELinux:

• [C-1-1] DOIT implémenter SELinux.
• [C-1-2] DOIT définir SELinux sur le mode d'application global.
• [C-1-3] DOIT configurer tous les domaines en mode "Enforcing". Aucun mode permissif les domaines sont autorisés, y compris les domaines propres à un appareil/fournisseur.
• [C-1-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes au sein du dossier system/sepolicy fourni dans le package Android Open Source en amont Project (AOSP) et la stratégie DOIVENT se compiler avec toutes les règles "Neverallow" présentes, pour les domaines AOSP SELinux ainsi que pour les domaines propres à l'appareil ou au fournisseur.
• [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application, avec des restrictions SELinux par application le répertoire de données privé de l'application.
• DEVRAIT conserver la règle SELinux par défaut fournie dans le fichier system/sepolicy du projet Android Open Source en amont et ne compléter que pour leur propre configuration spécifique à l'appareil.

Si les implémentations de périphériques utilisent un noyau autre que Linux ou Linux sans SELinux, ils:

• [C-2-1] DOIT utiliser un système obligatoire de contrôle des accès équivalent à SELinux.

Si les implémentations d'appareils utilisent des périphériques d'E/S compatibles avec la loi sur les marchés numériques, ils:

• [C-SR-8] Il est FORTEMENT RECOMMANDÉ d'isoler chaque périphérique d'E/S compatible avec la loi DMA à l'aide d'un IOMMU (par exemple, l'ARM SMMU).

Android contient plusieurs fonctionnalités de défense en profondeur intégrées à l’appareil la sécurité. De plus, Android s'efforce de réduire les classes clés de bugs courants qui contribuent à la mauvaise qualité et à la sécurité.

Afin de réduire les bugs de mémoire, les implémentations d'appareils:

• [C-SR-9] EST FORTEMENT RECOMMANDÉ d'être testés sur l'erreur de mémoire de l'espace utilisateur des outils de détection tels que MTE pour les appareils ARMv9, HWASan pour les appareils ARMv8+ ou ASan pour les autres types d'appareils.
• [C-SR-10] Il est FORTEMENT RECOMMANDÉ d'être testé en utilisant l'erreur de mémoire du noyau. des outils de détection tels que KASAN (CONFIG_KASAN, CONFIG_KASAN_HW_TAGS pour Appareils ARMv9, CONFIG_KASAN_SW_TAGS pour les appareils ARMv8 ou CONFIG_KASAN_GENERIC pour les autres types d'appareils).
• [C-SR-11] Il est FORTEMENT RECOMMANDÉ d'utiliser des outils de détection des erreurs de mémoire dans de production comme MTE, GWP-ASan et KFENCE.

Si les implémentations d'appareils utilisent un TEE basé sur Arm TrustZone, elles:

• [C-SR-12] Il est FORTEMENT RECOMMANDÉ d'utiliser un protocole standard pour la mémoire entre Android et le TEE, comme le framework de micrologiciel Arm pour Armv8-A (FF-A).
• [C-SR-13] Il est FORTEMENT RECOMMANDÉ de limiter les applications approuvées aux seules applications accédant à la mémoire qui a été explicitement partagée avec eux via la méthode ci-dessus standard. Si l'appareil est compatible avec le niveau d'exception S-EL2 ARM, doit être appliquée par le gestionnaire de partitions sécurisées. Sinon, il doit s'agir appliquée par le TEE OS.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et gère cet historique en UsageStatsManager

Implémentations pour les appareils:

• [C-0-1] DOIT conserver une durée de conservation raisonnable de cet historique utilisateur.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours configurés par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide de la StatsLog les identifiants, et gère cet historique via StatsManager et API système IncidentManager.

Implémentations pour les appareils:

• [C-0-2] DOIT inclure uniquement les champs marqués d'un DEST_AUTOMATIC dans rapport d'incident créé par la classe IncidentManager de l'API système.
• [C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour consigner tout autre événement que ce qui est décrit dans le fichier StatsLog Documents du SDK. Si d'autres événements système sont consignés, ils PEUVENT utiliser une un identifiant atomique différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui d'envoyer des informations privées sur l'utilisateur (par exemple, les frappes au clavier, le texte affiché sur le écran, rapport de bug) de l'appareil sans l'autorisation de l'utilisateur notifications en cours.
• [C-0-2] OBLIGATOIRE D'afficher et d'obtenir le consentement explicite de l'utilisateur, autorisant toute information les informations affichées sur l'écran de l'utilisateur doivent être capturées la diffusion ou l'enregistrement d'écran est activé via MediaProjection ou propriétaires. NE DOIT PAS fournir aux utilisateurs une affordance de désactiver l'avenir le consentement de l'utilisateur.
• [C-0-3] DOIT recevoir une notification d'activité en cours à l'utilisateur pendant la diffusion de l'écran ou l'enregistrement d'écran est activé. AOSP répond à cette exigence en présentant une l'icône de notification d'activité en cours dans la barre d'état.

Si les implémentations d'appareils incluent des fonctionnalités dans le système qui : capture le contenu affiché à l'écran et/ou enregistre le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ; ou d'autres moyens propriétaires décrits dans Section 9.8.6 Capture de contenu:

• [C-1-1] DOIT recevoir une notification d'activité en cours à l'utilisateur sont activées et capturent/enregistrent activement des données.

Si les implémentations d'appareils incluent un composant activé prêt à l'emploi, capable de enregistrer le son ambiant et/ou enregistrer le son lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, il:

• [C-2-1] NE DOIT PAS stocker de données dans un espace de stockage persistant sur l'appareil ni transmettre le son brut enregistré ou tout format pouvant être reconverti en le contenu audio original ou une copie proche de celle-ci, sauf avec le consentement explicite de l'utilisateur.

Un "indicateur de micro" fait référence à une vue à l'écran, qui est constamment visible à l'utilisateur et ne doit pas être dissimulé, ce que les utilisateurs comprennent en raison de la présence d'un micro utiliser(par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Un "indicateur d'appareil photo" désigne une vue à l'écran, qui est constamment visible par l'utilisateur et ne doit pas être dissimulée (ce que les utilisateurs comprennent lorsqu'une caméra est en cours d'utilisation). (par le biais d'un texte, d'une couleur, d'une icône ou d'une combinaison unique).

Après la première seconde affichée, un indicateur peut changer visuellement, par exemple : diminue et n'est pas nécessaire pour s'afficher tel qu'il était présenté initialement. compris.

L'indicateur du micro peut être fusionné avec une caméra affichée activement indicateur, à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que l'utilisation du micro a commencé.

L'indicateur de l'appareil photo peut être fusionné avec un micro affiché en cours. à condition que le texte, les icônes ou les couleurs indiquent à l'utilisateur que de la caméra a commencé.

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

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur du micro lorsqu'une application accède aux données audio du micro, mais pas lorsqu'il est uniquement accessible par HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService, ou une ou plusieurs applications détenant les rôles décrits dans la section 9.1 Autorisations avec identifiant CDD [C-3-X]. .
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'afficher les listes "Récents" et "Actifs" les applications utilisant le micro comme renvoyées par PermissionManager.getIndicatorAppOpUsageData(), et toute attribution messages qui leur sont associés.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de micro les applications système qui ont des interfaces utilisateur visibles ou une interaction directe de l’utilisateur.

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

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ d'afficher l'indicateur de l'appareil photo lorsqu'une application accéder aux données en direct de la caméra, mais pas lorsqu'elle est uniquement en cours d'accès par une ou plusieurs applications détenant les rôles décrits à la section 9.1 Autorisations avec le CDD identifiant [C-3-X].
• [C-SR-5] Il est FORTEMENT RECOMMANDÉ d'afficher les applications récentes et actives avec appareil photo renvoyé par PermissionManager.getIndicatorAppOpUsageData(), ainsi que tous les messages d'attribution qui leur sont associés.
• [C-SR-6] Il est FORTEMENT RECOMMANDÉ de ne pas masquer l'indicateur de l'appareil photo du système les applications dont l'interface utilisateur est visible ou dont l'interaction directe avec l'utilisateur est visible

9.8.3. Connectivité

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

• [C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant permettant d'accéder au contenu du stockage partagé sur le port USB.

9.8.4. Trafic réseau

Implémentations pour les appareils:

• [C-0-1] DOIT préinstaller les mêmes certificats racine pour le certificat Magasin de l'autorité de certification (CA) fourni dans le projet Open Source Android en amont.
• [C-0-2] DOIT être livré avec un magasin d'autorités de certification racine d'utilisateur vide.
• [C-0-3] DOIT afficher un avertissement indiquant à l'utilisateur le trafic réseau peuvent être surveillées, lorsqu'une AC racine d'utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations d'appareils:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant:
  • Ce trafic réseau peut être surveillé.
  • Ce trafic réseau est acheminé via le VPN l'application fournissant 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échargement d'un service VPN avec android.permission.CONTROL_VPN accordé), il:

• [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme. sauf si ce VPN est activé par l'outil de contrôle des règles relatives aux appareils via la DevicePolicyManager.setAlwaysOnVpnPackage() . Dans ce cas, l'utilisateur n'a pas besoin de donner un consentement distinct, mais DOIT seulement être notifiés.

Si les implémentations d'appareils implémentent une affordance utilisateur, activez "VPN permanent" d'une application VPN tierce, ils:

• [C-3-1] DOIT désactiver cette affordance utilisateur pour les applications non compatibles le service VPN permanent dans le fichier AndroidManifest.xml en définissant SERVICE_META_DATA_SUPPORTS_ALWAYS_ON à false.

9.8.5. Identifiants des appareils

Implémentations pour les appareils:

• [C-0-1] DOIT empêcher l'accès au numéro de série de l'appareil et, si code IMEI/MEID, numéro de série de la carte SIM et International Mobile Identité d'abonné (IMSI) d'une application, sauf si elle répond à l'un des critères suivants configuration requise:
  • est une application d'opérateur signée qui est validée par les fabricants d'appareils.
  • L'autorisation READ_PRIVILEGED_PHONE_STATE a été accordée.
  • dispose de privilèges d'opérateur tels que définis dans les droits d'opérateur de l'UICC.
  • est le propriétaire de l'appareil ou du profil auquel le Autorisation READ_PHONE_STATE.
  • (Pour le numéro de série de la carte SIM/ICCID uniquement) est conforme aux exigences de la réglementation locale que l'application détecte les changements dans l'identité de l'abonné.

9.8.6. Capture de contenu et recherche d'applications

Android, via l'API système ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query ou d'autres des moyens propriétaires, est compatible avec un mécanisme permettant aux implémentations d'appareils de capturer les interactions de données d'application suivantes entre les applications l'utilisateur:

• Le texte et les images affichées à l'écran, y compris, mais sans s'y limiter : notifications et données d'assistance via AssistStructure API.
• Données multimédias, telles que du contenu audio ou vidéo, enregistrées ou lues par l'appareil.
• Événements d'entrée (par exemple, touche, souris, geste, voix, vidéo et accessibilité)
• Tout autre événement fourni par une application au système via le Content Capture ou une API AppSearchManager, un appareil Android et API propriétaire.
• Tout texte ou toute autre donnée envoyé via le TextClassifier API au TextClassifier système, c'est-à-dire au service système, pour comprendre la signification du texte et générer des prédictions d'actions suivantes en fonction le texte.
• Données indexées par l'implémentation de la plate-forme AppSearch, y compris, mais pas se limite au texte, aux graphiques, aux données multimédias ou à d'autres données similaires.

Si les implémentations d'appareils collectent les données ci-dessus, elles:

• [C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées sur l'appareil. Ce le chiffrement PEUT être effectué à l'aide du chiffrement basé sur les fichiers Android, des algorithmes de chiffrement répertoriés dans la version 26 ou ultérieure de l'API, décrits dans le SDK de chiffrement.
• [C-1-2] NE DOIT PAS sauvegarder de données brutes ou chiffrées via des Méthodes de sauvegarde Android ou tout autre retour .
• [C-1-3] DOIT envoyer l'ensemble de ces données et le journal de l'appareil uniquement à l'aide d'un de protection de la confidentialité. Mécanisme de protection de la confidentialité est défini comme "ceux qui autorisent uniquement une analyse globale et empêchent la mise en correspondance des événements consignés ou des résultats dérivés avec des utilisateurs individuels", empêcher l'introspection de données par utilisateur (par exemple, en implémentant des une technologie de confidentialité différentielle comme RAPPOR).
• [C-1-4] NE DOIT PAS associer ces données à l'identité d'un utilisateur (tel que en tant que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont associées.
• [C-1-5] NE DOIT PAS partager ces données avec d'autres composants du système d'exploitation qui n'utilisent pas respecter les exigences décrites dans la section actuelle (9.8.6 Capture de contenu), sauf avec le consentement explicite de l'utilisateur à chaque fois il est partagé.
• [C-1-6] DOIT fournir une affordance à l'utilisateur pour effacer les données qui l'ContentCaptureService ou le moyen propriétaire collecte si le les données sont stockées sous n'importe quelle forme sur l'appareil.
• [C-1-7] DOIT fournir une affordance à l'utilisateur pour le refus des données, collectées via AppSearch ou des moyens propriétaires d'être diffusés sur la plate-forme Android Ex. : lanceur d'applications.
• [C-SR-1] IL EST FORTEMENT RECOMMANDÉ de NE PAS demander l'autorisation INTERNET.
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de n'accéder à Internet que via structurées et basées sur des implémentations Open Source publiques.

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService, AppSearchManager.index ou tout service propriétaire qui capture les données comme décrit ci-dessus, il:

• [C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer les services par un application ou service installable par l'utilisateur et DOIT autoriser uniquement services préinstallés pour capturer de telles données.
• [C-2-2] NE DOIT PAS autoriser d'applications autres que les services préinstallés pour capturer de telles données.
• [C-2-3] DOIT fournir une affordance à l'utilisateur pour désactiver les services.
• [C-2-4] NE DOIT PAS omettre l' affordance de l'utilisateur pour gérer les autorisations Android qui sont détenus par les services et respectent les autorisations Android tel que décrit dans la Section 9.1. Autorisation.

• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de séparer les services des autres Composants système(par exemple, absence de liaison du service ou partage d'ID de processus) hormis pour les cas suivants:

  • Téléphonie, contacts, UI du système et médias

Android, via SpeechRecognizer#onDeviceSpeechRecognizer(), offre la possibilité pour effectuer une reconnaissance vocale sur l'appareil, sans impliquer le réseau. Toute implémentation de la reconnaissance vocale sur l'appareil DOIT respecter les règles décrits dans cette section.

9.8.7. Accès au presse-papiers

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS renvoyer de données tronquées dans le presse-papiers (par exemple, via le ClipboardManager API), sauf s'il s'agit de l'IME par défaut ou de l'application qui a actuellement le focus.

9.8.8. Position

La localisation inclut les informations de la classe de localisation Android( comme Latitude, (longitude, altitude), ainsi que les identifiants pouvant être convertis en lieux. La localisation peut être aussi précise que le DGPS (Differential Global Positioning System) grossièrement au niveau du pays (par exemple, l'emplacement avec l'indicatif du pays - CM - Mobile) Code pays).

Vous trouverez ci-dessous la liste des types de lieux qui déterminent directement ou convertir celle d'un utilisateur. Cette liste n'est pas exhaustive mais ils doivent servir d'exemple pour déterminer sont indirectement dérivées de:

• GPS/GNSS/DGPS/PPP
  • Solution de positionnement global ou système de navigation satellite par satellite, ou Solution de positionnement global différentiel
  • Cela inclut également les mesures GNSS brutes et l'état GNSS
    • La position précise peut être obtenue à partir des mesures GNSS brutes
• Technologies sans fil avec des identifiants uniques tels que:
  • Points d'accès Wi-Fi (MAC, BSSID, nom ou SSID)
  • Bluetooth/BLE (MAC, BSSID, nom ou SSID)
  • UWB (MAC, BSSID, nom ou SSID)
  • Identifiant de la tour de téléphonie mobile (3G, 4G, 5G, etc., y compris tous les futurs modems mobiles) technologies à identifiants uniques)

Comme point de référence principal, consultez les API Android qui nécessitent ACCESS_FINE_Location ou ACCESS_COARSE_Autorisations d'accès à la position.

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS activer/désactiver la localisation de l'appareil ni le Wi-Fi/Bluetooth. les paramètres d'analyse sans consentement explicite ni initiation de l'utilisateur.
• [C-0-2] DOIT fournir à l'utilisateur les affordances d'accès liées à la localisation comme les demandes de localisation récentes, les autorisations au niveau des applis et leur utilisation de recherche Wi-Fi/Bluetooth pour déterminer la position.
• [C-0-3] DOIT s'assurer que l'application qui utilise l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] est une urgence déclenchée par l'utilisateur. (par exemple, appeler le 112 ou envoyer un SMS au 112). Pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction de l'utilisateur actif dans le dossier si un accident ou un accident est détecté (par exemple, pour répondre aux exigences d'eCall).
• [C-0-4] DOIT préserver la capacité de l'API Emergency Location Bypass ignorer les paramètres de localisation de l'appareil sans les modifier ;
• [C-0-5] DOIT programmer une notification de rappel à l'utilisateur après qu'une application l'arrière-plan a accédé à sa position à l'aide de Autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas afficher d'informations sur les autres installées par défaut (voir la section Visibilité des packages dans le dans la documentation du SDK).

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS exposer aux détails d'une application ciblant le niveau d'API 30 ou supérieur. sur toute autre application installée, sauf si l'application a déjà accès aux détails sur l'autre application installée via les API gérées. Cela inclut, mais est sans s'y limiter les informations fournies par les API personnalisées ajoutées par l'appareil ou accessibles via le système de fichiers.
• [C-0-2] NE DOIT PAS accorder à une application un accès en lecture ou en écriture aux fichiers d'une répertoire dédié et spécifique à l'application dans un espace de stockage externe. Les seules exceptions sont les suivantes:
  • Autorité du fournisseur de stockage externe (par exemple, des applications telles que DocumentsUI).
  • Fournisseur de téléchargement utilisant l'autorité de fournisseur "téléchargements" pour télécharger des fichiers vers l'espace de stockage de l'application.
  • Les applications MTP (Media Transfer Protocol) signées par la plate-forme qui utilisent l’autorisation privilégiée ACCESS_MTP pour permettre le transfert de fichiers vers un autre appareil.
  • Applications qui installent d'autres applications et qui disposent de l'autorisation INSTALLER_PACKAGES ne peuvent accéder qu'aux répertoires "obb" afin de gérer Fichiers d'extension pour APK

9.8.10. Rapport de bug de connectivité

Si les implémentations d'appareils déclarent le flag de fonctionnalité android.hardware.telephony, ils:

• [C-1-1] DOIT prendre en charge la génération de rapports de bugs de connectivité via BUGREPORT_MODE_TELEPHONY avec BugreportManager.
• [C-1-2] DOIT obtenir le consentement de l'utilisateur chaque fois que BUGREPORT_MODE_TELEPHONY utilisée pour générer un rapport et NE DOIT PAS inviter l'utilisateur à donner son consentement les futures requêtes de l'application.
• [C-1-3] NE DOIT PAS renvoyer le rapport généré à l'application à l'origine de la demande le consentement explicite de l'utilisateur.
• [C-1-4] Les rapports générés avec BUGREPORT_MODE_TELEPHONY DOIVENT contenir au moins les informations suivantes:
  • Fichier de dump TelephonyDebugService
  • Fichier de dump TelephonyRegistry
  • Fichier de dump WifiService
  • Fichier de dump ConnectivityService
  • Un vidage de l'instance CarrierService du package appelant (si lié)
  • Tampon journal radio
• [C-1-5] NE DOIT PAS inclure les éléments suivants dans les rapports générés:
  • Toute sorte d'information qui n'est pas directement liée à la connectivité le débogage.
  • Tout type de journaux de trafic ou de profils détaillés installés sur les applications installées par l'utilisateur des applications/packages installés par l'utilisateur (les UID sont acceptables, les noms de packages sont non).
• PEUT inclure des informations supplémentaires qui ne sont associées à aucun utilisateur. l'identité. (par exemple, les journaux des fournisseurs).

Si la mise en œuvre des appareils inclut des informations supplémentaires (par exemple, les journaux des fournisseurs) dans des rapports de bugs et que les informations ont des règles de confidentialité, de sécurité, de batterie, de stockage ou de mémoire. impact, elles:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ d'avoir un paramètre de développeur défini par défaut sur est désactivé. L'implémentation de référence AOSP répond à ce besoin en fournissant le Enable verbose vendor logging. dans les paramètres du développeur pour inclure des journaux supplémentaires de fournisseurs spécifiques à l'appareil dans les rapports de bug.

9.8.11. Partage de blobs de données

Android, via BlobStoreManager permet aux applications de fournir des blobs de données au système à partager avec un ensemble d'applications.

Si les implémentations d'appareils sont compatibles avec les blobs de données partagées, comme décrit dans le Documentation sur les SDK ils:

• [C-1-1] NE DOIT PAS partager de blobs de données appartenant à des applications au-delà destinés à autoriser (c'est-à-dire le champ d'application de l'accès par défaut et les autres modes qui peuvent être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess(), ou BlobStoreManager.session#allowPublicAccess() NE DOIVENT PAS être modifiées). L'implémentation de référence AOSP répond à ces exigences.
• [C-1-2] NE DOIT PAS envoyer les hachages sécurisés depuis l'appareil ni les partager avec d'autres applications de blobs de données (qui sont utilisés pour contrôler les accès).

9.8.12. Reconnaissance musicale

Android, par le biais de MusicRecognitionManager de l'API système, prend en charge un mécanisme pour des implémentations d'appareils pour demander la reconnaissance musicale à partir d'un enregistrement audio ; déléguer la reconnaissance musicale à une application privilégiée l'API MusicRecognitionService.

Si les implémentations d'appareils incluent un service qui implémente l'API System MusicRecognitionManager ou tout service propriétaire qui diffuse des données audio en tant que décrits ci-dessus, ils:

• [C-1-1] DOIT faire en sorte que l'appelant de MusicRecognitionManager conserve la Autorisation MANAGE_MUSIC_RECOGNITION
• [C-1-2] OBLIGATOIRE qu'un système de reconnaissance musicale unique préinstallé implémente MusicRecognitionService.
• [C-1-3] NE DOIT PAS autoriser les utilisateurs à remplacer MusicRecognitionManagerService ou MusicRecognitionService par une application ou un service installables par l'utilisateur.
• [C-1-4] DOIT s'assurer que lorsque MusicRecognitionManagerService accède au l'enregistrement audio et le transmet à l'application mettant en œuvre MusicRecognitionService, le suivi de l'accès audio est effectué via des appels de AppOpsManager.noteOp / startOp :

Si les implémentations de MusicRecognitionManagerService sur les appareils MusicRecognitionService stocke toutes les données audio capturées, qui:

• [C-2-1] NE DOIT PAS stocker d'empreintes audio ou audio brutes sur le disque. ou en mémoire pendant plus de 14 jours.
• [C-2-2] NE DOIT PAS partager ces données au-delà du service MusicRecognitionService, sauf avec le consentement explicite de l'utilisateur à chaque partage.

9.8.13. SensorPrivacyManager

Si les implémentations d'appareils fournissent à l'utilisateur une affordance logicielle pour désactiver l'entrée de la caméra et/ou du micro pour l'implémentation de l'appareil:

• [C-1-1] DOIT renvoyer avec précision la valeur "true" pour les supportsSensorToggle() .
• [C-1-2] OBLIGATOIRE lorsqu'une application tente d'accéder à un micro ou à une caméra bloqués présentent à l'utilisateur une affordance qu'il ne peut pas ignorer, indique que le capteur est bloqué et nécessite la possibilité de continuer de blocage ou de déblocage conformément à l'implémentation AOSP, cette exigence.
• [C-1-3] NE DOIT transmettre que des données d'appareil photo et audio vides (ou factices) aux applications et ne pas signaler de code d'erreur, car l'utilisateur n'allume pas la caméra ni le micro via l' affordance de l'utilisateur présentée comme [C-1-2] ci-dessus.

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT respecter les exigences de la section 9.9.1. Les appareils lancés à un niveau d'API antérieur à celui indiqué dans ce document sont êtes exempté des exigences des sections 9.9.2 et 9.9.3 ; à la place, ils DOIT respecter les exigences de la section 9.9 du règlement de compatibilité Android Document de définition correspondant au niveau d'API sur lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter les API en mode Démarrage direct, même si ils ne sont pas compatibles avec le chiffrement du stockage.

• [C-0-2] Le ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED Les intents DOIVENT être diffusés pour signaler les applications compatibles avec le démarrage direct qui Les emplacements de stockage de chiffrement d'appareil (DE) et de chiffrement d'identifiant (CE) sont à la disposition de l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations pour les appareils:

• [C-0-1] DOIT chiffrer l'application en mode privé (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil.
• [C-0-2] DOIT activer le chiffrement du stockage des données par défaut à chaque fois l'utilisateur a terminé la configuration initiale.

• [C-0-3] DOIT respecter les exigences de chiffrement du stockage de 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 du bloc par utilisateur, comme décrit dans la section 9.9.3.2.

Remarque :Les implémentations d'appareils livrées avec un niveau d'API 28 ou antérieur et qui ne répondent pas aux exigences de la section 9.9.2 via une mise à jour logicielle système DOIVENT respecter Les exigences indiquées dans la section 9.9 du document sur la définition de compatibilité Android correspondant au niveau d'API sur lequel l'appareil a été expédié.

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareils sont chiffrées, elles:

• [C-1-1] DOIT démarrer sans demander à l'utilisateur d'obtenir des identifiants Autoriser les applications compatibles avec le démarrage direct à accéder au stockage DE (Device Encrypted) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
• [C-1-2] DOIT autoriser l'accès au stockage CE (Identifiants chiffrés) uniquement après l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (code secret, code, schéma ou empreinte digitale, par exemple) et l'ACTION_USER_UNLOCKED le message est diffusé.
• [C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller l'espace de stockage protégé par CE sans les informations d'identification fournies par l'utilisateur, une clé de séquestre enregistrée ou un à la mise en œuvre du redémarrage répondant aux exigences de section 9.9.4.
• [C-1-4] DOIT utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers et métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec chiffrement des métadonnées, ils:

• [C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide de AES-256-XTS ou Adiantum. L'acronyme AES-256-XTS désigne la norme avec une longueur de clé de chiffrement de 256 bits, exploitée en mode XTS ; toute la durée est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme spécifié dans https://github.com/google/adiantum Les métadonnées du système de fichiers sont des données telles que les tailles, la propriété, les modes et les attributs étendus (xattrs).
• [C-1-6] DOIT chiffrer les noms de fichiers à l'aide de l'algorithme AES-256-CBC-CTS ou Adiantum.
• [C-1-12] Si l'appareil est doté de la norme AES (Advanced Encryption Standard) (telles que les extensions de cryptographie ARMv8 sur les appareils ARM, ou AES-NI sur les appareils basés sur x86), puis les options basées sur AES ci-dessus pour le nom de fichier, le contenu des fichiers et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisés, et non Adiantum.
• [C-1-13] DOIT utiliser une clé cryptographiquement sécurisée et non réversible de dérivation (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, clés par fichier) à partir des clés CE et DE. « Cryptographiquement solide et non réversible" signifie que la fonction de dérivation de clé a un pouvoir de sécurité d'au moins 256 bits et se comporte comme une fonction pseudo-aléatoire famille sur ses entrées.
• [C-1-14] NE DOIT PAS utiliser les mêmes clés ni sous-clés de chiffrement basé sur les fichiers (FBE) à des fins de chiffrement différentes (par exemple, pour le chiffrement et ou pour deux algorithmes de chiffrement différents).
• [C-1-15] DOIT s'assurer que tous les blocs de contenus de fichiers chiffrés non supprimés sur le stockage persistant étaient chiffrés à l'aide de combinaisons de clés vecteur d'initialisation (IV) qui dépend à la fois du fichier et du décalage dans le fichier. De plus, toutes ces combinaisons DOIVENT être distinctes, sauf si le chiffrement s'effectue à l'aide de matériel de chiffrement intégré qui n'accepte IV de 32 bits.
• [C-1-16] DOIT s'assurer que tous les noms de fichiers chiffrés non supprimés sur des disques persistants le stockage dans des répertoires distincts était chiffré à l'aide de combinaisons distinctes la clé de chiffrement et le vecteur d'initialisation (IV).

• [C-1-17] DOIT s'assurer que tous les blocs de métadonnées chiffrés du système de fichiers le stockage persistant étaient chiffrés à l'aide de combinaisons distinctes de clés et le vecteur d'initialisation (IV).

• Clés protégeant les zones de stockage CE et DE et les métadonnées du système de fichiers:

  • [C-1-7] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et au matériel de l'appareil racine de confiance.
  • [C-1-8] Les clés CE DOIVENT être liées aux identifiants de l'écran de verrouillage d'un utilisateur.
  • [C-1-9] Les clés CE DOIVENT être liées à un code secret par défaut lorsque l'utilisateur a identifiants d'écran de verrouillage non spécifiés.
  • [C-1-10] DOIT être unique et distinct, autrement dit, aucun certificat CE ou DE correspond aux clés CE ou DE de n'importe quel autre utilisateur.
  • [C-1-11] DOIT utiliser les algorithmes de chiffrement, longueurs de clé et différents modes.
  • [C-1-12] DOIT être effacés de manière sécurisée lors du déverrouillage et du verrouillage du bootloader. comme décrit ici.

• DEVRAIT créer des applications essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) Prise en compte du démarrage direct.

Le projet Android Open Source en amont offre une implémentation privilégiée Chiffrement basé sur les fichiers basé sur le noyau Linux "fscrypt" de chiffrement, et le chiffrement des métadonnées basé sur le noyau Linux "dm-default-key". .

Remarque :Les implémentations d'appareils livrées à partir du niveau d'API 28 ou antérieur et qui ne répond pas aux exigences de la section 9.9.3 via une mise à jour logicielle système DOIT respecter les exigences indiquées dans la section 9.9 du document sur la définition de compatibilité Android. correspondant au niveau d'API sur lequel l'appareil a été expédié.

9.9.3.2. Chiffrement au niveau du bloc par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau du bloc par utilisateur:

• [C-1-1] DOIT activer la prise en charge multi-utilisateur, comme décrit dans la section 9.5.
• [C-1-2] DOIT fournir des partitions par utilisateur, soit à l'aide de partitions brutes, soit des volumes logiques.
• [C-1-3] DOIT utiliser des clés de chiffrement uniques et distinctes par utilisateur pour le chiffrement des périphériques de traitement par blocs sous-jacents.

• [C-1-4] DOIT utiliser l'algorithme AES-256-XTS pour le chiffrement au niveau du bloc de l'utilisateur des partitions.

• Les clés qui protègent les appareils chiffrés au niveau du bloc par utilisateur:

  • [C-1-5] DOIT être lié de manière cryptographique à un keystore intégré au matériel. Ce keystore DOIT être lié au démarrage validé et au matériel de l'appareil racine de confiance.
  • [C-1-6] DOIT être lié à l'écran de verrouillage de l'utilisateur correspondant identifiants de connexion.

Le chiffrement au niveau du bloc par utilisateur peut être implémenté à l'aide du kernel Linux. "dm-crypt" 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 pour toutes les applications, y compris celles-ci qui ne prennent pas encore en charge le démarrage direct, après un redémarrage initié par une OTA. Ce permet aux utilisateurs de recevoir des notifications des applications installées redémarrer.

La mise en œuvre de la fonctionnalité Resume-on-Restart doit se poursuivre pour garantir que lorsqu'un entre les mains d’un pirate informatique, il est extrêmement difficile pour pour récupérer les données de l'utilisateur chiffrées par CE, même si l'appareil est sous tension le stockage CE est déverrouillé, et l'utilisateur a déverrouillé l'appareil après avoir reçu une agence de voyages en ligne. Pour la résistance aux attaques internes, nous supposons également que l’attaquant obtient l’accès pour diffuser des clés de signature cryptographique.

Plus spécifiquement :

• [C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour l'attaquant qui a physiquement présente alors les fonctionnalités et limites suivantes:

  • Possibilité d'utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer arbitrairement messages.
  • Ce paramètre peut entraîner la réception d'une mise à jour OTA par l'appareil.
  • Peut modifier le fonctionnement de tout matériel (point d'accès, flash, etc.), sauf en détaillé ci-dessous, mais une telle modification implique un délai d'au moins heure et un cycle d'arrêt et d'arrêt qui détruit le contenu de la RAM.
  • Ne peut pas modifier le fonctionnement d'un matériel protégé contre les accès non autorisés (Titan M, par exemple).
  • Impossible de lire la RAM de l'appareil actif.
  • ne peut pas obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ; ou sinon il sera saisi.

À titre d'exemple, une implémentation d'appareil qui implémente et respecte toutes des descriptions disponibles sur cette page est conforme aux normes [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes assurent la transparence de l'état l'intégrité de l'appareil. Implémentations pour les appareils:

• [C-0-1] DOIT signaler correctement le problème via la méthode de l'API System PersistentDataBlockManager.getFlashLockState(), que son bootloader autorise le flash de l'image système.

• [C-0-2] DOIT être compatible avec le démarrage validé pour assurer l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans être compatibles avec le démarrage validé sur une version antérieure d'Android et ne peut pas ajouter la prise en charge une mise à jour logicielle système, ils PEUVENT être exemptés du cette exigence.

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

• [C-1-1] DOIT déclarer le flag de fonctionnalité de la plate-forme android.software.verified_boot
• [C-1-2] DOIT effectuer une vérification sur chaque séquence de démarrage.
• [C-1-3] DOIT démarrer la validation à partir d'une clé matérielle immuable correspondant au racine de confiance et aller jusqu’à la partition du système.
• [C-1-4] DOIT mettre en œuvre chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets à l'étape suivante, avant d'exécuter le code dans l'étape suivante.
• [C-1-5] DOIT utiliser des algorithmes de vérification aussi puissants que recommandations du NIST pour les algorithmes de hachage (SHA-256) et les clés publiques (RSA-2048).
• [C-1-6] NE DOIT PAS autoriser le démarrage en cas d'échec de la vérification du système. sauf si l'utilisateur consent à tenter de le démarrer quand même, auquel cas les données les blocs de stockage non validés NE DOIVENT pas être utilisés.
• [C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur le périphérique sauf si l'utilisateur a explicitement déverrouillé le bootloader.
• [C-SR-1] Si l'appareil est équipé de plusieurs puces discrètes (radio, un processeur d'images spécialisé), le processus de démarrage de chacune de ces puces est FORTEMENT RECOMMANDÉ de vérifier chaque étape au démarrage.
• [C-1-8] DOIT utiliser des dispositifs de stockage avec système d'inviolabilité: pour savoir si le le bootloader est déverrouillé. Un stockage inviolable signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] DOIT envoyer une invite à l'utilisateur lorsqu'il se sert de l'appareil, et nécessitent une confirmation physique avant d'autoriser une transition depuis le bootloader du mode verrouillé au mode déverrouillé du bootloader.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (démarrage, partitions système, etc.) et utilisez un espace de stockage avec système d'inviolabilité pour le stockage Métadonnées utilisées pour déterminer la version minimale autorisée du système d'exploitation.
• [C-1-11] DOIT effacer de manière sécurisée toutes les données utilisateur lors du déverrouillage du bootloader et verrouiller, conformément à la version 9.12. Suppression des données (y compris la partition userdata et les espaces NVRAM).
• [C-SR-2] Il est FORTEMENT RECOMMANDÉ de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance enracinée dans des partitions protégées par le démarrage validé.
• [C-SR-3] Il est FORTEMENT RECOMMANDÉ de vérifier tout artefact exécutable chargé par une application privilégiée en dehors de son fichier APK (comme du code chargé dynamiquement ou code compilé) avant de les exécuter ou FORTEMENT RECOMMANDÉ de ne pas les exécuter du tout.
• DEVRAIT mettre en œuvre une protection contre le rollback pour tout composant avec (modem ou caméra, par exemple) et DEVRAIT utiliser un dispositif de 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 C-1-8 via C-1-11 sur une version antérieure d'Android et ne peut pas ajouter la prise en charge de ces exigences avec une mise à jour logicielle système, ils PEUVENT être exemptés du exigences.

Le projet Android Open Source en amont offre une implémentation privilégiée cette fonctionnalité dans la external/avb/ qui peut être intégré au bootloader utilisé pour le chargement Android

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge la vérification cryptographique du contenu d'un fichier par rapport à clé de confiance sans lire l’intégralité du fichier.
• [C-0-4] NE DOIT PAS autoriser la réussite des requêtes de lecture sur un fichier protégé lorsque le contenu lu n'est pas vérifié par rapport à une clé de confiance.

Si des implémentations d'appareils sont déjà lancées sans qu'il soit possible de les vérifier le contenu d'un fichier par rapport à une clé de confiance sur une version antérieure d'Android et ne peut pas ajouter de la prise en charge de cette fonctionnalité par une mise à jour logicielle système, ils PEUVENT être exemptés de cette exigence. Le projet Android Open Source en amont fournit l'implémentation préférée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations pour les appareils:

• [C-SR-4] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations de l'appareil sont compatibles avec la confirmation de protection Android API:

• [C-3-1] DOIT signaler true pour ConfirmationPrompt.isSupported() API.

• [C-3-2] DOIT s'assurer que le code exécuté dans le système d'exploitation Android, y compris ses du noyau, malveillant ou autre, ne peut pas générer de réponse positive sans l'interaction de l'utilisateur.

• [C-3-3] DOIT s'assurer que l'utilisateur a pu consulter et approuver les même si le système d'exploitation 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 des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

• [C-0-1] DOIT autoriser l'importation ou la génération d'au moins 8 192 clés.
• [C-0-2] L'authentification de l'écran de verrouillage DOIT implémenter un intervalle de temps entre les tentatives infructueuses. Avec "n" comme nombre de tentatives infructueuses, l'heure l'intervalle DOIT être d'au moins 30 secondes pour 9 < n < 30. Pour n > 29, le la valeur de l'intervalle de temps DOIT être au moins de 30*2^floor((n-30)/10)) secondes ou au moins 24 heures, selon la plus courte durée.
• NE DEVRAIT pas limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

• [C-1-1] DOIT sauvegarder l'implémentation du keystore avec une couche environnement d'exécution.
• [C-1-2] DOIT disposer d'implémentations de chiffrement RSA, AES, ECDSA et HMAC et les fonctions de hachage des familles MD5, SHA1 et SHA-2 les algorithmes pris en charge par le système Android Keystore dans un emplacement sécurisé isolés 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 pourrait accéder l'état interne de l'environnement isolé, y compris la zone de marché désignée. L'amont Le projet Android Open Source (AOSP) répond à cette exigence en utilisant le une implémentation fiable, une autre solution ARM TrustZone ou une solution tierce la mise en œuvre d’une isolation basée sur l’hyperviseur appropriée sont d’autres options.
• [C-1-3] DOIT réaliser l'authentification de l'écran de verrouillage dans l'environnement isolé environnement d'exécution et autoriser l'utilisation des clés liées à l'authentification qu’après une authentification réussie. Les identifiants de l'écran de verrouillage DOIVENT être stockés dans un qui permet uniquement à l'environnement d'exécution isolé d'effectuer un verrouillage d'écran l'authentification unique. Le projet Android Open Source en amont fournit Gatekeeper Hardware Abstraction Layer (HAL) et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
• [C-1-4] DOIT prendre en charge l'attestation des clés lorsque la clé de signature d'attestation est protégées par du matériel sécurisé et la signature s'effectue dans du matériel sécurisé. La les clés de signature d'attestation DOIVENT être partagées sur un nombre suffisant d'appareils pour empêcher l'utilisation des clés comme identifiants d'appareils. L'une des façons d'y parvenir doit partager la même clé d'attestation,sauf si elle comporte au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

• [C-1-5] DOIT permettre à l'utilisateur de choisir le délai de mise en veille pour la transition de déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé jusqu'à 15 secondes. Appareils automobiles, qui verrouillent l'écran chaque fois que l'unité principale est éteint ou que l'utilisateur change d'appareil, le délai de mise en veille n'est PEUT-ÊTRE PAS associé au délai de mise en veille. configuration.
• [C-1-6] DOIT prendre en charge l'un des éléments suivants:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1 ou
  • IKeyMintDevice version 1.
• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de prendre en charge la version 1 d'IKeyMintDevice.

9.11.1. Écran de verrouillage sécurisé et authentification

L'implémentation d'AOSP suit un modèle d'authentification à plusieurs niveaux dans lequel un l'authentification principale basée sur la fabrique de connaissances peut s'appuyer sur la biométrie secondaire forte, ou par des modalités tertiaires plus faibles.

Implémentations pour les appareils:

• [C-SR-1] Il est FORTEMENT RECOMMANDÉ de définir une seule des options suivantes comme authentification principale méthode:
  • Un code PIN numérique
  • Un mot de passe alphanumérique
  • Schéma de balayage sur une grille contenant exactement 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont appelées les principales méthodes d'authentification de ce document.

Si les mises en œuvre des appareils ajoutent ou modifient l'authentification principale recommandée méthodes et d’utiliser une nouvelle méthode d’authentification comme moyen sécurisé de verrouiller l’écran, la nouvelle méthode d'authentification:

• [C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans Exiger l'authentification utilisateur pour l'utilisation des clés.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'il est basé sur un secret connu et si vous utilisez une nouvelle pour verrouiller l'écran de manière sécurisée:

• [C-3-1] L'entropie de la longueur d'entrées la plus courte DOIT être supérieure à 10 bits.
• [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
• [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer les Méthodes d'authentification principales recommandées (code, schéma, mot de passe, etc.) implémentés et fournis 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 le mot de passe sur les exigences de conformité via la DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive PASSWORD_COMPLEXITY_NONE ou via la méthode DevicePolicyManager.setPasswordQuality() avec une constante plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-3-5] Les nouvelles méthodes d'authentification DOIVENT recourir au méthodes d'authentification principales recommandées (code PIN, schéma, mot de passe) une fois toutes les 72 heures ou moins OU le divulguer clairement au que certaines données ne seront pas sauvegardées la confidentialité de leurs données.

Si les mises en œuvre des appareils ajoutent ou modifient l'authentification principale recommandée pour déverrouiller l'écran de verrouillage et utiliser une nouvelle méthode d'authentification basée sur la biométrie soit traitée comme un moyen sûr de verrouiller l'écran, le nouveau méthode:

• [C-4-1] DOIT respecter l'ensemble des exigences décrites dans la section 7.3.10 pour la classe 1 (anciennement Pratique).
• [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées méthodes d'authentification principales, basées sur un secret connu.
• [C-4-3] DOIT être désactivé et n'autoriser que l'instance principale recommandée l'authentification pour déverrouiller l'écran lorsque l'outil de contrôle des règles relatives aux appareils (DPC) application a défini la règle de fonctionnalité de protection du clavier en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures()) , avec tout indicateur biométrique associé (par exemple, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences pour la classe 3 (anciennement Forte), comme décrit dans section 7.3.10:

• [C-5-1] Les méthodes DOIVENT être désactivées si l'outil de contrôle des règles relatives aux appareils (DPC) application a défini les exigences relatives aux mots de passe - règle de qualité via la méthode DevicePolicyManager.setRequiredPasswordComplexity(), avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_LOW ou à l'aide de DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive PASSWORD_QUALITY_BIOMETRIC_WEAK
• [C-5-2] L'utilisateur DOIT être invité à répondre à une question d'authentification principale recommandée (par exemple, code, schéma ou mot de passe), comme indiqué dans le document [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 être répondre aux exigences commençant par C-8 dans la section ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage et une nouvelle méthode d'authentification est basée sur un jeton physique ou l'emplacement:

• [C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées d'authentification unique basé sur un secret connu les exigences pour être considéré comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser qu'une méthodes d'authentification principales recommandées pour déverrouiller l'écran lorsque L'application DPC (Device Policy Controller) a défini la règle avec:
  • La DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) méthode
  • La DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive PASSWORD_QUALITY_NONE
  • DevicePolicyManager.setRequiredPasswordComplexity() avec un bucket de complexité plus restrictif que PASSWORD_COMPLEXITY_NONE
• [C-6-3] L'utilisateur DOIT être invité à répondre à une question d'authentification méthodes d'authentification (code, schéma, mot de passe, etc.) au moins une fois toutes les quatre heures ou moins.
• [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé, et DOIT être respectez les contraintes énuméré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 qui implémente l'API système TrustAgentService, il:

• [C-7-1] DOIT avoir une indication claire dans le menu des réglages et sur la serrure l'écran lorsque le verrouillage de l'appareil est différé ou qu'il peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour le paramètre "Verrouiller automatiquement" et "Verrouillage instantané" dans menu des paramètres et une icône distincte sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et implémenter intégralement toutes les API d'agent de confiance dans le DevicePolicyManager, comme la classe KEYGUARD_DISABLE_TRUST_AGENTS constante.
• [C-7-3] NE DOIT PAS implémenter complètement l'TrustAgentService.addEscrowToken() fonctionne sur un appareil utilisé comme appareil personnel principal (portable), mais PEUT mettre en œuvre la fonction complète sur l'appareil. des implémentations qui sont généralement partagées (par exemple, Android Television ou l'appareil automobile).
• [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken()
• [C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil sur lequel la clé est utilisée. Par exemple, il est autorisé une clé stockée sur un téléphone pour déverrouiller un compte utilisateur sur un téléviseur. Pour les appareils automobiles, le stockage du jeton de séquestre n'est pas autorisé. sur n'importe quelle partie du véhicule.
• [C-7-6] DOIT informer l'utilisateur des conséquences sur la sécurité avant permettant au jeton de séquestre de déchiffrer le stockage de données.
• [C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes recommandées méthodes d'authentification principales.
• [C-7-8] L'utilisateur DOIT être invité à répondre à une question d'authentification (par exemple, code, schéma ou mot de passe) au moins une fois toutes les 72 heures ou moins, sauf si la sécurité de l'utilisateur (par exemple, en cas de distraction au volant) est préoccupante.
• [C-7-9] L'utilisateur DOIT être invité à répondre à une question d'authentification d'authentification (code, schéma ou mot de passe, par exemple) telles que décrites dans [C-1-7] et [C-1-8] dans la section 7.3.10, sauf si la sécurité de l'utilisateur (par exemple, la distraction du conducteur) est préoccupante.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les les contraintes énumérées dans C-8 ci-dessous.
• [C-7-11] NE DOIT PAS autoriser les TrustAgents sur les appareils personnels principaux (p. ex., portable) pour déverrouiller l'appareil, et ne peut l'utiliser que pour un appareil déjà déverrouillé à l'état déverrouillé pendant une durée maximale 4 heures maximum. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
• [C-7-12] DOIT utiliser un chiffrement sécurisé (UKEY2, par exemple) canal de communication pour transmettre le jeton de séquestre à partir du stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage s'il ne s'agit pas d'un écran de verrouillage sécurisé tel que décrit ci-dessus et utilisez une nouvelle méthode d'authentification pour déverrouiller la protection du clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'outil de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité du mot de passe via la DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive PASSWORD_QUALITY_NONE ou via la DevicePolicyManager.setRequiredPasswordComplexity() avec une constante de complexité plus restrictive "PASSWORD_COMPLEXITY_NONE" :
• [C-8-2] Ils NE DOIVENT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout()
• [C-8-3] Ils NE DOIVENT PAS exposer d'API pour que des applications tierces puissent les utiliser modifier l'état de verrouillage.

Si les implémentations d'appareils sont compatibles avec des états d'affichage distincts via DeviceStateManager ET prendre en charge des états de verrouillage de l'écran distincts via KeyguardDisplayManager, ils:

• [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'organiser une réunion concernant les certificats. aux exigences définies dans la section 9.11.1 ou à une conformité biométrique au moins Les spécifications de classe 1 définies dans la section 7.3.10 permettent le déverrouillage depuis l'écran par défaut de l'appareil.
• [C-SR-3] SONT FORTEMENT RECOMMANDÉS de limiter le déverrouillage de l'écran séparément via un délai d'affichage défini.
• [C-SR-4] Sont FORTEMENT RECOMMANDÉS pour permettre à l'utilisateur de verrouiller globalement tous les écrans grâce au verrouillage de l’appareil portable principal.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker les clés cryptographiques dans un processeur sécurisé dédié ainsi que l'environnement d'exécution isolé décrit ci-dessus. Telle un processeur sécurisé dédié s'appelle "StrongBox". Exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre sont considérés comme des StrongBox.

Implémentations d'appareils disposant d'un processeur sécurisé dédié:

• [C-SR-1] EST VIVEMENT RECOMMANDÉ pour la compatibilité avec StrongBox. StrongBox va devenir une exigence dans une prochaine version.

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

• [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DOIT fournir du matériel dédié et sécurisé utilisé pour keystore et sécurisez l'authentification des utilisateurs. L'interface sécurisée le matériel peut également être utilisé à d'autres fins.

• [C-1-3] DOIT disposer d'un processeur distinct qui ne partage ni cache, ni DRAM, ni coprocesseurs ou d'autres ressources principales avec le processeur d'application.

• [C-1-4] DOIT s'assurer que les périphériques partagés avec le point d'accès ne peuvent pas StrongBox d'une manière ou d'une autre, ni obtenir des informations à partir de StrongBox. Le point d'accès PEUT désactiver ou bloquer l'accès à StrongBox.

• [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) immunisé contre la manipulation par le point d’accès.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires une sortie imprévisible et distribuée de manière uniforme.

• [C-1-7] DOIT disposer d'une résistance à la falsification, y compris contre la pénétration physique et les glitchs.

• [C-1-8] DOIT disposer d'une résistance dans le canal latéral, y compris contre les fuites d'informations via l'alimentation, la temporisation, le rayonnement électromagnétique et la les canaux secondaires de rayonnement.

• [C-1-9] DOIT disposer d'un stockage sécurisé qui garantit la confidentialité, l'intégrité, l'authenticité, la cohérence et l'actualisation des contenus. Le stockage NE DOIT PAS être lu ni modifié, sauf conformément aux API StrongBox.

• Pour valider la conformité avec les normes [C-1-3] à [C-1-9], appareil implémentations:

  • [C-1-10] DOIT inclure le matériel certifié conforme aux normes Profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essais accrédité au niveau national intégrant Évaluation du risque d'attaque élevé Critères communs, application du potentiel d'attaque sur les cartes à puce.
  • [C-1-11] DOIT inclure le micrologiciel évalué par une laboratoire d'essais accrédité au niveau national incorporant un niveau d'attaque élevé une évaluation des failles potentielles d'après Common Critères Application of Attack Potential to Smartcards.
  • [C-SR-2] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, le niveau d'assurance de l'évaluation (EAL) 5, augmentée de AVA_VAN.5. la certification EAL 5 deviendra une exigence dans une prochaine version.

• Les [C-SR-3] sont FORTEMENT RECOMMANDÉS pour offrir une résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature du micrologiciel ne peut pas qui provoque la fuite de secrets par la StrongBox, pour contourner les exigences de sécurité ou qui permettent d'accéder à des données utilisateur sensibles. La la méthode recommandée pour implémenter l'IAR consiste à n'autoriser les mises à jour du micrologiciel que lorsque le mot de passe de l'utilisateur principal est fourni via le HAL IAuthSecret.

9.11.3. Identifiants d'identité

Ce système est défini et réalisé en implémentant toutes API disponibles dans android.security.identity.* d'un package. Ces API permettent aux développeurs d'applications de stocker et de récupérer l'identité des utilisateurs documents. Implémentations pour les appareils:

• Il est FORTEMENT RECOMMANDÉ d'implémenter [C-SR-1] pour implémenter l'identifiant d'identité. Système.

Si les implémentations d'appareils implémentent le système d'identification de l'identité, celles-ci:

• [C-1-1] DOIT renvoyer une valeur non nulle pour la fonction IdentityCredentialStore#getInstance() .

• [C-1-2] DOIT implémenter le système d'identification de l'identité (par exemple, les API android.security.identity.*) avec du code communiquant avec une l'application dans une zone isolée en toute sécurité du code exécuté sur le noyau et versions ultérieures. L'isolation sécurisée DOIT bloquer tous les mécanismes potentiels par lequel le code du noyau ou de l'espace utilisateur peut accéder à l'état interne environnement isolé, y compris la loi sur les marchés numériques.

• [C-1-3] Les opérations cryptographiques nécessaires à la mise en œuvre Le système d'identifiants (par exemple, les API android.security.identity.*) DOIT être effectuées entièrement dans l'application approuvée et le matériel de clé privée DOIT Ne quittez jamais l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par des API de niveau supérieur (par exemple, createEphemeralKeyPair() ).

• [C-1-4] L'application de confiance DOIT être mise en œuvre de telle sorte que son les propriétés de sécurité ne sont pas affectées (par exemple, les données d'identification ne sont pas libérées à moins que l'accès si les conditions de contrôle sont remplies, il est impossible de produire des MAC pour données) même si Android est défaillant 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 présentes dans le système de fichiers userdata lors de l'exécution d'une "Rétablir la configuration d'usine".
• [C-0-3] DOIT supprimer les données de manière à respecter les exigences normes du secteur telles que NIST SP800-88 lors de l'exécution d'une étude Réinitialiser".
• [C-0-4] DOIT déclencher le rétablissement de la configuration d'usine ci-dessus lorsque le DevicePolicyManager.wipeData() L'API est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
• PEUT fournir une option d'effacement rapide des données qui n'effectue qu'une effacement logique des données.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces les applications sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", fournit à l'utilisateur de désinstaller des applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

• [C-SR-1] VIVEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

• [C-1-1] DOIT fournir à l'utilisateur la possibilité de passer en mode Démarrage sécurisé de manière à ce qu'il ne soit pas les applications installées sur l'appareil, sauf si l'application tierce est Device Policy Controller et a défini UserManager.DISALLOW_SAFE_BOOT sur "true".

• [C-1-2] DOIT fournir à l'utilisateur la possibilité de désinstaller les applications tierces en mode sans échec ;

• DEVRAIT donner à l'utilisateur la possibilité d'activer le mode Démarrage sécurisé à partir de un menu de démarrage à l’aide d’un flux de travail différent de celui d’un démarrage normal.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des véhicules critiques à l'aide du composant vehicle HAL pour envoyer et recevoir des messages sur des réseaux de véhicules tels que CAN Bus.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité situées sous le Les couches du framework Android pour empêcher toute interaction malveillante ou involontaire ces sous-systèmes.

9.15. Abonnements

"Abonnements" reportez-vous aux détails du forfait de facturation fourni par un opérateur mobile via SubscriptionManager.setSubscriptionPlans()

Toutes les implémentations d'appareils:

• [C-0-1] DOIT renvoyer les abonnements uniquement à l'application de l'opérateur mobile qui les a fournis à l'origine.
• [C-0-2] NE DOIT PAS sauvegarder ni importer de forfaits d'abonnement à distance.
• [C-0-3] DOIT uniquement autoriser les forçages SubscriptionManager.setSubscriptionOverrideCongested(), depuis l'application de l'opérateur mobile proposant actuellement des abonnements valides.

9.16. Migration des données d'application

Si les implémentations d'appareils permettent de migrer les données d'un appareil vers un autre appareil et ne limitez pas les données d'application qu'il copie à celles configurés par le développeur de l'application dans le fichier manifeste via android:fullBackupContent , ils:

• [C-1-1] NE DOIT PAS lancer de transferts de données d'application depuis appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale décrits dans 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 la source l'appareil et confirmer l'intention de l'utilisateur à copier les données sur la source appareil avant de transférer des données.
• [C-1-3] DOIT utiliser l'attestation des clés de sécurité pour s'assurer que la source et l'appareil cible lors de la migration d'un appareil à un autre sont appareils Android légitimes et ont un bootloader verrouillé.
• [C-1-4] DOIT migrer uniquement les données d'application vers la même application sur le appareil cible avec le même nom de package ET le même certificat de signature.
• [C-1-5] DOIT afficher une indication que l'appareil source a transmis des données migrés par une migration de données d'appareil à appareil dans le menu des paramètres. Un utilisateur NE DEVRAIT PAS être en mesure de supprimer cette indication.

10. Tests de compatibilité logicielle

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS de faire en sorte le nombre minimal de modifications possibles à apporter à la référence mise en œuvre d'Android disponible dans le projet Android Open Source. Vous limiterez ainsi le risque d'introduire des bugs qui créent des incompatibilités. nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations pour les appareils:

• [C-0-1] DOIT réussir la certification Android Compatibility Test Suite (CTS) disponible dans le projet Open Source Android, avec la livraison finale logiciel sur l'appareil.

• [C-0-2] DOIT garantir la compatibilité en cas d'ambiguïté dans CTS et pour toute les réimplémentations de certaines parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, la CTS peut elle-même contenir des bugs. Les versions de CTS seront gérées indépendamment définition de compatibilité, et plusieurs révisions de la CTS peuvent être publiées pour Android 12.

Implémentations pour les appareils:

• [C-0-3] DOIT réussir la dernière version CTS disponible au moment où l'appareil le logiciel est terminé.

• DEVRAIT utiliser l'implémentation de référence dans l'arborescence Open Source d'Android autant que possible.

10.2. Vérificateur CTS

Le vérificateur CTS est inclus dans la suite de tests de compatibilité. est destiné à être exécuté par un opérateur humain pour tester des fonctionnalités qui ne peuvent pas être testés par un système automatisé, comme le bon fonctionnement d'une caméra capteurs.

Implémentations pour les appareils:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans l'outil de vérification CTS.

Le vérificateur CTS a des tests pour de nombreux types de matériel, y compris certains qui est facultatif.

Implémentations pour les appareils:

• [C-0-2] DOIT réussir tous les tests de son matériel. par exemple, si un appareil est équipé d'un accéléromètre, il DOIT exécuter correctement les Cas de test de l'accéléromètre dans l'outil de vérification CTS.

Scénarios de test pour des fonctionnalités indiquées comme facultatives par la présente définition de compatibilité Le document PEUT être ignoré ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS. comme indiqué ci-dessus. Cependant, comme de nombreux builds sont très similaires, les appareils les développeurs ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manières insignifiantes. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant transmis le vérificateur CTS uniquement par des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à jour

• [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin de fonctionner "en direct" mises à niveau, c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité d’un logiciel préinstallé sur l’appareil. Par exemple, l'un des éléments suivants répondront à cette exigence:

  • Over The Air (OTA) téléchargements avec mise à jour hors connexion via un redémarrage.
  • "Partage de connexion" les mises à jour par USB à partir d’un PC hôte.
  • "Hors connexion" des mises à jour par un redémarrage et une mise à jour à partir d’un fichier sur un stockage amovible.

• [C-0-2] Le mécanisme de mise à jour utilisé DOIT prendre en charge les mises à jour sans effacer les données de l'utilisateur données. En d'autres termes, le mécanisme de mise à jour DOIT préserver les données privées de l'application et les données partagées de l'application. Notez que le logiciel Android en amont inclut de mise à jour répondant à cette exigence.

• [C-0-3] L'intégralité de la mise à jour DOIT être signée et le mécanisme de mise à jour sur l'appareil Vous DEVEZ valider la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.

• [C-SR-1] Le mécanisme de signature est FORTEMENT RECOMMANDÉ pour hacher la mise à jour avec SHA-256 et valider le hachage par rapport à la clé publique à l'aide de l'ECDSA NIST P-256.

Si les implémentations de l'appareil sont compatibles avec les données illimitées comme une connexion 802.11 ou un profil Bluetooth PAN (Personal Area Network, ou réseau personnel), puis:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Les implémentations d'appareils DOIVENT vérifier que l'image système est identique au binaire au résultat attendu après une OTA. OTA par bloc dans le projet Open Source Android en amont, ajouté depuis Android 5.1 répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT être compatibles avec les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide de la commande de démarrage HAL.

Si une erreur est détectée dans une implémentation d'appareil après sa sortie, mais pendant la durée de vie raisonnable du produit, déterminée en concertation avec l'équipe chargée de la compatibilité Android afin d'affecter la compatibilité des applications applications, puis procédez comme suit:

• [C-2-1] L'équipe chargée de la mise en œuvre de l'appareil DOIT corriger l'erreur au moyen d'un logiciel mise à jour disponible qui peut être appliquée par le mécanisme qui vient d'être décrit.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signalent android.software.device_admin, puis:

• [C-3-1] DOIT implémenter le comportement décrit dans l'élément SystemUpdatePolicy .

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version:

• Journal des modifications du document

Pour obtenir un résumé des modifications apportées à des sections spécifiques:

1. Introduction
2. Types d'appareils
3. Logiciels
4. Package d'application
5. Multimédia
6. Options et outils pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Test de compatibilité logicielle
11. Logiciel pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils d'affichage du journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications importantes des exigences de compatibilité.

• Docs
  Modifications esthétiques ou liées au développement.

Pour un affichage optimal, ajoutez les paramètres d'URL pretty=full et no-merges à votre les URL du journal des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité avec Android et de demander des éclaircissements ou de soulever des problèmes que le document ne vous semble pas la couverture.