À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Définition de la compatibilité avec Android 11

1. Introduction

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

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

Dans ce document, un "intégrateur d'appareil" ou un "intégrateur" désigne une personne ou une organisation qui développe une solution matérielle/logicielle exécutant Android 11. Une "implémentation d'appareil" ou "implémentation" désigne la solution matérielle/logicielle ainsi développée.

Pour être considérées comme compatibles avec Android 11, les implémentations d'appareils DOIVENT répondre aux exigences présentées dans cette définition de compatibilité, y compris les documents incorporés par référence.

Lorsque cette définition ou les tests logiciels décrits dans la section 10 sont silencieux, ambigus ou incomplets, il incombe à l'implémenteur de l'appareil d'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 privilégiée d'Android. Il est FORTEMENT RECOMMANDÉ aux développeurs d'appareils de baser leurs implémentations autant que possible sur le code source "en amont" disponible sur le projet Android Open Source. Bien que certains composants puissent théoriquement être remplacés par des implémentations alternatives, il est FORTEMENT DÉCONSEILLÉ de le faire, car il deviendra beaucoup plus difficile de réussir les tests logiciels. Il incombe à l'implémenteur d'assurer une compatibilité comportementale totale avec l'implémentation Android standard, y compris et au-delà de la Compatibility Test Suite. Enfin, notez que certaines substitutions et modifications de composants sont explicitement interdites par le présent document.

La plupart des ressources auxquelles ce document renvoie sont issues directement ou indirectement du SDK Android. Elles sont donc fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de compatibilité ou la suite de tests de compatibilité ne sont pas d'accord avec la documentation du SDK, cette dernière est considérée comme faisant autorité. Tous les détails techniques fournis dans les ressources associées tout au long de ce document sont considérés comme faisant partie de cette définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

Toutes les autres exigences, qui s'appliquent universellement à toutes les implémentations d'appareils Android, sont listées dans les sections après la section 2. Dans ce document, ces exigences sont appelées "Exigences de base".

1.1.2. ID de l'exigence

Un ID d'exigence est attribué aux exigences MUST.

L'ID n'est attribué qu'aux exigences MUST.
Les exigences FORTEMENT RECOMMANDÉES sont marquées [SR], mais aucun ID n'est attribué.
L'ID se compose de l'ID du type d'appareil, de l'ID de la condition et de l'ID de l'exigence (par exemple, C-0-1).

Chaque ID est défini comme suit :

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

1.1.3. ID de l'exigence dans la section 2

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

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

2. Types d'appareils

Bien que l'Android Open Source Project fournisse une pile logicielle pouvant être utilisée pour différents types d'appareils et facteurs de forme, certains types d'appareils disposent d'un écosystème de distribution d'applications relativement mieux établi.

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

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

2.1 Configurations de l'appareil

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

2.2. Exigences concernant les appareils mobiles

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

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

être alimenté par une source d'énergie mobile, comme une batterie ;
avoir une taille d'écran physique en diagonale comprise entre 3,3 pouces (ou 2,5 pouces pour les appareils lancés avec un niveau d'API antérieur à Android 11) et 8 pouces ;

Les exigences supplémentaires du reste de cette section sont spécifiques aux implémentations sur les appareils mobiles Android.

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

2.2.1. Matériel

Implémentations sur les appareils mobiles :

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

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

[7.1.1.1/H-1-1]* DOIT faire en sorte que l'écran logique mis à disposition des applications tierces mesure au moins 5,1 cm sur le ou les bords courts et 6,9 cm sur le ou les bords longs. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés de cette exigence.

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

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

Si les implémentations d'appareils portables affirment prendre en charge les écrans HDR (High Dynamic Range) via Configuration.isScreenHdr() , elles :

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

Implémentations sur les appareils mobiles :

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

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

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

Implémentations sur les appareils mobiles :

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

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

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

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

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

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

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

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

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

Implémentations sur les appareils mobiles :

[7.3.11/H-SR] Il est RECOMMANDÉ de prendre en charge le capteur de pose avec 6 degrés de liberté.
[7.4.3/H] DOIT inclure la compatibilité avec Bluetooth et Bluetooth LE.

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

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

Si les implémentations d'appareils portables incluent un périphérique de caméras logiques qui liste les fonctionnalités à l'aide de CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, elles :

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

Implémentations sur les appareils mobiles :

[7.6.1/H-0-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").
[7.6.1/H-0-2] DOIT renvoyer "true" pour ActivityManager.isLowRamDevice() lorsqu'il y a moins de 1 Go de mémoire disponible pour le noyau et l'espace utilisateur.

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

[7.6.1/H-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 416 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 592 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-3-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-4-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à QHD (par exemple, QWXGA).

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

[7.6.1/H-5-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à qHD (par exemple, FWVGA).
[7.6.1/H-6-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à HD+ (par exemple, HD, WSVGA).
[7.6.1/H-7-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'écran par défaut utilise des résolutions de framebuffer jusqu'à FHD (par exemple, WSXGA+).
[7.6.1/H-8-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'écran par défaut utilise des résolutions de mémoire tampon de trame jusqu'à QHD (par exemple, QWXGA).

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

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

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

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

[7.6.1/H-10-1] DOIT disposer d'au moins 4 Go de stockage non volatile disponible pour les données privées de l'application (c'est-à-dire la partition "/data").
DOIT déclarer le commutateur de fonctionnalité android.hardware.ram.normal.

Implémentations sur les appareils mobiles :

[7.6.2/H-0-1] NE DOIT PAS fournir un stockage partagé d'application inférieur à 1 Gio.
[7.7.1/H] DOIT inclure un port USB prenant en charge le mode périphérique.

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

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

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

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

Implémentations sur les appareils mobiles :

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

Si les implémentations d'appareils portables sont capables de répondre à toutes les exigences de performances pour la prise en charge du mode VR et incluent cette prise en charge, elles :

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

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

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

Fonction	Mappages	Contexte	Comportement
A	Page d'utilisation HID : 0x0C Utilisation HID : 0x0CD Clé du noyau : `KEY_PLAYPAUSE` Clé Android : `KEYCODE_MEDIA_PLAY_PAUSE`	Lecture des contenus multimédias	Entrée : appui bref sur Sortie : lecture ou pause
		Lecture des contenus multimédias	Entrée : appui prolongé sur Sortie : lancement de la commande vocale Envoi : `android.speech.action.VOICE_SEARCH_HANDS_FREE` si l'appareil est verrouillé ou si son écran est éteint. Envoi de `android.speech.RecognizerIntent.ACTION_WEB_SEARCH` dans le cas contraire
		Appel entrant	Entrée : appui bref sur Sortie : accepter l'appel
		Appel entrant	Entrée : appui prolongé sur Sortie : refuser l'appel
		Appel en cours	Entrée : appui bref Sortie : mettre fin à l'appel
		Appel en cours	Entrée : appui prolongé sur Sortie : activer ou couper le micro
B	Page d'utilisation HID : 0x0C Utilisation HID : 0x0E9 Clé du noyau : `KEY_VOLUMEUP` Clé Android : `VOLUME_UP`	Lecture de contenus multimédias, Appel en cours	Entrée : appui bref ou long sur Sortie : augmente le volume du système ou du casque
C	Page d'utilisation HID : 0x0C Utilisation HID : 0x0EA Clé du noyau : `KEY_VOLUMEDOWN` Clé Android : `VOLUME_DOWN`	Lecture de contenus multimédias, Appel en cours	Entrée : appuyez brièvement ou longuement sur Sortie : baisse le volume du système ou du casque
D	Page d'utilisation HID : 0x0C Utilisation HID : 0x0CF Clé du noyau : `KEY_VOICECOMMAND` Clé Android : `KEYCODE_VOICE_ASSIST`	Tous. Peut être déclenché dans n'importe quelle instance.	Entrée : appui bref ou long Sortie : lancer une commande vocale

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

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

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

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

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

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

[7.8.2.2/H-4-1] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSink() si le champ de type de terminal audio USB est 0x0302.
[7.8.2.2/H-4-2] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et role isSink() si le champ de type de terminal audio USB est 0x0402.
[7.8.2.2/H-4-3] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_HEADSET et le rôle isSource() si le champ du type de terminal audio USB est 0x0402.
[7.8.2.2/H-4-4] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle isSink() si le champ de type de terminal audio USB est 0x603.
[7.8.2.2/H-4-5] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et de rôle isSource() si le champ de type de terminal audio USB est 0x604.
[7.8.2.2/H-4-6] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et role isSink() si le champ de type de terminal audio USB est 0x400.
[7.8.2.2/H-4-7] DOIT lister un appareil de type AudioDeviceInfo.TYPE_USB_DEVICE et le rôle isSource() si le champ du type de terminal audio USB est 0x400.
[7.8.2.2/H-SR] Il est FORTEMENT RECOMMANDÉ d'effectuer l'énumération des descripteurs USB, d'identifier les types de terminaux et de diffuser l'Intent ACTION_HEADSET_PLUG en moins de 1 000 millisecondes lors de la connexion d'un périphérique audio USB-C.

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

[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de ne pas utiliser d'actionneur haptique (vibreur) à masse rotative excentrée(ERM).
[7.10/H]* DOIT positionner l'actionneur près de l'endroit où l'appareil est généralement tenu ou touché par les mains.
[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'implémenter toutes les constantes publiques pour le retour haptique clair dans android.view.HapticFeedbackConstants, à savoir (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START et GESTURE_END).
[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'implémenter toutes les constantes publiques pour les retours haptiques clairs dans android.os.VibrationEffect, à savoir (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK et EFFECT_DOUBLE_CLICK), et toutes les constantes publiques pour les retours haptiques riches dans android.os.VibrationEffect.Composition, à savoir (PRIMITIVE_CLICK et PRIMITIVE_TICK).
[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ d'utiliser ces mappages de constantes haptiques associées.
[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de suivre l'évaluation de la qualité pour les API createOneShot() et createWaveform().
[7.10/H-SR]* Il est FORTEMENT RECOMMANDÉ de vérifier les capacités de mise à l'échelle de l'amplitude en exécutant android.os.Vibrator.hasAmplitudeControl().

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

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

[7.10/H]* DOIT déplacer l'actionneur haptique sur l'axe X de l'orientation portrait.

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

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

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

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

2.2.2. Multimédia

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

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

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

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

Les implémentations sur les appareils portables DOIVENT être compatibles avec les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

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

2.2.3. Logiciel

Implémentations sur les appareils mobiles :

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

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

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

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

[3.8.4/H-1-1]* Les notifications de conversation DOIVENT s'afficher avant les notifications non liées à une conversation, à l'exception des notifications de service de premier plan en cours et des notifications importance:high.

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

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

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

[3.9/H-1-1] DOIT implémenter l'ensemble des règles d'administration des appareils définies dans la documentation du SDK Android.
[3.9/H-1-2] DOIT déclarer la prise en charge des profils gérés via le flag de fonctionnalité android.software.managed_users, sauf lorsque l'appareil est configuré de manière à se déclarer comme un appareil à faible RAM ou de manière à allouer un stockage interne (non amovible) comme stockage partagé.

Si les implémentations d'appareils portables incluent la prise en charge des API ControlsProviderService et Control et permettent aux applications tierces de publier des commandes de l'appareil, elles :

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

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

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

Implémentations sur les appareils mobiles :

[3.10/H-0-1] DOIT être compatible avec les services d'accessibilité tiers.
[3.10/H-SR] Il est FORTEMENT RECOMMANDÉ de précharger sur l'appareil des services d'accessibilité comparables ou supérieurs aux services d'accessibilité Switch Access et TalkBack (pour les langues prises en charge par le moteur de synthèse vocale préinstallé), tels que fournis dans le projet Open Source TalkBack.
[3.11/H-0-1] DOIT permettre l'installation de moteurs de synthèse vocale tiers.
[3.11/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale prenant en charge les langues disponibles sur l'appareil.
[3.13/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'UI Paramètres rapides.

Si les implémentations d'appareils portables Android déclarent la compatibilité avec FEATURE_BLUETOOTH ou FEATURE_WIFI, elles :

[3.16/H-1-1] DOIT être compatible avec la fonctionnalité d'association d'appareils associés.

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

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

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

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

2.2.4. Performances et puissance

[8.1/H-0-1] Latence d'image cohérente. La latence d'images incohérente ou le retard dans l'affichage des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
[8.1/H-0-2] Latence de l'interface utilisateur. Les implémentations d'appareils DOIVENT garantir une expérience utilisateur à faible latence en faisant défiler une liste de 10 000 entrées, comme défini par la suite de tests de compatibilité Android (CTS), en moins de 36 secondes.
[8.1/H-0-3] Multitâche. Lorsqu'une application déjà en cours d'exécution est relancée après le lancement de plusieurs applications, cela DOIT prendre moins d'une seconde.

Implémentations sur les appareils mobiles :

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

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

[8.3/H-1-1] DOIT permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
[8.3/H-1-2] DOIT fournir à l'utilisateur un moyen d'afficher toutes les applications exemptées des modes d'économie d'énergie Mise en veille des applications et Sommeil.

Implémentations sur les appareils mobiles :

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

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

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

2.2.5. Modèle de sécurité

Implémentations sur les appareils mobiles :

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

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

[9.11/H-0-2]* DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/H-0-3]* DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[9.11/H-0-4]* DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/H-0-5]* DOIT prendre en charge l'attestation de clé, où la clé de signature de l'attestation est protégée par un matériel sécurisé et la signature est effectuée dans un matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

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

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

[9.5/H-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

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

[9.5/H-3-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

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

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

[6.1/H-0-1]* DOIT être compatible avec la commande shell cmd testharness.

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

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

2.2.7 Classe de performances multimédias pour les appareils portables

Consultez la section 7.11 pour connaître la définition de la classe de performances média.

2.2.7.1. Contenus multimédias

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

[5.1/H-1-1] DOIT indiquer le nombre maximal de sessions de décodage vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-2] DOIT prendre en charge six sessions de décodeur vidéo matériel (AVC ou HEVC) dans n'importe quelle combinaison de codecs s'exécutant simultanément à une résolution de 720p à 30 fps.
[5.1/H-1-3] DOIT indiquer le nombre maximal de sessions d'encodeur vidéo matériel pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-4] DOIT prendre en charge six instances de sessions d'encodeur vidéo matériel (AVC ou HEVC) dans n'importe quelle combinaison de codecs s'exécutant simultanément à une résolution de 720p à 30 fps.
[5.1/H-1-5] DOIT indiquer le nombre maximal de sessions d'encodeur et de décodeur vidéo matériels pouvant être exécutées simultanément dans n'importe quelle combinaison de codecs via les méthodes CodecCapabilities.getMaxSupportedInstances() et VideoCapabilities.getSupportedPerformancePoints().
[5.1/H-1-6] DOIT prendre en charge six instances de sessions de décodeur vidéo matériel et d'encodeur vidéo matériel (AVC ou HEVC) dans n'importe quelle combinaison de codecs s'exécutant simultanément à une résolution de 720p à 30 fps.
[5.1/H-1-7] DOIT avoir une latence d'initialisation du codec de 65 ms ou moins pour une session d'encodage vidéo 1080p ou inférieure pour tous les encodeurs vidéo matériels (autres que le codec Dolby Vision) en cas de charge. La charge est définie comme une session de transcodage simultanée de 1080p à 720p (vidéo uniquement) utilisant des codecs vidéo matériels ainsi que l'initialisation de l'enregistrement audio-vidéo en 1080p.
[5.1/H-1-8] DOIT avoir une latence d'initialisation du codec de 50 ms ou moins pour une session d'encodage audio à un débit de 128 kbit/s ou moins pour tous les encodeurs audio en cas de charge.La charge est définie ici comme une session de transcodage vidéo uniquement de 1080p à 720p simultanée utilisant des codecs vidéo matériels avec l'initialisation de l'enregistrement audio-vidéo en 1080p.
[5.3/H-1-1] NE DOIT PAS perdre plus d'une image en 10 secondes (c'est-à-dire moins de 0,333 % d'images perdues) pour une session vidéo 1080p à 30 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement de 1080p à 720p en simultané à l'aide de codecs vidéo matériels, ainsi qu'une lecture audio AAC à 128 kbit/s.
[5.3/H-1-2] NE DOIT PAS perdre plus d'une image en 10 secondes lors d'un changement de résolution vidéo dans une session vidéo à 30 FPS sous charge. La charge est définie comme une session de transcodage vidéo uniquement de 1080p à 720p simultanée utilisant des codecs vidéo matériels, ainsi qu'une lecture audio AAC de 128 Kbit/s.
[5.6/H-1-1] DOIT avoir une latence entre le moment où l'utilisateur appuie sur l'écran et le moment où il entend le son inférieure à 100 millisecondes à l'aide du test "tap-to-tone" d'OboeTester ou de CTS Verifier.

2.2.7.2. Appareil photo

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

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

2.2.7.3. Matériel

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

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

2.2.7.4. Performances

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

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

2.3. Exigences concernant le téléviseur

Un appareil Android TV désigne une implémentation d'appareil Android qui constitue une interface de divertissement permettant de consommer des contenus multimé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 (une "interface utilisateur inclinée" ou "interface utilisateur à trois mètres").

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

fourni un mécanisme permettant de contrôler à distance l'interface utilisateur affichée sur l'écran qui peut se trouver à trois mètres de l'utilisateur.
Disposer d'un écran intégré dont la diagonale est supérieure à 61 cm OU inclure un port de sortie vidéo, tel que VGA, HDMI, DisplayPort ou un port sans fil pour l'affichage.

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

2.3.1. Matériel

Implémentations d'appareils de télévision :

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

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

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

Implémentations d'appareils de télévision :

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

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

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

Si les implémentations des appareils TV sont en 32 bits :

[7.6.1/T-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands

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

[7.6.1/T-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands

Implémentations d'appareils de télévision :

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

2.3.2. Multimédia

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

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

Les implémentations de téléviseurs DOIVENT être compatibles avec les formats d'encodage vidéo suivants et les mettre à la disposition des applications tierces :

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

Implémentations d'appareils de télévision :

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

Les implémentations de téléviseurs DOIVENT être compatibles avec les formats de décodage vidéo suivants et les mettre à la disposition des applications tierces :

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

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

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

Les implémentations de téléviseurs DOIVENT être compatibles avec le décodage H.264, comme indiqué dans la section 5.3.4, aux fréquences d'images vidéo standards et aux résolutions jusqu'à :

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

Les implémentations de téléviseurs avec des décodeurs matériels H.265 DOIVENT être compatibles avec le décodage H.265, comme indiqué dans la section 5.3.5, à des fréquences d'images vidéo et des résolutions standards, y compris :

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

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

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

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

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

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

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

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

[5.3.7/T-2-1] DOIT ê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] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil de décodage UHD à 60 images par seconde avec le profil 2 (profondeur de couleur de 10 bits).

Implémentations d'appareils de télévision :

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

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

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

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

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

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

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

2.3.3. Logiciel

Implémentations d'appareils de télévision :

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

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

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

Implémentations d'appareils de télévision :

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

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

[3.11/T-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale prenant en charge les langues disponibles sur l'appareil.
[3.11/T-1-1] DOIT permettre l'installation de moteurs TTS tiers.

Implémentations d'appareils de télévision :

[3.12/T-0-1] DOIT être compatible avec le framework TV Input.

2.3.4. Performances et puissance

[8.1/T-0-1] Latence d'image cohérente. La latence d'images incohérente ou le retard de rendu des images NE DOIVENT PAS se produire plus de cinq fois par seconde et DOIVENT être inférieurs à une fois par seconde.
[8.2/T-0-1] DOIT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s.
[8.2/T-0-2] DOIT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s.
[8.2/T-0-3] DOIT garantir des performances de lecture séquentielle d'au moins 15 Mo/s.
[8.2/T-0-4] DOIT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s.

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

[8.3/T-1-1] DOIT permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

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

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

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

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

Implémentations d'appareils de télévision :

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

2.3.5. Modèle de sécurité

Implémentations d'appareils de télévision :

[9.11/T-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/T-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[9.11/T-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/T-0-4] DOIT prendre en charge l'attestation de clé, où la clé de signature de l'attestation est protégée par un matériel sécurisé et la signature est effectuée dans un matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

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

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

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

[9.5/T-2-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

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

[9.5/T-3-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

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

Implémentations d'appareils de télévision :

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

2.4. Configuration requise pour la montre

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

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

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

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

2.4.1. Matériel

Implémentations d'appareils Wear :

[7.1.1.1/W-0-1] DOIT disposer d'un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
[7.2.3/W-0-1] DOIT proposer à l'utilisateur les fonctions Accueil et Retour, sauf lorsqu'il se trouve dans UI_MODE_TYPE_WATCH.
[7.2.4/W-0-1] DOIT accepter les entrées tactiles.
[7.3.1/W-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 axes.

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

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

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

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

Implémentations d'appareils connectés :

[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 (c'est-à-dire la 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.

2.4.2. Multimédia

Aucune autre condition requise.

2.4.3. Logiciel

Implémentations d'appareils Wear :

[3/W-0-1] MUST declare the feature android.hardware.type.watch.
[3/W-0-2] DOIT être compatible avec uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] DOIT précharger une ou plusieurs applications ou composants de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.

Implémentations d'appareils connectés :

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

Implémentations d'appareils connectés qui déclarent l'indicateur de fonctionnalité android.hardware.audio.output :

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

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

[3.11/W-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un moteur de synthèse vocale prenant en charge les langues disponibles sur l'appareil.
[3.11/W-0-1] DOIT permettre l'installation de moteurs de synthèse vocale tiers.

2.4.4. Performances et puissance

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

[8.3/W-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'afficher toutes les applications exemptées des modes d'économie d'énergie Veille de l'application et Veille.
[8.3/W-SR] Il est FORTEMENT RECOMMANDÉ de permettre à l'utilisateur d'activer et de désactiver la fonctionnalité d'économiseur de batterie.

Implémentations d'appareils connectés :

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

2.4.5. Modèle de sécurité

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

[9.5/W-1-1] DOIT être compatible avec les profils limités, une fonctionnalité qui permet aux propriétaires d'appareils de gérer d'autres utilisateurs et leurs capacités sur l'appareil. Grâce aux profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour que d'autres utilisateurs puissent y travailler. Ils peuvent également gérer des restrictions plus précises dans les applications disponibles dans ces environnements.

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

[9.5/W-2-1] NE DOIT PAS être compatible avec les profils restreints, mais DOIT s'aligner sur l'implémentation AOSP des commandes permettant d'autoriser /d'interdire l'accès aux appels vocaux et aux SMS pour les autres utilisateurs.

2.5. Exigences pour le secteur automobile

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

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

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

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

2.5.1. Matériel

Implémentations d'appareils automobiles :

[7.1.1.1/A-0-1] DOIT disposer d'un écran d'au moins 6 pouces de diagonale physique.
[7.1.1.1/A-0-2] DOIT avoir une disposition de taille d'écran d'au moins 750 dp x 480 dp.
[7.2.3/A-0-1] DOIT fournir la fonction Accueil et PEUT fournir les fonctions Retour et Récents.
[7.2.3/A-0-2] DOIT envoyer l'événement d'appui normal et l'événement d'appui long de la fonction Retour (KEYCODE_BACK) à l'application au 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 signal NIGHT_MODE DOIT être cohérente avec le mode Jour/Nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de luminosité ambiante. Le capteur de luminosité ambiante sous-jacent PEUT être le même que Photometer.
[7.3/A-0-3] DOIT fournir le champ d'informations supplémentaires du capteur TYPE_SENSOR_PLACEMENT dans SensorAdditionalInfo pour chaque capteur fourni.
[7.3/A-0-1] PEUT calculer à l'estime la position en fusionnant le GPS/GNSS avec des capteurs supplémentaires. Si la position est estimée, il est FORTEMENT RECOMMANDÉ d'implémenter et de signaler les types de capteurs et/ou les ID de propriété du véhicule correspondants utilisés.
[7.3/A-0-2] La position demandée via LocationManager#requestLocationUpdates() NE DOIT PAS être associée à une carte.

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

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

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

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

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

[7.3.3/A-3-1] DOIT déterminer la position la toute première fois que le récepteur GPS/GNSS est allumé ou après quatre jours ou plus, dans un délai de 60 secondes.
[7.3.3/A-3-2] DOIT respecter les critères de délai avant première localisation décrits 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 demandes qui ne sont pas la toute première ou après quatre jours ou plus). L'exigence 7.3.3/C-1-2 est généralement respectée dans les véhicules sans connectivité de données basée sur un réseau mobile, en utilisant les prédictions d'orbite GNSS calculées sur le récepteur, ou en utilisant la dernière position connue du véhicule avec la capacité de navigation à l'estime pendant au moins 60 secondes avec une précision de position satisfaisant à 7.3.3/C-1-3, ou une combinaison des deux.

Implémentations d'appareils automobiles :

[7.4.3/A-0-1] DOIT être compatible avec Bluetooth et DEVRAIT être compatible avec Bluetooth LE.
[7.4.3/A-0-2] Les implémentations Android Automotive DOIVENT prendre en charge les profils Bluetooth suivants :
- Appels téléphoniques via le profil mains libres (HFP).
- Lecture de contenus multimédias via le profil de distribution audio (A2DP).
- Contrôle de la lecture multimédia via le profil de télécommande (AVRCP).
- Partage de contacts à l'aide du profil d'accès à l'annuaire téléphonique (PBAP).
[7.4.3/A-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le profil d'accès aux messages (MAP).
[7.4.5/A] DOIT inclure la prise en charge de la connectivité des données basée sur le réseau mobile.
[7.4.5/A] PEUT utiliser la constante NetworkCapabilities#NET_CAPABILITY_OEM_PAID de l'API System pour les réseaux qui doivent être disponibles pour les applications système.

Une caméra de vue extérieure est une caméra qui filme des scènes à l'extérieur de l'implémentation de l'appareil, comme une caméra embarquée.

Implémentations d'appareils automobiles :

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

Si les implémentations d'appareils automobiles incluent une caméra de vue extérieure, pour une telle caméra, elles :

[7.5/A-1-1] NE DOIT PAS avoir de caméras avec vue extérieure accessibles via les API Android Camera, sauf si elles respectent les exigences de base concernant les caméras.
[7.5/A-SR] Il est FORTEMENT RECOMMANDÉ de ne pas faire pivoter ni mettre en miroir horizontalement l'aperçu de la caméra.
[7.5.5/A-SR] Il est FORTEMENT RECOMMANDÉ d'orienter les caméras de sorte que la dimension longue de l'appareil photo soit alignée sur l'horizon.
[7.5/A-SR] Nous RECOMMANDONS FORTEMENT que les caméras de sécurité aient une résolution d'au moins 1,3 mégapixel.
DOIT disposer d'un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF).
DOIT être compatible avec le framework de synchronisation Android.
PEUT avoir une mise au point automatique matérielle ou logicielle implémentée dans le pilote de la caméra.

Implémentations d'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 de l'application (c'est-à-dire la partition "/data").
[7.6.1/A] DOIT formater la partition de données pour améliorer les performances et la longévité du stockage flash, par exemple en utilisant le système de fichiers f2fs.

Si les implémentations d'appareils automobiles fournissent un stockage externe partagé via une partie du stockage interne non amovible, elles :

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

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

[7.6.1/A-1-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 512 Mo si l'une des densités suivantes est utilisée :
- 280 dpi ou moins sur les écrans de petite ou moyenne taille
- ldpi ou inférieur sur les écrans très grands
- mdpi ou inférieure sur les grands écrans
[7.6.1/A-1-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 608 Mo si l'une des densités suivantes est utilisée :
- xhdpi ou plus sur les écrans de petite ou moyenne taille
- hdpi ou résolution supérieure sur les grands écrans
- mdpi ou supérieur sur les écrans très grands
[7.6.1/A-1-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 896 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands
[7.6.1/A-1-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 344 Mo si l'une des densités suivantes est utilisée :
- 560 dpi ou plus sur les écrans de petite ou moyenne taille
- 400 dpi ou plus sur les grands écrans
- xhdpi ou supérieur sur les très grands écrans

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

[7.6.1/A-2-1] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 816 Mo si l'une des densités suivantes est utilisée :
- 280 dpi ou moins sur les écrans de petite ou moyenne taille
- ldpi ou inférieur sur les écrans très grands
- mdpi ou inférieure sur les grands écrans
[7.6.1/A-2-2] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 944 Mo si l'une des densités suivantes est utilisée :
- xhdpi ou plus sur les écrans de petite ou moyenne taille
- hdpi ou résolution supérieure sur les grands écrans
- mdpi ou supérieur sur les écrans très grands
[7.6.1/A-2-3] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 280 Mo si l'une des densités suivantes est utilisée :
- 400 dpi ou plus sur les écrans de petite ou moyenne taille
- xhdpi ou supérieur sur les grands écrans
- tvdpi ou plus sur les écrans très grands
[7.6.1/A-2-4] La mémoire disponible pour le noyau et l'espace utilisateur DOIT être d'au moins 1 824 Mo si l'une des densités suivantes est utilisée :
- 560 dpi ou plus sur les écrans de petite ou moyenne taille
- 400 dpi ou plus sur les grands écrans
- xhdpi ou supérieur sur les très grands écrans

Implémentations d'appareils automobiles :

[7.7.1/A] DOIT inclure un port USB prenant en charge le mode périphérique.

Implémentations d'appareils automobiles :

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

Implémentations d'appareils automobiles :

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

2.5.2. Multimédia

Les implémentations d'appareils automobiles DOIVENT être compatibles avec les formats d'encodage et de décodage audio suivants, et les mettre à la disposition des applications tierces :

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

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

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

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

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

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

[5.3/A-SR] H.265 HEVC

2.5.3. Logiciel

Implémentations d'appareils automobiles :

[3/A-0-1] 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 dans l'espace de noms android.car.*.

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

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

Implémentations d'appareils automobiles :

[3.2.1/A-0-1] DOIT être compatible avec toutes les constantes d'autorisation et les appliquer, 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 plusieurs composants d'application ou de service avec un gestionnaire d'intent, pour tous les modèles de filtre d'intent publics définis par les intents d'application suivants listés ici.
[3.4.1/A-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
[3.8.3/A-0-1] DOIT afficher les notifications qui utilisent l'API Notification.CarExtender lorsqu'elles sont demandées par des applications tierces.
[3.8.4/A-SR] Il est fortement recommandé d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

Si les implémentations d'appareils automobiles incluent un bouton "appuyer pour parler", elles doivent :

[3.8.4/A-1-1] DOIT utiliser un appui bref 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 d'appareils automobiles :

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

Implémentations d'appareils automobiles :

[3.14/A-0-1] DOIT inclure un framework d'UI pour prendre en charge les applications tierces utilisant les API Media, comme décrit dans la section 3.14.
[3.14/A-0-2] DOIT permettre à l'utilisateur d'interagir de manière sécurisée avec les applications multimédias pendant la conduite.
[3.14/A-0-3] DOIT prendre en charge l'action d'intent implicite CAR_INTENT_ACTION_MEDIA_TEMPLATE avec l'extra CAR_EXTRA_MEDIA_PACKAGE.
[3.14/A-0-4] DOIT fournir une affordance pour accéder à l'activité de préférences d'une application multimédia, mais DOIT uniquement l'activer lorsque les restrictions de l'UX automobile ne sont pas en vigueur.
[3.14/A-0-5] DOIT afficher les messages d'erreur définis par les applications multimédias et DOIT prendre en charge les options supplémentaires ERROR_RESOLUTION_ACTION_LABEL et ERROR_RESOLUTION_ACTION_INTENT.
[3.14/A-0-6] DOIT proposer une fonctionnalité de recherche dans l'application pour les applications qui prennent en charge la recherche.
[3.14/A-0-7] DOIT respecter les définitions de CONTENT_STYLE_BROWSABLE_HINT et CONTENT_STYLE_PLAYABLE_HINT lors de l'affichage de la hiérarchie MediaBrowser.

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

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

Implémentations d'appareils automobiles :

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

2.5.4. Performances et puissance

Implémentations d'appareils automobiles :

[8.2/A-0-1] DOIT signaler le nombre d'octets lus et écrits dans le stockage non volatile pour chaque UID de processus afin que les statistiques soient disponibles pour les développeurs via l'API système android.car.storagemonitoring.CarStorageMonitoringManager. Le projet Android Open Source répond à cette exigence grâce au module de noyau uid_sys_stats.
[8.3/A-1-3] DOIT être compatible avec le mode Garage.
[8.3/A] DOIT être en mode Garage pendant au moins 15 minutes après chaque trajet, sauf si :
- 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 de consommation électrique par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge approximative de la batterie causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
[8.4/A-0-2] DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heures (mAh).
[8.4/A-0-3] DOIT signaler la consommation d'énergie du processeur pour chaque UID de processus. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[8.4/A] La consommation d'énergie des composants matériels DOIT être attribuée au composant matériel lui-même s'il est impossible de l'attribuer à une application.
[8.4/A-0-4] DOIT mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.

2.5.5. Modèle de sécurité

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

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

Implémentations d'appareils automobiles :

[9.11/A-0-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[9.11/A-0-2] DOIT implémenter les algorithmes cryptographiques RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage MD5, SHA1 et de la famille SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[9.11/A-0-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[9.11/A-0-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

Implémentations d'appareils automobiles :

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

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

Implémentations d'appareils automobiles :

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

2.6. Configuration requise pour les tablettes

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

Utilisé en le tenant à deux mains.
Ne dispose pas d'une configuration à clapet ou convertible.
Les claviers physiques utilisés avec l'appareil se connectent à l'aide d'une connexion standard (par exemple, USB ou Bluetooth).
Il est alimenté par une source d'énergie qui lui permet de se déplacer, comme une batterie.
La taille physique de l'écran en diagonale est comprise entre 7 et 18 pouces.

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

2.6.1. Matériel

Taille de l'écran

[7.1.1.1/Tab-0-1] DOIT avoir un écran de 7 à 18 pouces.

Gyroscope

Si les implémentations de tablettes incluent un gyroscope à trois axes, elles :

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

Mémoire et stockage minimum (section 7.6.1)

Les densités d'écran indiquées pour les petits écrans/écrans normaux dans les exigences relatives aux appareils mobiles ne s'appliquent pas aux tablettes.

Mode périphérique USB (section 7.7.1)

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

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

Mode Réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

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

2.6.2. Modèle de sécurité

Clés et identifiants (section 9.11)

Consultez la section [9.11].

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

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

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

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

2.6.2. Logiciel

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

3. Logiciel

3.1. Compatibilité des API gérées

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

Implémentations sur les appareils :

[C-0-1] DOIT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android ou de toute API décorée avec le marqueur "@SystemApi" dans le code source Android en amont.
[C-0-2] DOIT prendre en charge/préserver toutes les classes, méthodes et éléments associés marqués par l'annotation TestApi (@TestApi).
[C-0-3] NE DOIT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure d'opérations sans effet, sauf si la présente Définition de compatibilité l'autorise spécifiquement.
[C-0-4] DOIT toujours conserver les API et se comporter de manière raisonnable, même lorsque certaines fonctionnalités matérielles pour lesquelles Android inclut des API sont omises. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.
[C-0-5] NE DOIT PAS autoriser les applications tierces à utiliser des interfaces non SDK, qui sont définies comme des méthodes et des champs dans les packages de langage Java qui se trouvent dans le chemin de classe de démarrage dans AOSP et qui ne font pas partie du SDK public. Cela inclut les API décorées avec l'annotation @hide, mais pas avec @SystemAPI, comme décrit dans les documents du SDK, ainsi que les membres de classe privés et package-privés.
[C-0-6] DOIT être fourni avec chaque interface non SDK sur les mêmes listes restreintes que celles fournies par le biais des indicateurs provisoires et de la liste de refus dans le chemin d'accès prebuilts/runtime/appcompat/hiddenapi-flags.csv pour la branche du niveau d'API approprié dans AOSP.
[C-0-7] DOIT être compatible avec le mécanisme de mise à jour dynamique de la configuration signée pour supprimer les interfaces non SDK d'une liste restreinte en intégrant une configuration signée dans n'importe quel APK, à l'aide des clés publiques existantes dans AOSP.

Toutefois, ils :
- MAI, si une API masquée est absente ou implémentée différemment sur l'implémentation de l'appareil, déplacez l'API masquée dans la liste de refus ou omettez-la de toutes les listes restreintes (c'est-à-dire gris clair, gris foncé, noir).
- SI une API masquée n'existe pas déjà dans l'AOSP, ajoutez-la à l'une des listes restreintes (c'est-à-dire gris clair, gris foncé ou noir).

3.1.1. Extensions Android

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

Implémentations sur les appareils Android :

[C-0-1] DOIT précharger l'implémentation AOSP de la bibliothèque partagée ExtShared et des services ExtServices avec des versions supérieures ou égales aux versions minimales autorisées pour chaque niveau d'API. Par exemple, les implémentations d'appareils Android 7.0, exécutant le niveau d'API 24, DOIVENT inclure au moins la version 1.
[C-0-2] DOIT uniquement renvoyer des numéros de version d'extension valides définis par l'AOSP.
[C-0-3] DOIT être compatible avec toutes les API définies par les versions d'extension renvoyées par android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) de la même manière que les autres API gérées, conformément aux exigences de la section 3.1.

3.1.2. Bibliothèque Android

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

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

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

3.2. Compatibilité logicielle avec les API

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

3.2.1. Autorisations

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

3.2.2. Créer des paramètres

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

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

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

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application courants

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

Implémentations sur les appareils :

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

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

3.2.3.2. Résolution des intents

[C-0-1] Android étant une plate-forme extensible, les implémentations d'appareils DOIVENT permettre aux applications tierces de remplacer chaque modèle d'intent référencé dans la section 3.2.3.1, à l'exception des paramètres. L'implémentation Open Source Android en amont l'autorise par défaut.
[C-0-2] Les implémenteurs d'appareils NE DOIVENT PAS attribuer de privilèges spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et d'en prendre le contrôle. Cette interdiction inclut, sans s'y limiter, la désactivation de l'interface utilisateur du sélecteur, qui permet à l'utilisateur de choisir entre plusieurs applications qui gèrent toutes le même modèle d'intent.
[C-0-3] Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.
Toutefois, les implémentations d'appareils PEUVENT fournir des activités par défaut pour des schémas d'URI spécifiques (par exemple, http://play.google.com) lorsque l'activité par défaut fournit un attribut plus spécifique pour l'URI de données. Par exemple, un modèle de filtre d'intent spécifiant l'URI de données "http://www.android.com" est plus spécifique que le modèle d'intent principal du navigateur pour "http://".

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

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

3.2.3.3. Espaces de noms d'intent

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

3.2.3.4. Intents de diffusion

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

Implémentations sur les appareils :

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

3.2.3.5. Intents d'application conditionnels

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

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

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

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

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

[C-2-1] DOIT fournir un menu de paramètres qui appelle l'intention android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut.
[C-2-2] DOIT respecter l'intention android.telecom.action.CHANGE_DEFAULT_DIALER d'afficher une boîte de dialogue permettant à l'utilisateur de modifier l'application Téléphone par défaut.
- DOIT utiliser l'UI de l'application de téléphone par défaut sélectionnée par l'utilisateur pour les appels entrants et sortants, à l'exception des appels d'urgence, qui doivent utiliser l'application de téléphone préinstallée.
[C-2-3] DOIT respecter l'intent android.telecom.action.CHANGE_PHONE_ACCOUNTS pour permettre à l'utilisateur de configurer le ConnectionServices associé à PhoneAccounts, ainsi qu'un PhoneAccount par défaut que l'opérateur de télécommunications utilisera pour passer des appels sortants. L'implémentation AOSP répond à cette exigence en incluant un menu "Options des comptes d'appel" dans le menu des paramètres "Appels".
[C-2-4] DOIT autoriser android.telecom.CallRedirectionService pour une application qui détient le rôle android.app.role.CALL_REDIRECTION.
[C-2-5] DOIT permettre à l'utilisateur de choisir une application qui détient le rôle android.app.role.CALL_REDIRECTION.
[C-2-6] DOIT respecter les intents android.intent.action.SENDTO et android.intent.action.VIEW et fournir une activité pour envoyer/afficher des SMS.
[C-SR] Il est fortement recommandé de respecter les intents android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW et android.intent.action.DIAL avec une application de numérotation préchargée capable de gérer ces intents et de fournir l'exécution décrite dans le SDK.

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

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

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

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

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

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

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

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

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

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

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

[C-7-1] DOIT fournir un mécanisme accessible aux utilisateurs pour ajouter et configurer des méthodes de saisie tierces en réponse à l'intention android.settings.INPUT_METHOD_SETTINGS.

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

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

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

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

Si les implémentations d'appareils fournissent le mode Économie de données, elles : * [C-10-1] DOIVENT fournir une interface utilisateur dans les paramètres, qui gère l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permettant aux utilisateurs d'ajouter des applications à la liste d'autorisation ou d'en supprimer.

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

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

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

[C-12-1] DOIT respecter les intents android.media.action.STILL_IMAGE_CAMERA et android.media.action.STILL_IMAGE_CAMERA_SECURE et lancer l'appareil photo en mode image fixe, comme décrit dans le SDK.
[C-12-2] DOIT respecter l'intention android.media.action.VIDEO_CAMERA de lancer la caméra en mode vidéo, comme décrit dans le SDK.
[C-12-3] DOIT autoriser uniquement les applications Android préinstallées à gérer les intents suivants : MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE et MediaStore.ACTION_VIDEO_CAPTURE, comme décrit dans le document du SDK.

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

[C-13-1] DOIT respecter l'intention android.app.action.ADD_DEVICE_ADMIN d'appeler une UI pour permettre à l'utilisateur d'ajouter l'administrateur de l'appareil au système (ou de le refuser).
[C-13-2] DOIT respecter les intents android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD et android.app.action.START_ENCRYPTION, et disposer d'une activité pour répondre à ces intents, comme décrit dans le SDK ici.

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

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

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

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

Si les implémentations d'appareils ont l'intention d'interdire l'accès aux statistiques d'utilisation à certaines applications, y compris les applications préinstallées, elles doivent :

[C-15-1] DOIT toujours disposer d'une activité qui gère le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais DOIT l'implémenter en tant qu'opération sans effet, c'est-à-dire avoir un comportement équivalent à celui qui se produit lorsque l'accès est refusé à l'utilisateur.

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

[C-SR] Il est fortement recommandé d'honorer les intents android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA et android.speech.tts.engine.GET_SAMPLE_TEXT en fournissant une activité pour répondre à ces intents, comme décrit dans le SDK ici.

Android est compatible avec les économiseurs d'écran interactifs, appelés précédemment "Rêves". Les économiseurs d'écran permettent aux utilisateurs d'interagir avec des applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou placé dans une station d'accueil. Implémentations de l'appareil :

DOIT inclure la prise en charge des économiseurs d'écran et fournir une option de paramètre permettant aux utilisateurs de configurer les économiseurs d'écran en réponse à l'intention android.settings.DREAM_SETTINGS.

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

Si les implémentations d'appareils autorisent le lancement d'activités Android normales sur plusieurs écrans, elles :

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

Si les implémentations d'appareil autorisent le lancement d'activités Android normales sur des écrans secondaires et qu'un écran secondaire possède l'indicateur android.view.Display.FLAG_PRIVATE :

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

3.3. Compatibilité avec les API natives

La compatibilité du code natif est difficile à obtenir. C'est pourquoi les développeurs d'appareils sont :

[SR] Il est 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 le fichier .apk de l'application en tant que fichier ELF .so compilé pour l'architecture matérielle de l'appareil approprié. Comme le code natif dépend fortement de la technologie du processeur sous-jacent, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android.

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec une ou plusieurs ABI NDK Android définies.
[C-0-2] DOIT inclure la prise en charge du code s'exécutant dans l'environnement géré pour appeler le code natif, en utilisant la sémantique standard de l'interface Java Native Interface (JNI).
[C-0-3] DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) de chaque bibliothèque requise dans la liste ci-dessous.
[C-0-5] DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparées par des virgules et classées de la plus à la moins préférée.
[C-0-6] DOIT signaler, via les paramètres ci-dessus, un sous-ensemble de la liste suivante d'ABI et NE DOIT PAS signaler d'ABI ne figurant pas dans la liste.
- armeabi (n'est plus compatible en tant que cible par le NDK)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] DOIT rendre toutes les bibliothèques suivantes, qui fournissent des API natives, disponibles pour les applications qui incluent du code natif :
- libaaudio.so (compatibilité audio native AAudio)
- libamidi.so (compatibilité MIDI native, si la fonctionnalité android.software.midi est revendiquée comme décrit dans la section 5.9)
- libandroid.so (prise en charge des activités Android natives)
- libc (bibliothèque C)
- libcamera2ndk.so
- libdl (éditeur de liens dynamiques)
- libEGL.so (gestion de 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 multimédias natives)
- libm (bibliothèque mathématique)
- libneuralnetworks.so (API Neural Networks)
- libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
- libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (compatibilité minimale avec C++)
- libvulkan.so (Vulkan)
- libz (compression Zlib)
- Interface JNI
[C-0-8] NE DOIT PAS ajouter ni supprimer les fonctions publiques des bibliothèques natives listées ci-dessus.
[C-0-9] DOIT lister les bibliothèques non-AOSP supplémentaires exposées directement aux applications tierces dans /vendor/etc/public.libraries.txt.
[C-0-10] NE DOIT PAS exposer d'autres bibliothèques natives, implémentées et fournies dans AOSP en tant que bibliothèques système, aux applications tierces ciblant le niveau d'API 24 ou supérieur, car elles sont réservées.
[C-0-11] DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack, tels que définis dans le NDK, via la bibliothèque libGLESv3.so. Notez que tous les symboles DOIVENT être présents, mais la section 7.1.4.1 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
[C-0-12] DOIT exporter les symboles de fonction pour les symboles de fonction Vulkan 1.0 de base, ainsi que les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1 et VK_KHR_get_physical_device_properties2 via la bibliothèque libvulkan.so. Notez que tous les symboles DOIVENT être présents, mais la section 7.1.4.2 décrit plus en détail les exigences concernant l'implémentation complète de chaque fonction correspondante.
DOIT être créé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Android Open Source en amont

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

3.3.2. Compatibilité du code natif ARM 32 bits

Si les implémentations d'appareil indiquent la compatibilité avec l'ABI armeabi, elles :

[C-3-1] MUST also support armeabi-v7a and report its support, as armeabi is only for backwards compatibility with older apps.

Si les implémentations d'appareils indiquent la compatibilité avec l'ABI armeabi-v7a, les applications utilisant cette ABI :

[C-2-1] MUST include the following lines in /proc/cpuinfo, and SHOULD NOT alter the values on the same device, even when they are read by other ABIs.
- Features:, suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives prises en charge par l'appareil.
- CPU architecture:, suivi d'un entier décrivant l'architecture ARM la plus élevée compatible avec l'appareil (par exemple, "8" pour les appareils ARMv8).
[C-2-2] DOIT toujours maintenir les opérations suivantes disponibles, même si l'ABI est implémentée sur une architecture ARMv8, que ce soit par le biais d'une prise en charge native du processeur ou par le biais d'une émulation logicielle :
- Instructions SWP et SWPB.
- Instruction SETEND.
- Opérations de barrière CP15ISB, CP15DSB et CP15DMB.
[C-2-3] DOIT inclure la prise en charge de l'extension Advanced SIMD (alias NEON).

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

[C-1-1] DOIT signaler android.software.webview.
[C-1-2] DOIT utiliser la version du projet Chromium à partir du projet Android Open Source en amont sur la branche Android 11 pour l'implémentation de l'API android.webkit.WebView.
[C-1-3] La chaîne de l'agent utilisateur signalée par WebView DOIT être au format suivant :

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- La valeur de la chaîne $(VERSION) DOIT être identique à celle de android.os.Build.VERSION.RELEASE.
- La chaîne $(MODEL) PEUT être vide, mais si elle ne l'est pas, elle DOIT avoir la même valeur que android.os.Build.MODEL.
- "Build/$(BUILD)" PEUT être omis, mais s'il est présent, la chaîne $(BUILD) DOIT être identique à la valeur de android.os.Build.ID.
- La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Android Open Source en amont.
- Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.
Le composant WebView DOIT inclure la prise en charge du plus grand nombre possible de fonctionnalités HTML5 et, s'il prend en charge la fonctionnalité, DOIT être conforme à la spécification HTML5.
[C-1-3] DOIT afficher le contenu fourni ou le contenu de l'URL distante dans un processus distinct de l'application qui instancie la WebView. Plus précisément, le processus de rendu distinct DOIT disposer de privilèges inférieurs, s'exécuter en tant qu'ID utilisateur distinct, ne pas avoir accès au répertoire de données de l'application, ne pas avoir d'accès direct au réseau et n'avoir accès qu'aux services système minimaux requis via Binder. L'implémentation AOSP de WebView répond à cette exigence.

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

3.4.2. Compatibilité du navigateur

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

[C-1-1] DOIT être compatible avec chacune des API associées à HTML5 :
[C-1-2] DOIT être compatible avec l'API Web Storage HTML5/W3C et DEVRAIT être compatible avec l'API IndexedDB HTML5/W3C. Notez que les organismes de normalisation du développement Web favorisent IndexedDB par rapport au stockage Web. IndexedDB devrait donc devenir un composant obligatoire dans une future version d'Android.
MAY ship a custom user agent string in the standalone Browser application.
DOIT implémenter la prise en charge d'autant de fonctionnalités HTML5 que possible dans l'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers).

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

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

3.5. Compatibilité comportementale de l'API

Implémentations sur les appareils :

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

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

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

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

3.5.1. Restriction d'application

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

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

3.6. Espaces de noms de l'API

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

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

Autrement dit, ils :

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

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

[C-0-3] NE DOIT PAS avoir d'incidence sur le comportement indiqué ni sur la signature en langage Java des API exposées publiquement.
[C-0-4] NE DOIT PAS être annoncé ni exposé aux développeurs.

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

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

Si un intégrateur d'appareils propose d'améliorer l'un des espaces de noms de package ci-dessus (par exemple, en ajoutant une nouvelle fonctionnalité utile à une API existante ou en ajoutant une nouvelle API), il DOIT se rendre sur source.android.com et commencer le processus de contribution des modifications et du code, conformément aux informations de ce site.

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

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

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec l'intégralité du format Dalvik Executable (DEX) et avec les spécifications et la sémantique du bytecode Dalvik.
[C-0-2] DOIT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme spécifié dans le tableau suivant. (Consultez la section 7.1.1 pour obtenir les définitions de la taille et de la densité de l'écran.)
DOIT utiliser Android RunTime (ART), l'implémentation en amont de référence du format Dalvik Executable et le système de gestion des packages de l'implémentation de référence.
DOIT exécuter des tests de fuzzing dans différents modes d'exécution et architectures cibles pour assurer la stabilité du runtime. Consultez JFuzz et DexFuzz sur le site Web du projet Android Open Source.

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

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

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur d'applications (écran d'accueil)

Android inclut une application de lanceur d'applications (écran d'accueil) et permet aux applications tierces de remplacer le lanceur d'applications de l'appareil (écran d'accueil).

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

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

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

[C-2-1] DOIT signaler true pour ShortcutManager.isRequestPinShortcutSupported().
[C-2-2] DOIT demander à l'utilisateur avant d'ajouter un raccourci demandé par les applications via la méthode d'API ShortcutManager.requestPinShortcut().
[C-2-3] DOIT être compatible avec les raccourcis épinglés, ainsi qu'avec les raccourcis dynamiques et statiques, comme indiqué sur la page Raccourcis d'application.

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

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

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

[C-4-1] DOIT être compatible avec toutes les fonctionnalités de raccourci documentées (par exemple, les raccourcis statiques et dynamiques, l'épinglage de raccourcis) et implémenter entièrement les API de la classe d'API ShortcutManager.

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

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

3.8.2. Widgets

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

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

[C-1-1] DOIT déclarer la compatibilité avec la fonctionnalité de plate-forme android.software.app_widgets.
[C-1-2] DOIT inclure une prise en charge intégrée des AppWidgets et exposer des affordances d'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur d'applications.
[C-1-3] DOIT être capable d'afficher des widgets de taille 4 x 4 dans la taille de grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android.
MAY 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'applications tierces et l'épinglage de raccourcis dans les applications, elles :

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

3.8.3. Notifications

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

3.8.3.1. Présentation des notifications

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

[C-1-1] DOIT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK, et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas du matériel, les API correspondantes DOIVENT être implémentées en tant qu'opérations sans effet. Ce comportement est décrit plus en détail dans la section 7.
[C-1-2] DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API ou dans le guide de style des icônes de la barre d'état/système, mais PEUT proposer une expérience utilisateur alternative pour les notifications par rapport à celle fournie par l'implémentation Android Open Source de référence.
[C-1-3] DOIT respecter et implémenter correctement les comportements décrits pour les API afin de mettre à jour, supprimer et regrouper les notifications.
[C-1-4] DOIT fournir le comportement complet de l'API NotificationChannel documentée dans le SDK.
[C-1-5] DOIT fournir une option permettant à l'utilisateur de bloquer et de modifier les notifications d'une application tierce spécifique pour chaque canal et chaque niveau de package d'application.
[C-1-6] DOIT également fournir une option permettant à l'utilisateur d'afficher les canaux de notification supprimés.
[C-1-7] DOIT afficher correctement toutes les ressources (images, autocollants, icônes, etc.) fournies par le biais de Notification.MessagingStyle à côté du texte de la notification, sans interaction supplémentaire de l'utilisateur. Par exemple, TOUTES les ressources, y compris les icônes fournies par le biais de android.app.Person, DOIVENT être affichées dans une conversation de groupe définie par setGroupConversation.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'afficher automatiquement une option permettant à l'utilisateur de bloquer les notifications d'une application tierce spécifique pour chaque canal et chaque niveau de package d'application après que l'utilisateur a ignoré cette notification à plusieurs reprises.
DOIT prendre en charge les notifications enrichies.
DOIT présenter certaines notifications à priorité élevée sous forme de notifications prioritaires.
DOIT permettre à l'utilisateur de répéter les notifications.
MAY ne peut gérer que la visibilité et le calendrier des notifications d'événements importants que les applications tierces peuvent envoyer aux utilisateurs, afin d'atténuer les problèmes de sécurité tels que la distraction du conducteur.

Android 11 est compatible avec les notifications de conversation, qui utilisent MessagingStyle et fournissent un ID de raccourci Personne publié.

Implémentations sur les appareils :

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

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

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

Si les implémentations d'appareils sont compatibles avec les notifications enrichies, elles :

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

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

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

3.8.3.2. Service d'écoute des notifications

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

Implémentations sur les appareils :

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

Si les implémentations d'appareils permettent aux utilisateurs de suspendre les notifications, elles :

[C-1-1] DOIT refléter correctement l'état de la notification mise en veille via les API standards telles que NotificationListenerService.getSnoozedNotifications().
[C-1-2] DOIT permettre à l'utilisateur de mettre en veille les notifications de chaque application tierce installée, sauf si elles proviennent de services persistants/de premier plan.

3.8.3.3. NPD (Ne pas déranger)

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

[C-1-1] DOIT, lorsque l'implémentation de l'appareil a fourni un moyen à l'utilisateur d'autoriser ou de 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éées par les applications à côté des règles créées par l'utilisateur et prédéfinies.
[C-1-3] DOIT respecter les valeurs suppressedVisualEffects transmises avec NotificationManager.Policy. Si une application a défini l'un des indicateurs SUPPRESSED_EFFECT_SCREEN_OFF ou SUPPRESSED_EFFECT_SCREEN_ON, elle DOIT indiquer à l'utilisateur que les effets visuels sont supprimés dans le menu des paramètres du mode Ne pas déranger.

3.8.4. Recherche

Android inclut des API qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. En règle générale, cette fonctionnalité se compose d'une interface utilisateur unique à l'échelle du système qui permet aux utilisateurs de saisir des requêtes, affiche des suggestions à mesure qu'ils saisissent du texte et affiche les résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour proposer une fonctionnalité de recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.

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

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

[C-1-1] DOIT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions dans le champ de recherche lorsqu'il est exécuté en mode Recherche globale.

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

Le comportement par défaut DOIT être d'afficher les résultats et les suggestions du moteur de recherche sur le Web.

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

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

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

3.8.5. Alertes et toasts

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

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

[C-1-1] DOIT fournir une affordance utilisateur pour empêcher une application d'afficher des fenêtres d'alerte qui utilisent TYPE_APPLICATION_OVERLAY . L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notification.
[C-1-2] DOIT respecter l'API Toast et afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.6. Thèmes

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

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

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

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

Android inclut également une famille de thèmes "Device Default" (Par défaut de l'appareil) qui correspond à un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent que l'apparence de leur application corresponde à celle du thème de l'appareil tel que défini par l'implémenteur de l'appareil.

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

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

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

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

3.8.7. Fonds d'écran animés

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

Un matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut exécuter tous les fonds d'écran animés, sans limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effets indésirables sur les autres applications. Si des limitations matérielles entraînent le plantage ou le dysfonctionnement des fonds d'écran et/ou des applications, une consommation excessive de processeur ou de batterie, ou une fréquence d'images inacceptablement basse, le matériel est considéré comme incapable d'exécuter des fonds d'écran animés. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne fonctionnera pas de manière fiable sur du matériel qui ne prend pas en charge plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

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

3.8.8. Changement d'activité

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

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

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

[C-1-1] DOIT prendre en charge au moins sept activités affichées.
DOIT au moins afficher 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é.
DOIT afficher la couleur de mise en surbrillance, l'icône et le titre de l'écran dans les éléments récents.
DOIT afficher une option de fermeture ("x"), mais PEUT la retarder jusqu'à ce que l'utilisateur interagisse avec les écrans.
DOIT implémenter un raccourci pour passer facilement à l'activité précédente.
DOIT déclencher l'action de changement rapide entre les deux applications les plus récemment utilisées lorsque la touche de fonction "Récents" est appuyée deux fois.
DOIT déclencher le mode multifenêtre en écran partagé, si celui-ci est pris en charge, lorsque l'utilisateur appuie de manière prolongée sur la touche de fonction "Récents".
PEUT afficher les éléments récents affiliés sous forme de groupe qui se déplace ensemble.
[SR] Il est FORTEMENT RECOMMANDÉ d'utiliser l'interface utilisateur Android en amont (ou une interface similaire basée sur des miniatures) pour l'écran "Récents".

3.8.9. Gestion des entrées

Android inclut la prise en charge de la gestion des entrées et des éditeurs de méthode d'entrée tiers.

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

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

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

L'API Remote Control Client est obsolète depuis Android 5.0 au profit du modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage.

3.8.11. Économiseurs d'écran (anciennement "Rêves")

Consultez la section 3.2.3.5 pour connaître l'intention de paramètre permettant de configurer les économiseurs d'écran.

3.8.12. Position

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

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

3.8.13. Unicode et police

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

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

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

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

DOIT fournir à l'utilisateur une méthode de saisie pour ces caractères emoji.

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

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

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

3.8.14. Mode multifenêtre

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

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

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

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

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

[C-3-1] DOIT lancer des activités en mode multifenêtre Picture-in-picture lorsque l'application : * cible le niveau d'API 26 ou supérieur et déclare android:supportsPictureInPicture ; * cible le niveau d'API 25 ou inférieur et déclare à la fois android:resizeableActivity et android:supportsPictureInPicture.
[C-3-2] DOIT exposer les actions dans son SystemUI, comme spécifié par l'activité PIP actuelle via l'API setActions().
[C-3-3] DOIT prendre en charge les formats d'image supérieurs ou égaux à 1:2.39 et inférieurs ou égaux à 2.39:1, comme spécifié par l'activité PIP via l'API setAspectRatio().
[C-3-4] DOIT utiliser KeyEvent.KEYCODE_WINDOW pour contrôler la fenêtre PIP. Si le mode PIP n'est pas implémenté, la clé DOIT être disponible pour l'activité au premier plan.
[C-3-5] DOIT fournir une affordance utilisateur pour empêcher une application de s'afficher en mode PIP. L'implémentation AOSP répond à cette exigence en proposant des commandes dans la barre de notifications.
[C-3-6] DOIT allouer la largeur et la hauteur minimales suivantes à la fenêtre PIP lorsqu'une application ne déclare aucune valeur pour AndroidManifestLayout_minWidth et AndroidManifestLayout_minHeight :
- Les appareils dont la valeur Configuration.uiMode est différente de UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur et une hauteur minimales de 108 dp.
- Les appareils dont Configuration.uiMode est défini sur UI_MODE_TYPE_TELEVISION DOIVENT allouer une largeur minimale de 240 dp et une hauteur minimale de 135 dp.

3.8.15. Encoche

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

Si les implémentations d'appareil incluent une ou plusieurs encoches, elles doivent :

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

3.8.16. Commandes de contrôle des appareils

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

Consultez la section 2_2_3 pour connaître les exigences spécifiques aux appareils.

3.9. Gestion de l'appareil

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

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

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

3.9.1 Préparation de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

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

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

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

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

3.9.1.2 Provisionnement de profils gérés

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

[C-1-1] DOIT implémenter les API permettant à une application Device Policy Controller (DPC) de devenir le propriétaire d'un nouveau profil géré.
[C-1-2] Le processus de provisionnement de profil géré (flux initié par android.app.action.PROVISION_MANAGED_PROFILE) que les utilisateurs expérimentent DOIT correspondre à l'implémentation AOSP.
[C-1-3] DOIT fournir les affordances utilisateur suivantes dans les paramètres pour indiquer à l'utilisateur lorsqu'une fonction système particulière a été désactivée par le contrôleur de règles relatives aux appareils (DPC) :
- Une icône cohérente ou une autre affordance utilisateur (par exemple, l'icône d'informations AOSP en amont) pour indiquer qu'un paramètre particulier est limité par un administrateur de l'appareil.
- Message explicatif court, fourni par l'administrateur de l'appareil via setShortSupportMessage.
- Icône de l'application DPC.

3.9.2 Prise en charge des profils gérés

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

[C-1-1] DOIT être compatible avec les profils gérés via les API android.app.admin.DevicePolicyManager.
[C-1-2] DOIT autoriser la création d'un seul profil géré.
[C-1-3] DOIT utiliser un badge d'icône (semblable au badge de travail en amont AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, comme les applications récentes et les notifications.
[C-1-4] DOIT afficher une icône de notification (semblable au badge de profil professionnel AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
[C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré lorsque l'appareil se réactive (ACTION_USER_PRESENT) et que l'application au premier plan se trouve dans le profil géré.
[C-1-6] Lorsqu'un profil géré existe, une indication visuelle DOIT être affichée dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré vers l'utilisateur principal ou inversement, si le contrôleur de règles de l'appareil l'a activé.
[C-1-7] Lorsqu'un profil géré existe, les affordances utilisateur suivantes DOIVENT être exposées à la fois pour l'utilisateur principal et pour le profil géré :
- Comptabilité distincte pour l'utilisation de la batterie, de la localisation, des données mobiles et du stockage pour l'utilisateur principal et le profil géré.
- Gestion indépendante des applications VPN installées dans le profil principal ou géré.
- Gestion indépendante des applications installées dans le profil principal ou géré.
- Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
[C-1-8] DOIT s'assurer que les applications de téléphone, de contacts et de messagerie préinstallées peuvent rechercher et consulter les informations sur l'appelant à partir du profil géré (le cas échéant) en plus de celles du profil principal, si le contrôleur de règles relatives aux appareils le permet.
[C-1-9] DOIT s'assurer de respecter toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas considéré comme un autre utilisateur en plus de l'utilisateur principal.

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

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

3.9.3 Assistance pour les utilisateurs gérés

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

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

3.10. Accessibilité

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

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

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

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

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

3.11. Synthèse vocale

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

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

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

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

[C-2-1] DOIT fournir à l'utilisateur la possibilité de sélectionner un moteur TTS à utiliser au niveau du système.

3.12. Framework d'entrée TV

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

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

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

3.13. Les réglages rapides

Android fournit un composant d'interface utilisateur de configuration rapide qui permet d'accéder rapidement aux actions fréquemment utilisées ou urgentes.

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

[C-1-1] DOIT permettre à l'utilisateur d'ajouter ou de supprimer les tuiles fournies par les API quicksettings à partir d'une application tierce.
[C-1-2] NE DOIT PAS ajouter automatiquement un bloc d'une application tierce directement aux réglages rapides.
[C-1-3] DOIT afficher tous les blocs ajoutés par l'utilisateur à partir d'applications tierces à côté des blocs de réglages rapides fournis par le système.

3.14. Interface utilisateur Media

Si les implémentations d'appareils incluent des applications non activées par la voix (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 obtenus via getTitle(), comme décrit dans MediaDescription. Les titres peuvent être raccourcis pour respecter les règles de sécurité (par exemple, la distraction du conducteur).
[C-1-3] DOIT afficher l'icône de l'application tierce chaque fois qu'il affiche du contenu fourni par cette application tierce.
[C-1-4] DOIT permettre à l'utilisateur d'interagir avec l'ensemble de la hiérarchie MediaBrowser. PEUT limiter l'accès à une partie de la hiérarchie pour respecter les règles de sécurité (par exemple, la distraction du conducteur), mais NE DOIT PAS accorder de traitement préférentiel en fonction du contenu ou du fournisseur de contenu.
[C-1-5] DOIT considérer le double-tap sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

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

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

Si les implémentations d'appareils sont compatibles avec les applications instantanées, elles :

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

3.16. Association d'un appareil associé

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

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

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

3.17. Applications gourmandes en ressources

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

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

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

[C-1-1] MUST ignore the cantSaveState attribute set by apps and MUST NOT change the app behavior based on that attribute.

3.18. Contacts

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

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

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

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

Implémentations sur les appareils :

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

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

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

4. Compatibilité du packaging d'application

Implémentations des appareils :

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

Implémentations sur les appareils :

[C-0-2] DOIT être compatible avec la validation des fichiers ".apk" à l'aide des schémas de signature des APK v3 et v2 , ainsi que de la signature JAR.
[C-0-3] NE DOIT PAS étendre les formats .apk, Android Manifest, bytecode Dalvik ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correctes de ces fichiers sur d'autres appareils compatibles.
[C-0-4] NE DOIT PAS autoriser les applications autres que l'"installateur par défaut" actuel du package à désinstaller silencieusement l'application sans aucune confirmation de l'utilisateur, comme indiqué dans le SDK pour l'autorisation DELETE_PACKAGE. Les seules exceptions sont l'application système de vérification des packages qui gère l'intent PACKAGE_NEEDS_VERIFICATION et l'application de gestion du stockage qui gère l'intent ACTION_MANAGE_STORAGE.
[C-0-5] DOIT disposer d'une activité qui gère l'intent android.settings.MANAGE_UNKNOWN_APP_SOURCES.
[C-0-6] NE DOIT PAS installer de packages d'application provenant de sources inconnues, sauf si l'application qui demande l'installation répond à toutes les exigences suivantes :
- Il DOIT déclarer l'autorisation REQUEST_INSTALL_PACKAGES ou définir android:targetSdkVersion sur 24 ou moins.
- L'utilisateur DOIT avoir autorisé l'installation d'applications provenant de sources inconnues.
DOIT fournir une affordance utilisateur pour accorder/révoquer l'autorisation d'installer des applications provenant de sources inconnues par application, mais PEUT choisir d'implémenter cela comme une no-op et de renvoyer RESULT_CANCELED pour startActivityForResult(), si l'implémentation de l'appareil ne souhaite pas permettre aux utilisateurs d'avoir ce choix. Toutefois, même dans ce cas, ils DOIVENT indiquer à l'utilisateur pourquoi ce choix ne lui est pas proposé.
[C-0-7] DOIT afficher une boîte de dialogue d'avertissement avec la chaîne d'avertissement fournie par l'API système PackageManager.setHarmfulAppWarning à l'utilisateur avant de lancer une activité dans une application qui a été marquée par la même API système PackageManager.setHarmfulAppWarning comme potentiellement dangereuse.
DOIT fournir une option permettant à l'utilisateur de choisir de désinstaller ou de lancer une application dans la boîte de dialogue d'avertissement.
[C-0-8] DOIT implémenter la prise en charge du système de fichiers incrémentiel, comme indiqué ici.
[C-0-9] DOIT être compatible avec la validation des fichiers .apk à l'aide du schéma de signature des fichiers APK v4.
Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre aux exigences [C-0-8] et [C-0-9] par le biais d'une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

5. Compatibilité multimédia

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

Implémentations sur les appareils :

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

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

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

5.1. Codecs multimédias

5.1.1. Encodage audio

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

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

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

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

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

5.1.2. Décodage audio

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

Si les implémentations d'appareil déclarent la compatibilité avec la fonctionnalité android.hardware.audio.output, elles doivent être en mesure de décoder les formats audio suivants :

[C-1-1] Profil AAC MPEG-4 (AAC LC)
[C-1-2] Profil MPEG-4 HE AAC (AAC+)
[C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
[C-1-4] AAC ELD (AAC à faible latence amélioré)
[C-1-11] xHE-AAC (profil étendu HE-AAC ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de la plage dynamique ISO/IEC 23003-4)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE, y compris les formats audio haute résolution jusqu'à 24 bits, avec une fréquence d'échantillonnage de 192 kHz et 8 canaux. Notez que cette exigence ne concerne que le décodage. Un appareil est autorisé à sous-échantillonner et à sous-mixer 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 flux multicanaux (c'est-à-dire plus de deux canaux) en PCM via le décodeur audio AAC par défaut dans l'API android.media.MediaCodec, les éléments suivants DOIVENT être pris en charge :

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

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

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

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

MAY est compatible avec le contrôle du volume et de la plage dynamique à l'aide du profil de contrôle de la plage dynamique ISO/IEC 23003-4.

Si la norme ISO/IEC 23003-4 est acceptée et que les métadonnées ISO/IEC 23003-4 et ISO/IEC 14496-3 sont présentes dans un flux binaire décodé :

Les métadonnées ISO/IEC 23003-4 DOIVENT prévaloir.

Tous les décodeurs audio DOIVENT être compatibles avec les sorties suivantes :

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

5.1.3. Détails des codecs audio

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

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

Les implémentations d'appareils DOIVENT être compatibles avec l'encodage d'image suivant :

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

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

[C-1-1] DOIT fournir un codec d'encodeur HEVC à accélération matérielle qui prend en charge le mode de contrôle du débit binaire BITRATE_MODE_CQ, le profil HEVCProfileMainStill et la taille de frame de 512 x 512 px.

5.1.5. Décodage d'image

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

Les implémentations d'appareils DOIVENT être compatibles avec 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] DOIVENT être compatibles avec le décodage d'images HEIF (HEIC).

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

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

5.1.6. Détails sur les codecs d'image

Format/Codec	Détails	Types de fichiers/formats de conteneurs compatibles
JPEG	Base+progressif	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)

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

[C-1-1] DOIT être compatible avec le format de couleur flexible YUV420 8:8:8 (COLOR_FormatYUV420Flexible) via CodecCapabilities.
[SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le format de couleurs RGB888 pour le mode Surface d'entrée.
[C-1-3] DOIT être compatible avec au moins un format de couleur YUV420 8:8:8 plan ou semi-plan : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'il soit compatible avec les deux.

5.1.7. Codecs vidéo

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

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

[C-1-1] Les codecs vidéo DOIVENT être compatibles avec les tailles de bytebuffer d'entrée et de sortie qui permettent d'accueillir la plus grande trame compressée et non compressée possible, comme le prévoient la norme et la configuration, mais sans surallocation.
[C-1-2] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec les formats de couleur flexibles YUV420 8:8:8 (COLOR_FormatYUV420Flexible) via CodecCapabilities.
[C-1-3] Les encodeurs et décodeurs vidéo DOIVENT être compatibles avec au moins un format de couleur YUV420 8:8:8 planaire ou semi-planaire : COLOR_FormatYUV420PackedPlanar (équivalent à COLOR_FormatYUV420Planar) ou COLOR_FormatYUV420PackedSemiPlanar (équivalent à COLOR_FormatYUV420SemiPlanar). Il est FORTEMENT RECOMMANDÉ qu'ils soient compatibles avec les deux.
[SR] Il est FORTEMENT RECOMMANDÉ que les encodeurs et décodeurs vidéo soient compatibles avec au moins un format de couleur YUV420 8:8:8 plan ou semi-plan optimisé pour le matériel (YV12, NV12, NV21 ou format équivalent optimisé par le fournisseur).
[C-1-5] Les décodeurs vidéo compatibles avec un format à haute profondeur de bits (9 bits ou plus par canal) DOIVENT être compatibles avec la sortie d'un format équivalent à 8 bits si l'application le demande. Cela DOIT se refléter dans la prise en charge d'un format de couleur YUV420 8:8:8 via android.media.MediaCodecInfo.

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

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

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

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

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

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

5.1.8. Liste des codecs vidéo

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

5.1.9. Sécurité des codecs multimédias

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

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

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

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

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

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

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

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

5.1.10. Caractérisation des codecs multimédias

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

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

En particulier :

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

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

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

	SD (qualité médiocre)	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)	1 408 x 1 152 px (H263) 1 280 x 720 px (autre)	1 920 x 1 080 px (autre que MPEG4)	3 840 x 2 160 px (HEVC, VP9)

[C-2-2] Les codecs vidéo caractérisés comme étant à accélération matérielle DOIVENT publier des informations sur les points de performance. Ils DOIVENT chacun lister tous les points de performances standards acceptés (listés dans l'API PerformancePoint), sauf s'ils sont couverts par un autre point de performances standards accepté.
Ils DOIVENT également publier des points de performances étendus s'ils prennent en charge des performances vidéo soutenues autres que celles listées dans les normes.

5.2. Encodage vidéo

Si les implémentations d'appareils sont compatibles avec un encodeur vidéo et le mettent à la disposition des applications tierces, elles :

NE DOIT PAS dépasser de plus de 15 % le débit binaire entre les intervalles d'images clés (I-frames) sur deux fenêtres glissantes.
NE DOIT PAS dépasser 100 % du débit binaire sur une fenêtre glissante d'une seconde.

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

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

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

[C-2-1] DOIT être compatible avec les débits configurables de manière dynamique.
DOIT être compatible avec les fréquences d'images variables, où l'encodeur vidéo DOIT déterminer la durée instantanée des images en fonction des codes temporels des tampons d'entrée et allouer son bit bucket en fonction de cette durée d'image.

Si les implémentations d'appareils sont compatibles avec l'encodeur vidéo MPEG-4 SP et le mettent à la disposition des applications tierces, elles :

DOIT être compatible avec les débits configurables de manière dynamique pour l'encodeur compatible.

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

[C-4-1] Tous les encodeurs vidéo et d'images avec accélération matérielle DOIVENT être compatibles avec l'encodage des frames à partir des caméras matérielles.
DOIT être compatible avec l'encodage des frames à partir des caméras matérielles via tous les encodeurs vidéo ou d'image.

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

[C-1-2] DOIT être compatible avec le profil 0 niveau 3.
[C-1-1] DOIT être compatible avec l'écriture de fichiers Matroska WebM.
[C-1-3] DOIT générer des données CodecPrivate.
DOIT prendre en charge les profils de décodage HD indiqués dans le tableau suivant.
[SR] : il est FORTEMENT RECOMMANDÉ que les SR prennent en charge les profils de décodage HD indiqués 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	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

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

La prise en charge du format 12 bits est FACULTATIVE.

5.2.5. H.265

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

[C-1-1] DOIT être compatible avec le profil principal de niveau 3.
DOIT prendre en charge les profils d'encodage HD indiqués dans le tableau suivant.
[SR] : il est FORTEMENT RECOMMANDÉ que les SR prennent en charge les profils d'encodage HD indiqués 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	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	30 ips
Débit vidéo	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

5.3. Décodage vidéo

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

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

5.3.1. MPEG-2

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

[C-1-1] DOIT être compatible avec le profil principal de niveau élevé.

5.3.2. H.263

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

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

5.3.3. MPEG-4

Si les implémentations d'appareils comportent des décodeurs MPEG-4, elles :

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

5.3.4. H.264

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

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

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

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

	SD (qualité médiocre)	SD (haute qualité)	HD – 720p	HD – 1080p
Résolution vidéo	320 x 240 px	720 x 480 px	1 280 x 720 px	1 920 x 1 080 px
Fréquence d'images de la vidéo	30 ips	30 ips	60 FPS	30 fps (60 fps^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, elles :

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

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

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

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

Si les implémentations d'appareils affirment prendre en charge un profil HDR via les API Media :

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

5.3.6. VP8

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

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

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

[C-2-1] Les implémentations d'appareils DOIVENT être compatibles avec les profils 720p du tableau suivant.
[C-2-2] Les implémentations d'appareils DOIVENT être compatibles avec les profils 1080p du tableau suivant.

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

5.3.7. VP9

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

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

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

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

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

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

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

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

La prise en charge du format 12 bits est FACULTATIVE.

Si les implémentations d'appareils affirment prendre en charge un profil HDR (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) via les API Media :

[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) provenant de l'application. Ils DOIVENT également être capables d'extraire et de générer les métadonnées HDR requises à partir du flux binaire et/ou du conteneur.
[C-4-2] Les implémentations d'appareils DOIVENT afficher correctement le contenu HDR sur l'écran de l'appareil ou sur un port de sortie vidéo standard (par exemple, HDMI).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

[C-1-1] DOIT être compatible avec le profil 0, y compris le contenu 10 bits.

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient listées comme "SHOULD" depuis Android 4.3, la définition de compatibilité pour les futures versions prévoit de les remplacer par "MUST". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences listées comme "SHOULD" (DOIVENT). Sinon, ils ne pourront pas atteindre la compatibilité Android lorsqu'ils seront mis à niveau vers la future version.

5.4.1. Capture audio brute et informations sur le micro

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

[C-1-1] DOIT permettre la capture de contenu audio brut présentant les caractéristiques suivantes :
- Format : PCM linéaire, 16 bits
- Taux d'échantillonnage : 8 000, 11 025, 16 000, 44 100, 48 000 Hz
- Canaux : mono
DOIT autoriser la capture de contenu audio brut présentant les caractéristiques suivantes :
- Format : PCM linéaire, 16 bits et 24 bits
- Taux d'échantillonnage : 8 000, 11 025, 16 000, 22 050, 24 000, 32 000, 44 100, 48 000 Hz
- Canaux : autant de canaux que de micros sur l'appareil
[C-1-2] DOIT capturer aux taux d'échantillonnage ci-dessus sans suréchantillonnage.
[C-1-3] DOIT inclure un filtre anti-aliasing approprié lorsque les taux d'échantillonnage ci-dessus sont capturés avec un sous-échantillonnage.
DOIT autoriser la capture de contenu audio brut de qualité radio AM et DVD, ce qui signifie les caractéristiques suivantes :
- Format : PCM linéaire, 16 bits
- Taux d'échantillonnage : 22 050, 48 000 Hz
- Chaînes : stéréo
- [C-1-4] DOIT respecter l'API MicrophoneInfo et renseigner correctement les informations concernant les microphones disponibles sur l'appareil et accessibles aux applications tierces via l'API AudioManager.getMicrophones(), ainsi que les microphones actuellement actifs et accessibles aux applications tierces via les API AudioRecord.getActiveMicrophones() et MediaRecorder.getActiveMicrophones(). Si les implémentations d'appareils permettent la capture de contenu audio brut en qualité radio AM et DVD, elles :
[C-2-1] DOIT capturer sans suréchantillonner à un rapport supérieur à 16000:22050 ou 44100:48000.
[C-2-2] DOIT inclure un filtre anti-aliasing approprié pour tout suréchantillonnage ou sous-échantillonnage.

5.4.2. Capture pour la reconnaissance vocale

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

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

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

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

5.4.3. Capture pour le reroutage de la lecture

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

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

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

5.4.4. Annulation de l'écho acoustique

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

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

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

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

5.4.5. Capture simultanée

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

[C-1-1] DOIT autoriser l'accès simultané au micro par un service d'accessibilité capturant avec AudioSource.VOICE_RECOGNITION et au moins une application capturant avec n'importe quel AudioSource.
[C-1-2] DOIT autoriser l'accès simultané au micro par une application préinstallée qui détient un rôle d'Assistant et au moins une application qui capture avec n'importe quel AudioSource, à l'exception de AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER.
[C-1-3] DOIT couper le son capturé par toute autre application, à l'exception d'un service d'accessibilité, lorsqu'une application capture du son avec AudioSource.VOICE_COMMUNICATION ou AudioSource.CAMCORDER. Toutefois, lorsqu'une application capture l'audio via AudioSource.VOICE_COMMUNICATION, une autre application peut capturer l'appel vocal s'il s'agit d'une application privilégiée (préinstallée) avec l'autorisation CAPTURE_AUDIO_OUTPUT.
[C-1-4] Si deux applications ou plus capturent du contenu simultanément et qu'aucune d'elles n'a d'interface utilisateur au premier plan, celle qui a commencé la capture le plus récemment reçoit l'audio.

5.4.6. Niveaux de gain du micro

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

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

5.5. Lecture audio

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

5.5.1. Lecture audio brute

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

[C-1-1] DOIT permettre la lecture de contenus audio bruts présentant les caractéristiques suivantes :
- Formats sources : PCM linéaire, 16 bits, 8 bits, float
- Canaux : mono, stéréo, configurations multicanaux valides avec jusqu'à huit canaux
- Taux d'échantillonnage (en Hz) :
  - 8 000, 11 025, 16 000, 22 050, 32 000, 44 100, 48 000 pour les configurations de canaux listées ci-dessus
  - 96 000 en mono et en stéréo
DOIT autoriser la lecture de contenu audio brut présentant les caractéristiques suivantes :
- Taux d'échantillonnage : 24 000, 48 000

5.5.2. Effets audio

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

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

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

5.5.3. Volume de sortie audio

Implémentations d'appareils automobiles :

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

5.6. Latence audio

La latence audio correspond au délai entre le moment où un signal audio entre dans un système et celui où il en sort. De nombreuses classes d'applications s'appuient sur de faibles latences pour obtenir des effets sonores en temps réel.

Aux fins de la présente section, utilisez les définitions suivantes :

Latence de sortie : Intervalle entre le moment où une application écrit une trame de données codées PCM et le moment où le son correspondant est présenté à l'environnement au niveau d'un transducteur intégré ou le moment où le signal quitte l'appareil via un port et peut être observé en externe.
Latence de sortie à froid : Latence de sortie pour la première frame, lorsque le système de sortie audio est inactif et éteint avant la requête.
Latence de sortie continue Latence de sortie pour les frames suivants, une fois que l'appareil lit l'audio.
Latence d'entrée : Intervalle entre le moment où un son est présenté par l'environnement à un transducteur sur l'appareil ou où un signal entre dans l'appareil via un port, et le moment où une application lit la trame de données codées PCM correspondante.
Entrée perdue : Partie initiale d'un signal d'entrée inutilisable ou indisponible.
Latence d'entrée à froid : Somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio est inactif et éteint avant la requête.
Latence d'entrée continue : Latence d'entrée pour les frames suivants, lorsque l'appareil enregistre l'audio.
Jitter de sortie à froid : Variabilité entre les différentes mesures des valeurs de latence de sortie à froid.
Gigue d'entrée à froid. Variabilité entre les différentes mesures des valeurs de latence d'entrée à froid.
Latence aller-retour continue. Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de mise en mémoire tampon. Le délai tampon permet à l'application de traiter le signal et d'atténuer la différence de phase entre les flux d'entrée et de sortie.
API de file d'attente de tampon PCM OpenSL ES. Ensemble d'API OpenSL ES liées à PCM dans Android NDK.
API audio native AAudio Ensemble d'API AAudio dans le NDK Android.
Code temporel. Paire composée d'une position de frame relative dans un flux et de l'heure estimée à laquelle ce frame entre ou quitte le pipeline de traitement audio sur le point de terminaison associé. Voir aussi AudioTimestamp.
glitch. Il s'agit d'une interruption temporaire ou d'une valeur d'échantillon incorrecte dans le signal audio, généralement causée par un manque de données dans le tampon pour la sortie, un dépassement de tampon pour l'entrée ou toute autre source de bruit numérique ou analogique.

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

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

Si les implémentations d'appareil déclarent android.hardware.audio.output, il est FORTEMENT RECOMMANDÉ qu'elles respectent ou dépassent les exigences suivantes :

[C-SR] Latence de sortie à froid de 100 millisecondes ou moins. Il est FORTEMENT RECOMMANDÉ aux appareils existants et nouveaux qui exécutent cette version d'Android de respecter ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence de sortie à froid de 200 ms ou moins.
[C-SR] Latence de sortie continue de 45 millisecondes ou moins.
[C-SR] Minimiser le jitter de sortie à froid.
[C-SR] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 1 ms.

Si les implémentations d'appareil répondent aux exigences ci-dessus, après toute calibration initiale, lorsqu'elles utilisent à la fois les API audio natives AAudio et la file d'attente de tampon PCM OpenSL ES, pour la latence de sortie continue et la latence de sortie à froid sur au moins un périphérique de sortie audio compatible, elles sont :

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

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

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

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

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

Si les implémentations d'appareils incluent android.hardware.microphone, il est FORTEMENT RECOMMANDÉ qu'elles répondent aux exigences suivantes concernant l'entrée audio :

[C-SR] Latence d'entrée à froid de 100 millisecondes ou moins. Il est FORTEMENT RECOMMANDÉ aux appareils existants et nouveaux qui exécutent cette version d'Android de respecter ces exigences dès maintenant. Dans une prochaine version de la plate-forme en 2021, nous exigerons une latence d'entrée à froid de 200 ms ou moins.
[C-SR] Latence d'entrée continue de 30 millisecondes ou moins.
[C-SR] Latence aller-retour continue de 50 millisecondes ou moins.
[C-SR] Minimiser le jitter d'entrée à froid.
[C-SR] Limitez l'erreur dans les codes temporels d'entrée, tels que renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

5.7. Protocoles de réseau

Les implémentations d'appareils DOIVENT être compatibles avec les protocoles de réseau multimédia pour la lecture audio et vidéo, comme spécifié dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un décodeur audio ou vidéo, elles :

[C-1-1] DOIT être compatible avec tous les codecs et formats de conteneur requis dans la section 5.1 sur HTTP(S).
[C-1-2] DOIT être compatible avec les formats de segments multimédias indiqués dans le tableau des formats de segments multimédias ci-dessous sur le protocole HTTP Live Streaming, version 7.
[C-1-3] DOIT être compatible avec le profil audio/vidéo RTP et les codecs associés dans le tableau RTSP ci-dessous. Pour connaître les exceptions, veuillez consulter les notes de bas de page du tableau de la section 5.1.

Formats des segments multimédias

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

Formats de segments

Référence(s)

Compatibilité avec les codecs requise

Flux de transport MPEG-2

ISO 13818

Codecs vidéo :

H264 AVC
MPEG-4 SP
MPEG-2

Pour en savoir plus sur H264 AVC, MPEG2-4 SP,
et MPEG-2, consultez la section 5.1.3.

Codecs audio :

Pour en savoir plus sur l'AAC et ses variantes, consultez la section 5.1.1.

AAC avec trame ADTS et tags ID3

ISO 13818-7

Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1.

WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

Si les implémentations d'appareils sont compatibles avec les sorties vidéo sécurisées et les surfaces sécurisées, elles :

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

Si les implémentations d'appareil déclarent la compatibilité avec Display.FLAG_SECURE et le protocole d'affichage sans fil, elles :

[C-2-1] DOIT sécuriser la liaison avec un mécanisme cryptographiquement robuste tel que HDCP 2.x ou version ultérieure pour les écrans connectés via des protocoles sans fil tels que Miracast.

Si les implémentations d'appareils déclarent la compatibilité avec Display.FLAG_SECURE et la compatibilité avec les écrans externes filaires, elles :

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

5.9. Musical Instrument Digital Interface (MIDI)

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

[C-1-1] DOIT être compatible avec le protocole MIDI sur tous les transports matériels compatibles avec le protocole MIDI pour lesquels il fournit une connectivité générique non MIDI, lorsque ces transports sont :
- Mode hôte USB, section 7.7
- MIDI sur Bluetooth LE en tant que périphérique central, section 7.4.3
[C-1-2] DOIT être compatible avec le transport logiciel MIDI entre applications (appareils MIDI virtuels)
[C-1-3] DOIT inclure libamidi.so (compatibilité MIDI native)
DOIT prendre en charge le mode périphérique MIDI sur USB, section 7.7

5.10. Audio professionnel

Si les implémentations d'appareil signalent la compatibilité avec la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager, elles :

[C-1-1] DOIT signaler la compatibilité avec la fonctionnalité android.hardware.audio.low_latency.
[C-1-2] La latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, DOIT être de 20 millisecondes ou moins et DOIT ÊTRE de 10 millisecondes ou moins sur au moins un chemin d'accès compatible.
[C-1-3] DOIT inclure un ou plusieurs ports USB prenant en charge le mode hôte USB et le mode périphérique USB.
[C-1-4] DOIT indiquer la compatibilité avec la fonctionnalité android.software.midi.
[C-1-5] DOIT respecter les exigences de latence et d'audio USB en utilisant à la fois l'API de file d'attente de tampon PCM OpenSL ES et au moins un chemin d'accès de l'API AAudio native audio.
[SR] Il est FORTEMENT RECOMMANDÉ de respecter les exigences de latence et d'audio USB en utilisant l'API AAudio native audio plutôt que le chemin MMAP.
[C-1-6] DOIT avoir une latence de sortie à froid de 200 millisecondes ou moins.
[C-1-7] La latence d'entrée à froid DOIT être inférieure ou égale à 200 millisecondes.
[SR] Il est FORTEMENT RECOMMANDÉ de fournir un niveau constant de performances du processeur lorsque l'audio est actif et que la charge du processeur varie. Ce test doit être effectué à l'aide de la version Android de l'application SynthMark avec l'ID de commit 09b13c6f49ea089f8c31e5d035f912cc405b7ab8. SynthMark utilise un synthétiseur logiciel exécuté sur un framework audio simulé qui mesure les performances du système. L'application SynthMark doit être exécutée à l'aide de l'option "Automated Test" (Test automatisé) et obtenir les résultats suivants :
- voicemark.90 >= 32 voix
- latencymark.fixed.little <= 15 ms
- latencymark.dynamic.little <= 50 ms

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

DOIT minimiser l'imprécision et la dérive de l'horloge audio par rapport à l'heure standard.
DOIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
DOIT minimiser la latence audio sur les transducteurs de l'appareil.
DOIT minimiser la latence audio sur l'audio numérique USB.
SHOULD document audio latency measurements over all paths.
DOIT minimiser le jitter dans les temps d'entrée du rappel de finalisation du tampon audio, car cela affecte le pourcentage utilisable de la bande passante CPU complète par le rappel.
DOIT fournir zéro problème audio en utilisation normale à la latence signalée.
DOIT fournir une différence de latence intercanaux nulle.
DOIT minimiser la latence moyenne du MIDI sur tous les transports.
DOIT minimiser la variabilité de la latence MIDI sous charge (gigue) sur tous les transports.
DOIT fournir des codes temporels MIDI précis pour tous les transports.
DOIT minimiser le bruit du signal audio sur les transducteurs de l'appareil, y compris pendant la période qui suit immédiatement le démarrage à froid.
DOIT fournir une différence d'horloge audio nulle entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Par exemple, le micro et le haut-parleur de l'appareil, ou l'entrée et la sortie de la prise audio.
DOIT gérer les rappels de fin de remplissage du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et entrer dans le rappel de sortie immédiatement après le retour du rappel d'entrée. Si la gestion des rappels sur le même thread n'est pas possible, saisissez le rappel de sortie peu après le rappel d'entrée pour permettre à l'application d'avoir un timing cohérent des côtés d'entrée et de sortie.
DOIT minimiser la différence de phase entre la mise en mémoire tampon audio HAL pour les côtés d'entrée et de sortie des points de terminaison correspondants.
DOIT minimiser la latence tactile.
DOIT minimiser la variabilité de la latence tactile sous charge (instabilité).
La latence entre l'entrée tactile et la sortie audio DOIT être inférieure ou égale à 40 ms.

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

[SR] Il est FORTEMENT RECOMMANDÉ de signaler la compatibilité avec la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

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

[C-2-1] La latence audio aller-retour continue doit être inférieure ou égale à 20 millisecondes sur le chemin du connecteur audio.
[SR] FORTEMENT RECOMMANDÉ de respecter la section Spécifications des appareils mobiles (prise) de la Spécification des casques audio filaires (v1.1).
La latence audio aller-retour continue DOIT être de 10 millisecondes ou moins sur le chemin du connecteur audio.

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

[C-3-1] DOIT implémenter la classe audio USB.
[C-3-2] DOIT avoir une latence audio aller-retour continue de 20 millisecondes ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.
La latence audio aller-retour continue DOIT être de 10 millisecondes ou moins sur le port en mode hôte USB à l'aide de la classe audio USB.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les E/S simultanées jusqu'à huit canaux dans chaque sens, une fréquence d'échantillonnage de 96 kHz et une profondeur de 24 ou 32 bits, lorsqu'elles sont utilisées avec des périphériques audio USB qui prennent également en charge ces exigences.

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

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

5.11. Capture pour "Non traité"

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

Si les implémentations d'appareils ont l'intention de prendre en charge la source audio brute et de la mettre à la disposition des applications tierces, elles :

[C-1-1] DOIT signaler la prise en charge via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.
[C-1-2] DOIT présenter des caractéristiques d'amplitude-fréquence relativement plates dans la plage de fréquences moyennes, plus précisément ±10 dB de 100 Hz à 7 000 Hz pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-3] DOIT présenter des niveaux d'amplitude dans la plage de basses fréquences, plus précisément de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de moyennes fréquences pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-4] DOIT présenter des niveaux d'amplitude dans la plage de hautes fréquences : plus précisément, ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de moyennes fréquences pour chacun des micros utilisés pour enregistrer la source audio brute.
[C-1-5] La sensibilité de l'entrée audio DOIT être définie de sorte qu'une source de tonalité sinusoïdale de 1 000 Hz lue à un niveau de pression acoustique (SPL) de 94 dB produise une réponse avec une valeur efficace de 520 pour les échantillons de 16 bits (ou -36 dB à pleine échelle pour les échantillons à virgule flottante/double précision) pour chacun des microphones utilisés pour enregistrer la source audio brute.
[C-1-6] DOIT présenter un rapport signal/bruit (SNR) de 60 dB ou plus pour chacun des micros utilisés pour enregistrer la source audio brute. (alors que le SNR est mesuré comme la différence entre 94 dB SPL et le niveau de pression acoustique équivalent du bruit propre, pondéré A).
[C-1-7] DOIT présenter un taux de distorsion harmonique totale (THD) inférieur à 1 % pour 1 kHz à un niveau d'entrée de 90 dB SPL pour chacun des micros utilisés pour enregistrer la source audio brute.
NE DOIT PAS avoir d'autre traitement du signal (par exemple, contrôle automatique du gain, filtre passe-haut ou suppression de l'écho) dans le chemin, à l'exception d'un multiplicateur de niveau pour amener le niveau à la plage souhaitée. Autrement dit :
[C-1-8] Si un traitement du signal est présent dans l'architecture pour une raison quelconque, il DOIT être désactivé et n'introduire aucun retard ni latence supplémentaire dans le chemin du signal.
[C-1-9] Le multiplicateur de niveau, bien qu'il soit autorisé sur le chemin, NE DOIT PAS introduire de retard ni de latence dans le chemin du signal.

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

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

[C-2-1] DOIT renvoyer null pour la méthode d'API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), afin d'indiquer correctement l'absence de prise en charge.
[SR] est TOUJOURS FORTEMENT RECOMMANDÉ pour répondre à autant d'exigences que possible concernant le chemin du signal pour la source d'enregistrement brute.

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

6.1. Outils pour les développeurs

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec les outils de développement Android fournis dans le SDK Android.
Android Debug Bridge (adb)
- [C-0-2] DOIT être compatible avec adb, comme indiqué dans le SDK Android et les commandes shell fournies dans l'AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys cmd stats
- [C-0-11] DOIT être compatible avec la commande shell cmd testharness. La mise à niveau des implémentations d'appareils à partir d'une version antérieure d'Android sans bloc de données persistant PEUT être exemptée de la règle C-0-11.
- [C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) enregistrés à l'aide de la commande dumpsys.
- [C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell cmd stats et la classe d'API système StatsManager.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] Le démon adb côté appareil DOIT être inactif par défaut et il DOIT exister un mécanisme accessible à l'utilisateur pour activer Android Debug Bridge.
- [C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Secure adb permet d'activer adb sur des hôtes authentifiés connus.
- [C-0-6] DOIT fournir un mécanisme permettant de connecter adb à partir d'une machine hôte. Plus spécifiquement :
Si les implémentations d'appareils sans port USB sont compatibles avec le mode périphérique, elles :
- [C-3-1] MUST implement adb via local-area network (such as Ethernet or Wi-Fi).
- [C-3-2] DOIT fournir des pilotes pour Windows 7, 8 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.
Si les implémentations d'appareils sont compatibles avec les connexions adb à une machine hôte via le Wi-Fi, elles :
- [C-4-1] La méthode AdbManager#isAdbWifiSupported() DOIT renvoyer true.
Si les implémentations d'appareils acceptent les connexions adb à une machine hôte via le Wi-Fi et incluent au moins une caméra, elles :
- [C-5-1] La méthode AdbManager#isAdbWifiQrSupported() DOIT renvoyer true.
Service Dalvik Debug Monitor (ddms)
- [C-0-7] DOIT être compatible avec toutes les fonctionnalités ddms telles que documentées dans le SDK Android. Étant donné que ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être disponible chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.
Singe
- [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.
SysTrace
- [C-0-9] DOIT être compatible avec l'outil systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT exister un mécanisme accessible à l'utilisateur pour activer Systrace.
Perfetto
- [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer un binaire /system/bin/perfetto à l'utilisateur du shell dont la ligne de commande est conforme à la documentation Perfetto.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que le binaire perfetto accepte en entrée une configuration protobuf conforme au schéma défini dans la documentation perfetto.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que le binaire Perfetto écrive en sortie une trace protobuf conforme au schéma défini dans la documentation Perfetto.
- [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir, via le binaire perfetto, au moins les sources de données décrites dans la documentation perfetto.
Tueur de mémoire faible
- [C-0-10] DOIT écrire un LMK_KILL_OCCURRED_FIELD_NUMBER Atom dans le journal statsd lorsqu'une application est arrêtée par le Low Memory Killer.
Mode Test Harness : si les implémentations d'appareil prennent en charge la commande shell cmd testharness et exécutent cmd testharness enable, elles :
- [C-2-1] DOIT renvoyer true pour ActivityManager.isRunningInUserTestHarness()
- [C-2-2] DOIT implémenter le mode Atelier de test comme décrit dans la documentation du mode Atelier de test.

Si les implémentations d'appareils indiquent la compatibilité avec Vulkan 1.0 ou version ultérieure via les indicateurs de fonctionnalité android.hardware.vulkan.version, elles :

[C-1-1] DOIT fournir une affordance permettant au développeur d'application d'activer/de désactiver les couches de débogage GPU.
[C-1-2] DOIT, lorsque les couches de débogage GPU sont activées, énumérer les couches dans les bibliothèques fournies par des outils externes (c'est-à-dire ne faisant pas partie du package de plate-forme ou d'application) trouvées dans le répertoire de base des applications débogables pour prendre en charge les méthodes d'API vkEnumerateInstanceLayerProperties() et vkCreateInstance().

6.2. Options pour les développeurs

Android permet aux développeurs de configurer les paramètres liés au développement d'applications.

Les implémentations d'appareils DOIVENT fournir une expérience cohérente pour les options pour les développeurs. Elles :

[C-0-1] DOIT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de le lancer après avoir appuyé sept fois sur l'élément de menu Paramètres > À propos de l'appareil > Numéro de version.
[C-0-2] DOIT masquer les options pour les développeurs par défaut.
[C-0-3] DOIT fournir un mécanisme clair qui ne favorise pas une application tierce par rapport à une autre pour activer les options pour les développeurs. Vous DEVEZ fournir un document ou un site Web visible publiquement qui décrit comment activer les options pour les développeurs. Ce document ou ce site Web DOIT être accessible depuis les documents du SDK Android.
DOIT afficher une notification visuelle continue à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est menacée.
PEUT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant visuellement ou en le désactivant, pour éviter toute distraction dans les scénarios où la sécurité de l'utilisateur est concernée.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel spécifique qui dispose d'une API correspondante pour les développeurs tiers :

[C-0-1] L'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android.

Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant :

[C-0-2] Les définitions de classe complètes (telles que documentées par le SDK) pour les API de composants DOIVENT toujours être présentées.
[C-0-3] Les comportements de l'API DOIVENT être implémentés de manière raisonnable en tant qu'opérations sans effet.
[C-0-4] Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
[C-0-5] Les méthodes d'API DOIVENT renvoyer des implémentations no-op de classes lorsque les valeurs nulles ne sont pas autorisées par la documentation du SDK.
[C-0-6] Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.
[C-0-7] Les implémentations d'appareils DOIVENT signaler de manière cohérente des informations précises sur la configuration matérielle via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte numérique de compilation.

L'API Telephony en est un exemple typique : même sur les appareils autres que les téléphones, ces API doivent être implémentées comme des no-ops raisonnables.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les ressources et les mises en page de l'UI des applications de manière appropriée pour l'appareil, afin de garantir que les applications tierces fonctionnent correctement sur une variété de configurations matérielles. Sur les écrans compatibles avec Android sur lesquels toutes les applications tierces compatibles avec Android peuvent s'exécuter, les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

Les unités auxquelles font référence les exigences de cette section sont définies comme suit :

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

7.1.1. Configuration de l'écran

7.1.1.1. Taille et forme de l'écran

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

Implémentations sur les appareils :

[C-0-1] MUST report the correct layout size for the Configuration.screenLayout as defined in the Android SDK documentation. Plus précisément, les implémentations d'appareils DOIVENT indiquer les dimensions d'écran logiques en pixels indépendants de la densité (dp) comme suit :
- Les appareils dont la valeur Configuration.uiMode est définie sur une valeur autre que UI_MODE_TYPE_WATCH et qui signalent une taille small pour Configuration.screenLayout DOIVENT avoir au moins 426 dp x 320 dp.
- Les appareils qui indiquent une taille normal pour Configuration.screenLayout DOIVENT avoir au moins 480 dp x 320 dp.
- Les appareils qui signalent une taille large pour Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
- Les appareils qui signalent une taille xlarge pour Configuration.screenLayout DOIVENT avoir au moins 960 dp x 720 dp.
[C-0-2] DOIT respecter correctement la prise en charge des tailles d'écran indiquée par les applications via l'attribut <supports-screens> dans le fichier AndroidManifest.xml, comme décrit dans la documentation du SDK Android.
L'appareil PEUT être équipé d'un ou plusieurs écrans compatibles avec Android et dotés de coins arrondis.

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

[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'un cadre de 15 dp sur 15 dp est ancré à chaque angle de l'écran logique, au moins un pixel de chaque cadre est visible à l'écran.
DOIT inclure une option permettant à l'utilisateur de passer au mode d'affichage avec des coins rectangulaires.

Si les implémentations d'appareils incluent un ou plusieurs écrans compatibles avec Android qui sont pliables, ou qui incluent une charnière entre plusieurs panneaux d'affichage et qui rendent ces écrans disponibles pour l'affichage d'applications tierces, elles :

[C-2-1] DOIT implémenter la dernière version stable disponible de l'API Extensions ou la version stable de l'API Sidecar à utiliser par la bibliothèque Window Manager Jetpack.

Si les implémentations d'appareils incluent un ou plusieurs écrans pliables compatibles avec Android, ou une charnière entre plusieurs panneaux d'affichage, et si la charnière ou le pli traverse une fenêtre d'application en plein écran, elles :

[C-3-1] DOIT signaler la position, les limites et l'état de la charnière ou du pli à l'application via des extensions ou des API side-car.

Pour savoir comment implémenter correctement les API sidecar ou d'extension, consultez la documentation publique de Window Manager Jetpack.

7.1.1.2. Format de l'écran

Bien qu'il n'y ait aucune restriction concernant le format de l'écran physique pour les écrans compatibles avec Android, le format de l'écran logique sur lequel les applications tierces sont affichées, qui peut être dérivé des valeurs de hauteur et de largeur signalées par les API view.Display et les API Configuration, DOIT répondre aux exigences suivantes :

[C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format d'image inférieur ou égal à 1,86 (environ 16:9), sauf si l'application remplit l'une des conditions suivantes :
- L'application a déclaré qu'elle était compatible avec un format d'écran plus grand grâce à la valeur de métadonnées android.max_aspect.
- L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
- L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de android:maxAspectRatio qui limiterait le format autorisé.
[C-0-2] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format égal ou supérieur à 1,3333 (4:3), sauf si l'application peut être étirée en largeur en remplissant l'une des conditions suivantes :
- L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
- L'application déclare un android:minAspectRatio qui restreindrait le format autorisé.
[C-0-3] Les implémentations d'appareil avec Configuration.uiMode défini sur UI_MODE_TYPE_WATCH DOIVENT avoir une valeur de format d'image définie sur 1.0 (1:1).

7.1.1.3. Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application.

[C-0-1] Par défaut, les implémentations d'appareils DOIVENT signaler une seule des densités du framework Android listées sur DisplayMetrics via l'API DENSITY_DEVICE_STABLE, et cette valeur NE DOIT JAMAIS changer. Toutefois, l'appareil PEUT signaler une densité arbitraire différente en fonction des modifications de configuration de l'écran effectuées par l'utilisateur (par exemple, la taille de l'écran) définies après le démarrage initial.
Les implémentations d'appareils DOIVENT définir la densité du framework Android standard qui est numériquement la plus proche de la densité physique de l'écran, sauf si cette densité logique réduit la taille de l'écran signalée en dessous de la taille minimale acceptée. Si la densité du framework Android standard qui est numériquement la plus proche de la densité physique entraîne une taille d'écran inférieure à la plus petite taille d'écran compatible acceptée (320 dp de largeur), les implémentations d'appareil DOIVENT indiquer la densité du framework Android standard immédiatement inférieure.

Si une option permet de modifier la taille d'affichage de l'appareil :

[C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle à plus de 1,5 fois la densité native ni produire une dimension d'écran minimale effective inférieure à 320 dp (équivalente au qualificatif de ressource sw320dp), selon la première de ces conditions qui se produit.
[C-1-2] La taille de l'écran NE DOIT PAS être réduite à moins de 0,85 fois la densité native.
Pour garantir une bonne facilité d'utilisation et des tailles de police cohérentes, il est RECOMMANDÉ de fournir la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus).
Petite : 0,85x
Valeur par défaut : 1x (échelle d'affichage native)
Grand : x 1,15
Plus grand : x 1,3
Très grand : x 1,45

7.1.2. Métriques display

Si les implémentations d'appareils incluent le ou les écrans compatibles avec Android ou la sortie vidéo vers le ou les écrans compatibles avec Android, elles :

[C-1-1] DOIT signaler les valeurs correctes pour toutes les métriques d'affichage compatibles avec Android définies dans l'API android.util.DisplayMetrics.

Si les implémentations d'appareils n'incluent pas d'écran ni de sortie vidéo intégrés, elles :

[C-2-1] DOIT signaler les valeurs correctes de l'écran compatible avec Android, telles que définies dans l'API android.util.DisplayMetrics pour le view.Display par défaut émulé.

7.1.3. Orientation de l'écran

Implémentations sur les appareils :

[C-0-1] DOIT indiquer les orientations d'écran qu'il prend en charge (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIT indiquer au moins une orientation prise en charge. Par exemple, un appareil avec un écran paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, NE DOIT signaler que android.hardware.screen.landscape.
[C-0-2] DOIT signaler la valeur correcte de l'orientation actuelle de l'appareil, chaque fois qu'elle est demandée via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Si les implémentations d'appareil sont compatibles avec les deux orientations d'écran, elles :

[C-1-1] DOIT être compatible avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande d'orientation d'écran spécifique de l'application.
[C-1-2] NE DOIT PAS modifier la taille ou la densité de l'écran signalées lors du changement d'orientation.
Le fabricant MAY peut sélectionner l'orientation portrait ou paysage comme orientation par défaut.

7.1.4. Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations sur les appareils :

[C-0-1] DOIT identifier correctement les versions OpenGL ES compatibles (1.1, 2.0, 3.0, 3.1, 3.2) via les API gérées (par exemple, via la méthode GLES10.getString()) et les API natives.
[C-0-2] DOIT inclure la prise en charge de toutes les API gérées et natives correspondantes pour chaque version d'OpenGL ES qu'il a identifiée comme étant compatible.

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

[C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.1.
DOIT être compatible avec OpenGL ES 3.2.

Si les implémentations d'appareil sont compatibles avec l'une des versions d'OpenGL ES, elles :

[C-2-1] DOIT signaler via les API gérées OpenGL ES et les API natives toutes les autres extensions OpenGL ES qu'il a implémentées, et inversement NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas en charge.
[C-2-2] DOIT être compatible avec les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable et EGL_ANDROID_GLES_layers.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions EGL_KHR_partial_update et OES_EGL_image_external.
DOIT signaler avec précision, via la méthode getString(), tout format de compression de texture qu'il prend en charge, qui est généralement spécifique au fournisseur.

Si les implémentations d'appareil déclarent être compatibles avec OpenGL ES 3.0, 3.1 ou 3.2, elles :

[C-3-1] DOIT exporter les symboles de fonction correspondants pour ces versions en plus des symboles de fonction OpenGL ES 2.0 dans la bibliothèque libGLESv2.so.
[SR] : il est FORTEMENT RECOMMANDÉ de prendre en charge l'extension OES_EGL_image_external_essl3.

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

[C-4-1] DOIT être entièrement compatible avec le pack d'extensions Android OpenGL ES.

Si les implémentations d'appareils sont entièrement compatibles avec le pack d'extensions Android d'OpenGL ES, elles :

[C-5-1] DOIT identifier la prise en charge via le flag de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareil exposent la prise en charge de l'extension EGL_KHR_mutable_render_buffer, elles :

[C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple permettant la création de graphiques 3D hautes performances.

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

[SR] Il est FORTEMENT RECOMMANDÉ d'inclure la compatibilité avec Vulkan 1.1.

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

DOIT inclure la compatibilité avec Vulkan 1.1.

Les tests dEQP Vulkan sont divisés en plusieurs listes de tests, chacune associée à une date/version. Ils se trouvent dans l'arborescence source Android, sous external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt. Un appareil compatible avec Vulkan à un niveau auto-déclaré indique qu'il peut réussir les tests dEQP dans toutes les listes de tests de ce niveau et des niveaux précédents.

Si les implémentations d'appareils sont compatibles avec Vulkan 1.0 ou version ultérieure, elles :

[C-1-1] DOIT signaler la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
[C-1-2] DOIT énumérer au moins un VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices() .
[C-1-3] DOIT implémenter entièrement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
[C-1-4] DOIT énumérer les couches contenues dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire des bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() .
[C-1-5] NE DOIT PAS énumérer les couches fournies par des bibliothèques en dehors du package d'application, ni fournir d'autres moyens de tracer ou d'intercepter l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
[C-1-6] DOIT signaler toutes les chaînes d'extension qu'il prend en charge via les API natives Vulkan, et inversement, NE DOIT PAS signaler les chaînes d'extension qu'il ne prend pas correctement en charge.
[C-1-7] DOIT être compatible avec les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.
[C-1-8] DOIT indiquer la version maximale des tests dEQP Vulkan compatibles via le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-1-9] DOIT au moins être compatible avec la version 132317953 (à partir du 1er mars 2019) telle qu'indiquée dans le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-1-10] DOIT réussir tous les tests dEQP Vulkan dans les listes de tests entre la version 132317953 et la version spécifiée dans le flag de fonctionnalité android.software.vulkan.deqp.level.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les extensions VK_KHR_driver_properties et VK_GOOGLE_display_timing.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles :

[C-2-1] NE DOIT PAS déclarer de commutateurs de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations d'appareils incluent la compatibilité avec Vulkan 1.1 et déclarent l'un des indicateurs de fonctionnalité Vulkan, elles :

[C-3-1] DOIT exposer la compatibilité avec les types de sémaphores et de handles 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 être compatibles avec Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs.

Implémentations sur les appareils :

[C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT la désactiver si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API Android View.
[C-0-2] DOIT se comporter de manière cohérente avec la documentation du SDK Android sur l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par le matériel en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations sur les appareils :

[C-0-3] DOIT être compatible avec l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans à large gamme de couleurs

Si les implémentations d'appareils affirment prendre en charge les écrans à large gamme de couleurs via Configuration.isScreenWideColorGamut() , elles :

[C-1-1] DOIT disposer d'un écran calibré en couleur.
[C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace CIE 1931 xyY.
[C-1-3] DOIT disposer d'un écran dont la gamme a une superficie d'au moins 90 % de DCI-P3 dans l'espace CIE 1931 xyY.
[C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et le signaler correctement.
[C-1-5] DOIT annoncer la compatibilité avec les extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear et EGL_EXT_gl_colorspace_display_p3_passthrough.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans à large gamme de couleurs, elles :

[C-2-1] DOIT couvrir 100 % ou plus de l'espace sRGB dans l'espace CIE 1931 xyY, bien que la gamme de couleurs de l'écran ne soit pas définie.

7.1.5. Mode de compatibilité avec les anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" équivalente (largeur de 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille de l'écran.

7.1.6. Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches sur un écran compatible avec Android. Les appareils DOIVENT être compatibles avec toutes ces API telles que définies par le SDK Android, sauf si ce document l'autorise spécifiquement.

Tous les écrans compatibles avec Android d'une implémentation d'appareil :

[C-0-1] DOIT être capable d'afficher des graphiques en couleur 16 bits.
DOIT être compatible avec les écrans capables d'afficher des graphiques en couleur 24 bits.
[C-0-2] DOIT être capable d'afficher des animations.
[C-0-3] DOIT avoir un format de pixels (PAR) compris entre 0,9 et 1,15. Autrement dit, les proportions de pixels DOIVENT être presque carrées (1.0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec les écrans secondaires compatibles avec Android pour permettre le partage de contenus multimédias et les API de développeur pour accéder aux écrans externes.

Si les implémentations d'appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou une connexion d'écran supplémentaire intégrée, elles :

[C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations sur les appareils :

[C-0-1] DOIT inclure un mécanisme de saisie, tel qu'un écran tactile ou une navigation sans contact, pour naviguer entre les éléments de l'UI.

7.2.1. Clavier

Si les implémentations d'appareils incluent la prise en charge des applications tierces d'éditeur de méthode de saisie (IME), elles :

[C-1-1] DOIT déclarer le commutateur de fonctionnalité android.software.input_methods.
[C-1-2] DOIT implémenter entièrement Input Management Framework
[C-1-3] DOIT disposer d'un clavier logiciel préinstallé.

Implémentations d'appareils : * [C-0-1] NE DOIVENT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches). * DOIT inclure des implémentations de clavier virtuel supplémentaires. * PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, la trackball et la molette comme mécanismes de navigation sans écran tactile.

Implémentations sur les appareils :

[C-0-1] DOIT signaler la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne disposent pas de navigations non tactiles, elles :

[C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification de texte, compatible avec les moteurs de gestion des entrées. L'implémentation Android Open Source en amont inclut un mécanisme de sélection adapté aux appareils dépourvus de commandes de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour, généralement fournies par le biais d'une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile, sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils :

[C-0-1] DOIT fournir une affordance utilisateur pour lancer les applications installées qui ont une activité avec <intent-filter> défini sur ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations d'appareils TV. La fonction Accueil DOIT être le mécanisme permettant cette affordance utilisateur.
DOIT 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 (par exemple, appuyer, double-cliquer ou faire un geste) lorsque l'un d'eux est accessible.
[C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Par exemple, vous pouvez afficher une icône visible sur le bouton, une icône logicielle sur la partie barre de navigation de l'écran ou guider l'utilisateur à travers une démo pas à pas lors de la configuration initiale.

Implémentations sur les appareils :

[SR] Il est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme de saisie pour la fonction de menu, car elle est obsolète au profit de la barre d'action depuis Android 4.0.

Si les implémentations d'appareils fournissent la fonction Menu, elles :

[C-2-1] DOIT afficher le bouton de menu d'actions supplémentaires chaque fois que le menu pop-up d'actions supplémentaires n'est pas vide et que la barre d'action est visible.
[C-2-2] NE DOIT PAS modifier la position du pop-up de menu d'actions affiché en sélectionnant le bouton de menu d'actions dans la barre d'actions, mais PEUT afficher le pop-up de menu d'actions à une position modifiée sur l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareil ne fournissent pas la fonction Menu, pour la rétrocompatibilité, elles :

[C-3-1] DOIT rendre la fonction de menu disponible pour les applications lorsque targetSdkVersion est inférieur à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils fournissent la fonctionnalité d'assistance, elles :

[C-4-1] La fonction d'assistance DOIT être accessible en une seule action (par exemple, un appui, un double-clic ou un geste) lorsque d'autres touches de navigation sont accessibles.
[SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction ACCUEIL comme interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles :

[C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, non disponible pour les applications, et NE DOIVENT PAS masquer ni gêner la partie de l'écran disponible pour les applications.
[C-5-2] DOIT mettre à la disposition des applications une partie de l'écran qui répond aux exigences définies dans la section 7.1.1.
[C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), afin que cette partie distincte de l'écran (c'est-à-dire la barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() DOIT uniquement être utilisé pour signaler la zone de reconnaissance des gestes pour la maison.
[C-6-2] Les gestes qui commencent dans un rectangle d'exclusion fourni par l'application de premier plan via View#setSystemGestureExclusionRects(), mais en dehors de WindowInsets#getMandatorySystemGestureInsets(), NE DOIVENT PAS être interceptés pour la fonction de navigation tant que le rectangle d'exclusion est autorisé dans la limite d'exclusion maximale spécifiée dans la documentation pour View#setSystemGestureExclusionRects().
[C-6-3] DOIT envoyer un événement MotionEvent.ACTION_CANCEL à l'application de premier plan une fois que les événements tactiles commencent à être interceptés pour un geste système, si un événement MotionEvent.ACTION_DOWN a déjà été envoyé à l'application de premier plan.
[C-6-4] DOIT fournir une affordance utilisateur pour passer à une navigation à l'écran basée sur des boutons (par exemple, dans les paramètres).
DOIT fournir la fonction Accueil en balayant l'écran vers le haut depuis le bord inférieur de l'orientation actuelle de l'écran.
DOIT fournir la fonctionnalité "Récents" en effectuant un balayage vers le haut et en maintenant le doigt appuyé avant de le relâcher, à partir de la même zone que le geste "Accueil".
Les gestes qui commencent dans WindowInsets#getMandatorySystemGestureInsets() NE DOIVENT PAS être affectés par les rectangles d'exclusion fournis par l'application de premier plan via View#setSystemGestureExclusionRects().

Si une fonction de navigation est disponible depuis n'importe quel point des bords gauche et droit de l'orientation actuelle de l'écran :

[C-7-1] La fonction de navigation DOIT être "Retour" et doit être accessible en balayant l'écran de gauche à droite et de droite à gauche dans l'orientation actuelle de l'écran.
[C-7-2] Si des panneaux système personnalisés et balayables sont fournis sur les bords gauche ou droit, ils DOIVENT être placés dans le tiers supérieur de l'écran avec une indication visuelle claire et persistante indiquant que le fait de les faire glisser vers l'intérieur invoquerait les panneaux susmentionnés, et donc pas le bouton "Retour". Un panneau système PEUT être configuré par un utilisateur de sorte qu'il se trouve en dessous du tiers supérieur du ou des bords de l'écran, mais il NE DOIT PAS utiliser plus d'un tiers du ou des bords.
[C-7-3] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, le balayage depuis les bords DOIT se comporter comme implémenté dans AOSP, tel que décrit dans le SDK.
[C-7-4] Lorsque l'application au premier plan a défini les indicateurs View.SYSTEM_UI_FLAG_IMMERSIVE ou View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, les panneaux système personnalisés pouvant être balayés DOIVENT être masqués jusqu'à ce que l'utilisateur affiche les barres système (c'est-à-dire la barre de navigation et la barre d'état) telles qu'implémentées dans AOSP.

7.2.4. Saisie sur écran tactile

Android est compatible avec différents systèmes de saisie au pointeur, tels que les écrans tactiles, les pavés tactiles et les faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur a l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune autre affordance pour indiquer les objets manipulés.

Implémentations sur les appareils :

DOIT disposer d'un système de saisie au pointeur (de type souris ou tactile).
DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante.

Si les implémentations d'appareils incluent un écran tactile (à un ou plusieurs points de contact) sur un écran principal compatible avec Android, elles :

[C-1-1] DOIT signaler TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
[C-1-2] DOIT signaler les indicateurs de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils incluent un écran tactile capable de suivre plusieurs points de contact sur un écran principal compatible avec Android, elles :

[C-2-1] DOIT signaler les indicateurs de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils s'appuient sur un périphérique d'entrée externe tel qu'une souris ou une trackball (c'est-à-dire sans toucher directement l'écran) pour la saisie sur un écran principal compatible avec Android et répondent aux exigences de faux toucher de la section 7.2.5, elles :

[C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen.
[C-3-2] MUST report only android.hardware.faketouch.
[C-3-3] DOIT signaler TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

7.2.5. Fausse saisie tactile

Une interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui oriente un curseur à l'écran se rapproche du toucher, mais nécessite que l'utilisateur pointe ou sélectionne d'abord, puis clique. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris aérienne gyroscopique, le pointeur gyroscopique, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate une entrée 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 d'écran tactile.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie au pointeur qu'elles souhaitent rendre disponible, elles doivent :

DOIT déclarer la compatibilité avec le flag de fonctionnalité android.hardware.faketouch.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch, elles :

[C-1-1] DOIT signaler les positions absolues X et Y de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
[C-1-2] DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou remonte sur l'écran.
[C-1-3] DOIT prendre en charge les événements de pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
[C-1-4] DOIT prendre en charge les événements pointer down, pointer up, pointer down puis pointer up au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double-tap sur un objet à l'écran.
[C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glisser tactile.
[C-1-6] DOIT permettre aux utilisateurs de déplacer rapidement un objet vers une autre position sur l'écran, puis de le faire glisser sur l'écran.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch.multitouch.distinct, elles :

[C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
[C-2-2] DOIT permettre le suivi distinct de deux entrées de pointeur indépendantes ou plus.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.faketouch.multitouch.jazzhand, elles :

[C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
[C-3-2] DOIT permettre le suivi distinct d'au moins cinq entrées de pointeur de manière totalement indépendante.

7.2.6. Compatibilité avec les manettes de jeu

7.2.6.1. Mappages des boutons

Implémentations sur 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 un contrôleur ou sont fournies avec un contrôleur distinct dans la boîte qui permettrait de saisir tous les événements listés dans les tableaux ci-dessous, elles :

[C-2-1] DOIT déclarer le commutateur de fonctionnalité android.hardware.gamepad

Bouton	Utilisation HID²	Bouton Android
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Haut du pavé directionnel¹ Bas du pavé directionnel¹	0x01 0x0039³	AXIS_HAT_Y⁴
Flèche vers la gauche du pavé directionnel1 Flèche vers la droite du pavé directionnel¹	0x01 0x0039³	AXIS_HAT_X⁴
Bouton supérieur gauche¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton supérieur droit¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic sur le joystick droit¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Accueil¹	0x0c 0x0223	KEYCODE_HOME (3)
Retour¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 Les utilisations HID ci-dessus doivent être déclarées dans une autorité de certification de manette de jeu (0x01 0x0005).

3 Cette utilisation doit avoir une valeur logique minimale de 0, une valeur logique maximale de 7, une valeur physique minimale de 0, une valeur physique maximale de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme la rotation dans le sens des aiguilles d'une montre par rapport à l'axe vertical. Par exemple, une valeur logique de 0 représente l'absence de rotation et l'appui sur le bouton Haut, tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et l'appui sur les touches Haut et Gauche.

4 MotionEvent

Commandes analogiques¹	Utilisation HID	Bouton Android
Bouton de déclenchement gauche	0x02 0x00C5	AXIS_LTRIGGER
Bouton de tranche droit	0x02 0x00C4	AXIS_RTRIGGER
Stick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Stick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Consultez la section 2.3.1 pour connaître les exigences spécifiques aux appareils.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Android Open Source sur les capteurs.

Implémentations sur les appareils :

[C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs selon la classe android.content.pm.PackageManager.
[C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires.
[C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteur (par exemple, en renvoyant true ou false, selon le cas, lorsque des applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteur lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles :

[C-1-1] DOIT signaler toutes les mesures des capteurs en utilisant les valeurs du Système international d'unités (métriques) appropriées pour chaque type de capteur, telles que définies dans la documentation du SDK Android.
[C-1-2] DOIT signaler les données des capteurs avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un flux de capteurs avec une latence maximale demandée de 0 ms lorsque le processeur d'application est actif. Ce délai n'inclut pas les délais de filtrage.
[C-1-3] DOIT signaler le premier échantillon de capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Il est acceptable que cet échantillon ait une précision de 0.
[C-1-4] Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques qui DOIVENT avoir une gigue inférieure à 3 %. La gigue est définie comme l'écart-type de la différence entre les valeurs d'horodatage signalées entre les é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 d'entrer en état de veille ou de sortir de l'état de veille.
[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ée avec l'horloge SystemClock.elapsedRealtimeNano().
[C-SR] Il est FORTEMENT RECOMMANDÉ que l'erreur de synchronisation du code temporel soit inférieure à 100 millisecondes, et il est RECOMMANDÉ qu'elle soit inférieure à 1 milliseconde.
Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme des consommations d'énergie individuelles des capteurs.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et des documentations Open Source Android sur les capteurs doit être considéré comme faisant autorité.

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles :

[C-1-6] DOIT définir une résolution non nulle pour tous les capteurs et signaler la valeur via la méthode d'API Sensor.getResolution().

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations sur les appareils :

DOIT implémenter ces types de capteurs, lorsqu'ils incluent les capteurs physiques requis, comme décrit dans Types de capteurs.

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

[C-2-1] DOIT implémenter le capteur tel que décrit dans la documentation Android Open Source sur les capteurs composites.

Si les implémentations d'appareils incluent un type de capteur particulier qui possède une API correspondante pour les développeurs tiers et que le capteur ne signale qu'une seule valeur, les implémentations d'appareils :

[C-3-1] DOIT définir la résolution sur 1 pour le capteur et signaler la valeur via la méthode d'API Sensor.getResolution().

Si les implémentations d'appareils incluent un type de capteur particulier compatible avec SensorAdditionalInfo#TYPE_VEC3_CALIBRATION et que le capteur est exposé aux développeurs tiers, elles :

[C-4-1] NE DOIT PAS inclure de paramètres de calibration fixes déterminés en usine dans les données fournies.

Si les implémentations d'appareils incluent une combinaison d'un accéléromètre à trois axes, d'un capteur gyroscopique à trois axes ou d'un capteur magnétomètre, elles sont :

[C-SR] FORTEMENT RECOMMANDÉ pour s'assurer que l'accéléromètre, le gyroscope et le magnétomètre ont une position relative fixe, de sorte que si l'appareil est transformable (par exemple, pliable), les axes des capteurs restent alignés et cohérents avec le système de coordonnées des capteurs dans tous les états de transformation possibles de l'appareil.

7.3.1. Accéléromètre

Implémentations sur les appareils :

[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un accéléromètre 3 axes.

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

[C-1-1] DOIT pouvoir signaler des événements à une fréquence d'au moins 50 Hz.
[C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
[C-1-3] DOIT être conforme au système de coordonnées des capteurs Android, comme indiqué dans les API Android.
[C-1-4] DOIT être capable de mesurer la chute libre jusqu'à quatre fois la gravité(4 g) ou plus sur n'importe quel axe.
[C-1-5] DOIT avoir une résolution d'au moins 12 bits.
[C-1-6] DOIT avoir un écart-type ne dépassant pas 0,05 m/s^, où l'écart-type doit être calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes à la fréquence d'échantillonnage la plus rapide.
La mise en œuvre du capteur composite TYPE_SIGNIFICANT_MOTION est FORTEMENT RECOMMANDÉE pour [SR].
Nous RECOMMANDONS VIVEMENT aux [SR] d'implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED et de générer des rapports à son sujet. Nous RECOMMANDONS FORTEMENT d'utiliser des appareils Android pour répondre à cette exigence, car il est possible qu'elle devienne OBLIGATOIRE dans les futures versions de la plate-forme.
DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans la documentation du SDK Android.
DOIT signaler les événements jusqu'à au moins 200 Hz.
DOIT avoir une résolution d'au moins 16 bits.
DOIT être calibré pendant l'utilisation si les caractéristiques changent au cours du cycle de vie et compensé, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
DOIT être compensé en température.

Si les implémentations d'appareils incluent un accéléromètre à trois axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR ou TYPE_STEP_COUNTER est implémenté :

[C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
DOIVENT être inférieurs à 2 mW et 0,5 mW lorsque l'appareil est dans une condition dynamique ou statique.

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

[C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

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

[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un magnétomètre 3 axes (boussole).

Si les implémentations d'appareils incluent un magnétomètre à trois axes, elles :

[C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
[C-1-2] DOIT être capable de signaler des événements jusqu'à une fréquence d'au moins 10 Hz et DOIT signaler des événements jusqu'à au moins 50 Hz.
[C-1-3] DOIT être conforme au système de coordonnées des capteurs Android, comme indiqué dans les API Android.
[C-1-4] DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant saturation.
[C-1-5] DOIT avoir une valeur de décalage ferreux inférieure à 700 µT et DOIT avoir une valeur inférieure à 200 µT en plaçant le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
[C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 µT.
[C-1-7] DOIT prendre en charge la calibration et la compensation en ligne du biais de fer doux, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
[C-1-8] La compensation du fer doux DOIT être appliquée. La calibration peut être effectuée pendant l'utilisation ou lors de la production de l'appareil.
[C-1-9] DOIT avoir un écart-type, calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes à la fréquence d'échantillonnage la plus rapide, qui ne doit pas dépasser 1,5 µT ; DOIT avoir un écart-type qui ne doit pas dépasser 0,5 µT.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un capteur d'accéléromètre et un capteur de gyroscope à trois axes, elles :

[C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

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

PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils incluent un magnétomètre à trois axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles :

[C-3-1] DOIT consommer moins de 10 mW.
DOIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.

7.3.3. GPS

Implémentations sur les appareils :

[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un récepteur GPS/GNSS.

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

[C-1-1] DOIT prendre en charge les sorties de localisation à un taux d'au moins 1 Hz lorsqu'elles sont demandées via LocationManager#requestLocationUpdate.
[C-1-2] DOIT être en mesure de déterminer la position dans des conditions de ciel dégagé (signaux forts, multitrajet négligeable, HDOP < 2) en 10 secondes (temps rapide pour la première correction), lorsqu'il est connecté à une connexion Internet d'une vitesse de 0,5 Mbit/s ou supérieure. Pour ce faire, il est généralement nécessaire d'utiliser une technique de localisation GPS/GNSS assistée ou par prédiction afin de réduire le temps de verrouillage du GPS/GNSS (les données d'assistance incluent l'heure de référence, la position de référence et l'éphéméride/horloge du satellite) ;
- [C-1-6] Après avoir effectué un tel calcul de localisation, les implémentations d'appareils DOIVENT déterminer leur position en ciel dégagé dans un délai de cinq secondes, lorsque les requêtes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même lorsque la requête suivante est effectuée sans connexion de données et/ou après arrêt et redémarrage.
En conditions de ciel dégagé après avoir déterminé la position, à l'arrêt ou en mouvement avec une accélération inférieure à 1 mètre par seconde au carré :
- [C-1-3] DOIT être en mesure de déterminer la position à 20 mètres près et la vitesse à 0,5 mètre par seconde près, et ce, au moins 95 % du temps.
- [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une même constellation.
- DOIT être capable de suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, GPS + au moins l'une des constellations Glonass, Beidou ou Galileo).
- [C-SR] Il est FORTEMENT RECOMMANDÉ de continuer à fournir des données de localisation GPS/GNSS normales via les API GNSS Location Provider lors d'un appel téléphonique d'urgence.
- [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
- [C-SR] Il est FORTEMENT RECOMMANDÉ d'indiquer l'AGC et la fréquence de mesure GNSS.
- [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler toutes les estimations de précision (y compris le cap, la vitesse et la précision verticale) pour chaque position GPS/GNSS.
- [C-SR] Il est FORTEMENT RECOMMANDÉ de signaler les mesures GNSS dès qu'elles sont trouvées, même si aucune position calculée à partir du GPS/GNSS n'est encore signalée.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que les STR signalent les pseudo-distances et les taux de pseudo-distance GNSS qui, dans des conditions de ciel dégagé après avoir déterminé la position, lorsqu'ils sont à l'arrêt ou se déplacent avec une accélération inférieure à 0, 2 mètre par seconde au carré, sont suffisants pour calculer la position à 20 mètres près et la vitesse à 0, 2 mètre par seconde près, au moins 95 % du temps.

7.3.4. Gyroscope

Implémentations sur les appareils :

[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un capteur gyroscopique.

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

[C-1-1] DOIT pouvoir signaler des événements à une fréquence d'au moins 50 Hz.
[C-1-2] DOIT implémenter le capteur TYPE_GYROSCOPE et est FORTEMENT RECOMMANDÉ d'implémenter également le capteur TYPE_GYROSCOPE_UNCALIBRATED.
[C-1-4] DOIT avoir une résolution d'au moins 12 bits et DOIT AVOIR une résolution d'au moins 16 bits.
[C-1-5] DOIT être compensé en température.
[C-1-6] DOIT être calibré et compensé pendant l'utilisation, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
[C-1-7] La variance ne DOIT PAS être supérieure à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du taux d'échantillonnage, mais DOIT être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à une fréquence d'échantillonnage de 1 Hz, elle NE DOIT PAS être supérieure à 1e-7 rad^2/s^2.
[SR] Il est FORTEMENT RECOMMANDÉ que l'erreur de calibration soit inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
DOIT signaler les événements jusqu'à au moins 200 Hz.

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

[C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

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

[C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

7.3.5. Le baromètre

Implémentations sur les appareils :

Il est FORTEMENT RECOMMANDÉ d'inclure un baromètre (capteur de pression atmosphérique) dans les [C-SR].

Si les implémentations d'appareil incluent un baromètre, elles :

[C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
[C-1-2] DOIT être capable de fournir des événements à 5 Hz ou plus.
[C-1-3] DOIT être compensé en température.
[SR] FORTEMENT RECOMMANDÉ pour pouvoir signaler les mesures de pression dans la plage de 300 hPa à 1 100 hPa.
DOIT avoir une précision absolue de 1 hPa.
DOIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (ce qui équivaut à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Si les implémentations d'appareils incluent un thermomètre ambiant (capteur de température), elles :

[C-1-1] DOIT définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température ambiante. Le capteur DOIT mesurer la température ambiante (de la pièce/de l'habitacle du véhicule) à partir de l'endroit où l'utilisateur interagit avec l'appareil, en degrés Celsius.

Si les implémentations d'appareils incluent un capteur de thermomètre qui mesure une température autre que la température ambiante, telle que la température du processeur, elles :

[C-2-1] NE DOIT PAS définir SENSOR_TYPE_AMBIENT_TEMPERATURE pour le capteur de température.

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'appareil incluent un capteur de proximité, elles :

[C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté de manière à détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
[C-1-2] DOIT avoir une précision d'au moins un bit.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de qualité supérieure, tels que définis dans cette section, et les mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT identifier la fonctionnalité à l'aide du flag de fonctionnalité android.hardware.sensor.hifi_sensors.

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

[C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui :
- DOIT avoir une plage de mesure d'au moins -8 g et +8 g, et il est FORTEMENT RECOMMANDÉ qu'elle soit d'au moins -16 g et +16 g.
- DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
- DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT être compatible avec SensorDirectChannel RATE_VERY_FAST.
- DOIT présenter un bruit de mesure ne dépassant pas 400 μg/√Hz.
- DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
- DOIT avoir une consommation d'énergie par lot ne dépassant pas 3 mW.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que la bande passante de mesure à 3 dB soit d'au moins 80 % de la fréquence de Nyquist, et que le spectre du bruit blanc se trouve dans cette bande passante.
- DOIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
- DOIT présenter une variation du biais en fonction de la température ≤ +/- 1 mg/°C.
- DOIT avoir une non-linéarité de la ligne de régression ≤ 0,5 % et une variation de la sensibilité en fonction de la température ≤ 0,03 %/°C.
- DOIT avoir une sensibilité à l'axe transversal inférieure à 2,5 % et une variation de la sensibilité à l'axe transversal inférieure à 0,2 % dans la plage de températures de fonctionnement de l'appareil.
[C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.
[C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui :
- DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps au minimum.
- DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
- DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DOIT être compatible avec SensorDirectChannel RATE_VERY_FAST.
- DOIT avoir un bruit de mesure ne dépassant pas 0,014°/s/√Hz.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que la bande passante de mesure à 3 dB soit d'au moins 80 % de la fréquence de Nyquist, et que le spectre du bruit blanc se trouve dans cette bande passante.
- DOIT avoir une marche aléatoire de taux inférieure à 0,001 °/s √Hz testée à température ambiante.
- La variation du biais par rapport à la température DOIT être inférieure ou égale à +/- 0,05 °/ s / °C.
- DOIT présenter une variation de sensibilité en fonction de la température ≤ 0,02 % / °C.
- DOIT avoir une non-linéarité de la droite d'ajustement optimal ≤ 0,2 %.
- DOIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
- DOIT présenter une erreur de calibration inférieure à 0,002 rad/s dans la plage de température de 10 à 40 °C lorsque l'appareil est immobile.
- DOIT avoir une sensibilité g inférieure à 0,1°/s/g.
- DOIT avoir une sensibilité à l'axe transversal inférieure à 4,0 % et une variation de sensibilité à l'axe transversal inférieure à 0,3 % dans la plage de température de fonctionnement de l'appareil.
[C-2-4] DOIT avoir un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.
[C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui :
- DOIT avoir une plage de mesure comprise entre au moins -900 et +900 μT.
- DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
- DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
- DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
- DOIT avoir un bruit de mesure ne dépassant pas 0,5 uT.
[C-2-6] DOIT comporter un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GEOMAGNETIC_FIELD et, en plus :
- DOIT implémenter une forme non-wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
- [C-SR] Il est FORTEMENT RECOMMANDÉ que le spectre du bruit blanc soit compris entre 1 Hz et au moins 10 Hz lorsque la fréquence de rapport est de 50 Hz ou plus.
[C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui :
- DOIT avoir une plage de mesure 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 avoir un bruit de mesure ne dépassant pas 2 Pa/√Hz.
- DOIT implémenter une forme non-wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
- La consommation d'énergie par lot ne doit pas dépasser 2 mW.
[C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR.
[C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui :
- DOIT implémenter une forme non wake-up de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
- DOIT avoir une consommation d'énergie par lot ne dépassant pas 4 mW.
[C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui :
- DOIT avoir une consommation d'énergie inférieure ou égale à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsqu'il est en mouvement.
[C-2-13] L'horodatage du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT être à moins de 2, 5 millisecondes les uns des autres. L'horodatage de l'événement physique identique signalé par l'accéléromètre et le gyroscope DOIT être à moins de 0,25 milliseconde l'un de l'autre.
[C-2-14] Les codes temporels des événements du capteur gyroscopique DOIVENT être sur la même base temporelle que le sous-système de caméras et présenter une marge d'erreur de 1 milliseconde.
[C-2-15] DOIT fournir des échantillons aux applications dans un délai de cinq millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus.
[C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2,0 mW lorsqu'il est en mouvement lorsque l'une des combinaisons de capteurs suivantes est activée :
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] PEUT disposer d'un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT avoir une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle inclut la puissance absorbée par l'ensemble de la chaîne de capteurs (capteur, circuits auxiliaires, système de traitement des capteurs dédié, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, elles :

[C-3-1] DOIT déclarer correctement la compatibilité avec les types de canaux directs et le niveau de taux de signalement direct via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
[C-3-2] DOIT être compatible avec au moins l'un des deux types de canaux directs de capteur pour tous les capteurs qui déclarent être compatibles avec le canal direct de capteur.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
DOIT être compatible avec le signalement d'événements via le canal direct du capteur pour le capteur principal (variante non-réveil) des types suivants :
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Pour en savoir plus sur la mesure de la sécurité du déverrouillage biométrique, consultez la documentation sur la mesure de la sécurité biométrique.

Si les implémentations d'appareils incluent un écran de verrouillage sécurisé, elles :

DOIT inclure un capteur biométrique

Les capteurs biométriques peuvent être classés comme Classe 3 (anciennement Forte), Classe 2 (anciennement Faible) ou Classe 1 (anciennement Commodité) en fonction de leurs taux d'acceptation des usurpations et des imposteurs, ainsi que de la sécurité du pipeline biométrique. Cette classification détermine les capacités du capteur biométrique à interagir avec la plate-forme et les applications tierces. Les capteurs sont classés par défaut dans la classe 1 et doivent répondre à des exigences supplémentaires, détaillées ci-dessous, s'ils souhaitent être classés dans la classe 2 ou la classe 3. Les méthodes biométriques de classe 2 et de classe 3 bénéficient de fonctionnalités supplémentaires, comme indiqué ci-dessous.

Si les implémentations d'appareils mettent un capteur biométrique à la disposition des applications tierces via android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt et android.provider.Settings.ACTION_BIOMETRIC_ENROLL, elles :

[C-4-1] DOIT répondre aux exigences de la biométrie de classe 3 ou classe 2, telles que définies dans le présent document.
[C-4-2] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe Authenticators et toute combinaison de ceux-ci. À l'inverse, il NE DOIT PAS honorer ni reconnaître les constantes entières transmises aux méthodes canAuthenticate(int) et setAllowedAuthenticators(int) autres que celles documentées en tant que constantes publiques dans Authenticators et toute combinaison de celles-ci.
[C-4-3] DOIT implémenter l'action ACTION_BIOMETRIC_ENROLL sur les appareils disposant de données biométriques de classe 3 ou de classe 2. Cette action DOIT uniquement présenter les points d'entrée d'enregistrement pour les données biométriques de classe 3 ou classe 2.

Si les implémentations d'appareils sont compatibles avec la biométrie passive, elles :

[C-5-1] DOIT exiger par défaut une étape de confirmation supplémentaire (par exemple, appuyer sur un bouton).
[C-SR] Il est FORTEMENT RECOMMANDÉ de prévoir un paramètre permettant aux utilisateurs de remplacer les préférences de l'application et d'exiger systématiquement une étape de confirmation.
[C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas la simuler. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche d'entrée/sortie à usage général (GPIO) en entrée uniquement d'un élément sécurisé (SE) qui ne peut être déclenchée que par l'appui sur un bouton physique.
[C-5-2] DOIT également implémenter un flux d'authentification implicite (sans étape de confirmation) correspondant à setConfirmationRequired(boolean), que les applications peuvent définir pour les flux de connexion.

Si les implémentations d'appareils comportent plusieurs capteurs biométriques, elles :

[C-SR] Il est FORTEMENT RECOMMANDÉ de n'exiger qu'une seule authentification biométrique par authentification (par exemple, si des capteurs d'empreinte digitale et de reconnaissance faciale sont disponibles sur l'appareil, onAuthenticationSucceeded doit être envoyé après la confirmation de l'un d'eux).

Pour que les implémentations d'appareils autorisent l'accès aux clés du keystore par des applications tierces, elles doivent :

[C-6-1] DOIT répondre aux exigences de la classe 3 telles que définies dans la section ci-dessous.
[C-6-2] DOIT présenter uniquement des données biométriques de classe 3 lorsque l'authentification nécessite BIOMETRIC_STRONG ou lorsque l'authentification est appelée avec un CryptoObject.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Classe 1 (anciennement Commodité), elles doivent :

[C-1-1] DOIT avoir un taux de fausse acceptation inférieur à 0,002 %.
[C-1-2] DOIT indiquer que ce mode peut être moins sécurisé qu'un code, un schéma ou un mot de passe sécurisés, et énumérer clairement les risques liés à son activation si les taux d'acceptation de l'usurpation d'identité et de l'imposture sont supérieurs à 7 %, comme indiqué dans les Protocoles de test biométrique Android.
[C-1-3] DOIT limiter le nombre de tentatives pendant au moins 30 secondes après cinq tentatives infructueuses de vérification biométrique (une tentative infructueuse étant une tentative avec une qualité de capture adéquate (BIOMETRIC_ACQUIRED_GOOD) qui ne correspond pas à une empreinte biométrique enregistrée).
[C-1-4] DOIT empêcher l'ajout de nouvelles données biométriques sans avoir d'abord établi une chaîne de confiance en demandant à l'utilisateur de confirmer les identifiants d'appareil existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par TEE. L'implémentation Android Open Source Project fournit le mécanisme nécessaire dans le framework.
[C-1-5] DOIT supprimer complètement toutes les données biométriques identifiables d'un utilisateur lorsque son compte est supprimé (y compris par le biais d'une réinitialisation des paramètres d'usine).
[C-1-6] MUST honor the individual flag for that biometric (i.e. DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE , or DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
[C-1-7] DOIT demander à l'utilisateur de s'authentifier avec la méthode principale recommandée (par exemple, code, schéma ou mot de passe) au moins une fois toutes les 24 heures pour les nouveaux appareils lancés avec Android 10, et au moins une fois toutes les 72 heures pour les appareils mis à niveau à partir d'une version antérieure d'Android.
[C-1-8] DOIT demander à l'utilisateur de s'authentifier à l'aide de la méthode d'authentification principale recommandée (par exemple, code, schéma ou mot de passe) dans l'un des cas suivants :
- un délai d'inactivité de quatre heures, OU
- Trois tentatives d'authentification biométrique ont échoué.
- La période de délai d'inactivité et le nombre d'échecs d'authentification sont réinitialisés après toute confirmation réussie des identifiants de l'appareil.
La mise à niveau des appareils à partir d'une version antérieure d'Android peut être exemptée de la section C-1-8. * [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser la logique du framework fourni par le projet Android Open Source pour appliquer les contraintes spécifiées dans [C-1-7] et [C-1-8] pour les nouveaux appareils. * [C-SR] Il est FORTEMENT RECOMMANDÉ que les STR aient un taux de faux rejets inférieur à 10 %, tel que mesuré sur l'appareil. * [C-SR] Il est FORTEMENT RECOMMANDÉ que la latence soit inférieure à une seconde, mesurée à partir du moment où la donnée biométrique est détectée jusqu'au déverrouillage de l'écran, pour chaque donnée biométrique enregistrée.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme classe 2 (anciennement faible), elles doivent :

[C-2-1] DOIT répondre à toutes les exigences de la classe 1 ci-dessus.
[C-2-2] DOIT avoir un taux d'acceptation des usurpations et des imposteurs ne dépassant pas 20 %, tel que mesuré par les Protocoles de test biométrique Android.
[C-2-3] DOIT effectuer la mise en correspondance biométrique dans un environnement d'exécution isolé en dehors de l'espace utilisateur ou du noyau Android, tel que l'environnement d'exécution sécurisé (TEE) ou sur une puce 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 authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ou modifiées en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé, comme indiqué dans les consignes d'implémentation sur le site Android Open Source Project.
[C-2-5] Lors de l'authentification ou de l'enregistrement biométriques basés sur une caméra :
- DOIT faire fonctionner la caméra dans un mode qui empêche la lecture ou la modification des images de la caméra en dehors de l'environnement d'exécution isolé ou d'une puce avec un canal sécurisé vers l'environnement d'exécution isolé.
- Pour les solutions RVB à une seule caméra, les frames de la caméra PEUVENT être lisibles en dehors de l'environnement d'exécution isolé pour prendre en charge des opérations telles que l'aperçu pour l'enregistrement, mais NE DOIVENT TOUJOURS PAS être modifiables.
[C-2-6] NE DOIT PAS permettre aux applications tierces de faire la distinction entre les inscriptions biométriques individuelles.
[C-2-7] NE DOIT PAS autoriser l'accès non chiffré aux données biométriques identifiables ni aux données qui en sont dérivées (telles que les embeddings) au processeur d'applications en dehors du contexte de l'environnement d'exécution sécurisé.
[C-2-8] DOIT disposer d'un pipeline de traitement sécurisé de sorte qu'une compromission du système d'exploitation ou du noyau ne puisse pas permettre d'injecter directement des données pour s'authentifier de manière frauduleuse en tant qu'utilisateur.

Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre à l'exigence C-2-8 par le biais d'une mise à jour du logiciel système, elles PEUVENT être exemptées de l'exigence.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure la détection de présence pour toutes les modalités biométriques et la détection de l'attention pour la biométrie faciale.

Si les implémentations d'appareils souhaitent traiter un capteur biométrique comme Classe 3 (anciennement Forte), elles doivent :

[C-3-1] DOIT répondre à toutes les exigences de la classe 2 ci-dessus, à l'exception de [C-1-7] et [C-1-8]. La clause C-2-7 s'applique également aux appareils mis à niveau à partir d'une version antérieure d'Android.
[C-3-2] DOIT disposer d'une implémentation de keystore soutenue par le matériel.
[C-3-3] DOIT avoir un taux d'acceptation des usurpations et des imposteurs ne dépassant pas 7 %, tel que mesuré par les Protocoles de test biométrique Android.
[C-3-4] DOIT demander à l'utilisateur de s'authentifier avec la méthode d'authentification principale recommandée (code, schéma, mot de passe, par exemple) au moins une fois toutes les 72 heures.

7.3.12. Capteur de posture

Implémentations sur les appareils :

MAY prend en charge le capteur de pose avec 6 degrés de liberté.

Si les implémentations d'appareils sont compatibles avec le capteur de pose à 6 degrés de liberté, elles :

[C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
[C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.3.13. Capteur d'angle de charnière

Si les implémentations d'appareil sont compatibles avec un capteur d'angle de charnière, elles :

[C-1-1] DOIT implémenter et signaler TYPE_HINGLE_ANGLE.
[C-1-2] DOIT prendre en charge au moins deux lectures entre 0 et 360 degrés (inclus, c'est-à-dire 0 et 360 degrés).
[C-1-3] DOIT renvoyer un capteur wakeup pour getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE).

7.4. Connectivité des données

7.4.1. Téléphonie

Le terme "téléphonie" tel qu'il est utilisé par les API Android et dans ce document fait spécifiquement référence au matériel permettant de passer des appels vocaux et d'envoyer des messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être commutés par paquets, ils sont considérés par Android comme indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité et les API "téléphonie" d'Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS ne sont pas considérées comme des appareils de téléphonie, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec les appareils autres que les téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, elles :

[C-1-1] DOIT déclarer l'option android.hardware.telephony et les autres options de sous-fonctionnalités en fonction de la technologie.
[C-1-2] DOIT implémenter une compatibilité complète avec l'API pour cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie, elles :

[C-2-1] DOIT implémenter les API complètes en tant qu'opérations sans effet.

Si les implémentations d'appareils sont compatibles avec les eUICCs ou les eSIM/SIM intégrées et incluent un mécanisme propriétaire pour rendre la fonctionnalité eSIM disponible pour les développeurs tiers, elles :

[C-3-1] DOIT fournir une implémentation complète de EuiccManager API.

7.4.1.1. Compatibilité du blocage de numéros

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

[C-1-1] DOIT inclure la fonctionnalité de blocage de numéros
[C-1-2] DOIT implémenter entièrement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
[C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone dans "BlockedNumberProvider" sans aucune interaction avec les applications. La seule exception est lorsque le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
[C-1-4] NE DOIT PAS écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
[C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
[C-1-6] DOIT implémenter une UI de gestion des numéros bloqués, qui est ouverte avec l'intention renvoyée par la méthode TelecomManager.createManageBlockedNumbersIntent().
[C-1-7] NE DOIT PAS autoriser les utilisateurs secondaires à afficher ni à modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie, une seule instance, sur l'appareil. Toute l'UI liée au blocage DOIT être masquée pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT toujours être respectée.
DOIT migrer les numéros bloqués vers le fournisseur lorsqu'un appareil est mis à jour vers Android 7.0.

7.4.1.2. API Telecom

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

[C-1-1] DOIT être compatible avec les API ConnectionService décrites dans le SDK.
[C-1-2] DOIT afficher un nouvel appel entrant et permettre à l'utilisateur d'accepter ou de refuser l'appel entrant lorsqu'il est en cours d'appel avec une application tierce qui ne prend pas en charge la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.
[C-1-3] DOIT disposer d'une application qui implémente InCallService.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'informer l'utilisateur que répondre à un appel entrant mettra fin à l'appel en cours.

L'implémentation AOSP répond à ces exigences par le biais d'une notification heads-up qui indique à l'utilisateur que répondre à un appel entrant entraînera la fin de l'autre appel.
[C-SR] Il est FORTEMENT RECOMMANDÉ aux fabricants d'OEM de précharger l'application de téléphone par défaut qui affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels lorsque l'application tierce définit la clé d'extras EXTRA_LOG_SELF_MANAGED_CALLS sur son PhoneAccount sur true.
[C-SR] Il est FORTEMENT RECOMMANDÉ aux STR de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom comme suit :
- Appelez Connection.onDisconnect() lorsqu'une brève pression sur l'événement clé est détectée pendant un appel en cours.
- Appelez Connection.onAnswer() lorsqu'une pression courte sur l'événement clé est détectée lors d'un appel entrant.
- Appelez Connection.onReject() lorsqu'une pression longue sur l'événement clé est détectée lors d'un appel entrant.
- Activez ou désactivez le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations sur les appareils :

DOIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.11 et exposent la fonctionnalité à une application tierce, elles :

[C-1-1] DOIT implémenter l'API Android correspondante.
[C-1-2] DOIT signaler le commutateur de fonctionnalité matérielle android.hardware.wifi.
[C-1-3] DOIT implémenter l'API multicast comme décrit dans la documentation du SDK.
[C-1-4] DOIT être compatible avec le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de son fonctionnement, y compris :
- même lorsque l'écran n'est pas actif.
- Pour les implémentations d'appareils Android TV, même en mode veille.
[C-1-5] NE DOIT PAS considérer l'appel de la méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif qui est utilisé par défaut pour le trafic d'application et qui est renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils NE PEUVENT désactiver l'accès à Internet fourni par un autre fournisseur de réseau (par exemple, les données mobiles) que s'ils valident que le réseau Wi-Fi fournit un accès à Internet.
[C-1-6] Il est FORTEMENT RECOMMANDÉ de réévaluer l'accès à Internet sur le Network lorsque la méthode d'API ConnectivityManager.reportNetworkConnectivity() est appelée, et de passer à tout autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet une fois que l'évaluation détermine que le Network actuel ne fournit plus d'accès à Internet.
[C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source et le numéro de séquence des trames de requête de sonde, une fois au début de chaque analyse, lorsque la STA est déconnectée.
- Chaque groupe de trames de requête de sonde constituant un scan doit utiliser une adresse MAC cohérente (l'adresse MAC NE DOIT PAS être aléatoire à mi-parcours d'un scan).
- Le numéro de séquence de la requête de vérification doit être incrémenté normalement (de manière séquentielle) entre les requêtes de vérification d'un scan.
- Le numéro de séquence de la demande de vérification doit être aléatoire entre la dernière demande de vérification d'une analyse et la première demande de vérification de l'analyse suivante.
[C-SR] sont FORTEMENT RECOMMANDÉS, tandis que STA est déconnecté, pour n'autoriser que les éléments suivants dans les trames de requête de sonde :
- Ensemble de paramètres SSID (0)
- Ensemble de paramètres DS (3)

Si les implémentations d'appareils incluent la prise en charge du mode économie d'énergie Wi-Fi tel que défini dans la norme IEEE 802.11, elles :

[C-3-1] DOIT désactiver le mode d'économie d'énergie du Wi-Fi chaque fois qu'une application acquiert un verrou WIFI_MODE_FULL_HIGH_PERF ou un verrou WIFI_MODE_FULL_LOW_LATENCY via les API WifiManager.createWifiLock() et WifiManager.WifiLock.acquire(), et que le verrou est actif.
[C-3-2] La latence moyenne aller-retour entre l'appareil et un point d'accès lorsque l'appareil est en mode Wi-Fi Low Latency Lock (WIFI_MODE_FULL_LOW_LATENCY) DOIT être inférieure à la latence en mode Wi-Fi High Perf Lock (WIFI_MODE_FULL_HIGH_PERF).
[C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser des STRONGLY RECOMMENDED pour minimiser la latence aller-retour du Wi-Fi chaque fois qu'un verrou de faible latence (WIFI_MODE_FULL_LOW_LATENCY) est acquis et prend effet.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour la recherche de position, elles :

[C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode d'API WifiManager.isScanAlwaysAvailable.

7.4.2.1. Wi-Fi Direct

Implémentations sur les appareils :

DOIT inclure la prise en charge de Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Direct, elles :

[C-1-1] DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK.
[C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
[C-1-3] DOIT être compatible avec le fonctionnement normal du Wi-Fi.
[C-1-4] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Direct simultanément.

7.4.2.2. Configuration de la liaison directe tunnelée Wi-Fi

Implémentations sur les appareils :

DOIT inclure la prise en charge de la configuration de la liaison directe tunnelisée Wi-Fi (TDLS), comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils incluent la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, elles :

[C-1-1] DOIT déclarer la compatibilité avec TDLS via WifiManager.isTdlsSupported.
N'UTILISEZ TDLS que lorsque cela est possible ET bénéfique.
DOIT disposer d'une heuristique et NE DOIT PAS utiliser TDLS lorsque ses performances peuvent être inférieures à celles d'un point d'accès Wi-Fi.

7.4.2.3. Wi-Fi Aware

Implémentations sur les appareils :

DOIT inclure la prise en charge de Wi-Fi Aware.

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Aware et exposent la fonctionnalité aux applications tierces, elles doivent :

[C-1-1] DOIT implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
[C-1-2] DOIT déclarer l'option android.hardware.wifi.aware.
[C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
[C-1-4] DOIT randomiser l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé, sauf si une opération de mesure de distance Aware est en cours ou si un chemin de données Aware est actif (la randomisation n'est pas attendue tant que le chemin de données est actif).

Si les implémentations d'appareils incluent la compatibilité avec Wi-Fi Aware et la localisation Wi-Fi, comme décrit dans la section 7.4.2.5, et exposent ces fonctionnalités aux applications tierces, elles doivent :

[C-2-1] DOIT implémenter les API de découverte avec localisation : setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Si les implémentations d'appareils incluent la compatibilité avec la norme 802.11 (Wi-Fi), elles :

DOIT être compatible avec Wi-Fi Passpoint.

Si les implémentations d'appareils incluent la prise en charge de Wi-Fi Passpoint, elles :

[C-1-2] DOIT implémenter les API WifiManager liées à Passpoint, comme décrit dans la documentation du SDK.
[C-1-3] DOIT être compatible avec la norme IEEE 802.11u, en particulier en ce qui concerne la découverte et la sélection du réseau, comme le service d'annonce générique (GAS, Generic Advertisement Service) et le protocole de requête de réseau d'accès (ANQP, Access Network Query Protocol).

Inversement, si les implémentations d'appareils ne sont pas compatibles avec Wi-Fi Passpoint :

[C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.

7.4.2.5. Position Wi-Fi (délai aller-retour Wi-Fi)

Implémentations sur les appareils :

DOIT inclure la prise en charge de la localisation Wi-Fi.

Si les implémentations d'appareils incluent la prise en charge de la localisation Wi-Fi et exposent la fonctionnalité aux applications tierces, elles doivent :

[C-1-1] DOIT implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
[C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
[C-1-3] DOIT sélectionner une adresse MAC source aléatoire pour chaque rafale RTT exécutée lorsque l'interface Wi-Fi sur laquelle le RTT est exécuté n'est pas associée à un point d'accès.

7.4.2.6. Déchargement du keepalive Wi-Fi

Implémentations sur les appareils :

DOIT inclure la prise en charge du déchargement de la fonctionnalité Wi-Fi Keep-Alive.

Si les implémentations d'appareils incluent la prise en charge du déchargement de keepalive Wi-Fi et exposent la fonctionnalité aux applications tierces, elles :

[C-1-1] DOIT être compatible avec l'API SocketKeepAlive.
[C-1-2] DOIT prendre en charge au moins trois emplacements de signal de présence simultanés sur le Wi-Fi et au moins un emplacement de signal de présence sur le réseau mobile.

Si les implémentations d'appareils n'incluent pas la prise en charge du déchargement de keep-alive Wi-Fi, elles :

[C-2-1] DOIT renvoyer ERROR_UNSUPPORTED.

7.4.2.7. Wi-Fi Easy Connect (protocole de configuration des appareils)

Implémentations sur les appareils :

DOIT être compatible avec Wi-Fi Easy Connect (DPP).

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

[C-1-1] La méthode WifiManager#isEasyConnectSupported() DOIT renvoyer true.

7.4.3. Bluetooth

Si les implémentations d'appareils sont compatibles avec le profil audio Bluetooth, elles :

DOIT être compatible avec les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec HFP, A2DP et AVRCP, elles :

DOIT prendre en charge au moins cinq appareils connectés au total.

Si les implémentations d'appareil déclarent la fonctionnalité android.hardware.vr.high_performance, elles :

[C-1-1] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE.

Android est compatible avec Bluetooth et Bluetooth à basse consommation.

Si les implémentations d'appareils incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation, elles :

[C-2-1] DOIT déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de plate-forme.
DOIT implémenter les profils Bluetooth pertinents tels que A2DP, AVRCP, OBEX, HFP, etc., selon l'appareil.

Si les implémentations d'appareils incluent la prise en charge du Bluetooth à basse consommation (BLE), elles :

[C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
[C-3-2] DOIT activer les API Bluetooth basées sur GATT (Generic Attribute Profile), comme décrit dans la documentation du SDK et android.bluetooth.
[C-3-3] DOIT signaler la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() afin d'indiquer si la logique de filtrage des classes d'API ScanFilter est implémentée.
[C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() afin de préciser si la publicité à faible consommation d'énergie est prise en charge.
[C-3-5] DOIT implémenter un délai d'expiration pour l'adresse privée résolvable (RPA, Resolvable Private Address) ne dépassant pas 15 minutes et faire tourner l'adresse à l'expiration du délai pour protéger la confidentialité de l'utilisateur lorsque l'appareil utilise activement le BLE pour la recherche ou la publicité. Pour éviter les attaques par temporisation, les intervalles de délai avant expiration DOIVENT également être aléatoires et compris entre 5 et 15 minutes.
DOIT prendre en charge le déchargement de la logique de filtrage sur le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
DOIT prendre en charge le déchargement de l'analyse par lots sur le chipset Bluetooth.
DOIT être compatible avec plusieurs annonces (au moins quatre emplacements).

Si les implémentations d'appareils sont compatibles avec le Bluetooth LE et l'utilisent pour la recherche de position, elles :

[C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via l'API système BluetoothAdapter.isBleScanAlwaysAvailable().

Si les implémentations d'appareils incluent la prise en charge du profil Bluetooth LE et d'appareils auditifs, comme décrit dans Prise en charge audio des appareils auditifs avec Bluetooth LE, elles :

[C-5-1] DOIT renvoyer true pour BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).

7.4.4. Communication en champ proche

Implémentations sur les appareils :

DOIT inclure un émetteur-récepteur et le matériel associé pour la communication en champ proche (NFC).
[C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord, même si elles ne sont pas compatibles avec la technologie NFC ou ne déclarent pas la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation des données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le mettre à la disposition des applications tierces, elles doivent :

[C-1-1] DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature().
DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes :
[C-1-2] DOIT être capable de fonctionner comme un lecteur/enregistreur NFC Forum (tel que défini par la spécification technique NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NFC-F (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- Types de tags NFC Forum 1, 2, 3, 4 et 5 (définis par le NFC Forum)
[SR] Il est FORTEMENT RECOMMANDÉ d'être capable de lire et d'écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que, bien que les normes NFC soient fortement recommandées, la définition de compatibilité pour une future version prévoit de les remplacer par "DOIT". Ces normes sont facultatives dans cette version, mais seront obligatoires dans les versions ultérieures. Nous encourageons vivement les appareils existants et nouveaux qui exécutent cette version d'Android à respecter ces exigences dès maintenant afin de pouvoir passer aux futures versions de la plate-forme.
[C-1-13] DOIT interroger toutes les technologies compatibles en mode de détection NFC.
DOIT être en mode découverte NFC lorsque l'appareil est réveillé, que l'écran est actif et que l'écran de verrouillage est déverrouillé.
DOIT être capable de lire le code-barres et l'URL (si elle est encodée) des produits Thinfilm NFC Barcode.

Notez que les liens accessibles au public ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.

Android est compatible avec le mode NFC HCE (Host Card Emulation).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage de l'ID d'application (AID), elles :

[C-2-1] DOIT signaler la constante de fonctionnalité android.hardware.nfc.hce.
[C-2-2] DOIT être compatible avec les API NFC HCE telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent la fonctionnalité pour les applications tierces, elles :

[C-3-1] DOIT signaler la constante de fonctionnalité android.hardware.nfc.hcef.
[C-3-2] DOIT implémenter les API d'émulation de carte NfcF telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent la compatibilité NFC générale décrite dans cette section et prennent en charge les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/enregistreur, elles :

[C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le SDK Android.
[C-4-2] DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas en tant que constante dans la classe android.content.pm.PackageManager.

7.4.5. Protocoles et API de mise en réseau

7.4.5.1. Capacité réseau minimale

Implémentations sur les appareils :

[C-0-1] DOIT inclure la prise en charge d'une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT inclure la prise en charge d'au moins une norme de données capable d'atteindre 200 Kbit/s ou plus. Voici quelques exemples de technologies qui répondent à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth PAN.
Il DOIT également être compatible avec au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (telle qu'Ethernet) est la connexion de données principale.
PEUT implémenter plusieurs formes de connectivité des données.

7.4.5.2. IPv6

Implémentations sur les appareils :

[C-0-2] DOIT inclure une pile réseau IPv6 et accepter la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
[C-0-3] DOIT activer IPv6 par défaut.
DOIT s'assurer que la communication IPv6 est aussi fiable que la communication IPv4, par exemple :
- [C-0-4] DOIT maintenir la connectivité IPv6 en mode Veille.
- [C-0-5] La limitation du débit ne DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau compatible IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.
[C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port au niveau local sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort) et les API NDK telles que getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau, et qui sont visibles en tant qu'adresse IP et port sources pour les serveurs Internet (Web).

Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les implémentations d'appareils sont compatibles avec le Wi-Fi, elles :

[C-1-1] DOIT être compatible avec le fonctionnement à double pile et uniquement IPv6 sur le Wi-Fi.

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

[C-2-1] DOIT être compatible avec le fonctionnement à double pile et IPv6 uniquement sur Ethernet.

Si les implémentations d'appareils sont compatibles avec les données mobiles, elles :

[C-3-1] DOIT être compatible avec le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseau (par exemple, Wi-Fi et données mobiles) :

[C-4-1] DOIT répondre simultanément aux exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

7.4.5.3. Portails captifs

Un portail captif est un réseau qui nécessite une connexion pour accéder à Internet.

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

[C-1-1] DOIT fournir une application de portail captif pour gérer l'intent ACTION_CAPTIVE_PORTAL_SIGN_IN et afficher la page de connexion du portail captif en envoyant cet intent lors de l'appel à l'API système ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] DOIT détecter les portails captifs et permettre la connexion via l'application de portail captif lorsque l'appareil est connecté à un réseau de quelque type que ce soit, y compris un réseau mobile, Wi-Fi, Ethernet ou Bluetooth.
[C-1-3] DOIT permettre la connexion aux portails captifs à l'aide du DNS en texte clair lorsque l'appareil est configuré pour utiliser le mode strict du DNS privé.
[C-1-4] DOIT utiliser le DNS chiffré conformément à la documentation du SDK pour android.net.LinkProperties.getPrivateDnsServerName et android.net.LinkProperties.isPrivateDnsActive pour tout le trafic réseau qui ne communique pas explicitement avec le portail captif.
[C-1-5] DOIT s'assurer que, pendant que l'utilisateur se connecte à un portail captif, le réseau par défaut utilisé par les applications (tel que renvoyé par ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback et utilisé par défaut par les API réseau Java telles que java.net.Socket et les API natives telles que connect()) est tout autre réseau disponible qui fournit un accès à Internet, le cas échéant.

7.4.6. Paramètres de synchronisation

Implémentations sur les appareils :

[C-0-1] La synchronisation automatique principale DOIT être activée par défaut afin que la méthode getMasterSyncAutomatically() renvoie "true".

7.4.7. Économiseur de données

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

[SR] STRONGLY RECOMMENDED to provide the data saver mode.

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

[C-1-1] DOIT être compatible avec toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.

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

[C-2-1] DOIT renvoyer la valeur RESTRICT_BACKGROUND_STATUS_DISABLED pour ConnectivityManager.getRestrictBackgroundStatus()
[C-2-2] NE DOIT PAS diffuser ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. Composants sécurisés

Si les implémentations d'appareils sont compatibles avec les éléments sécurisés compatibles avec l'API Open Mobile et les mettent à la disposition des applications tierces, elles :

[C-1-1] DOIT énumérer les lecteurs d'éléments sécurisés disponibles via l'API android.se.omapi.SEService.getReaders().
[C-1-2] DOIT déclarer les bons indicateurs de fonctionnalité via android.hardware.se.omapi.uicc pour l'appareil avec des éléments sécurisés basés sur UICC, android.hardware.se.omapi.ese pour l'appareil avec des éléments sécurisés basés sur eSE et android.hardware.se.omapi.sd pour l'appareil avec des éléments sécurisés basés sur SD.

7.5. Caméras

Si les implémentations d'appareil incluent au moins une caméra, elles :

[C-1-1] DOIT déclarer le commutateur de fonctionnalité android.hardware.camera.any.
[C-1-2] Il DOIT être possible pour une application d'allouer simultanément trois bitmaps RGBA_8888 de la taille des images produites par le capteur de caméra de la plus haute résolution sur l'appareil, tandis que la caméra est ouverte à des fins d'aperçu de base et de capture d'image fixe.
[C-1-3] DOIT s'assurer que l'application d'appareil photo par défaut préinstallée qui gère les intents MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE ou MediaStore.ACTION_VIDEO_CAPTURE est responsable de la suppression de la position de l'utilisateur dans les métadonnées de l'image avant de l'envoyer à l'application destinataire lorsque celle-ci ne dispose pas de ACCESS_FINE_LOCATION.

7.5.1. Caméra arrière

Une caméra arrière est une caméra située sur le côté de l'appareil opposé à l'écran. Elle permet de prendre des photos de scènes situées à l'arrière de l'appareil, comme une caméra traditionnelle.

Implémentations sur les appareils :

DOIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra orientée vers l'arrière, elles :

[C-1-1] DOIT signaler les commutateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
[C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
DOIT avoir une mise au point automatique matérielle ou logicielle implémentée dans le pilote de l'appareil photo (transparente pour le logiciel d'application).
PEUT disposer d'un matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
PEUT inclure un flash.

Si la caméra inclut un flash :

[C-2-1] La lampe flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de la caméra, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméras système intégrée à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil que l'écran, c'est-à-dire une caméra généralement utilisée pour filmer l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Implémentations sur les appareils :

PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra frontale, elles :

[C-1-1] DOIT signaler les commutateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
[C-1-2] DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
[C-1-3] NE DOIT PAS utiliser de caméra frontale comme caméra par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme caméra arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
[C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque l'application actuelle a explicitement demandé la rotation de l'affichage de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application actuelle ne demande pas explicitement la rotation de l'affichage de la caméra via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
[C-1-5] NE DOIT PAS mettre en miroir l'image fixe ou les flux vidéo finaux capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.
[C-1-6] DOIT refléter l'image affichée par la post-vue de la même manière que le flux d'images de prévisualisation de la caméra.
PEUT inclure des fonctionnalités (comme l'autofocus, le flash, etc.) disponibles pour les caméras orientées vers l'arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (automatiquement via un accéléromètre ou manuellement via une saisie utilisateur, par exemple) :

[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 sur les appareils :

PEUT inclure la compatibilité avec une caméra externe qui n'est pas nécessairement toujours connectée.

Si les implémentations d'appareils incluent la prise en charge d'une caméra externe, elles :

[C-1-1] DOIT déclarer les indicateurs de fonctionnalité de la plate-forme android.hardware.camera.external et android.hardware camera.any.
[C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
[C-1-3] DOIT réussir les tests CTS de la caméra avec un appareil photo externe physique connecté. Pour en savoir plus sur les tests CTS de l'appareil photo, consultez source.android.com.
DOIT être compatible avec les compressions vidéo telles que MJPEG pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
MAY est compatible avec plusieurs caméras.
MAY prend en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est pris en charge :

[C-2-1] Une diffusion simultanée non encodée / MJPEG (résolution QVGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. La nouvelle API android.hardware.camera2 expose un contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de rafale/streaming efficaces sans copie et des contrôles par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, de la réduction du bruit, de l'amélioration de la netteté et plus encore.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe android.hardware.Camera obsolète et le package android.hardware.camera2 plus récent DOIVENT avoir des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être la même. Les fonctionnalités qui dépendent des différentes sémantiques des deux API ne sont pas tenues d'avoir une vitesse ou une qualité identiques, mais DOIVENT être aussi proches que possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à l'appareil photo, pour tous les appareils photo disponibles. Implémentations sur les appareils :

[C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
[C-0-2] DOIT également être au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP, les données du byte[] sont transmises à onPreviewFrame(). En d'autres termes, NV21 DOIT être la valeur par défaut.
[C-0-3] DOIT être compatible avec le format YV12 (tel qu'indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion au format YV12.)
[C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la fonctionnalité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
[C-0-5] DOIT toujours implémenter l'intégralité de l'API Camera incluse dans la documentation du SDK Android, que l'appareil inclue ou non la mise au point automatique matérielle ou d'autres fonctionnalités. Par exemple, les caméras sans autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour une caméra sans autofocus). Notez que cela s'applique aux caméras frontales. Par exemple, même si la plupart des caméras frontales ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "simulés" comme décrit.
[C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini comme constante dans les classes android.hardware.Camera.Parameters et android.hardware.camera2.CaptureRequest. À l'inverse, les implémentations d'appareil NE DOIVENT PAS honorer ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées comme constantes sur android.hardware.Camera.Parameters. En d'autres termes, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres de caméra standards si le matériel le permet, et NE DOIVENT PAS prendre en charge les types de paramètres de caméra personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'images à l'aide de techniques d'imagerie à plage dynamique élevée (HDR) DOIVENT prendre en charge le paramètre de caméra Camera.SCENE_MODE_HDR.
[C-0-7] DOIT signaler le niveau de compatibilité approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et signaler les indicateurs de fonctionnalité du framework appropriés.
[C-0-8] DOIT également déclarer les capacités de caméra individuelles de android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés ; DOIT définir l'indicateur de fonctionnalité si l'un de ses appareils photo associés est compatible avec la fonctionnalité.
[C-0-9] DOIT diffuser l'intention Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée à la galerie multimédia.
[C-0-10] DOIT diffuser l'intention Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au Media Store.
[C-0-11] DOIT permettre d'accéder à toutes les caméras via l'API android.hardware.camera2, en plus de l'API android.hardware.Camera obsolète.
[C-0-12] DOIT s'assurer que l'apparence du visage n'est PAS modifiée, y compris, mais sans s'y limiter, la géométrie, le teint ou le lissage de la peau du visage pour toute API android.hardware.camera2 ou android.hardware.Camera.
[C-SR] Pour les appareils dotés de plusieurs caméras RVB orientées dans la même direction, il est FORTEMENT RECOMMANDÉ de prendre en charge un périphérique de caméra logique qui liste la fonctionnalité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, composée de toutes les caméras RVB orientées dans cette direction en tant que sous-périphériques physiques.

Si les implémentations d'appareils fournissent une API de caméra propriétaire aux applications tierces, elles :

[C-1-1] DOIT implémenter une telle API d'appareil photo à l'aide de l'API android.hardware.camera2.
PEUT fournir des tags et/ou des extensions de fournisseur à l'API android.hardware.camera2.

7.5.5. Orientation de la caméra

Si les implémentations d'appareils sont dotées d'une caméra avant ou arrière, celle-ci ou celles-ci :

[C-1-1] DOIT être orienté de sorte à faire correspondre la dimension longue de l'appareil photo à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est en mode Paysage, les caméras DOIVENT capturer des images en mode Paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils dont l'orientation principale est le mode paysage, ainsi qu'à ceux dont l'orientation principale est le mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et espace de stockage minimum

Implémentations sur les appareils :

[C-0-1] DOIT inclure un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Il DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo vers l'emplacement de "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations sur les appareils :

[C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "espace de stockage externe partagé", "espace de stockage partagé par les applications" ou par le chemin Linux "/sdcard" sur lequel il est monté.
[C-0-2] DOIT être configuré avec un stockage partagé monté par défaut, en d'autres termes "prêt à l'emploi", que le stockage soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (par exemple, un emplacement pour carte Secure Digital).
[C-0-3] DOIT monter le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux de sdcard vers le point de montage réel.
[C-0-4] DOIT activer l'espace de stockage cloisonné par défaut pour toutes les applications ciblant le niveau d'API 29 ou supérieur, sauf dans la situation suivante :
- Lorsque l'application a demandé android:requestLegacyExternalStorage="true" dans son fichier manifeste.
[C-0-5] DOIT masquer les métadonnées de localisation, telles que les tags Exif GPS, stockées dans les fichiers multimédias lorsque ces fichiers sont consultés via MediaStore, sauf lorsque l'application appelante détient l'autorisation ACCESS_MEDIA_LOCATION.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus en utilisant l'une des méthodes suivantes :

Un espace de stockage amovible accessible par l'utilisateur, tel qu'un lecteur de carte Secure Digital (SD).
Partie du stockage interne (non amovible) telle qu'implémentée dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un stockage amovible pour répondre aux exigences ci-dessus, elles :

[C-1-1] DOIT implémenter une interface utilisateur de type toast ou pop-up pour avertir l'utilisateur lorsqu'aucun support de stockage n'est inséré dans le lecteur.
[C-1-2] DOIT inclure un support de stockage au format FAT (par exemple, une carte SD) ou indiquer sur l'emballage et les autres supports disponibles au moment de l'achat que le support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles :

DOIT utiliser l'implémentation AOSP du stockage partagé interne des applications.
PEUT partager l'espace de stockage avec les données privées de l'application.

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

[C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données du stockage partagé de l'application depuis un ordinateur hôte.
DOIT exposer le contenu des deux chemins de stockage de manière transparente via le service de scanner multimédia d'Android et android.provider.MediaStore.
PEUT utiliser le stockage de masse USB, mais DOIT utiliser le protocole MTP (Media Transfer Protocol) pour répondre à cette exigence.

Si les implémentations d'appareils disposent d'un port USB avec mode périphérique USB et sont compatibles avec le protocole MTP (Media Transfer Protocol), elles :

DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
DOIT signaler une classe de périphérique USB de 0x00.
DOIT indiquer le nom d'interface USB "MTP".

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile (contrairement à un téléviseur), les implémentations d'appareils sont les suivantes :

[SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adaptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption des données.

Si le port du périphérique de stockage amovible se trouve dans un emplacement stable à long terme, par exemple dans le compartiment de la batterie ou sous un autre couvercle de protection, les implémentations de l'appareil sont les suivantes :

[SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable.

7.7. USB

Si les implémentations d'appareils disposent d'un port USB, elles :

DOIT être compatible avec le mode périphérique USB et DOIT être compatible avec le mode hôte USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils incluent 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 port USB standard de type A ou de type C.
[C-1-2] DOIT signaler la valeur correcte de iSerialNumber dans le descripteur de périphérique standard USB via android.os.Build.SERIAL.
[C-1-3] DOIT détecter les chargeurs de 1,5 A et 3,0 A conformément à la norme de résistance Type-C et DOIT détecter les changements dans la publicité s'ils prennent en charge l'USB Type-C.
[SR] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
[SR] Le port DOIT être situé en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage soit correct lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
[SR] DOIT implémenter la prise en charge du tirage d'un courant de 1,5 A pendant le chirp et le trafic HS, comme spécifié dans la spécification USB Battery Charging, révision 1.2. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin de pouvoir passer aux futures versions de la plate-forme.
[SR] Il est FORTEMENT RECOMMANDÉ de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut ou qui modifient les rôles de source/récepteur, car cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les méthodes de recharge USB standard. Bien que cela soit indiqué comme "FORTEMENT RECOMMANDÉ", il est possible que nous EXIGIONS à l'avenir que tous les appareils Type-C soient entièrement interopérables avec les chargeurs Type-C standards dans les futures versions d'Android.
[SR] STRONGLY RECOMMENDED to support Power Delivery for data and power role swapping when they support Type-C USB and USB host mode.
DOIT prendre en charge la technologie Power Delivery pour la recharge haute tension et les modes alternatifs tels que la sortie vidéo.
DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, elles :

[C-2-1] DOIT déclarer la compatibilité avec la fonctionnalité matérielle android.hardware.usb.accessory.
[C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne de description de l'interface iInterface du stockage de masse USB.

7.7.2. Mode hôte USB

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

[C-1-1] DOIT implémenter l'API hôte USB Android telle qu'elle est documentée dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
[C-1-2] DOIT implémenter la prise en charge de la connexion de périphériques USB standards, c'est-à-dire qu'il DOIT :
- Disposer d'un port Type-C sur l'appareil ou être livré avec un ou plusieurs câbles adaptant un port propriétaire sur l'appareil à un port USB Type-C standard (appareil USB Type-C).
- Disposer d'un port de type A intégré ou être fourni avec un ou plusieurs câbles adaptant un port propriétaire intégré à un port USB de type A standard.
- Disposer d'un port micro-AB sur l'appareil, qui DOIT être fourni avec un câble adaptateur pour un port Type-A standard.
[C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant les ports USB de type A ou micro-AB en port de type C (prise).
[C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android.
DOIT prendre en charge la recharge du périphérique USB connecté en mode hôte, en annonçant un courant source d'au moins 1,5 A, comme spécifié dans la section "Termination Parameters" de la spécification USB Type-C Cable and Connector Revision 1.2 pour les connecteurs USB Type-C, ou en utilisant la plage de courant de sortie Charging Downstream Port(CDP) comme spécifié dans les spécifications USB Battery Charging, révision 1.2 pour les connecteurs Micro-AB.
DOIT implémenter et prendre en charge les normes USB Type-C.

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

[C-2-1] DOIT être compatible avec la classe USB HID.
[C-2-2] DOIT prendre en charge la détection et le mappage des champs de données HID suivants spécifiés dans les tables d'utilisation USB HID et la demande d'utilisation de commandes vocales aux constantes KeyEvent comme suit :
- Page d'utilisation (0xC), ID d'utilisation (0x0CD) : KEYCODE_MEDIA_PLAY_PAUSE
- Page d'utilisation (0xC), ID d'utilisation (0x0E9) : KEYCODE_VOLUME_UP
- Page d'utilisation (0xC) ID d'utilisation (0x0EA) : KEYCODE_VOLUME_DOWN
- Page d'utilisation (0xC), ID d'utilisation (0x0CF) : KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et le Storage Access Framework (SAF), elles :

[C-3-1] DOIT reconnaître tout appareil MTP (Media Transfer Protocol) connecté à distance et rendre son contenu accessible via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et l'USB Type-C, elles :

[C-4-1] DOIT implémenter la fonctionnalité de port à double rôle telle que définie par la spécification USB Type-C (section 4.5.1.3.3).
[SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge DisplayPort, il est RECOMMANDÉ de prendre en charge les débits de données USB SuperSpeed et il est FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour l'échange de rôle des données et de l'alimentation.
[SR] Il est FORTEMENT RECOMMANDÉ de NE PAS prendre en charge le mode accessoire de l'adaptateur audio décrit dans l'annexe A de la spécification du câble et du connecteur USB Type-C, révision 1.2.
DOIT implémenter le modèle Try.* le plus approprié au facteur de forme de l'appareil. Par exemple, un appareil portable DOIT implémenter le modèle Try.SNK.

7.8. Audio

7.8.1. Micro

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

[C-1-1] DOIT signaler la constante de fonctionnalité android.hardware.microphone.
[C-1-2] DOIT respecter les exigences relatives à l'enregistrement audio de la section 5.4.
[C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
[SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement de sons proches des ultrasons, comme décrit dans la section 7.8.3.

Si les implémentations d'appareils omettent un micro, elles doivent :

[C-2-1] NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone.
[C-2-2] DOIT implémenter l'API d'enregistrement audio au moins en tant que no-ops, conformément à la section 7.

7.8.2. Sortie audio

Si les implémentations d'appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'une prise audio 3,5 mm à quatre conducteurs ou un port en mode hôte USB utilisant la classe audio USB, elles :

[C-1-1] DOIT signaler la constante de fonctionnalité android.hardware.audio.output.
[C-1-2] DOIT répondre aux exigences de lecture audio de la section 5.5.
[C-1-3] DOIT répondre aux exigences de latence audio de la section 5.6.
[SR] STRONGLY RECOMMENDED to support near-ultrasound playback as described in section 7.8.3.

Si les implémentations d'appareils n'incluent pas de haut-parleur ni de port de sortie audio, elles :

[C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
[C-2-2] DOIT implémenter au moins les API liées à la sortie audio en tant qu'opérations sans effet.

Dans cette section, un "port de sortie" désigne une interface physique telle qu'une prise audio de 3, 5 mm, un port HDMI ou un port USB en mode hôte avec classe audio USB. La prise en charge de la sortie audio via des protocoles radio tels que le Bluetooth, le Wi-Fi ou le réseau mobile ne constitue pas un "port de sortie".

7.8.2.1. Ports audio analogiques

Pour être compatibles avec les casques et autres accessoires audio utilisant la prise audio de 3,5 mm dans l'écosystème Android, si les implémentations d'appareils incluent un ou plusieurs ports audio analogiques, elles :

[C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un port audio de type connecteur audio 3,5 mm à quatre conducteurs.

Si les implémentations d'appareils disposent d'une prise audio 3,5 mm à quatre conducteurs, elles :

[C-1-1] DOIT être compatible avec la lecture audio sur des écouteurs stéréo et des casques stéréo avec micro.
[C-1-2] DOIT être compatible avec les connecteurs audio TRRS avec l'ordre de broches CTIA.
[C-1-3] DOIT prendre en charge la détection et le mappage des codes de touches pour les trois plages d'impédance équivalente suivantes entre les conducteurs du microphone et de la masse sur la prise audio :
- 70 ohms ou moins : KEYCODE_HEADSETHOOK
- 210 à 290 ohms : KEYCODE_VOLUME_UP
- 360 à 680 ohms : KEYCODE_VOLUME_DOWN
[C-1-4] MUST déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une fiche, mais uniquement une fois que tous les contacts de la fiche touchent les segments correspondants de la prise.
[C-1-5] DOIT être capable de générer au moins 150 mV ± 10 % de tension de sortie sur une impédance de haut-parleur de 32 ohms.
[C-1-6] DOIT avoir une tension de polarisation du micro comprise entre 1,8 V et 2,9 V.
[C-1-7] DOIT détecter et mapper le code clé pour la plage suivante d'impédance équivalente entre les conducteurs du micro et de la masse sur la prise audio :
- 110 à 180 ohms : KEYCODE_VOICE_ASSIST
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge les connecteurs audio avec l'ordre des broches OMTP.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement audio à partir de casques stéréo avec micro.

Si les implémentations d'appareils sont dotées d'un connecteur audio 3,5 mm à quatre conducteurs et sont compatibles avec un micro, et qu'elles diffusent android.intent.action.HEADSET_PLUG avec la valeur supplémentaire du micro définie sur 1, elles :

[C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.2.2. Ports audio numériques

Pour être compatible avec les casques et autres accessoires audio utilisant des connecteurs USB-C et implémentant (classe audio USB) dans l'écosystème Android, comme défini dans la spécification des casques USB Android.

Consultez la section 2.2.1 pour connaître les exigences spécifiques aux appareils.

7.8.3. Proche des ultrasons

La bande audio proche des ultrasons se situe entre 18,5 kHz et 20 kHz.

Implémentations sur les appareils :

DOIT signaler correctement la compatibilité avec la fonctionnalité audio proche des ultrasons via l'API AudioManager.getProperty comme suit :

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT répondre aux exigences suivantes :

[C-1-1] La réponse en puissance moyenne du microphone dans la bande de fréquences de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB maximum à la réponse à 2 kHz.
[C-1-2] Le rapport signal/bruit non pondéré du micro sur la plage de fréquences de 18,5 kHz à 20 kHz pour une tonalité de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est défini sur "true" :

[C-2-1] La réponse moyenne de l'enceinte entre 18,5 kHz et 20 kHz DOIT être inférieure d'au moins 40 dB à la réponse à 2 kHz.

7.8.4. Intégrité du signal

Implémentations d'appareils : * DOIVENT fournir un chemin de signal audio sans problème pour les flux d'entrée et de sortie sur les appareils portables, tel que défini par zéro problème mesuré lors d'un test d'une minute par chemin. Testez à l'aide de [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) "Automated Glitch Test".

Le test nécessite un dongle de boucle audio, utilisé directement dans une prise 3,5 mm et/ou en combinaison avec un adaptateur USB-C vers 3,5 mm. TOUS les ports de sortie audio DOIVENT être testés.

OboeTester est actuellement compatible avec les chemins AAudio. Les combinaisons suivantes DOIVENT donc être testées pour détecter les problèmes à l'aide d'AAudio :

Mode Performances	Partage	Taux d'échantillonnage de sortie	Dans les chans	Out Chans
LOW_LATENCY	EXCLUSIFS	NON DÉFINI	1	2
LOW_LATENCY	EXCLUSIFS	NON DÉFINI	2	1
LOW_LATENCY	PARTAGÉ	NON DÉFINI	1	2
LOW_LATENCY	PARTAGÉ	NON DÉFINI	2	1
AUCUNE	PARTAGÉ	48000	1	2
AUCUNE	PARTAGÉ	48000	2	1
AUCUNE	PARTAGÉ	44100	1	2
AUCUNE	PARTAGÉ	44100	2	1
AUCUNE	PARTAGÉ	16000	1	2
AUCUNE	PARTAGÉ	16000	2	1

Un flux fiable DOIT répondre aux critères suivants concernant le rapport signal/bruit (SNR) et la distorsion harmonique totale (THD) pour une sinusoïde de 2 000 Hz.

Transducteur	THD	SNR
Haut-parleur principal intégré, mesuré à l'aide d'un micro de référence externe	< 3,0 %	>= 50 dB
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 à l'aide d'un adaptateur de boucle	< 1 %	>= 60 dB
Adaptateurs USB fournis avec le téléphone, testés à l'aide d'un adaptateur de boucle	< 1,0 %	>= 60 dB

7.9. Réalité virtuelle

Android inclut des API et des outils permettant de créer des applications de réalité virtuelle (RV), y compris des expériences de RV mobile de haute qualité. Les implémentations d'appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android est compatible avec le mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est sélectionnée par l'utilisateur.

7.9.2. Mode Réalité virtuelle : hautes performances

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

[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] MUST support sustained performance mode.
[C-1-4] Il est FORTEMENT RECOMMANDÉ de prendre en charge OpenGL ES 3.2.
[C-1-5] DOIT prendre en charge android.hardware.vulkan.level 0.
DOIT être compatible avec android.hardware.vulkan.level 1 ou version ultérieure.
[C-1-6] DOIT implémenter EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace et exposer les extensions dans la liste des extensions EGL disponibles.
[C-1-8] DOIT implémenter GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures et exposer les extensions dans la liste des extensions GL disponibles.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer, GL_EXT_EGL_image_array et GL_OVR_multiview_multisampled_render_to_texture, et d'exposer les extensions dans la liste des extensions GL disponibles.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge Vulkan 1.1.
[C-SR] Il est FORTEMENT RECOMMANDÉ aux développeurs d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de l'exposer dans la liste des extensions Vulkan disponibles.
[C-SR] Il est FORTEMENT RECOMMANDÉ que les SR exposent au moins une famille de files d'attente Vulkan où flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et où queueCount est au moins égal à 2.
[C-1-7] Le GPU et l'écran DOIVENT être capables de synchroniser l'accès au tampon avant partagé de sorte que le rendu alterné pour les yeux du contenu VR à 60 fps avec deux contextes de rendu s'affiche sans artefacts de déchirement visibles.
[C-1-9] DOIT implémenter la prise en charge des indicateurs AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, comme décrit dans le NDK.
[C-1-10] DOIT implémenter la compatibilité avec les AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants : AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge l'attribution des AHardwareBuffer comportant plusieurs calques, ainsi que les indicateurs et les formats spécifiés dans C-1-10.
[C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 fps, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 fps-10 Mbit/s ou 2 instances de 1 920 x 1 080 à 60 fps-20 Mbit/s).
[C-1-12] DOIT prendre en charge HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 fps compressé à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 fps-20 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 fps-5 Mbit/s).
[C-1-13] DOIT être compatible avec l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs précises pour la température cutanée.
[C-1-14] DOIT comporter un écran intégré dont la résolution DOIT être d'au moins 1 920 x 1 080.
[C-SR] Il est FORTEMENT RECOMMANDÉ que la résolution d'affichage soit d'au moins 2 560 x 1 440.
[C-1-15] L'affichage DOIT se mettre à jour à au moins 60 Hz en mode VR.
[C-1-17] L'écran DOIT être compatible avec un mode à faible persistance (≤ 5 millisecondes). La persistance est définie comme la durée pendant laquelle un pixel émet de la lumière.
[C-1-18] DOIT être compatible avec Bluetooth 4.2 et l'extension de la longueur des données Bluetooth LE section 7.4.3.
[C-1-19] DOIT prendre en charge et signaler correctement le type de canal direct pour tous les types de capteurs par défaut suivants :
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
[C-1-21] DOIT répondre aux exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge la fonctionnalité android.hardware.sensor.hifi_sensors.
[C-1-22] La latence de bout en bout entre le mouvement et le photon ne DOIT PAS dépasser 28 millisecondes.
[C-SR] Il est FORTEMENT RECOMMANDÉ que la latence de bout en bout entre le mouvement et le photon ne dépasse pas 20 millisecondes.
[C-1-23] DOIT avoir un ratio de première image d'au moins 85 %, qui correspond au rapport entre la luminosité des pixels de la première image après une transition du noir au blanc et la luminosité des pixels blancs en régime permanent.
[C-SR] Il est FORTEMENT RECOMMANDÉ que les STR aient un ratio de première image d'au moins 90 %.
PEUT fournir un cœur exclusif à l'application au premier plan et PEUT prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application au premier plan.

Si le cœur exclusif est pris en charge, le cœur :

[C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus d'espace utilisateur (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUT autoriser l'exécution de certains processus du noyau si nécessaire.

7.10. Technologie tactile

Consultez la section 2.2.1 pour connaître les exigences spécifiques aux appareils.

7.11. Classe de performances média

La classe de performances multimédias de l'implémentation de l'appareil peut être obtenue à partir de l'API android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS. Les exigences relatives à la classe de performances multimédias sont définies pour chaque version d'Android à partir de la version R (version 30). La valeur spéciale 0 indique que l'appareil n'appartient pas à une classe de performances multimédias.

Si les implémentations d'appareil renvoient une valeur non nulle pour android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, elles :

[C-1-1] DOIT renvoyer au moins une valeur de android.os.Build.VERSION_CODES.R.
[C-1-2] DOIT être une implémentation d'appareil mobile.
[C-1-3] DOIT répondre à toutes les exigences de la "classe de performances multimédias" décrites dans la section 2.2.7.

Consultez la section 2.2.7 pour connaître les exigences spécifiques aux appareils.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lors du développement d'une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être fournie à l'utilisateur final si certaines exigences minimales sont respectées pour garantir une fréquence d'images et des temps de réponse cohérents pour les applications et les jeux. Selon le type d'appareil, les implémentations d'appareils PEUVENT avoir des exigences mesurables concernant la latence de l'interface utilisateur et le changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

En fournissant une base de référence commune pour des performances d'accès aux fichiers cohérentes sur la partition de stockage des données privées de l'application (/data), les développeurs d'applications peuvent définir une attente appropriée qui les aidera à concevoir leur logiciel. Les implémentations d'appareils, selon le type d'appareil, PEUVENT avoir certaines exigences décrites dans la section 2 pour les opérations de lecture et d'écriture suivantes :

Performances d'écriture séquentielle : Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
Performances d'écriture aléatoire Mesuré en écrivant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 Ko.
Performances de lecture séquentielle : Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 10 Mo.
Performances de lecture aléatoire Mesuré en lisant un fichier de 256 Mo à l'aide d'une mémoire tampon d'écriture de 4 Ko.

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 qui sont incluses dans AOSP (par exemple, le bucket de mise en veille des applications, le mode Veille) ou étendent les fonctionnalités qui n'appliquent pas de restrictions plus strictes que le bucket de mise en veille des applications rares, elles :

[C-1-1] NE DOIT PAS s'écarter de l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de réveil, ni pour l'utilisation des paramètres système globaux des modes d'économie d'énergie Veille de l'application et Veille.
[C-1-2] NE DOIT PAS s'écarter de l'implémentation AOSP pour l'utilisation des paramètres généraux permettant de gérer la limitation des tâches, des alarmes et du réseau pour les applications de chaque bucket dans le mode Veille de l'application.
[C-1-3] NE DOIT PAS s'écarter de l'implémentation AOSP pour le nombre de buckets App Standby utilisés pour App Standby.
[C-1-4] DOIT implémenter les buckets App Standby et le mode Veille comme décrit dans Gestion de l'alimentation.
[C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
[C-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'activer et de désactiver la fonctionnalité d'économiseur de batterie.
[C-SR] Il est FORTEMENT RECOMMANDÉ de fournir aux utilisateurs la possibilité d'afficher toutes les applications exemptées des modes d'économie d'énergie Veille de l'application et Veille prolongée.

Si les implémentations d'appareils étendent les fonctionnalités de gestion de l'alimentation incluses dans AOSP et que cette extension applique des restrictions plus strictes que le bucket de mise en veille des applications "Rare", consultez la section 3.5.1.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter tout ou partie des quatre états de veille définis par l'interface ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles :

[C-1-1] L'appareil DOIT passer dans cet état uniquement après que l'utilisateur a effectué une action explicite pour le mettre dans un état inactif (par exemple, en fermant un couvercle qui fait physiquement partie de l'appareil ou en éteignant un véhicule ou un téléviseur) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le couvercle ou en rallumant le véhicule ou le téléviseur).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles :

[C-2-1] DOIT répondre à C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran, le processeur).

À l'inverse, il DOIT quitter l'état S3 lorsque des applications tierces ont besoin des ressources système, comme décrit dans ce SDK.

Par exemple, alors que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur en fonctionnement via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer à l'état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris des mesures explicites pour mettre l'appareil en état inactif. Inversement, lorsqu'une tâche que des applications tierces implémentent via JobScheduler est déclenchée ou que Firebase Cloud Messaging est distribué à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur a mis l'appareil en état inactif. Il ne s'agit pas d'exemples exhaustifs. L'AOSP implémente de nombreux signaux de réveil qui déclenchent une sortie de cet état.

8.4. Comptabilisation de la consommation électrique

Une comptabilisation et un reporting plus précis de la consommation d'énergie fournissent au développeur d'applications à la fois les incitations et les outils nécessaires pour optimiser le modèle d'utilisation de l'énergie de l'application.

Implémentations sur les appareils :

[SR] Il est FORTEMENT RECOMMANDÉ de fournir un profil de puissance par composant qui définit la valeur de consommation de courant pour chaque composant matériel et la décharge de batterie approximative causée par les composants au fil du temps, comme indiqué sur le site Android Open Source Project.
[SR] Il est FORTEMENT RECOMMANDÉ de signaler toutes les valeurs de consommation d'énergie en milliampères-heure (mAh).
[SR] STRONGLY RECOMMENDED to report CPU power consumption per each process's UID. Le projet Android Open Source répond à cette exigence grâce à l'implémentation du module de noyau uid_cputime.
[SR] Il est FORTEMENT RECOMMANDÉ de mettre cette consommation d'énergie à la disposition du développeur d'applications via la commande shell adb shell dumpsys batterystats.
DOIT être attribuée au composant matériel lui-même s'il est impossible d'attribuer la consommation d'énergie du composant matériel à une application.

8.5. Constance des performances

Les performances peuvent fluctuer considérablement pour les applications de longue durée à hautes performances, soit en raison des autres applications exécutées en arrière-plan, soit en raison de la limitation de la fréquence du processeur due aux limites de température. Android inclut des interfaces programmatiques qui permettent à l'application de premier plan de demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations lorsque l'appareil en est capable.

Implémentations sur les appareils :

[C-0-1] DOIT signaler avec précision la prise en charge du mode Performances soutenues via la méthode d'API PowerManager.isSustainedPerformanceModeSupported().
DOIT être compatible avec le mode Performances soutenues.

Si les implémentations d'appareils indiquent la prise en charge du mode Performances soutenues, elles :

[C-1-1] DOIT fournir à l'application de premier plan supérieure un niveau de performances constant pendant au moins 30 minutes, lorsque l'application le demande.
[C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent deux cœurs de processeur ou plus, elles :

DOIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan.

Si les implémentations d'appareils sont compatibles avec la réservation d'un cœur exclusif pour l'application de premier plan, elles :

[C-2-1] DOIT signaler via la méthode d'API Process.getExclusiveCores() les numéros d'ID des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
[C-2-2] NE DOIT PAS autoriser les processus de l'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 PEUT autoriser l'exécution de certains processus du noyau si nécessaire.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, elles :

[C-3-1] DOIT renvoyer une liste vide via la méthode d'API Process.getExclusiveCores().

9. Compatibilité du modèle de sécurité

Implémentations sur les appareils :

[C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations dans la documentation pour les développeurs Android.
[C-0-2] DOIT permettre l'installation d'applications autosignées sans nécessiter d'autorisations ni de certificats supplémentaires de la part de tiers ou d'autorités. Plus précisément, les appareils compatibles DOIVENT être compatibles avec les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Implémentations sur les appareils :

[C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android. Plus précisément, ils DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK. Aucune autorisation ne peut être omise, modifiée ni ignorée.
PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne se trouvent pas dans l'espace de noms android.\*.
[C-0-2] Les autorisations avec un protectionLevel de PROTECTION_FLAG_PRIVILEGED DOIVENT uniquement être accordées aux applications préinstallées dans le ou les chemins privilégiés de l'image système et dans le sous-ensemble des autorisations explicitement autorisées pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en respectant les autorisations autorisées 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 "dangerous" (dangereux) sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution.

Implémentations sur les appareils :

[C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder ou non les autorisations d'exécution demandées, et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
[C-0-4] DOIT avoir une et une seule implémentation des deux interfaces utilisateur.
[C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf si :
- Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise.
- Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
[C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un stockage distant hors appareil, équipé d'un matériel sécurisé avec une protection équivalente ou supérieure à celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

Implémentations sur les appareils :

[C-0-7] DOIT respecter les propriétés de l'autorisation de localisation Android lorsqu'une application demande les données de localisation ou d'activité physique via une API Android standard ou un mécanisme propriétaire. Ces données incluent, entre autres, les éléments suivants :
- Position de l'appareil (latitude et longitude, par exemple).
- Informations permettant de déterminer ou d'estimer la position de l'appareil (par exemple, SSID, BSSID, ID de cellule ou position du réseau auquel l'appareil est connecté).
- Activité physique de l'utilisateur ou classification de l'activité physique.

Plus précisément, les implémentations d'appareils :

[C-0-8] L'application DOIT obtenir le consentement de l'utilisateur pour accéder aux données de localisation ou d'activité physique.
[C-0-9] DOIT accorder une autorisation d'exécution UNIQUEMENT à l'application qui dispose d'une autorisation suffisante, comme décrit dans le SDK. Par exemple, TelephonyManager#getServiceState nécessite android.permission.ACCESS_FINE_LOCATION.

Les autorisations peuvent être marquées comme restreintes, ce qui modifie leur comportement.

[C-0-10] Les autorisations marquées par l'indicateur hardRestricted NE DOIVENT PAS être accordées à une application, sauf si :
- Le fichier APK d'une application se trouve dans la partition système.
- L'utilisateur attribue à une application un rôle associé aux autorisations hardRestricted.
- Le programme d'installation accorde hardRestricted à une application.
- Une application se voit accorder l'autorisation hardRestricted sur une version antérieure d'Android.
[C-0-11] Les applications disposant d'une autorisation softRestricted DOIVENT obtenir un accès limité et NE DOIVENT PAS obtenir un accès complet tant qu'elles ne sont pas ajoutées à la liste d'autorisation, comme décrit dans le SDK, où l'accès complet et l'accès limité sont définis pour chaque autorisation softRestricted (par exemple, READ_EXTERNAL_STORAGE).

Si les implémentations d'appareil offrent à l'utilisateur la possibilité de choisir les applications qui peuvent s'afficher au-dessus d'autres applications avec une activité qui gère l'intent ACTION_MANAGE_OVERLAY_PERMISSION, elles :

[C-2-1] DOIT s'assurer que toutes les activités avec des filtres d'intent pour l'intent ACTION_MANAGE_OVERLAY_PERMISSION ont le même écran d'UI, quelle que soit l'application à l'origine de l'intent ou les informations qu'elle fournit.

9.2. UID et isolement des processus

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le modèle de bac à sable des applications Android, dans lequel chaque application s'exécute en tant qu'UID de style Unix unique et dans un processus distinct.
[C-0-2] DOIT permettre l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme défini dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations sur les appareils :

[C-0-1] DOIT être compatible avec le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisations Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Autrement dit :

[C-0-1] Les environnements d'exécution alternatifs DOIVENT être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.
[C-0-2] Les runtimes alternatifs NE DOIVENT PAS avoir accès aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml du runtime via le mécanisme <uses-permission>.
[C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android réservées aux applications système.
[C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées à l'aide d'un environnement d'exécution alternatif NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf par le biais des mécanismes Android standards d'ID utilisateur partagé et de certificat de signature.
[C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS se lancer avec, accorder ou se voir accorder l'accès aux bacs à sable correspondant à d'autres applications Android.
[C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec des privilèges de superutilisateur (root) ou d'un autre ID utilisateur, ni accorder de tels privilèges à d'autres applications.
[C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses avec les implémentations d'appareils.
[C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.
[C-0-9] Lorsqu'une application doit utiliser une ressource de l'appareil pour laquelle il existe une autorisation Android correspondante (comme l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.
[C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les capacités de l'application de cette manière, il DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.
Les environnements d'exécution alternatifs DOIVENT installer les applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.

9.5. Compatibilité multi-utilisateur

Android prend en charge plusieurs utilisateurs et offre une isolation complète des utilisateurs.

Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur si elles utilisent un support amovible pour le stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs, elles :

[C-1-1] DOIT répondre aux exigences suivantes concernant la prise en charge du mode multi-utilisateur.
[C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android tel que défini dans le document de référence sur la sécurité et les autorisations des API.
[C-1-3] DOIT disposer de répertoires de stockage d'applications partagées distincts et isolés (également appelés /sdcard) pour chaque instance utilisateur.
[C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et s'exécutant en son nom ne peuvent pas lister, lire ni écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
[C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations d'appareils utilisent un support amovible pour les API de stockage externe. Comme cela rendra le contenu multimédia illisible par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout SMS surtaxé sortant. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur et qui peuvent être facturés à l'utilisateur.

Si les implémentations d'appareil déclarent la compatibilité avec android.hardware.telephony, elles :

[C-1-1] DOIT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT assurer la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) Security-Enhanced Linux (SELinux), le bac à sable seccomp et d'autres fonctionnalités de sécurité du noyau Linux. Implémentations sur les appareils :

[C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou d'autres fonctionnalités de sécurité sont implémentées sous le framework Android.
[C-0-2] NE DOIT PAS comporter d'interface utilisateur visible lorsqu'une atteinte à la sécurité est détectée et bloquée par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT comporter une interface utilisateur visible lorsqu'une atteinte à la sécurité non bloquée se produit et entraîne une exploitation réussie.
[C-0-3] NE DOIT PAS permettre à l'utilisateur ni au développeur d'application de configurer SELinux ni aucune autre fonctionnalité de sécurité implémentée sous le framework Android.
[C-0-4] NE DOIT PAS autoriser une application qui peut affecter une autre application via une API (telle qu'une API d'administration des appareils) à configurer une règle qui rompt la compatibilité.
[C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin de pouvoir accorder un accès plus limité à chaque processus, comme décrit sur le site du projet Android Open Source.
[C-0-6] DOIT implémenter un mécanisme de bac à sable pour les applications du noyau qui permet de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Android Open Source en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation de groupe de threads (TSYNC), comme décrit dans la section "Configuration du noyau" de source.android.com.

L'intégrité et l'autoprotection du noyau font partie intégrante de la sécurité d'Android. Implémentations sur les appareils :

[C-0-7] DOIT implémenter des mécanismes de protection contre le dépassement de tampon de pile du noyau. (par exemple, CC_STACKPROTECTOR_REGULAR et CONFIG_CC_STACKPROTECTOR_STRONG).
[C-0-8] DOIT implémenter des protections strictes de la mémoire du noyau, où le code exécutable est en lecture seule, les données en lecture seule ne sont ni exécutables ni accessibles en écriture, et les données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
[C-0-9] DOIT implémenter la vérification des limites de taille des objets statiques et dynamiques des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
[C-0-10] NE DOIT PAS exécuter de mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, PXN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur.
[C-0-11] NE DOIT PAS lire ni écrire dans la mémoire de l'espace utilisateur du noyau en dehors des API d'accès usercopy normales (par exemple, PAN matériel ou émulation via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils fournis à l'origine 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 à CVE-2017-5754 sur tous les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] DOIT implémenter le renforcement de la prédiction de branchement si le matériel est vulnérable à CVE-2017-5715 sur tous les appareils fournis à l'origine avec le niveau d'API 28 ou supérieur (par exemple, CONFIG_HARDEN_BRANCH_PREDICTOR).
[SR] Il est FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation en lecture seule après l'initialisation (par exemple, __ro_after_init).
[C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser la mise en page du code et de la mémoire du noyau, et d'éviter les expositions qui compromettraient la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).
[C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'intégrité du flux de contrôle (CFI) dans le noyau pour fournir une protection supplémentaire contre les attaques par réutilisation de code (par exemple, CONFIG_CFI_CLANG et CONFIG_SHADOW_CALL_STACK).
[C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI), la pile d'appels fantôme (SCS) ni la désinfection des dépassements d'entiers (IntSan) sur les composants pour lesquels ces fonctionnalités sont activées.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'activer CFI, SCS et IntSan pour tous les composants d'espace utilisateur supplémentaires sensibles à la sécurité, comme expliqué dans CFI et IntSan.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation de la pile dans le noyau pour éviter l'utilisation de variables locales non initialisées (CONFIG_INIT_STACK_ALL ou CONFIG_INIT_STACK_ALL_ZERO). De plus, les implémentations d'appareils NE DOIVENT PAS supposer la valeur utilisée par le compilateur pour initialiser les variables locales.
[C-SR] Il est FORTEMENT RECOMMANDÉ d'activer l'initialisation du tas dans le noyau pour éviter l'utilisation d'allocations de tas non initialisées (CONFIG_INIT_ON_ALLOC_DEFAULT_ON). Il est également DÉCONSEILLÉ de supposer la valeur utilisée par le noyau pour initialiser ces allocations.

Si les implémentations d'appareils utilisent un noyau Linux, elles :

[C-1-1] DOIT implémenter SELinux.
[C-1-2] DOIT définir SELinux sur le mode d'application forcée global.
[C-1-3] DOIT configurer tous les domaines en mode "Appliquer". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil ou à un fournisseur.
[C-1-4] Il NE DOIT PAS modifier, omettre ni remplacer les règles "neverallow" présentes dans le dossier system/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. La règle DOIT être compilée avec toutes les règles "neverallow" présentes, à la fois pour les domaines SELinux AOSP et pour les domaines spécifiques à l'appareil/au fournisseur.
[C-1-5] DOIT exécuter les applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application avec des restrictions SELinux par application sur le répertoire de données privées de chaque application.
DOIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et ne l'étendre que pour sa propre configuration spécifique à l'appareil.

Si les implémentations d'appareils sont déjà lancées sur une version antérieure d'Android et ne peuvent pas répondre aux exigences [C-1-1] et [C-1-5] par le biais d'une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Si les implémentations d'appareils utilisent un noyau autre que Linux, elles :

[C-2-1] DOIT utiliser un système de contrôle d'accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et le gère à l'aide de UsageStatsManager.

Implémentations sur les appareils :

[C-0-1] DOIT conserver un historique des utilisateurs pendant une période raisonnable.
[SR] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle qu'elle est configurée par défaut dans l'implémentation AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via les API système StatsManager et IncidentManager.

Implémentations sur les appareils :

[C-0-2] MUST only include the fields marked with DEST_AUTOMATIC in the incident report created by the System API class IncidentManager.
[C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour consigner d'autres événements que ceux décrits dans la documentation du SDK StatsLog. Si des événements système supplémentaires sont enregistrés, ils PEUVENT utiliser un identifiant d'atome différent dans la plage comprise entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient les informations privées de l'utilisateur (par exemple, les frappes au clavier, le texte affiché à l'écran, le rapport de bug) hors de l'appareil sans le consentement de l'utilisateur ni des notifications claires et continues.
[C-0-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur pour permettre la capture de toute information sensible affichée sur l'écran de l'utilisateur chaque fois que la diffusion ou l'enregistrement d'écran sont activés via MediaProjection ou des API propriétaires. NE DOIT PAS fournir aux utilisateurs un moyen de désactiver l'affichage futur du consentement de l'utilisateur.
[C-0-3] Une notification continue DOIT être affichée à l'utilisateur lorsque la diffusion ou l'enregistrement d'écran sont activés. AOSP répond à cette exigence en affichant une icône de notification continue dans la barre d'état.

Si les implémentations d'appareils incluent des fonctionnalités dans le système qui capturent le contenu affiché à l'écran et/ou enregistrent le flux audio lu sur l'appareil autrement que via l'API système ContentCaptureService ou d'autres moyens propriétaires décrits dans la section 9.8.6, Capture de contenu, elles :

[C-1-1] Une notification continue doit être affichée à l'utilisateur chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement des données.

Si les implémentations d'appareils incluent un composant activé prêt à l'emploi, capable d'enregistrer l'audio ambiant et/ou l'audio lu sur l'appareil pour déduire des informations utiles sur le contexte de l'utilisateur, elles :

[C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil l'audio brut enregistré ou tout format pouvant être reconverti en audio d'origine ou en une copie presque identique, sauf avec le consentement explicite de l'utilisateur.

9.8.3. Connectivité

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

[C-1-1] DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.8.4. Trafic réseau

Implémentations sur les appareils :

[C-0-1] DOIT préinstaller les mêmes certificats racine pour le magasin d'autorité de certification (CA) approuvé par le système que ceux fournis dans le projet Android Open Source en amont.
[C-0-2] DOIT être livré avec un magasin d'autorité de certification racine utilisateur vide.
[C-0-3] DOIT afficher un avertissement à l'utilisateur indiquant que le trafic réseau peut être surveillé lorsqu'une autorité de certification racine utilisateur est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations de l'appareil :

[C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
- Ce trafic réseau peut être surveillé.
- Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, en préchargeant un service VPN avec l'autorisation android.permission.CONTROL_VPN), elles :

[C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par le contrôleur de règles de l'appareil via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas , l'utilisateur n'a pas besoin de fournir un consentement distinct, mais DOIT uniquement être averti.

Si les implémentations d'appareils implémentent une affordance utilisateur pour activer la fonction "VPN permanent" d'une application VPN tierce, elles :

[C-3-1] DOIT désactiver cette fonctionnalité pour les applications qui ne sont pas compatibles avec le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.8.5. Identifiants des appareils

Implémentations sur les appareils :

[C-0-1] DOIT empêcher l'accès au numéro de série de l'appareil et, le cas échéant, à l'IMEI/MEID, au numéro de série de la carte SIM et à l'identité internationale d'abonné mobile (IMSI) depuis une application, sauf si elle répond à l'une des exigences suivantes :
- est une application opérateur signée et validée par les fabricants d'appareils.
- a reçu l'autorisation READ_PRIVILEGED_PHONE_STATE.
- dispose de privilèges d'opérateur tels que définis dans UICC Carrier Privileges.
- est le propriétaire de l'appareil ou du profil et dispose de l'autorisation READ_PHONE_STATE.
- (Pour le numéro de série de la carte SIM/ICCID uniquement) est soumis aux réglementations locales qui exigent que l'application détecte les changements d'identité de l'abonné.

9.8.6. Capture de contenu

Android, via l'API système ContentCaptureService ou par d'autres moyens propriétaires, prend en charge un mécanisme permettant aux implémentations d'appareil de capturer les interactions suivantes entre les applications et l'utilisateur.

Texte et éléments graphiques affichés à l'écran, y compris, mais sans s'y limiter, les notifications et les données d'assistance via l'API AssistStructure.
Données multimédias, telles que les données audio ou vidéo enregistrées ou lues par l'appareil.
Événements d'entrée (par exemple, clavier, souris, geste, voix, vidéo et accessibilité).
Tout autre événement qu'une application fournit au système via l'API Content Capture ou une API propriétaire aux fonctionnalités similaires.
Tout texte ou autre donnée envoyée via TextClassifier API au TextClassifier du système, c'est-à-dire au service système, pour comprendre la signification du texte et générer les prochaines actions prévues en fonction du texte.

Si les implémentations d'appareil capturent les données ci-dessus, elles :

[C-1-1] DOIT chiffrer toutes ces données lorsqu'elles sont stockées dans l'appareil. Ce chiffrement PEUT être effectué à l'aide du chiffrement Android basé sur les fichiers ou de l'un des algorithmes de chiffrement listés pour la version 26 de l'API ou ultérieure, comme décrit dans Cipher SDK.
[C-1-2] NE DOIT PAS sauvegarder les données brutes ou chiffrées à l'aide des méthodes de sauvegarde Android ni d'aucune autre méthode de sauvegarde.
[C-1-3] DOIT uniquement envoyer toutes ces données et le journal de l'appareil à l'aide d'un mécanisme respectueux de la confidentialité. Le mécanisme de préservation de la confidentialité est défini comme "ceux qui n'autorisent que l'analyse agrégée et empêchent la mise en correspondance des événements enregistrés ou des résultats dérivés avec des utilisateurs individuels", afin d'empêcher toute introspection des données par utilisateur (par exemple, implémentée à l'aide d'une technologie de confidentialité différentielle telle que RAPPOR).
[C-1-4] NE DOIT PAS associer ces données à une identité utilisateur (telle que Account) sur l'appareil, sauf avec le consentement explicite de l'utilisateur chaque fois que les données sont associées.
[C-1-5] NE DOIT PAS partager ces données avec d'autres applications, sauf avec le consentement explicite de l'utilisateur à chaque fois qu'elles sont partagées.
[C-1-6] DOIT fournir à l'utilisateur la possibilité d'effacer les données collectées par ContentCaptureService ou par des moyens propriétaires si les données sont stockées sous quelque forme que ce soit sur l'appareil.

Si les implémentations d'appareils incluent un service qui implémente l'API System ContentCaptureService ou tout service propriétaire qui capture les données comme décrit ci-dessus, elles :

[C-2-1] NE DOIT PAS permettre aux utilisateurs de remplacer le service de capture de contenu par une application ou un service installable par l'utilisateur et NE DOIT autoriser que le service préinstallé à capturer ces données.
[C-2-2] NE DOIT PAS autoriser d'autres applications que le mécanisme de service de capture de contenu préinstallé à capturer ces données.
[C-2-3] DOIT fournir à l'utilisateur un moyen de désactiver le service de capture de contenu.
[C-2-4] NE DOIT PAS omettre la possibilité pour l'utilisateur de gérer les autorisations Android détenues par le service de capture de contenu et doit suivre le modèle d'autorisations Android décrit dans la section 9.1. Autorisation.
[C-SR] Il est FORTEMENT RECOMMANDÉ de conserver les composants du service de capture de contenu séparés, par exemple en ne liant pas le service ni en partageant les ID de processus, des autres composants du système, à l'exception des suivants :
- Téléphonie, Contacts, UI système et Multimédia

9.8.7. Accès au presse-papiers

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS renvoyer de données tronquées dans le presse-papiers (par exemple, via l'API ClipboardManager), sauf si l'application est l'IME par défaut ou l'application actuellement sélectionnée.

9.8.8. Position

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS activer/désactiver les paramètres de localisation de l'appareil ni les paramètres de recherche Wi-Fi/Bluetooth sans le consentement explicite de l'utilisateur ou sans que l'utilisateur en soit à l'origine.
[C-0-2] DOIT fournir à l'utilisateur un moyen d'accéder aux informations liées à la localisation, y compris les demandes de localisation récentes, les autorisations au niveau de l'application et l'utilisation du scan Wi-Fi/Bluetooth pour déterminer la position.
[C-0-3] DOIT s'assurer que l'application utilisant l'API Emergency Location Bypass [LocationRequest.setLocationSettingsIgnored()] est une session d'urgence initiée par l'utilisateur (par exemple, appel ou message au 112). Toutefois, pour l'automobile, un véhicule PEUT lancer une session d'urgence sans interaction active de l'utilisateur en cas de détection d'un accident (par exemple, pour répondre aux exigences eCall).
[C-0-4] DOIT préserver la capacité de l'API Emergency Location Bypass à contourner les paramètres de localisation de l'appareil sans les modifier.
[C-0-5] DOIT planifier une notification qui rappelle à l'utilisateur qu'une application en arrière-plan a accédé à sa position à l'aide de l'autorisation [ACCESS_BACKGROUND_LOCATION].

9.8.9. Applications installées

Par défaut, les applications Android ciblant le niveau d'API 30 ou supérieur ne peuvent pas voir les détails des autres applications installées (consultez la section Visibilité des packages dans la documentation du SDK Android).

Implémentations sur les appareils :

[C-0-1] NE DOIT PAS exposer à une application ciblant le niveau d'API 30 ou supérieur des informations sur une autre application installée, sauf si l'application peut déjà voir des informations sur l'autre application installée via les API gérées. Cela inclut, sans s'y limiter, les détails exposés par les API personnalisées ajoutées par l'intégrateur de l'appareil ou accessibles via le système de fichiers.

9.8.10. Rapport de bug sur la connectivité

Si les implémentations d'appareils génèrent des rapports de bug à l'aide de l'API système BUGREPORT_MODE_TELEPHONY avec BugreportManager, elles :

[C-1-1] DOIT obtenir le consentement de l'utilisateur chaque fois que l'API System BUGREPORT_MODE_TELEPHONY est appelée pour générer un rapport et NE DOIT PAS inviter l'utilisateur à consentir à toutes les futures demandes de l'application.
[C-1-2] DOIT afficher et obtenir le consentement explicite de l'utilisateur lorsque les rapports commencent à être générés, et NE DOIT PAS renvoyer le rapport généré à l'application demandeuse sans le consentement explicite de l'utilisateur.
[C-1-3] DOIT générer les rapports demandés contenant au moins les informations suivantes :
- Dump TelephonyDebugService
- Dump TelephonyRegistry
- Dump WifiService
- Dump ConnectivityService
- Dump de l'instance CarrierService du package appelant (si elle est liée)
- Mémoire tampon du journal radio
[C-1-4] NE DOIT PAS inclure les éléments suivants dans les rapports générés :
- Toute information sans rapport avec le débogage de la connectivité.
- Tout type de journaux de trafic d'applications installées par l'utilisateur ou de profils détaillés d'applications/packages installés par l'utilisateur (les UID sont acceptés, mais pas les noms de packages).
PEUT inclure des informations supplémentaires qui ne sont associées à aucune identité utilisateur. (par exemple, les journaux des fournisseurs).

Si les implémentations d'appareils incluent des informations supplémentaires (par exemple, des journaux de fournisseurs) dans le rapport de bug et que ces informations ont un impact sur la confidentialité, la sécurité, la batterie, le stockage ou la mémoire, elles :

[C-SR] Il est FORTEMENT RECOMMANDÉ que le paramètre développeur soit désactivé par défaut. L'AOSP répond à cette exigence en fournissant l'option Enable verbose vendor logging dans les paramètres du développeur pour inclure des journaux de fournisseur supplémentaires spécifiques à l'appareil dans les rapports de bug.

9.8.11. Partage de blobs de données

Android, via BlobStoreManager, permet aux applications de fournir des blobs de données au système pour qu'ils soient partagés avec un ensemble d'applications sélectionnées.

Si les implémentations d'appareils sont compatibles avec les blobs de données partagés, comme décrit dans la documentation du SDK, elles :

[C-1-1] Les blobs de données appartenant aux applications NE DOIVENT PAS être partagés au-delà de ce qu'elles ont prévu d'autoriser (c'est-à-dire que le champ d'accès par défaut et les autres modes d'accès qui peuvent être spécifiés à l'aide de BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() ou BlobStoreManager.session#allowPublicAccess() NE DOIVENT PAS être modifiés). L'implémentation de référence AOSP répond à ces exigences.
[C-1-2] NE DOIT PAS envoyer hors de l'appareil ni partager avec d'autres applications les hachages sécurisés des blobs de données (qui sont utilisés pour contrôler l'accès).

9.9. Chiffrement du stockage des données

Tous les appareils DOIVENT répondre aux exigences de la section 9.9.1. Les appareils lancés avec un niveau d'API antérieur à celui de ce document sont exemptés des exigences des sections 9.9.2 et 9.9.3. Ils DOIVENT en revanche répondre aux exigences de la section 9.9 du document de définition de compatibilité Android correspondant au niveau d'API avec lequel l'appareil a été lancé.

9.9.1. Démarrage direct

Implémentations sur les appareils :

[C-0-1] DOIT implémenter les API du mode Démarrage direct, même si elles ne sont pas compatibles avec le chiffrement du stockage.
[C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que les emplacements de stockage chiffrés par l'appareil (DE) et chiffrés par les identifiants (CE) sont disponibles pour l'utilisateur.

9.9.2. Exigences de chiffrement

Implémentations sur les appareils :

[C-0-1] DOIT chiffrer les données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) si elle constitue une partie permanente et non amovible de l'appareil.
[C-0-2] DOIT activer le chiffrement du stockage des données par défaut une fois que l'utilisateur a terminé la configuration initiale.
[C-0-3] DOIT répondre aux exigences de chiffrement du stockage des données ci-dessus en implémentant l'une des deux méthodes de chiffrement suivantes :
- Chiffrement basé sur les fichiers (FBE) et chiffrement des métadonnées, comme décrit dans la section 9.9.3.1.
- Chiffrement au niveau des blocs par utilisateur, comme décrit dans la section 9.9.3.2.

9.9.3. Méthodes de chiffrement

Si les implémentations d'appareil sont chiffrées, elles :

[C-1-1] DOIT démarrer sans demander d'identifiants à l'utilisateur et autoriser les applications compatibles avec le démarrage direct à accéder au stockage chiffré de l'appareil (DE) après la diffusion du message ACTION_LOCKED_BOOT_COMPLETED.
[C-1-2] DOIT autoriser l'accès au stockage chiffré par identifiants (CE, Credential Encrypted) uniquement après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, un code secret, un code PIN, un schéma ou une empreinte digitale) et que le message ACTION_USER_UNLOCKED a été diffusé.
[C-1-13] NE DOIT PAS proposer de méthode pour déverrouiller l'espace de stockage protégé par CE sans les identifiants fournis par l'utilisateur, une clé de dépôt enregistrée ou une implémentation de reprise au redémarrage répondant aux exigences de la section 9.9.4.
[C-1-4] DOIT utiliser le démarrage validé.

9.9.3.1. Chiffrement basé sur les fichiers avec chiffrement des métadonnées

Si les implémentations d'appareils utilisent le chiffrement basé sur les fichiers avec le chiffrement des métadonnées, elles :

[C-1-5] DOIT chiffrer le contenu des fichiers et les métadonnées du système de fichiers à l'aide d'AES-256-XTS ou d'Adiantum. AES-256-XTS fait référence à la norme Advanced Encryption Standard avec une longueur de clé de chiffrement de 256 bits, fonctionnant en mode XTS. La longueur totale de la clé est de 512 bits. Adiantum fait référence à Adiantum-XChaCha12-AES, comme indiqué sur https://github.com/google/adiantum. Les métadonnées du système de fichiers sont des données telles que la taille des fichiers, la propriété, les modes et les attributs étendus (xattrs).
[C-1-6] DOIT chiffrer les noms de fichiers à l'aide d'AES-256-CBC-CTS ou d'Adiantum.
[C-1-12] Si l'appareil dispose d'instructions AES (Advanced Encryption Standard) (telles que les extensions de chiffrement ARMv8 sur les appareils basés sur ARM ou AES-NI sur les appareils basés sur x86), les options basées sur AES ci-dessus pour le nom de fichier, le contenu du fichier et le chiffrement des métadonnées du système de fichiers DOIVENT être utilisées, et non Adiantum.
[C-1-13] DOIT utiliser une fonction de dérivation de clé cryptographiquement robuste et non réversible (par exemple, HKDF-SHA512) pour dériver les sous-clés nécessaires (par exemple, les clés par fichier) à partir des clés CE et DE. "Cryptographiquement robuste et non réversible" signifie que la fonction de dérivation de clé a une robustesse de sécurité d'au moins 256 bits et se comporte comme une famille de fonctions pseudo-aléatoires sur ses entrées.
[C-1-14] NE DOIT PAS utiliser les mêmes clés ou sous-clés de chiffrement basé sur des fichiers (FBE) pour différents objectifs cryptographiques (par exemple, à la fois pour le chiffrement et la dérivation de clés, ou pour deux algorithmes de chiffrement différents).
Clés protégeant les zones de stockage et les métadonnées du système de fichiers CE et DE :
[C-1-7] DOIT être lié de manière cryptographique à un Keystore avec support matériel. Ce keystore DOIT être lié au démarrage sécurisé et à la racine de confiance matérielle de l'appareil.
[C-1-8] Les clés CE DOIVENT être associées aux identifiants de l'écran de verrouillage d'un utilisateur.
[C-1-9] Les clés CE DOIVENT être liées à un code secret par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants pour l'écran de verrouillage.
[C-1-10] DOIT être unique et distinct. En d'autres termes, la clé CE ou DE d'un utilisateur ne doit correspondre à la clé CE ou DE d'aucun autre utilisateur.
[C-1-11] DOIT utiliser les modes, les longueurs de clé et les algorithmes de chiffrement obligatoirement pris en charge.
DOIT rendre les applications essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) compatibles avec le démarrage direct.

Le projet Android Open Source en amont fournit une implémentation privilégiée du chiffrement basé sur les fichiers, qui s'appuie sur la fonctionnalité de chiffrement "fscrypt" du noyau Linux, et du chiffrement des métadonnées, qui s'appuie sur la fonctionnalité "dm-default-key" du noyau Linux.

9.9.3.2. Chiffrement au niveau du bloc par utilisateur

Si les implémentations d'appareils utilisent le chiffrement au niveau des blocs par utilisateur, elles :

[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 en utilisant des 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 stockage sous-jacents.
[C-1-4] DOIT utiliser AES-256-XTS pour le chiffrement au niveau des blocs des partitions utilisateur.
Clés protégeant les appareils chiffrés au niveau des blocs par utilisateur :
[C-1-5] DOIT être lié de manière cryptographique à un Keystore avec support matériel. Ce keystore DOIT être lié au démarrage sécurisé et à la racine de confiance matérielle de l'appareil.
[C-1-6] DOIT être associé aux identifiants de l'écran de verrouillage de l'utilisateur correspondant.

Le chiffrement au niveau des blocs par utilisateur peut être implémenté à l'aide de la fonctionnalité "dm-crypt" du noyau Linux sur les partitions par utilisateur.

9.9.4. Reprendre la lecture après un redémarrage

La reprise au redémarrage permet de déverrouiller le stockage CE de toutes les applications, y compris celles qui ne sont pas encore compatibles avec le démarrage direct, après un redémarrage initié par une mise à jour OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications des applications installées après le redémarrage.

Une implémentation de la reprise au redémarrage doit continuer à garantir que, lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour ce pirate de récupérer les données chiffrées par le CE de l'utilisateur, même si l'appareil est allumé, que le stockage CE est déverrouillé et que l'utilisateur a déverrouillé l'appareil après avoir reçu une mise à jour OTA. Pour résister aux attaques d'initiés, nous supposons également que le pirate informatique accède aux clés de signature cryptographiques de diffusion.

Plus spécifiquement :

[C-0-1] Le stockage CE NE DOIT PAS être lisible, même pour le pirate informatique qui a physiquement l'appareil et qui dispose des capacités et des limites suivantes :
- Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
- Peut entraîner la réception d'une mise à jour OTA par l'appareil.
- Peut modifier le fonctionnement de tout matériel (AP, flash, etc.) sauf comme indiqué ci-dessous, mais une telle modification implique un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.
- Vous ne pouvez pas modifier le fonctionnement du matériel inviolable (par exemple, Titan M).
- Impossible de lire la RAM de l'appareil en direct.
- Ne pas pouvoir obtenir les identifiants de l'utilisateur (code, schéma, mot de passe) ou les faire saisir d'une autre manière.

Par exemple, une implémentation d'appareil qui implémente et respecte toutes les descriptions disponibles ici sera conforme à [C-0-1].

9.10. Intégrité de l'appareil

Les exigences suivantes garantissent la transparence de l'état de l'intégrité de l'appareil. Implémentations sur les appareils :

[C-0-1] DOIT indiquer correctement via la méthode PersistentDataBlockManager.getFlashLockState() de l'API System si l'état de son bootloader permet le flashage de l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils qui effectuent une mise à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.
[C-0-2] DOIT prendre en charge le démarrage sécurisé pour l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans prise en charge du démarrage validé sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations d'appareil sont compatibles avec la fonctionnalité, elles :

[C-1-1] DOIT déclarer le commutateur de fonctionnalité de la plate-forme android.software.verified_boot.
[C-1-2] DOIT effectuer une vérification à chaque séquence de démarrage.
[C-1-3] DOIT commencer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et remonter jusqu'à la partition système.
[C-1-4] DOIT implémenter chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
[C-1-5] DOIT utiliser des algorithmes de validation aussi puissants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
[C-1-6] NE DOIT PAS autoriser le démarrage à se terminer en cas d'échec de la validation du système, sauf si l'utilisateur accepte de tenter le démarrage quand même, auquel cas les données des blocs de stockage non validés NE DOIVENT PAS être utilisées.
[C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
[C-SR] Si l'appareil comporte plusieurs puces distinctes (par exemple, une puce radio ou un processeur d'image spécialisé), il est FORTEMENT RECOMMANDÉ de vérifier chaque étape du processus de démarrage de chacune de ces puces.
[C-1-8] DOIT utiliser un stockage inviolable : pour stocker si le bootloader est déverrouillé. Le stockage inviolable signifie que le bootloader peut détecter si le stockage a été falsifié depuis Android.
[C-1-9] DOIT inviter l'utilisateur à confirmer physiquement la transition du mode bootloader verrouillé au mode bootloader déverrouillé pendant l'utilisation de l'appareil.
[C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (par exemple, les partitions de démarrage et système) et utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée de l'OS.
[C-SR] Il est FORTEMENT RECOMMANDÉ de valider tous les fichiers APK des applications privilégiées avec une chaîne de confiance ancrée dans les partitions protégées par le démarrage validé.
[C-SR] Il est FORTEMENT RECOMMANDÉ de valider tout artefact exécutable chargé par une application privilégiée en dehors de son fichier APK (comme du code chargé dynamiquement ou du code compilé) avant de l'exécuter, ou FORTEMENT RECOMMANDÉ de ne pas l'exécuter du tout.
DOIT implémenter une protection contre la restauration pour tout composant avec un micrologiciel persistant (par exemple, le modem ou la caméra) et DOIT utiliser un stockage inviolable pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si des implémentations d'appareils sont déjà lancées sans prendre en charge les exigences C-1-8 à C-1-10 sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de ces exigences avec une mise à jour du logiciel système, elles PEUVENT être exemptées de ces exigences.

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégrée au bootloader utilisé pour charger Android.

Implémentations sur les appareils :

[C-0-3] DOIT permettre de valider de manière cryptographique le contenu d'un fichier par rapport à une clé de confiance sans lire l'intégralité du fichier.
[C-0-4] NE DOIT PAS autoriser les requêtes de lecture sur un fichier protégé à aboutir lorsque le contenu lu n'est pas validé par rapport à une clé de confiance.

Si des implémentations d'appareils sont déjà lancées sans possibilité de valider le contenu des fichiers par rapport à une clé de confiance sur une version antérieure d'Android et qu'il est impossible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour du logiciel système, elles PEUVENT être exemptées de cette exigence. Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité fs-verity du noyau Linux.

Implémentations sur les appareils :

[C-R] Il est RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations d'appareils sont compatibles avec l'API Android Protected Confirmation, elles :

[C-3-1] DOIT signaler true pour l'API ConfirmationPrompt.isSupported().
[C-3-2] DOIT s'assurer que le code s'exécutant dans l'OS Android, y compris son noyau, malveillant ou non, ne peut pas générer de réponse positive sans interaction de l'utilisateur.
[C-3-3] DOIT s'assurer que l'utilisateur a pu examiner et approuver le message affiché, même si l'OS Android, y compris son noyau, est compromis.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations cryptographiques via l'API KeyChain ou l'API Keystore. Implémentations sur les appareils :

[C-0-1] DOIT permettre d'importer ou de générer au moins 8 192 clés.
[C-0-2] L'authentification sur l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT utiliser un algorithme d'intervalle exponentiel entre les tentatives. Au-delà de 150 tentatives infructueuses, le délai DOIT être d'au moins 24 heures par tentative.
NE DOIT PAS limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé, elle :

[C-1-1] DOIT sauvegarder l'implémentation du keystore avec un environnement d'exécution isolé.
[C-1-2] DOIT implémenter les algorithmes de chiffrement RSA, AES, ECDSA et HMAC, ainsi que les fonctions de hachage de la famille MD5, SHA1 et SHA-2 pour prendre correctement en charge les algorithmes compatibles du système Android Keystore dans une zone sécurisée et isolée du code s'exécutant 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 le DMA. Le projet Android Open Source Project (AOSP) en amont répond à cette exigence en utilisant l'implémentation Trusty, mais d'autres solutions basées sur ARM TrustZone ou une implémentation sécurisée tierce et examinée d'une isolation appropriée basée sur un hyperviseur sont également possibles.
[C-1-3] DOIT effectuer l'authentification de l'écran de verrouillage dans l'environnement d'exécution isolé et n'autoriser l'utilisation des clés liées à l'authentification qu'en cas de succès. Les identifiants de l'écran de verrouillage DOIVENT être stockés de manière à ce que seul l'environnement d'exécution isolé puisse effectuer l'authentification de l'écran de verrouillage. Le projet Android Open Source en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper et Trusty, qui peuvent être utilisés pour répondre à cette exigence.
[C-1-4] DOIT prendre en charge l'attestation de clé lorsque la clé de signature de l'attestation est protégée par du matériel sécurisé et que la signature est effectuée dans du matériel sécurisé. Les clés de signature d'attestation DOIVENT être partagées sur un nombre d'appareils suffisamment important pour empêcher qu'elles ne soient utilisées comme identifiants d'appareil. Pour répondre à cette exigence, vous pouvez partager la même clé d'attestation, sauf si au moins 100 000 unités d'un SKU donné sont produites. Si plus de 100 000 unités d'un SKU sont produites, une clé différente PEUT être utilisée pour chaque tranche de 100 000 unités.

[C-1-5] DOIT permettre à l'utilisateur de choisir le délai d'inactivité pour passer de l'état déverrouillé à l'état verrouillé, avec un délai d'inactivité minimal autorisé de 15 secondes. Les appareils automobiles qui verrouillent l'écran chaque fois que l'unité principale est éteinte ou que l'utilisateur est changé NE DOIVENT PAS avoir la configuration du délai d'inactivité.

9.11.1. Écran de verrouillage sécurisé et authentification

L'implémentation AOSP suit un modèle d'authentification à plusieurs niveaux, dans lequel une authentification principale basée sur un facteur de connaissance peut être soutenue par une authentification biométrique secondaire forte ou par des modalités tertiaires plus faibles.

Implémentations sur les appareils :

[C-SR] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes d'authentification suivantes comme méthode principale :
- Un code numérique
- Un mot de passe alphanumérique
- Un schéma de balayage sur une grille de 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont appelées méthodes d'authentification principales recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principales recommandées et utilisent une nouvelle méthode d'authentification comme moyen sécurisé de verrouiller l'écran, la nouvelle méthode d'authentification :

[C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans Exiger l'authentification de l'utilisateur pour l'utilisation des clés.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage si elles sont basées sur un secret connu et utilisent une nouvelle méthode d'authentification pour être traitées comme un moyen sécurisé de verrouiller l'écran :

[C-3-1] L'entropie de la longueur d'entrée la plus courte autorisée DOIT être supérieure à 10 bits.
[C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
[C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer les méthodes d'authentification principales recommandées (c'est-à-dire le code, le schéma ou le mot de passe) implémentées et fournies dans AOSP.
[C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING.
[C-3-5] Les nouvelles méthodes d'authentification DOIVENT revenir aux méthodes d'authentification principales recommandées (c'est-à-dire le code, le schéma ou le mot de passe) au moins une fois toutes les 72 heures OU indiquer clairement à l'utilisateur que certaines données ne seront pas sauvegardées afin de préserver la confidentialité de ses données.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification principale recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie pour être traitées comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode :

[C-4-1] DOIT répondre à toutes les exigences décrites dans la section 7.3.10 pour la classe 1 (anciennement Praticité).
[C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées, qui repose sur un secret connu.
[C-4-3] DOIT être désactivé et n'autoriser que l'authentification principale recommandée pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la règle de fonctionnalité keyguard en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures(), avec l'un des indicateurs biométriques associés (c'est-à-dire KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).

Si les méthodes d'authentification biométrique ne répondent pas aux exigences de la classe 3 (anciennement forte) décrites dans la section 7.3.10 :

[C-5-1] Les méthodes DOIVENT être désactivées si l'application Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] L'utilisateur DOIT être invité à utiliser la méthode d'authentification principale recommandée (par exemple, code, schéma ou mot de passe) comme décrit dans [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 répondre aux exigences commençant par C-8 dans la section ci-dessous.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur la position :

[C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principale recommandées, qui est basée sur un secret connu et répond aux exigences pour être traitée comme un écran de verrouillage sécurisé.
[C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser qu'une seule des méthodes d'authentification principale recommandées pour déverrouiller l'écran lorsque l'application Device Policy Controller (DPC) a défini la règle avec la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
[C-6-3] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma, mot de passe) 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 respecter les contraintes listées dans C-8 ci-dessous.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui implémentent l'API système TrustAgentService, elles :

[C-7-1] Une indication claire doit figurer dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouillage automatique" et "Bouton Marche/Arrêt verrouille instantanément" dans le menu des paramètres, ainsi qu'une icône distinctive sur l'écran de verrouillage.
[C-7-2] DOIT respecter et implémenter entièrement toutes les API d'agent de confiance de la classe DevicePolicyManager, telles que la constante KEYGUARD_DISABLE_TRUST_AGENTS.
[C-7-3] NE DOIT PAS implémenter entièrement la fonction TrustAgentService.addEscrowToken() sur un appareil utilisé comme appareil personnel principal (par exemple, un appareil mobile), mais PEUT implémenter entièrement la fonction sur les implémentations d'appareils qui sont généralement partagées (par exemple, un appareil Android TV ou automobile).
[C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
[C-7-5] NE DOIT PAS stocker la clé de chiffrement ni le jeton de séquestre sur le même appareil que celui sur lequel la clé est utilisée. Par exemple, une clé stockée sur un téléphone peut être autorisée à déverrouiller un compte utilisateur sur un téléviseur. Pour les appareils automobiles, le jeton de séquestre ne doit pas être stocké sur une partie quelconque du véhicule.
[C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'activer le jeton de séquestre pour déchiffrer le stockage de données.
[C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées.
[C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma, mot de passe) au moins une fois toutes les 72 heures ou moins, sauf si la sécurité de l'utilisateur (par exemple, distraction du conducteur) est préoccupante.
[C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (code, schéma, mot de passe, par exemple) décrites dans [C-1-7] et [C-1-8] de la section 7.3.10, sauf si la sécurité de l'utilisateur est menacée (par exemple, en cas de distraction du conducteur).
[C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes listées dans C-8 ci-dessous.
[C-7-11] NE DOIT PAS autoriser les TrustAgents sur les appareils personnels principaux (par exemple, les appareils portables) à déverrouiller l'appareil.Ils ne peuvent être utilisés que pour maintenir un appareil déjà déverrouillé dans cet état pendant une durée maximale de quatre heures. L'implémentation par défaut de TrustManagerService dans AOSP répond à cette exigence.
[C-7-12] DOIT utiliser un canal de communication cryptographiquement sécurisé (par exemple, UKEY2) pour transmettre le jeton de dépôt de garantie du périphérique de stockage à l'appareil cible.

Si les implémentations d'appareils ajoutent ou modifient les méthodes d'authentification pour déverrouiller l'écran de verrouillage qui n'est pas un écran de verrouillage sécurisé comme décrit ci-dessus, et utilisent une nouvelle méthode d'authentification pour déverrouiller le keyguard :

[C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application Device Policy Controller (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
[C-8-2] Ils NE DOIVENT PAS réinitialiser les minuteurs d'expiration des mots de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
[C-8-3] Elles NE DOIVENT PAS exposer d'API permettant aux applications tierces de modifier l'état de la serrure.

9.11.2. StrongBox

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un processeur sécurisé dédié, ainsi que dans l'environnement d'exécution isolé décrit ci-dessus. Ce processeur sécurisé dédié est appelé "StrongBox". Les exigences C-1-3 à C-1-11 ci-dessous définissent les exigences auxquelles un appareil doit répondre pour être considéré comme une StrongBox.

Implémentations d'appareils dotés d'un processeur sécurisé dédié :

[C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge StrongBox. StrongBox deviendra probablement une exigence dans une prochaine version.

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

[C-1-1] Vous DEVEZ déclarer FEATURE_STRONGBOX_KEYSTORE.
[C-1-2] DOIT fournir un matériel sécurisé dédié utilisé pour le keystore et l'authentification sécurisée des utilisateurs. Le matériel sécurisé dédié peut également être utilisé à d'autres fins.
[C-1-3] DOIT disposer d'un processeur distinct qui ne partage pas de cache, de DRAM, de coprocesseurs ni d'autres ressources de base avec le processeur d'application (AP).
[C-1-4] DOIT s'assurer que les périphériques partagés avec l'AP ne peuvent en aucun cas modifier le traitement StrongBox ni obtenir d'informations de StrongBox. L'AP PEUT désactiver ou bloquer l'accès à StrongBox.
[C-1-5] DOIT disposer d'une horloge interne d'une précision raisonnable (± 10 %) et à l'abri de toute manipulation par le PA.
[C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires qui produit des résultats imprévisibles et uniformément répartis.
[C-1-7] DOIT être résistant à la falsification, y compris à la pénétration physique et aux problèmes techniques.
[C-1-8] DOIT être résistant aux canaux auxiliaires, y compris aux fuites d'informations via les canaux auxiliaires de puissance, de timing, de rayonnement électromagnétique et de rayonnement thermique.
[C-1-9] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. Le stockage NE DOIT PAS pouvoir être lu ni modifié, sauf dans les limites autorisées par les API StrongBox.
Pour valider la conformité avec les sections [C-1-3] à [C-1-9], les implémentations d'appareils doivent :
- [C-1-10] DOIT inclure le matériel certifié conforme au profil de protection Secure IC BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation de la vulnérabilité à fort potentiel d'attaque conformément à l'application des critères communs du potentiel d'attaque aux cartes à puce.
- [C-1-11] DOIT inclure le micrologiciel évalué par un laboratoire d'essai accrédité au niveau national intégrant une évaluation de la vulnérabilité à fort potentiel d'attaque conformément à l'application des critères communs du potentiel d'attaque aux cartes à puce.
- [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, d'un niveau d'assurance d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement obligatoire dans une prochaine version.
[C-SR] Il est FORTEMENT RECOMMANDÉ de fournir une protection contre les attaques internes (IAR, Insider Attack Resistance). Cela signifie qu'un employé ayant accès aux clés de signature du micrologiciel ne peut pas produire un micrologiciel qui provoque la fuite de secrets par StrongBox, contourne les exigences de sécurité fonctionnelles ou permet d'accéder à des données utilisateur sensibles. La méthode recommandée pour implémenter IAR consiste à autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fourni via IAuthSecret HAL.

9.11.3. Informations d'identité

Le système d'identifiants d'identité est défini et obtenu en implémentant toutes les API du package android.security.identity.*. Ces API permettent aux développeurs d'applications de stocker et de récupérer les documents d'identité des utilisateurs. Implémentations sur les appareils :

[C-SR] Il est FORTEMENT RECOMMANDÉ aux développeurs de mettre en œuvre le système d'identifiants.

Si les implémentations d'appareils implémentent le système d'informations d'identité, elles :

[C-0-1] La méthode IdentityCredentialStore#getInstance() DOIT renvoyer une valeur non nulle.
[C-0-2] DOIT implémenter le système d'identifiants (par exemple, les API android.security.identity.*) avec du code communiquant avec une application de confiance dans une zone isolée de manière sécurisée du code s'exécutant 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 le DMA.
[C-0-3] Les opérations de chiffrement nécessaires à l'implémentation du système d'identifiants (par exemple, les API android.security.identity.*) DOIVENT être effectuées entièrement dans l'application de confiance, et le matériel de clé privée ne DOIT jamais quitter l'environnement d'exécution isolé, sauf si cela est spécifiquement requis par les API de niveau supérieur (par exemple, la méthode createEphemeralKeyPair()).
[C-0-4] L'application de confiance DOIT être implémentée de manière à ce que ses propriétés de sécurité ne soient pas affectées (par exemple, les données d'identification ne sont pas divulguées tant que les conditions de contrôle d'accès ne sont pas remplies, les MAC ne peuvent pas être produits pour des données arbitraires), même si Android se comporte mal ou est compromis.

9.12. Suppression des données

Toutes les implémentations d'appareils :

[C-0-1] DOIT fournir aux utilisateurs un mécanisme permettant de rétablir la configuration d'usine.
[C-0-2] DOIT supprimer toutes les données du système de fichiers userdata.
[C-0-3] DOIT supprimer les données de manière à respecter les normes sectorielles pertinentes, telles que NIST SP800-88.
[C-0-4] DOIT déclencher la procédure de réinitialisation des données d'usine ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application Device Policy Controller de l'utilisateur principal.
PEUT proposer une option d'effacement rapide des données qui n'effectue qu'un effacement logique des données.

9.13. Mode démarrage sécurisé

Android propose un mode de démarrage sécurisé qui permet aux utilisateurs de démarrer l'appareil dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et où toutes les applications tierces sont désactivées. Ce mode, appelé "mode sans échec", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes :

[SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le mode Démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode Safe Boot, elles :

[C-1-1] DOIT fournir à l'utilisateur une option permettant d'accéder au mode démarrage sécurisé de manière ininterrompue par les applications tierces installées sur l'appareil, sauf lorsque l'application tierce est un contrôleur de règles relatives aux appareils et que l'indicateur UserManager.DISALLOW_SAFE_BOOT est défini sur "true".
[C-1-2] DOIT permettre à l'utilisateur de désinstaller les applications tierces en mode sans échec.
DOIT fournir à l'utilisateur une option permettant d'accéder au mode sans échec à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation du système de véhicule automobile

Les appareils Android Automotive sont censés échanger des données avec les sous-systèmes critiques du véhicule à l'aide de la HAL du véhicule pour envoyer et recevoir des messages sur les réseaux du véhicule, tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android pour empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits d'abonnement" font référence aux détails du forfait de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils :

[C-0-1] DOIT renvoyer les forfaits d'abonnement uniquement à l'application de l'opérateur mobile qui les a fournis à l'origine.
[C-0-2] NE DOIT PAS sauvegarder ni importer à distance des forfaits d'abonnement.
[C-0-3] DOIT uniquement autoriser les remplacements, tels que SubscriptionManager.setSubscriptionOverrideCongested(), à partir de l'application de l'opérateur mobile qui fournit actuellement des forfaits valides.

9.16. Migration des données d'application

Si les implémentations d'appareils incluent une fonctionnalité permettant de migrer des données d'un appareil vers un autre et ne limitent pas les données d'application qu'elles copient à celles configurées par le développeur d'application dans le fichier manifeste via l'attribut android:fullBackupContent, elles :

[C-1-1] NE DOIT PAS lancer de transfert de données d'application depuis des appareils sur lesquels l'utilisateur n'a pas défini d'authentification principale, comme décrit dans 9.11.1 Écran de verrouillage et authentification sécurisés.
[C-1-2] DOIT confirmer de manière sécurisée l'authentification principale sur l'appareil source et confirmer l'intention de l'utilisateur de copier les données sur l'appareil source avant tout transfert de données.
[C-1-3] DOIT utiliser l'attestation de clé de sécurité pour s'assurer que l'appareil source et l'appareil cible de la migration d'appareil à appareil sont des appareils Android légitimes et que leur bootloader est verrouillé.
[C-1-4] DOIT uniquement migrer les données d'application vers la même application sur l'appareil cible, avec le même nom de package ET le même certificat de signature.
[C-1-5] DOIT afficher une indication dans le menu des paramètres indiquant que les données de l'appareil source ont été migrées à l'aide de la migration de données d'appareil à appareil. Un utilisateur NE DOIT PAS pouvoir supprimer cette indication.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Toutefois, notez qu'aucun package de test logiciel n'est entièrement exhaustif. C'est pourquoi il est FORTEMENT RECOMMANDÉ aux développeurs d'appareils d'apporter le moins de modifications possible à l'implémentation de référence et préférée d'Android disponible dans le Projet Android Open Source. Cela permet de minimiser le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations sur les appareils :

[C-0-1] DOIT réussir la suite de tests de compatibilité (CTS) Android disponible sur le projet Android Open Source, en utilisant le logiciel final fourni sur l'appareil.
[C-0-2] DOIT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. La CTS sera versionnée indépendamment de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 11.

Implémentations sur les appareils :

[C-0-3] DOIT réussir la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.
DOIT utiliser l'implémentation de référence dans l'arborescence Android Open Source autant que possible.

10.2. Vérificateur CTS

CTS Verifier est inclus dans la suite de tests de compatibilité. Il est conçu pour être exécuté par un opérateur humain afin de tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

Implémentations sur les appareils :

[C-0-1] DOIT exécuter correctement tous les cas applicables dans le CTS Verifier.

Le CTS Verifier comporte des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations sur les appareils :

[C-0-2] DOIT réussir tous les tests pour le matériel dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans CTS Verifier.

Les cas de test pour les fonctionnalités indiquées comme facultatives par le présent document de définition de compatibilité PEUVENT être ignorés ou omis.

[C-0-2] Chaque appareil et chaque compilation DOIVENT exécuter correctement le CTS Verifier, comme indiqué ci-dessus. Toutefois, comme de nombreuses compilations sont très similaires, les responsables de l'implémentation des appareils ne sont pas censés exécuter explicitement le CTS Verifier sur les compilations qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le test CTS Verifier uniquement par l'ensemble des paramètres régionaux inclus, la marque, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels pouvant être mis à jour

[C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à niveau "en direct", c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité des logiciels préinstallés sur l'appareil. Par exemple, l'une des approches suivantes répondra à cette exigence :
- Téléchargements "Over-the-Air (OTA)" avec mise à jour hors connexion via le redémarrage.
- Mises à jour "ancrées" via USB depuis un PC hôte.
- Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un espace de stockage amovible.
[C-0-2] Le mécanisme de mise à jour utilisé DOIT permettre les mises à jour sans effacer les données utilisateur. En d'autres termes, le mécanisme de mise à jour DOIT préserver les données privées et partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.
[C-0-3] L'intégralité de la mise à jour DOIT être signée, et le mécanisme de mise à jour sur l'appareil DOIT vérifier la mise à jour et la signature par rapport à une clé publique stockée sur l'appareil.
[C-SR] Il est FORTEMENT RECOMMANDÉ que le mécanisme de signature hache la mise à jour avec SHA-256 et valide le hachage par rapport à la clé publique à l'aide d'ECDSA NIST P-256.

Si les implémentations d'appareils incluent la prise en charge d'une connexion de données illimitée telle que le profil 802.11 ou Bluetooth PAN (Personal Area Network), elles :

[C-1-1] DOIT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Pour les implémentations d'appareils lancées avec Android 6.0 et versions ultérieures, le mécanisme de mise à jour DOIT permettre de vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur des blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT être compatibles avec les mises à jour système A/B. L'AOSP implémente cette fonctionnalité à l'aide du HAL de contrôle du démarrage.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais pendant sa durée de vie raisonnable déterminée en concertation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces :

[C-2-1] L'intégrateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée selon le mécanisme décrit ci-dessus.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, cela signifie que :

[C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications des documents

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version :

Journal des modifications des documents

Pour obtenir un résumé des modifications apportées aux sections concernant les particuliers :

12.1. Conseils pour consulter le journal des modifications

Les modifications sont indiquées comme suit :

CDD
Modifications importantes apportées aux exigences de compatibilité.
Docs
Modifications esthétiques ou liées à la compilation.

Pour une expérience optimale, ajoutez les paramètres d'URL pretty=full et no-merges à vos URL de journaux des modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler tout problème qui, selon vous, n'est pas abordé dans le document.

Définition de la compatibilité avec Android 11 Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

1. Introduction

1.1 Structure du document

1.1.1. Exigences par type d'appareil

1.1.2. ID de l'exigence

1.1.3. ID de l'exigence dans la section 2

2. Types d'appareils

2.1 Configurations de l'appareil

2.2. Exigences concernant les appareils mobiles

2.2.1. Matériel

2.2.2. Multimédia

2.2.3. Logiciel

2.2.4. Performances et puissance

2.2.5. Modèle de sécurité

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

2.2.7 Classe de performances multimédias pour les appareils portables

2.2.7.1. Contenus multimédias

2.2.7.2. Appareil photo

2.2.7.3. Matériel

2.2.7.4. Performances

2.3. Exigences concernant le téléviseur

2.3.1. Matériel

2.3.2. Multimédia

2.3.3. Logiciel

2.3.4. Performances et puissance

2.3.5. Modèle de sécurité

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

2.4. Configuration requise pour la montre

2.4.1. Matériel

2.4.2. Multimédia

2.4.3. Logiciel

2.4.4. Performances et puissance

2.4.5. Modèle de sécurité

2.5. Exigences pour le secteur automobile

2.5.1. Matériel

2.5.2. Multimédia

2.5.3. Logiciel

2.5.4. Performances et puissance

2.5.5. Modèle de sécurité

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

2.6. Configuration requise pour les tablettes

2.6.1. Matériel

2.6.2. Modèle de sécurité

2.6.2. Logiciel

3. Logiciel

3.1. Compatibilité des API gérées

3.1.1. Extensions Android

3.1.2. Bibliothèque Android

3.2. Compatibilité logicielle avec les API

3.2.1. Autorisations

3.2.2. Créer des paramètres

3.2.3. Compatibilité des intents

3.2.3.1. Intents d'application courants

3.2.3.2. Résolution des intents

3.2.3.3. Espaces de noms d'intent

3.2.3.4. Intents de diffusion

3.2.3.5. Intents d'application conditionnels

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

3.3. Compatibilité avec les API natives

3.3.1. Interfaces binaires d'application

3.3.2. Compatibilité du code natif ARM 32 bits

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

3.4.2. Compatibilité du navigateur

3.5. Compatibilité comportementale de l'API

3.5.1. Restriction d'application

3.6. Espaces de noms de l'API

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

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur d'applications (écran d'accueil)

3.8.2. Widgets

3.8.3. Notifications

3.8.3.1. Présentation des notifications

3.8.3.2. Service d'écoute des notifications

3.8.3.3. NPD (Ne pas déranger)

3.8.4. Recherche

3.8.5. Alertes et toasts

3.8.6. Thèmes

3.8.7. Fonds d'écran animés

3.8.8. Changement d'activité

Définition de la compatibilité avec Android 11