Définition de compatibilité Android 9

1. Introduction

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

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

Dans ce document, un "outil de mise en œuvre d'appareil" est une personne ou une organisation qui développe une solution matérielle/logicielle sous Android 9. Une « implémentation d'appareil » ou « implémentation » est la solution matérielle/logicielle ainsi développée.

Pour être considérées comme compatibles avec Android 9, les implémentations d'appareils DOIVENT respecter les exigences présentées dans la présente Définition de compatibilité, y compris tout document intégré via une référence.

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

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

La plupart des ressources mentionnées dans ce document proviennent directement ou indirectement du SDK Android. D'un point de vue fonctionnel, elles sont identiques aux informations contenues dans la documentation de ce SDK. En cas de désaccord entre cette définition de compatibilité ou la suite de tests de compatibilité avec la documentation du SDK, celle-ci fait autorité. Tous les détails techniques fournis dans les ressources ci-dessous de ce document sont considérés comme faisant partie de la présente Définition de compatibilité.

1.1 Structure du document

1.1.1. Exigences par type d'appareil

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

Toutes les autres exigences, qui s'appliquent universellement à l'ensemble des implémentations d'appareils Android, sont énumérées dans les sections qui suivent la section 2. Ces exigences sont référencées sous le terme "Exigences principales" dans ce document.

1.1.2. Identifiant du prérequis

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

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

Chaque ID est défini comme suit:

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

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

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

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

2. Types d'appareils

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

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

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

2.1 Configurations des appareils

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

2.2. Configuration requise pour les appareils portables

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

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

• Disposer d'une source d'alimentation qui permet la mobilité, telle qu'une batterie.
• La diagonale de l'écran doit être comprise entre 2,5 et 8 pouces.

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

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

2.2.1. Matériel

Implémentations pour les appareils portables:

• [7.1.1.1/H-0-1] DOIT disposer d'un écran d'au moins 2,5 pouces en diagonale.
• [7.1.1.3/H-SR] SONT FORTEMENT RECOMMANDÉS de fournir aux utilisateurs l' affordance de modifier la taille d'affichage.(Densité d'écran)

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

• [7.1.4.5/H-1-1] DOIT faire la promotion des extensions EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace et VK_EXT_hdr_metadata.

Implémentations pour les appareils portables:

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

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

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

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

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

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

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

Implémentations pour les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

2.2.2. Multimédia

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

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

Les implémentations d'appareils portables DOIVENT prendre en charge le décodage audio suivant:

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

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

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

Les implémentations d'appareils portables DOIVENT prendre en charge le décodage vidéo suivant:

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

2.2.3. Logiciels

Implémentations pour les appareils portables:

• [3.2.3.1/H-0-1] DOIT disposer d'une application qui gère les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE et ACTION_CREATE_DOCUMENT comme décrit dans les documents du SDK, et fournir à l'utilisateur l'allocation d'accès aux données du fournisseur de documents via l'API DocumentsProvider.
• [3.4.1/H-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.
• [3.4.2/H-0-1] DOIT inclure une application de navigateur autonome pour la navigation Web de l'utilisateur standard.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut compatible avec l'épinglage des raccourcis, des widgets et des widgetFeatures dans l'application.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un lanceur d'applications par défaut qui permet d'accéder rapidement aux raccourcis supplémentaires fournis par les applications tierces via l'API ShortcutManager.
• [3.8.1/H-SR] Il est FORTEMENT RECOMMANDÉ d'inclure une application de lancement par défaut qui affiche les badges correspondant aux icônes des applications.
• [3.8.2/H-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge les widgets d'applications tierces.
• [3.8.3/H-0-1] DOIT autoriser les applications tierces à avertir les utilisateurs d'événements importants via les classes d'API Notification et NotificationManager.
• [3.8.3/H-0-2] DOIT prendre en charge les notifications enrichies.
• [3.8.3/H-0-3] DOIT prendre en charge les notifications prioritaires.
• [3.8.3/H-0-4] DOIT inclure un volet des notifications, permettant à l'utilisateur de contrôler directement les notifications (par exemple, répondre, répéter, ignorer ou bloquer) les notifications par le biais des affordances de l'utilisateur telles que des boutons d'action ou le panneau de configuration, comme implémenté dans l'AOSP.
• [3.8.3/H-0-5] DOIT afficher les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher le premier choix fourni via RemoteInput.Builder setChoices() dans le volet des notifications sans intervention supplémentaire de l'utilisateur.
• [3.8.3/H-SR] Il est FORTEMENT RECOMMANDÉ d'afficher toutes les options fournies via RemoteInput.Builder setChoices() dans le volet des notifications lorsque l'utilisateur développe toutes les notifications dans ce volet.
• [3.8.4/H-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter un assistant sur l'appareil pour gérer l'action d'assistance.

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

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

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

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

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

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

Implémentations pour les appareils portables:

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

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

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

Performances et puissance

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

Implémentations pour les appareils portables:

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

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

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

Implémentations pour les appareils portables:

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

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

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

Modèle de sécurité

Implémentations pour les appareils portables:

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

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

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

2.3. Configuration requise pour la télévision

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

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

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

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

Matériel

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

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

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

Pour les téléviseurs 32 bits:

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

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

Pour les téléviseurs 64 bits:

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

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

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

Implémentations pour les téléviseurs:

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

2.3.2. Multimédia

Les installations de télévision DOIVENT prendre en charge les formats d'encodage audio suivants:

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

Les téléviseurs DOIVENT prendre en charge les formats d'encodage vidéo suivants:

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

Implémentations pour les téléviseurs:

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

Les implémentations de téléviseurs DOIVENT prendre en charge les formats de décodage vidéo suivants:

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

Il est FORTEMENT RECOMMANDÉ d'implémenter un téléviseur pour prendre en charge les formats de décodage vidéo suivants:

• [5.3.1/T-SR] MPEG-2

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

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

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

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

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

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

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

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

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

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

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

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

Implémentations pour les téléviseurs:

• [5.5.3/T-0-1] DOIT inclure la prise en charge du volume principal du système et de l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie audio compressée passthrough (où aucun décodage audio n'est effectué sur l'appareil).
• [5.8/T-0-1] DOIT définir le mode de sortie HDMI de manière à sélectionner la résolution maximale compatible avec une fréquence d'actualisation de 50 Hz ou de 60 Hz pour tous les écrans filaires.
• [5.8/T-SR] Il est FORTEMENT RECOMMANDÉ de fournir un sélecteur de fréquence d'actualisation HDMI configurable par l'utilisateur pour tous les écrans filaires.
• [5.8/T-SR] SONT VIVEMENT RECOMMANDÉS de prendre en charge le décodage simultané de flux sécurisés. Au minimum, le décodage simultané de deux flux est FORTEMENT RECOMMANDÉ.
• [5.8] DEVRAIT définir la fréquence d'actualisation du mode de sortie HDMI sur 50 Hz ou 60 Hz, en fonction de la fréquence d'actualisation vidéo pour la région où l'appareil est vendu pour tous les écrans filaires.

Si les téléviseurs sont compatibles avec le décodage UHD et les écrans externes, ils:

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

Si les téléviseurs ne prennent pas en charge le décodage UHD, mais sont compatibles avec les écrans externes, ils:

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

Logiciels

Implémentations pour les téléviseurs:

• [3/T-0-1] DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television.
• [3.4.1/T-0-1] DOIT fournir une implémentation complète de l'API android.webkit.Webview.

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

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

Implémentations pour les téléviseurs:

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

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

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

Implémentations pour les téléviseurs:

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

Performances et puissance

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

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

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

Implémentations pour les téléviseurs:

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

2.4. Configuration requise pour la montre

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

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

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

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

Matériel

Implémentations sur les montres:

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

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

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

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

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

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

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

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

• [7.8.2/W] PEUT, mais NE DEVRAIT PAS disposer d'une sortie audio.

Multimédia

Aucune exigence supplémentaire.

Logiciels

Implémentations sur les montres:

• [3/W-0-1] DOIT déclarer la fonctionnalité android.hardware.type.watch.
• [3/W-0-2] DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH.

Implémentations sur les montres:

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

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

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

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

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

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

Performances et puissance

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

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

Implémentations sur les montres:

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

2.5. Exigences concernant l'automobile

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

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

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

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

Matériel

Implémentations pour les appareils automobiles:

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils automobiles:

• [7.3.11/A-0-1] DOIT fournir l'équipement actuel au format SENSOR_TYPE_GEAR.

Implémentations pour les appareils automobiles:

• [7.3.11.2/A-0-1] DOIT prendre en charge le mode Jour/Nuit défini sur SENSOR_TYPE_NIGHT.
• [7.3.11.2/A-0-2] La valeur de l'indicateur SENSOR_TYPE_NIGHT DOIT être cohérente avec le mode Jour/Nuit du tableau de bord et DOIT être basée sur l'entrée du capteur de luminosité ambiante.

• Le capteur de luminosité ambiante sous-jacent PEUT être le même que le photomètre.

• [7.3.11.4/A-0-1] DOIT indiquer la vitesse du véhicule telle que définie dans le fichier SENSOR_TYPE_CAR_SPEED.

• [7.3.11.5/A-0-1] DOIT indiquer l'état du frein à main, tel que défini dans le document SENSOR_TYPE_PARKING_BRAKE.

• [7.4.3/A-0-1] DOIT être compatible avec Bluetooth et Bluetooth LE.

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

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

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

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

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

Implémentations pour les appareils automobiles:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

Implémentations pour les appareils automobiles:

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

2.5.2. Multimédia

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

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

Les implémentations d'appareils automobiles DOIVENT prendre en charge l'encodage vidéo suivant:

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

Les implémentations d'appareils automobiles DOIVENT prendre en charge le décodage vidéo suivant:

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

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

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

Logiciels

Implémentations pour les appareils automobiles:

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

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

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

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

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

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

• [3.13/A-SR] Il est FORTEMENT RECOMMANDÉ d'inclure un composant d'interface utilisateur "Réglages rapides".

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

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

Implémentations pour les appareils automobiles:

• [3.14/A-0-1] DOIT inclure un framework d'interface utilisateur compatible avec les applications tierces utilisant les API multimédias, comme décrit dans la section 3.14.

Performances et puissance

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

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

Implémentations pour les appareils automobiles:

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

2.5.5. Modèle de sécurité

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

• [9.5/A-1-1] DOIT inclure un compte invité permettant toutes les fonctionnalités fournies par le système du véhicule sans que l'utilisateur ait à se connecter.

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

• [9.9.2/A-1-1] DOIT prendre en charge le chiffrement par clé d'authentification spécifique à l'utilisateur. Le chiffrement basé sur les fichiers (FBE) est une façon de procéder.

Implémentations pour les appareils automobiles:

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

2.6. Configuration requise pour les tablettes

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

• Généralement utilisé en tenant l'appareil dans les deux mains.
• Elle ne dispose pas d'un ordinateur à clapet ni d'une configuration convertible.
• Toute implémentation de clavier physique utilisée avec l'appareil DOIT se connecter au moyen d'une connexion standard.
• dispose d'une source d'alimentation qui permet de la mobilité, telle qu'une batterie ;
• possède une diagonale d'écran comprise entre 7 et 18 pouces.

Les implémentations de tablettes ont des exigences similaires à celles des implémentations d’appareils portables. Les exceptions sont indiquées par et * dans cette section, à titre indicatif.

Matériel

Taille de l'écran

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

Mémoire et stockage minimaux (section 7.6.1)

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

Mode périphérique USB (section 7.7.1)

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

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

Mode de réalité virtuelle (section 7.9.1)

Réalité virtuelle hautes performances (section 7.9.2)

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

3. Logiciels

3.1. Compatibilité des API gérées

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

Implémentations pour les appareils:

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

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

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

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

• [C-0-5] DOIT restreindre l'utilisation d'API cachées par des applications tierces, définies en tant qu'API dans l'espace de noms Android décoré avec l'annotation @hidden, mais pas avec l'annotation @SystemAPI ou @TestApi, comme décrit dans les documents du SDK. Chaque API cachée doit figurer sur les mêmes listes restreintes que celles fournies via la liste provisoire et les fichiers de liste de blocage dans le chemin prebuilts/runtime/appcompat/ pour la branche de niveau d'API appropriée dans l'AOSP. Cependant, ils:

  • PEUT-ÊTRE, si une API masquée est absente ou implémentée différemment sur l'appareil, déplacez-la dans la liste de blocage ou omettez-la de toutes les listes restreintes.
  • PEUT-ÊTRE, si une API masquée n'existe pas déjà dans l'AOSP, ajoutez-la à l'une des listes restreintes.
  • PEUVENT implémenter un mécanisme de mise à jour dynamique qui déplace une API masquée d'une liste restreinte vers une liste moins restrictive, à l'exception de la liste d'autorisation.

3.1.1. Extensions Android

Android permet d'étendre les API gérées tout en conservant la même version du niveau d'API.

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

3.1.2. Bibliothèque Android

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

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

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

3.2. Compatibilité avec les API soft

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

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

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

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

Compatibilité des intents

Intents d'application principaux

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

• [C-0-1] Les implémentations d'appareils DOIVENT précharger un ou plusieurs composants d'applications ou de services avec un gestionnaire d'intent, pour tous les modèles de filtres d'intent public définis par les principales applications Android suivantes dans AOSP:

  • Horloge de bureau
  • Navigateur
  • Agenda
  • Contacts
  • Galerie
  • Recherche globale
  • Lanceur d'applications
  • Musique
  • Paramètres

Résolution d'intent

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

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

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

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

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

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

Espaces de noms des intents

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

Intents de diffusion

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

Implémentations pour les appareils:

• [C-0-1] DOIT diffuser les intents de diffusion publique en réponse aux événements système appropriés, comme décrit dans la documentation du SDK. Notez que cette exigence n'est pas en conflit avec la section 3.5, car la limitation applicable aux applications en arrière-plan est également décrite dans la documentation du SDK.

Paramètres d'application par défaut

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

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

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

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

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

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

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

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

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

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

• [C-3-1] DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS à afficher un menu de paramètres par défaut de l'application pour le paiement sans contact.

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

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

Activités sur les écrans secondaires

Si les implémentations d'appareils permettent le lancement d'activités Android normales sur les écrans secondaires:

• [C-1-1] DOIT définir le flag de fonctionnalité android.software.activities_on_secondary_displays.
• [C-1-2] DOIT garantir la compatibilité de l'API de la même manière qu'une activité exécutée sur l'écran principal.
• [C-1-3] DOIT envoyer la nouvelle activité sur le même écran que l'activité qui l'a lancée lorsque la nouvelle activité est lancée sans spécifier d'écran cible via l'API ActivityOptions.setLaunchDisplayId().
• [C-1-4] DOIT détruire toutes les activités lorsqu'un écran avec l'indicateur Display.FLAG_PRIVATE est supprimé.
• [C-1-5] DOIT redimensionner en conséquence toutes les activités sur un VirtualDisplay si l'écran lui-même est redimensionné.
• PEUT afficher un éditeur de mode de saisie (IME, une commande permettant aux utilisateurs de saisir du texte) sur l'écran principal lorsqu'un champ de saisie est sélectionné sur un écran secondaire.
• DEVRAIT implémenter la sélection de la saisie sur l'écran secondaire indépendamment de l'écran principal, lorsque la saisie tactile ou au clavier est possible.
• DEVRAIT avoir android.content.res.Configuration correspondant à cet écran pour s'afficher, fonctionner correctement et assurer la compatibilité si une activité est lancée sur un écran secondaire.

Si les implémentations sur les appareils permettent de lancer des activités Android normales sur les écrans secondaires, et que les android.util.DisplayMetrics sont différents pour les écrans principal et secondaire:

• [C-2-1] Les activités non redimensionnables (qui comportent resizeableActivity=false dans AndroidManifest.xml) et les applications ciblant le niveau d'API 23 ou inférieur NE DOIVENT PAS être autorisées sur les écrans secondaires.

Si les implémentations d'appareils autorisent le lancement des activités Android normales sur des écrans secondaires et que celui-ci comporte l'indicateur android.view.Display.FLAG_PRIVATE:

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

3.3. Compatibilité avec les API natives

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

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

3.3.1. Interfaces binaires d'application

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

Implémentations pour les appareils:

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

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

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (compatibilité native avec AAudio)

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

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

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

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

3.3.2. Compatibilité avec le code natif ARM 32 bits

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

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

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

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

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

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

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

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

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

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

• [C-1-1] DOIT signaler android.software.webview.
• [C-1-2] DOIT utiliser la version du projet Chromium du projet Android Open Source en amont sur la branche Android 9 pour l'implémentation de l'API android.webkit.WebView.

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

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

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

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

Compatibilité du navigateur

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

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

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

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

3.5. Compatibilité comportementale de l'API

Implémentations pour les appareils:

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

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

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

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

3.5.1. Restriction d'arrière-plan

Si les implémentations d'appareils implémentent les restrictions d'application incluses dans AOSP ou étendent les restrictions d'application, elles:

• [C-SR] SONT FORTEMENT RECOMMANDÉS de fournir à l'utilisateur l' affordance de consulter la liste des applications dont l'accès est limité.
• [C-1-2] DOIT fournir une affordance à l'utilisateur pour activer / désactiver les restrictions sur chaque application.
• [C-1-3] NE DOIT PAS appliquer automatiquement de restrictions sans preuve d'un mauvais comportement du système, mais PEUVENT appliquer les restrictions aux applications en cas de détection d'un comportement médiocre du système, comme les wakelocks figés, les services de longue durée et d'autres critères. Les critères PEUVENT être déterminés par les responsables de la mise en œuvre de l'appareil, mais DOIVENT être liés à l'impact de l'application sur l'état du système. D'autres critères qui ne sont pas uniquement liés à l'état du système, tels que le manque de popularité de l'application sur le marché, NE DOIVENT PAS être utilisés comme critères.
• [C-1-4] NE DOIT PAS appliquer automatiquement des restrictions aux applications lorsqu'un utilisateur les désactive manuellement, et PEUT suggérer à l'utilisateur d'appliquer des restrictions d'application.
• [C-1-5] DOIT informer les utilisateurs si des restrictions sont appliquées automatiquement à une application.
• [C-1-6] DOIT renvoyer true pour ActivityManager.isBackgroundRestricted() lorsque l'application dont l'accès est limité appelle cette API.
• [C-1-7] NE DOIT PAS limiter l'application au premier plan qui est explicitement utilisée par l'utilisateur.
• [C-1-8] DOIT suspendre les restrictions appliquées à une application qui devient l'application de premier plan lorsque l'utilisateur commence explicitement à utiliser l'application qui était auparavant restreinte.

3.6. Espaces de noms de l'API

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

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

En d'autres termes, ils:

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

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

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

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

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

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

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

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

Implémentations pour les appareils:

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

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

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

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

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

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

3.8. Compatibilité de l'interface utilisateur

Lanceur d'applications (écran d'accueil)

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

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

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

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

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

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

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

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

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

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

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

Widgets

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

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

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

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

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

3.8.3. Notifications

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

Présentation des notifications

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

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

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

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

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

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

Service d'écoute des notifications

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

Si les implémentations d'appareils signalent l'indicateur de fonctionnalité android.hardware.ram.normal:

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

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

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

Ne pas déranger

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

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

3.8.4. Rechercher

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

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

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

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

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

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

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

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

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

Alertes et toasts

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

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

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

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

3.8.6. Thèmes

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

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

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

• [C-1-1] NE DOIT PAS modifier les attributs du thème Holo associés aux applications.
• [C-1-2] DOIT être compatible avec la famille de thèmes "Material" et NE DOIT PAS modifier les attributs du thème Material ni leurs éléments exposés aux applications.

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

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

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

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

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

3.8.7. Fonds d'écran animés

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

Le matériel est considéré comme capable d'exécuter de manière fiable des fonds d'écran animés s'il peut diffuser tous les fonds d'écran animés, sans limitation de fonctionnalité, à une fréquence d'images raisonnable sans aucun effet négatif sur les autres applications. Si les limitations du matériel entraînent le plantage, le dysfonctionnement des fonds d'écran et/ou des applications, une utilisation excessive du processeur ou de la batterie, ou une fréquence d'images trop faible, le matériel est considéré comme incapable d'exécuter des fonds d'écran animés. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécutera pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL. En effet, l'utilisation d'un fond d'écran animé avec un contexte OpenGL peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

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

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

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

3.8.8. Changement d'activité

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

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

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

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

3.8.9. Gestion des entrées

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

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

• [C-1-1] DOIT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME telles que définies dans la documentation du SDK Android.
• [C-1-2] DOIT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des modes de saisie tiers en réponse à l'intent android.settings.INPUT_method_SETTINGS.

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

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

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

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

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

Android est compatible avec les économiseurs d'écran interactifs, auparavant appelés "Rêves". Les économiseurs d'écran permettent aux utilisateurs d'interagir avec les applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou sur une station d'accueil de bureau. Les montres Android PEUVENT implémenter des économiseurs d'écran, mais d'autres types d'implémentations DOIVENT inclure la prise en charge des économiseurs d'écran et fournir aux utilisateurs une option permettant de les configurer en réponse à l'intent android.settings.DREAM_SETTINGS.

3.8.12. Position

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

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

3.8.13. Unicode et police

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

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

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

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

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

3.8.14. Multifenêtre

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

• [C-1-1] DOIT implémenter ce ou ces modes multifenêtres conformément aux comportements d'application et aux API décrits dans la documentation de prise en charge du mode multifenêtre du SDK Android, et respecter les exigences suivantes:
• [C-1-2] Les applications peuvent indiquer si elles peuvent fonctionner en mode multifenêtre dans le fichier AndroidManifest.xml, soit explicitement en définissant l'attribut android:resizeableActivity sur true, soit implicitement en définissant targetSdkVersion > 24. Les applications qui définissent explicitement cet attribut sur false dans leur fichier manifeste NE DOIVENT PAS être lancées en mode multifenêtre. Les anciennes applis avec targetSdkVersion < 24 et qui n'ont pas défini cet attribut android:resizeableActivity PEUVENT être lancées en mode multifenêtre, mais le système DOIT avertir le système que l'appli peut ne pas fonctionner comme prévu en mode multifenêtre.
• [C-1-3] NE DOIT PAS proposer le mode Écran partagé ou Format libre si la hauteur de l'écran est inférieure à 440 dp et sa largeur est inférieure à 440 dp.
• Les implémentations d'appareils avec une taille d'écran xlarge DEVRAIT prendre en charge le mode Format libre.

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

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

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

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

3.8.15. Découpe de l'écran

Android prend en charge une découpe d'affichage comme décrit dans le document du SDK. L'API DisplayCutout définit une zone située sur le bord de l'écran qui n'est pas fonctionnelle pour afficher du contenu.

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

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

3.9. Gestion de l'appareil

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

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

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

3.9.1 Préparation des appareils

3.9.1.1 Configuration du propriétaire de l'appareil

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

• [C-1-1] DOIT prendre en charge l'enregistrement d'un client Device Policy (DPC) en tant qu'application propriétaire de l'appareil, comme décrit ci-dessous :
  • Si aucune donnée utilisateur n'est encore configurée pour la mise en œuvre de l'appareil, 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 du propriétaire de l'appareil en réponse à l'action d'intent android.app.action.PROVISION_MANAGED_DEVICE.
    • [C-1-5] DOIT enregistrer l'application DPC en tant qu'application Propriétaire de l'appareil si l'appareil déclare la compatibilité NFC (communication en champ proche) via le flag de fonctionnalité android.hardware.nfc et reçoit un message NFC contenant un enregistrement de type MIME MIME_TYPE_PROVISIONING_NFC.
  • Lorsque l'implémentation de l'appareil dispose de données utilisateur, elle :
    • [C-1-6] DOIT signaler false pour DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE).
    • [C-1-7] NE DOIT PAS enregistrer d'application DPC en tant qu'application du propriétaire de l'appareil.
• [C-1-2] DOIT exiger une action positive au cours du processus de provisionnement pour que l'application soit définie comme propriétaire de l'appareil. Le consentement peut être obtenu via une action de l'utilisateur ou par un moyen programmatique lors du provisionnement, mais il NE DOIT PAS être codé en dur 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 propriétaire de gestion des propriétaires d'appareils et fournissent un mécanisme permettant de promouvoir une application configurée dans leur solution en tant que "Propriétaire de l'appareil équivalent" au "Propriétaire de l'appareil" standard tel qu'il est reconnu par les API DevicePolicyManager Android standards, les conditions suivantes doivent être réunies:

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

3.9.1.2 Provisionnement des profils gérés

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

• [C-1-1] DOIT implémenter les API permettant à une application de contrôle des règles relatives aux appareils (DPC) de devenir le propriétaire d'un nouveau profil géré.

• [C-1-2] Le processus de provisionnement du profil géré (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE) DOIT être aligné sur l'implémentation d'AOSP.

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

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

3.9.2 Prise en charge des profils gérés

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

• [C-1-1] DOIT prendre en charge les profils gérés via les API android.app.admin.DevicePolicyManager.
• [C-1-2] DOIT autoriser la création d'un seul profil géré.
• [C-1-3] DOIT utiliser un badge d'icône (semblable au badge professionnel en amont AOSP) pour représenter les applications et widgets gérés, ainsi que les autres éléments d'interface utilisateur dotés d'un badge tels que les applications récentes et les notifications.
• [C-1-4] DOIT afficher une icône de notification (semblable au badge professionnel en amont AOSP) pour indiquer que l'utilisateur se trouve dans une application de profil géré.
• [C-1-5] DOIT afficher un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se met en marche (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
• [C-1-6] Lorsqu'un profil géré existe, DOIT afficher une affordance visuelle dans le sélecteur d'intent pour permettre à l'utilisateur de transférer l'intent du profil géré à l'utilisateur principal, ou inversement, s'il est activé par l'outil de contrôle des règles relatives aux appareils.
• [C-1-7] Lorsqu'un profil géré existe, DOIT exposer les affordances d'utilisateur suivantes pour l'utilisateur principal et le profil géré :
  • Les données sont séparées pour l'utilisation de la batterie, de l'emplacement, des données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées dans le profil utilisateur principal ou le profil géré
  • Gestion indépendante des applications installées dans l'utilisateur principal ou le profil géré
  • Gestion indépendante des comptes au sein de l'utilisateur principal ou du profil géré.
• [C-1-8] DOIT s'assurer que le clavier, les contacts et les applications de messagerie préinstallés peuvent rechercher et consulter des informations sur l'appelant dans le profil géré (le cas échéant) en plus de celles du profil principal, si l'outil de contrôle des règles relatives aux appareils le permet.
• [C-1-9] DOIT s'assurer qu'il satisfait à toutes les exigences de sécurité applicables à un appareil sur lequel plusieurs utilisateurs sont activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un utilisateur supplémentaire en plus de l'utilisateur principal.
• [C-1-10] DOIT prendre en charge la possibilité de spécifier un écran de verrouillage distinct répondant aux exigences suivantes pour accorder l'accès aux applications exécutées dans un profil géré.
  • Les implémentations d'appareils DOIVENT respecter l'intent DevicePolicyManager.ACTION_SET_NEW_PASSWORD et afficher une interface permettant de configurer des identifiants d'écran de verrouillage distincts pour le profil géré.
  • Les identifiants de l'écran de verrouillage du profil géré DOIVENT utiliser les mêmes mécanismes de stockage et de gestion des identifiants que le profil parent, comme indiqué sur le site du projet Android Open Source.
  • Les règles de mot de passe de l'outil DPC DOIVENT s'appliquer uniquement aux identifiants de l'écran de verrouillage du profil géré, sauf si elles sont appelées sur l'instance DevicePolicyManager renvoyée par getParentProfileInstance.
• Lorsque les contacts du profil géré sont affichés dans le journal d'appels préinstallé, l'interface utilisateur de l'appel, les notifications d'appels en cours et manqués, les contacts et les applications de chat, ils DOIVENT porter le même badge que celui utilisé pour indiquer les applications du profil géré.

3.9.3 Assistance aux utilisateurs gérés

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

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

3.10. Accessibilité

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

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

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

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

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

3.11. Synthèse vocale

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

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

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

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

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

3.12. Framework d'entrée TV

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

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

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

3.13. Réglages rapides

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

Si les implémentations d'appareils incluent un composant d'interface utilisateur Réglages rapides, elles:

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

3.14. Interface utilisateur multimédia

Si les implémentations d'appareils incluent le framework d'interface utilisateur compatible avec les applications tierces qui dépendent de MediaBrowser et de MediaSession , elles:

• [C-1-1] DOIT afficher les icônes MediaItem et les icônes de notification telles quelles.
• [C-1-2] DOIT afficher ces éléments comme décrit par MediaSession (métadonnées, icônes, images, etc.).
• [C-1-3] DOIT afficher le titre de l'application.
• [C-1-4] DOIT disposer d'un panneau ou d'un autre mécanisme pour présenter la hiérarchie MediaBrowser et fournir une affordance utilisateur pour la hiérarchie MediaBrowser.
• [C-1-5] DOIT considérer le fait d'appuyer deux fois sur KEYCODE_HEADSETHOOK ou KEYCODE_MEDIA_PLAY_PAUSE comme étant KEYCODE_MEDIA_NEXT pour MediaSession.Callback#onMediaButtonEvent.

3.15. Applis instantanées

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

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

3.16. Association d'un appareil associé

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

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

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

3.17. Applications lourdes

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

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

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

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

4. Compatibilité avec les packages d'applications

Implémentations pour les appareils:

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

Implémentations pour les appareils:

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

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

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

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

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

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

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

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

5. Compatibilité multimédia

Implémentations pour les appareils:

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

Implémentations pour les appareils:

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

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

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

5.1. Codecs multimédias

5.1.1. Encodage audio

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

Si les intégrations d'appareils déclarent android.hardware.microphone, ils DOIVENT prendre en charge l'encodage audio suivant:

• [C-1-1] PCM/WAVE

5.1.2. Décodage audio

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

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

• [C-1-1] Profil MPEG-4 AAC (AAC LC)
• [C-1-2] Profil MPEG-4 HE AAC (AAC+)
• [C-1-3] Profil MPEG-4 HE AACv2 (AAC+ amélioré)
• [C-1-4] AAC ELD (AAC à faible décalage amélioré)
• [C-1-11] xHE-AAC (profil HE AAC étendu ISO/IEC 23003-3, qui inclut le profil de référence USAC et le profil de contrôle de plage dynamique ISO/IEC 23003-4)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] MIDI
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE
• [C-1-10] Opus

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

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

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

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

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

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

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

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

5.1.3. Détails des codecs audio

Format/Codec	Détails	Types de fichiers/formats de conteneur acceptés
Profil MPEG-4 AAC (AAC LC)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (0,3gp) MPEG-4 (.mp4, .m4a) ADTS AAC bruts (.aac, ADIF non compatibles) MPEG-TS (.ts, impossible de rechercher)
Profil MPEG-4 HE AAC (AAC+)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
Profil MPEG-4 HE AACv2 (AAC+ amélioré)	Compatibilité avec le contenu mono/stéréo/5.0/5.1 avec des taux d'échantillonnage standards de 16 à 48 kHz.
AAC ELD (AAC à faible délai amélioré)	Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
USAC	Compatibilité avec les contenus mono/stéréo avec des taux d'échantillonnage standards de 7,35 à 48 kHz.	MPEG-4 (.mp4, .m4a)
AMR-NB	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (0,3gp)
AMR-WB	9 débits échantillonnés de 6,60 kbit/s à 23,85 kbit/s à 16 kHz
FLAC	Mono/stéréo (pas de canaux multicanaux). Taux d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz sont RECOMMANDÉS sur les appareils avec sortie 44,1 kHz, car le sous-échantillonneur de 48 à 44,1 kHz n'inclut pas de filtre passe bas). 16 bits RECOMMANDÉ ; aucun tramage appliqué pour 24 bits.	FLAC (.flac) uniquement
MP3	Constante CBR (Mono/Stéréo) de 8 à 320 kbit/s ou débit variable (VBR)	MP3 (.mp3)
MIDI	Type MIDI 0 et 1. DLS version 1 et 2. XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody	Type 0 et 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	PCM linéaire 16 bits (débits allant jusqu'à la limite du matériel). Les appareils DOIVENT prendre en charge les taux d'échantillonnage de l'enregistrement PCM brut aux fréquences 8 000, 11 025, 16 000 et 44 100 Hz.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. Encodage d'image

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

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

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

5.1.5. Décodage d'images

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

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

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] Brut
• [C-0-7] HEIF (HEIC)

5.1.6. Détails des codecs image

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

5.1.7. Codecs vidéo

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

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

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

• [C-1-2] Les encodeurs et décodeurs vidéo DOIVENT prendre en charge le format de couleur flexible YUV420 (COLOR_FormatYUV420Flexible).

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

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

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

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

5.1.8. Liste des codecs vidéo

Format/Codec	Détails	Types de fichiers compatibles/ Formats de conteneur
H.263		3GPP (0,3gp) MPEG-4 (.mp4)
H.264 AVC	Pour en savoir plus, consultez les sections 5.2 et 5.3.	3GPP (0,3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, audio AAC uniquement, recherche impossible, Android 3.0 ou version ultérieure)
HEVC H.265	Pour en savoir plus, consultez la section 5.3.	MPEG-4 (.mp4)
MPEG-2	Main Profile	MPEG2-TS
MPEG-4 SP		3GPP (0,3gp)
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.2. Encodage vidéo

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

• DEVRAIT prendre en charge l'écriture de fichiers Matroska WebM.

5.3. Décodage vidéo

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

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

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

• [C-2-1] DOIT fournir un extracteur compatible Dolby Vision.
• [C-2-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-2-3] DOIT définir l'index de piste des couches de base rétrocompatibles (le cas échéant) de sorte qu'ils soient identiques à ceux de la couche Dolby Vision combinée.

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

5.4. Enregistrement audio

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

5.4.1. Capture audio brute

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

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

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

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

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

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

  • Format: PCM linéaire 16 bits
  • Taux d'échantillonnage: 22 050, 48 000 Hz
  • Canaux: stéréo

Si les implémentations d'appareils permettent une capture radio AM et DVD de qualité du contenu audio brut, elles:

• [C-2-1] DOIT effectuer une capture sans suréchantillonnage à un ratio supérieur à 16 000:22050 ou 44 100:48 000.
• [C-2-2] DOIT inclure un filtre d'anticrénelage approprié pour tout sur-échantillonnage ou sous-échantillonnage.

5.4.2. Capturer pour la reconnaissance vocale

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

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

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

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

5.4.3. Capturer pour réacheminer la lecture

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

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

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

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

5.5. Lecture audio

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

5.5.1. Lecture audio brute

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

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

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

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

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

5.5.2. Effets audio

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

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

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

5.5.3. Volume de sortie audio

Implémentations pour les appareils automobiles:

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

5.6. Latence audio

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

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

• latence de sortie. Intervalle entre le moment où une application écrit une trame de données codées PCM et le moment où le son correspondant est présenté à l'environnement par un transducteur sur l'appareil ou un signal qui quitte l'appareil via un port et peut être observé en externe.
• latence de sortie à froid. Latence de sortie de la première trame, lorsque le système de sortie audio a été inactif et mis hors tension avant la requête.
• latence de sortie continue. Latence de sortie des frames suivants, une fois que l'appareil lit du contenu audio.
• la latence d'entrée. Intervalle entre le moment où un son est présenté par l'environnement à l'appareil au niveau d'un transducteur ou un signal sur l'appareil via un port et lorsqu'une application lit la trame correspondante de données codées PCM.
• perd input. Partie initiale d'un signal d'entrée inutilisable ou indisponible.
• latence d'entrée à froid. Somme du temps d'entrée perdu et de la latence d'entrée pour la première trame, lorsque le système d'entrée audio a été inactif et hors tension avant la requête.
• latence d'entrée continue. Latence d'entrée des trames suivantes pendant la capture audio par l'appareil.
• gigue de sortie à froid. La variabilité entre les mesures distinctes des valeurs de latence de sortie à froid.
• gigue d'entrée à froid. La variabilité entre les différentes mesures des valeurs de latence d'entrée à froid.
• la latence aller-retour continue. Somme de la latence d'entrée continue et de la latence de sortie continue, plus une période de tampon. La période de mise en mémoire tampon permet à l'application de traiter le signal, et le temps nécessaire à l'application pour atténuer la différence de phase entre les flux d'entrée et de sortie.
• API de file d'attente de tampon OpenSL ES PCM Ensemble d'API OpenSL ES liées au PCM dans le NDK Android.
• API audio native AAudio : Ensemble des API AAudio dans le NDK Android.
• Code temporel : Paire composée d'une position relative de trame dans un flux et du temps estimé où cette trame entre ou sort du pipeline de traitement audio sur le point de terminaison associé. Consultez également AudioTimestamp.

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

• [C-SR] Latence de sortie à froid de 100 millisecondes ou moins
• [C-SR] Latence de sortie continue inférieure ou égale à 45 millisecondes
• [C-SR] Réduire la gigue à la sortie à froid
• [C-SR] Le code temporel de sortie renvoyé par AudioTrack.getTimestamp et AAudioStream_getTimestamp est précis à +/- 1 ms.

Si les implémentations d'appareils répondent aux exigences ci-dessus, après tout étalonnage initial, lors de l'utilisation à la fois de la file d'attente de tampon OpenSL ES PCM et des API audio natives AAudio, pour une latence de sortie continue et une latence de sortie à froid sur au moins un périphérique de sortie audio compatible, les deux valeurs sont les suivantes:

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

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

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

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

• [C-SR] Latence d'entrée froide inférieure ou égale à 100 millisecondes.
• [C-SR] Latence d'entrée continue inférieure ou égale à 30 millisecondes.
• [C-SR] Latence aller-retour continue de 50 millisecondes ou moins.
• [C-SR] Réduisez la gigue à l'entrée à froid.
• [C-SR] Limite l'erreur dans les horodatages d'entrée, tels qu'ils sont renvoyés par AudioRecord.getTimestamp ou AAudioStream_getTimestamp, à +/- 1 ms.

5.7. Protocoles de réseau

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

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

• [C-1-1] DOIT prendre en charge tous les codecs et formats de conteneur requis dans la section 5.1 via HTTP(S).

• [C-1-2] DOIT prendre en charge les formats de segment multimédia indiqués dans le tableau ci-dessous par rapport au projet de protocole HTTP Live Streaming, version 7.

• [C-1-3] DOIT prendre en charge le profil audio vidéo RTP suivant et les codecs associés dans le tableau RTSP ci-dessous. Pour les exceptions, veuillez consulter les notes de bas de tableau de la section 5.1.

Formats des segments média

Formats de segment	Référence(s)	Compatibilité avec le codec requise
Flux de transport MPEG-2	ISO 13818	Codecs vidéo : H264 AVC MPEG-4 SP MPEG-2 Pour en savoir plus sur H264 AVC, MPEG2-4 SP et MPEG-2,consultez la section 5.1.3. Codecs audio: AAC Pour en savoir plus sur AAC et ses variantes, consultez la section 5.1.1.
AAC avec encadrement ADTS et balises ID3	ISO 13818-7	Consultez la section 5.1.1 pour en savoir plus sur AAC et ses variantes.
WebVTT	WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

Si les implémentations d'appareils prennent en charge la sortie vidéo sécurisée et les surfaces sécurisées, elles:

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

Si les implémentations d'appareils déclarent prendre en charge Display.FLAG_SECURE et le protocole d'affichage sans fil:

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

Si les implémentations d'appareils déclarent prendre en charge Display.FLAG_SECURE et les écrans externes filaires, elles:

• [C-3-1] DOIT prendre en charge HDCP 1.2 ou version ultérieure pour tous les écrans externes connectés via un port filaire accessible à l'utilisateur.

5.9. Interface numérique pour instruments de musique (MIDI)

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

• [C-1-1] DOIT prendre en charge MIDI sur tous les transports matériels compatibles MIDI pour lesquels il fournit une connectivité générique non-MIDI, lorsque ces transports sont:

  • Mode hôte USB, section 7.7
  • Mode périphérique USB, section 7.7
  • MIDI via Bluetooth LE agissant en tant que rôle central, section 7.4.3

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

5.10. Audio professionnel

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

• [C-1-1] DOIT signaler la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
• [C-1-2] DOIT présenter une latence audio aller-retour continue, telle que définie dans la section 5.6 Latence audio, DOIT être inférieure ou égale à 20 millisecondes et DOIT être inférieure ou égale à 10 millisecondes sur au moins un chemin pris en charge.
• [C-1-3] DOIT inclure un ou plusieurs ports USB compatibles avec les modes hôte USB et périphérique USB.
• [C-1-4] DOIT signaler la prise en charge de la fonctionnalité android.software.midi.
• [C-1-5] DOIT respecter les latences et la configuration audio USB requise à l'aide de la file d'attente de tampon PCM OpenSL ES et des API AAudio native audio.
• [SR] SONT FORTEMENT RECOMMANDÉS de fournir un niveau de performances constant du processeur lorsque le son est actif et que la charge du processeur varie. Il doit être testé à l'aide du commit SimpleSynth 1bd6391. L'application SimpleSynth doit être exécutée avec les paramètres ci-dessous et ne subir aucune sous-utilisation après 10 minutes :
  • Cycles de travail: 200 000
  • Charge variable: activée (cette option permet de basculer entre 100% et 10% de la valeur des cycles de travail toutes les deux secondes et est conçue pour tester le comportement du gouverneur de processeur)
  • Charge stabilisée: DÉSACTIVÉE
• DOIT minimiser les inexactitudes et les dérives de l'horloge audio par rapport à l'heure standard.
• DEVRAIT minimiser la dérive de l'horloge audio par rapport au CLOCK_MONOTONIC du processeur lorsque les deux sont actifs.
• DEVRAIT minimiser la latence audio par rapport aux transducteurs intégrés à l'appareil.
• DEVRAIT minimiser la latence audio sur l'audio numérique USB.
• DEVRAIT documenter les mesures de latence audio sur tous les chemins.
• DOIT réduire la gigue des temps d'entrée du rappel de fin de tampon audio, car cela affecte le pourcentage utilisable de la bande passante complète du processeur par le rappel.
• DEVRAIT ne fournir aucune sous-utilisation (sortie) ou dépassement (entrée) audio dans des conditions d'utilisation normale et avec une latence signalée.
• DEVRAIT ne fournir aucune différence de latence entre les canaux.
• DEVRAIT minimiser la latence moyenne MIDI sur tous les transports.
• DEVRAIT minimiser la variabilité de la latence MIDI en cas de charge (gigue) sur tous les transports.
• DEVRAIT fournir des horodatages MIDI précis pour tous les transports.
• DOIT minimiser le bruit du signal audio sur les transducteurs intégrés à l'appareil, y compris la période qui suit le démarrage à froid.
• DEVRAIT ne fournir aucune différence d'horloge audio entre les côtés d'entrée et de sortie des points de terminaison correspondants, lorsque les deux sont actifs. Exemples de points de terminaison correspondants : micro et haut-parleur de l'appareil, ou entrée et sortie du connecteur audio.
• DEVRAIT gérer les rappels d'achèvement du tampon audio pour les côtés d'entrée et de sortie des points de terminaison correspondants sur le même thread lorsque les deux sont actifs, et saisir le rappel de sortie immédiatement après le retour du rappel d'entrée. S'il n'est pas possible de gérer les rappels sur le même thread, entrez le rappel de sortie peu de temps après la saisie du rappel d'entrée pour permettre à l'application d'avoir une synchronisation cohérente des côtés d'entrée et de sortie.
• DEVRAIT minimiser la différence de phase entre la mise en mémoire tampon de l'audio HAL pour les côtés entrée et sortie des points de terminaison correspondants.
• DEVRAIT minimiser la latence tactile.
• DEVRAIT minimiser la variabilité de la latence tactile en cas de charge (gigue).
• DEVRAIT avoir une latence inférieure ou égale à 40 ms entre l'entrée tactile et la sortie audio.

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

• [SR] FORTEMENT RECOMMANDÉ de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager.

Si les appareils sont équipés d'un connecteur audio 3,5 mm à 4 conducteurs, ils:

• [C-2-1] DOIT présenter une latence audio aller-retour continue de 20 millisecondes ou moins sur le chemin du connecteur audio.
• [SR] VIVEMENT RECOMMANDÉ pour respecter la section Caractéristiques des appareils mobiles (connecteurs) des spécifications du casque audio filaire (v1.1).
• La latence audio aller-retour en continu DOIT être inférieure ou égale à 10 millisecondes sur le chemin du connecteur audio.

Si les appareils ne comprennent pas de connecteur audio 3, 5 mm à 4 conducteurs et incluent un ou plusieurs ports USB compatibles avec le mode hôte USB:

• [C-3-1] DOIT implémenter la classe audio USB.
• [C-3-2] DOIT avoir une latence audio aller-retour continue de 20 millisecondes ou moins sur le port du mode hôte USB en utilisant la classe audio USB.
• La latence audio aller-retour en continu DOIT être inférieure ou égale à 10 millisecondes sur le port du mode hôte USB en utilisant la classe audio USB.

Si les appareils incluent un port HDMI, ils:

• [C-4-1] DOIT accepter une sortie stéréo et 8 canaux à une profondeur de 20 bits ou 24 bits et à 192 kHz sans perte de profondeur de bits ni rééchantillonnage, dans au moins une configuration.

5.11. Capturer pour les éléments non traités

Android est compatible avec l'enregistrement de contenus audio non traités via la source audio android.media.MediaRecorder.AudioSource.UNPROCESSED. Dans OpenSL ES, il est accessible avec le préréglage d'enregistrement SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

Si les implémentations d'appareils ont l'intention de prendre en charge une source audio non traitée et de la rendre disponible pour les applications tierces:

• [C-1-1] DOIT signaler cette compatibilité via la propriété android.media.AudioManager PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.

• [C-1-2] DOIT présenter des caractéristiques amplitude-fréquence approximativement plates dans la plage de fréquences moyennes: plus précisément, ±10 dB de 100 Hz à 7 000 Hz pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-3] DOIT présenter des niveaux d'amplitude dans la plage des basses fréquences, en particulier de ±20 dB de 5 Hz à 100 Hz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-4] DOIT présenter des niveaux d'amplitude dans la plage des hautes fréquences, en particulier de ±30 dB de 7 000 Hz à 22 kHz par rapport à la plage de fréquence moyenne pour chaque micro utilisé pour enregistrer la source audio non traitée.

• [C-1-5] DOIT définir la sensibilité de l'entrée audio de sorte qu'une source de tonalités sinusoïdales de 1 000 Hz lue à un niveau de pression sonore (SPL) de 94 dB génère une réponse avec un RMS de 520 pour les échantillons de 16 bits (ou une échelle de -36 dB pour les échantillons audio à virgule flottante/double processus) pour chaque source audio non utilisée.

• [C-1-6] DOIT avoir un rapport signal sur bruit (SNR) d'au moins 60 dB pour chaque micro utilisé pour enregistrer la source audio non traitée. (alors que le rapport SNR correspond à la différence entre une valeur SPL de 94 dB et une valeur SPL équivalente de bruit propre, pondérée A).

• [C-1-7] DOIT avoir une distorsion harmonique totale (THD) inférieure à 1% pour 1 kHZ à un niveau d'entrée SPL de 90 dB sur chacun des micros utilisés pour enregistrer la source audio non traitée.

• NE DOIT PAS comporter d'autre traitement de signal (contrôle automatique du gain, filtre passe-haut ou annulation d'écho) dans le chemin autre qu'un multiplicateur de niveau pour atteindre la plage souhaitée. Autrement dit :

• [C-1-8] Si l'architecture comporte un traitement de signal, quelle qu'en soit la raison, il DOIT être désactivé et introduire zéro délai ou une latence supplémentaire dans le chemin du signal.
• [C-1-9] Le multiplicateur de niveau, bien qu'il puisse se trouver sur le chemin, NE DOIT PAS introduire de retard ni de latence dans le chemin du signal.

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

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

• [C-2-1] DOIT renvoyer null pour la méthode API AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) afin d'indiquer correctement l'absence de compatibilité.
• Les enregistrements [SR] sont FORTEMENT RECOMMANDÉS pour répondre à un maximum d'exigences concernant le chemin du signal pour la source d'enregistrement non traitée.

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

6.1. Outils pour les développeurs

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge les outils pour les développeurs Android fournis dans le SDK Android.

• Android Debug Bridge (adb)

  • [C-0-2] DOIT prendre en charge adb comme indiqué dans le SDK Android et les commandes shell fournies dans AOSP, qui peuvent être utilisées par les développeurs d'applications, y compris dumpsys et cmd stats.
  • [C-0-3] NE DOIT PAS modifier le format ni le contenu des événements système de l'appareil (batterystats , diskstats, fingerprint, charts, netstats, notification, procstats) enregistrés via la commande dumpsys.
  • [C-0-10] DOIT enregistrer, sans omission, et rendre les événements suivants accessibles et disponibles pour la commande shell cmd stats et la classe d'API système StatsManager.
    • État de premier plan de l'activité modifié
    • Anomalie détectée
    • Fil d'Ariane signalé
    • AppCrashOccured
    • AppStartOccurred (Démarrage de l'application)
    • Niveau de batterie modifié
    • État du mode d'économie de batterie modifié
    • BleScanResultReceived (Résultat reçu)
    • BleScanStateChanged
    • État de facturation modifié
    • DeviceIdleModeStateChanged
    • État du service de premier plan modifié
    • GpsScanStateChanged
    • État du job modifié
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • État de l'écran modifié
    • SyncStateChanged (État de synchronisation modifié)
    • SystèmeElapsedRealtime
    • UidProcessStateChanged
    • État du wakelock modifié
    • Alarme du réveilSure
    • État du verrouillage du Wi-Fi modifié
    • État du verrouillage WifiMulticast modifié
    • État du Wi-Fi modifié
  • [C-0-4] DOIT avoir le daemon adb côté appareil inactif par défaut et il DOIT y avoir un mécanisme accessible à l'utilisateur pour activer Android Debug Bridge.
  • [C-0-5] DOIT être compatible avec adb sécurisé. Android est compatible avec adb sécurisé. Le service adb sécurisé active adb sur des hôtes authentifiés connus.

  • [C-0-6] DOIT fournir un mécanisme permettant à adb d'être connecté à partir d'une machine hôte. Par exemple :

    • Les implémentations d'appareils sans port USB compatible avec le mode périphérique DOIVENT implémenter adb via un réseau local (Ethernet ou Wi-Fi, par exemple).
    • DOIT fournir des pilotes pour Windows 7, 9 et 10, permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb.

• Service Dalvik Debug Monitor (ddms)

  • [C-0-7] DOIT prendre en charge toutes les fonctionnalités ddms décrites dans le SDK Android. Étant donné que ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme ci-dessus.
• Singe
  • [C-0-8] DOIT inclure le framework Monkey et le mettre à la disposition des applications.
• SysTrace
  • [C-0-9] DOIT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut et il DOIT y avoir un mécanisme accessible par l'utilisateur pour activer Systrace.

Si les implémentations d'appareils indiquent la prise en charge de Vulkan 1.0 ou version ultérieure via les flags de fonctionnalité android.hardware.vulkan.version, elles:

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

6.2. Options pour les développeurs

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

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

• [C-0-1] DOIT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer ces options après avoir appuyé sept (7) fois sur Paramètres > À propos de l'appareil > Numéro de version.
• [C-0-2] DOIT masquer les options pour les développeurs par défaut.
• [C-0-3] DOIT fournir un mécanisme clair qui n'accorde pas un traitement préférentiel à une application tierce plutôt qu'à une autre afin d'activer les Options pour les développeurs. DOIT fournir un document ou un site Web visibles au public expliquant comment activer les Options pour les développeurs. Ce document ou ce site Web DOIT pouvoir rediriger les utilisateurs vers les documents du SDK Android.
• DEVRAIT afficher une notification visuelle en continu à l'utilisateur lorsque les options pour les développeurs sont activées et que la sécurité de l'utilisateur est préoccupante.
• PEUVENT limiter temporairement l'accès au menu "Options pour les développeurs", en le masquant ou en le désactivant visuellement, afin d'éviter toute distraction dans les cas où la sécurité de l'utilisateur est préoccupante.

7. Compatibilité matérielle

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

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

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

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

L'API de téléphonie est un exemple type de scénario dans lequel ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées de manière à être implémentées de manière no-ops raisonnable.

7.1. Écran et graphismes

Android inclut des fonctionnalités qui ajustent automatiquement les éléments d'application et les mises en page de l'interface utilisateur en fonction de l'appareil, afin de garantir le bon fonctionnement des applications tierces sur différentes configurations matérielles. Les appareils DOIVENT implémenter ces API et ces comportements correctement, comme indiqué dans cette section.

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

• taille physique en diagonale. Distance en pouces entre les deux coins opposés de la partie éclairée de l'écran.
• points par pouce (PPP). Nombre de pixels englobés par une étendue linéaire horizontale ou verticale de 1". Lorsque les valeurs PPP sont indiquées, les dpi horizontal et vertical doivent être compris dans la plage.
• format. Rapport entre le nombre de pixels de la dimension la plus longue et celle du côté le plus court de l'écran. Par exemple, un écran de 480 x 854 pixels correspondrait à 854/480 = 1,779, soit approximativement "16:9".
• pixel indépendant de la densité (dp). Unité de pixel virtuel normalisée sur un écran de 160 ppp, calculée comme suit: pixels = dps * (densité/160).

7.1.1. Configuration de l'écran

Taille et forme de l'écran

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

Implémentations pour les appareils:

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

  • Les appareils dont le paramètre Configuration.uiMode est défini sur une valeur autre que UI_MODE_TYPE_WATCH et qui signalent une taille small pour Configuration.screenLayout DOIVENT avoir au moins 426 dp x 320 dp.
  • Les appareils indiquant une taille normal pour Configuration.screenLayout DOIVENT avoir au moins 480 dp x 320 dp.
  • Les appareils indiquant une taille large pour Configuration.screenLayout DOIVENT avoir au moins 640 dp x 480 dp.
  • Les appareils indiquant une taille xlarge pour Configuration.screenLayout DOIVENT avoir au moins 960 dp x 720 dp.

• [C-0-2] DOIT respecter correctement la prise en charge déclarée des tailles d'écran par les applications via l'attribut <supports-screens> du fichier AndroidManifest.xml, comme indiqué dans la documentation du SDK Android.

• PEUT disposer d'un écran aux coins arrondis.

Si les implémentations d'appareils sont compatibles avec UI_MODE_TYPE_NORMAL et incluent un écran à coins arrondis, ils:

• [C-1-1] DOIT s'assurer que le rayon des angles arrondis est inférieur ou égal à 38 dp.
• DEVRAIT inclure l' affordance de l'utilisateur pour passer au mode d'affichage avec les coins rectangulaires.

Format de l'écran

Bien qu'il n'existe aucune restriction concernant la valeur du format de l'écran physique, le format de l'écran logique dans lequel les applications tierces sont affichées, comme pouvant être dérivés des valeurs de hauteur et de largeur indiquées via les API view.Display et l'API Configuration, DOIT respecter les exigences suivantes:

• [C-0-1] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_NORMAL DOIVENT avoir un format compris entre 1,3333 (4:3) et 1,86 (environ 16:9), sauf si l'application peut être considérée comme prête à être étirée plus longtemps en remplissant l'une des conditions suivantes:

  • L'application a déclaré qu'elle était compatible avec un format d'écran plus grand via la valeur de métadonnées android.max_aspect.
  • L'application déclare qu'elle est redimensionnable via l'attribut android:resizeableActivity.
  • L'application cible le niveau d'API 24 ou supérieur et ne déclare pas de paramètre android:MaxAspectRatio qui limiterait les proportions autorisées.

• [C-0-2] Les implémentations d'appareils avec Configuration.uiMode défini sur UI_MODE_TYPE_WATCH DOIVENT avoir un format de 1.0 (1:1).

Densité d'écran

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

• [C-0-1] Par défaut, les implémentations d'appareils DOIVENT indiquer une seule des densités du framework Android logique suivantes via l'API DENSITY_DEVICE_STABLE, et cette valeur NE DOIT PAS changer à aucun moment. Toutefois, l'appareil PEUT signaler une densité arbitraire différente selon les modifications apportées à la configuration d'affichage par l'utilisateur (par exemple, la taille de l'écran) définies après le démarrage initial.

  • 120 ppp (ldpi)
  • 160 ppp (mdpi)
  • 213 ppp (tvdpi)
  • 240 ppp (hdpi)
  • 260 ppp (260 ppp)
  • 280 ppp (280 ppp)
  • 300 ppp (300 ppp)
  • 320 ppp (xhdpi)
  • 340 ppp (340 ppp)
  • 360 ppp (360 ppp)
  • 400 ppp (400 ppp)
  • 420 ppp (420 ppp)
  • 480 ppp (xxhdpi)
  • 560 ppp (560 ppp)
  • 640 ppp (xxxhdpi)

• Les implémentations d'appareils DOIVENT définir la densité standard du framework Android la plus proche numériquement de la densité physique de l'écran, sauf si cette densité logique pousse la taille d'écran indiquée en dessous de la taille minimale prise en charge. Si la densité du framework Android standard la plus proche numériquement de la densité physique correspond à une taille d'écran inférieure à la plus petite taille d'écran compatible acceptée (largeur de 320 dp), les implémentations d'appareils DOIVENT indiquer la deuxième densité de framework standard Android la plus basse.

S'il existe une affordance pour modifier la taille d'affichage de l'appareil:

• [C-1-1] La taille d'affichage NE DOIT PAS être mise à l'échelle au-delà de 1,5 fois la densité native ou produire une dimension minimale effective inférieure à 320 dp (équivalent au qualificatif de ressource sw320dp), selon la première éventualité.
• [C-1-2] La taille de l'écran NE DOIT PAS être mise à l'échelle en dessous de 0,85 fois la densité native.
• Pour garantir une bonne facilité d'utilisation et des tailles de police cohérentes, il est RECOMMANDÉ de proposer la mise à l'échelle suivante des options d'affichage natif (tout en respectant les limites spécifiées ci-dessus).
• S: x 0,85
• Par défaut: 1x (échelle d'affichage natif)
• Grande: x 1,15
• Plus grande: x1,3
• Plus grande x 1,45

Métriques sur le Réseau Display

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

• [C-1-1] DOIT indiquer des valeurs correctes pour toutes les métriques d'affichage définies dans l'API android.util.DisplayMetrics.

Si les appareils ne comprennent pas d'écran intégré ni de sortie vidéo:

• [C-2-1] DOIT indiquer des valeurs raisonnables pour toutes les métriques d'affichage 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 pour les appareils:

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

Si les implémentations d'appareils sont compatibles avec les deux orientations d'écran:

• [C-1-1] DOIT prendre en charge l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la requête de l'application pour une orientation d'écran spécifique.
• [C-1-2] NE DOIT PAS modifier la taille ni la densité d'écran indiquées lors du changement d'orientation.
• PEUT sélectionner l'orientation portrait ou paysage par défaut.

Accélération graphique 2D et 3D

7.1.4.1 OpenGL ES

Implémentations pour les appareils:

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

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

• [C-1-1] DOIT être compatible avec OpenGL ES 1.1 et 2.0, comme indiqué dans la documentation du SDK Android.
• Les [SR] sont FORTEMENT RECOMMANDÉS pour la compatibilité avec OpenGL ES 3.1.
• DEVRAIT prendre en charge OpenGL ES 3.2.

Si les implémentations d'appareils sont compatibles avec l'une des versions d'OpenGL ES, celles-ci:

• [C-2-1] DOIT signaler via les API gérées et les API natives OpenGL ES toute autre extension OpenGL ES mise en œuvre, et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.
• [C-2-2] DOIT prendre en charge les extensions EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage et EGL_ANDROID_recordable.
• Les [SR] sont FORTEMENT RECOMMANDÉS de prendre en charge EGL_KHR_partial_update.
• DEVRAIT enregistrer avec précision via la méthode getString(), tout format de compression de texture compatible, généralement spécifique au fournisseur.

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

• [C-3-1] DOIT exporter les symboles de fonction correspondants à cette version en plus des symboles de fonction OpenGL ES 2.0 de la bibliothèque libGLESv2.so.

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

• [C-4-1] DOIT prendre en charge le pack d'extensions Android OpenGL ES dans son intégralité.

Si les implémentations d'appareils sont compatibles avec le pack d'extensions Android OpenGL ES dans son intégralité, celles-ci:

• [C-5-1] DOIT identifier la compatibilité via l'indicateur de fonctionnalité android.hardware.opengles.aep.

Si les implémentations d'appareils sont compatibles avec l'extension EGL_KHR_mutable_render_buffer, elles:

• [C-6-1] DOIT également prendre en charge l'extension EGL_ANDROID_front_buffer_auto_refresh.

7.1.4.2 Vulkan

Android est compatible avec Vulkan, une API multiplate-forme simple pour des graphismes 3D hautes performances.

Si les implémentations d'appareils sont compatibles avec OpenGL ES 3.1, celles-ci:

• [SR] Il est FORTEMENT RECOMMANDÉ d'inclure la prise en charge de Vulkan 1.1.

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

• DEVRAIT inclure la prise en charge de Vulkan 1.1.

Si les implémentations d'appareils sont compatibles avec Vulkan 1.0, elles:

• [C-1-1] DOIT indiquer la valeur entière correcte avec les indicateurs de fonctionnalité android.hardware.vulkan.level et android.hardware.vulkan.version.
• [C-1-2] DOIT énumérer au moins un élément VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices() .
• [C-1-3] DOIT implémenter intégralement les API Vulkan 1.0 pour chaque VkPhysicalDevice énuméré.
• [C-1-4] DOIT énumérer les couches contenues dans les bibliothèques natives nommées libVkLayer*.so dans le répertoire de bibliothèques natives du package d'application, via les API natives Vulkan vkEnumerateInstanceLayerProperties() et vkEnumerateDeviceLayerProperties() .
• [C-1-5] NE DOIT PAS énumérer les couches fournies par les bibliothèques en dehors du package d'application, ni fournir d'autres moyens de traçage ou d'interception de l'API Vulkan, sauf si l'attribut android:debuggable de l'application est défini sur true.
• [C-1-6] DOIT indiquer toutes les chaînes d'extension compatibles avec les API natives Vulkan et, à l'inverse, NE DOIT PAS signaler les chaînes d'extension qu'ils ne prennent pas correctement en charge.
• [C-1-7] DOIT prendre en charge les extensions VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain et VK_KHR_incremental_present.

Si les implémentations d'appareils ne sont pas compatibles avec Vulkan 1.0, elles:

• [C-2-1] NE DOIT PAS déclarer d'indicateur de fonctionnalité Vulkan (par exemple, android.hardware.vulkan.level ou android.hardware.vulkan.version).
• [C-2-2] NE DOIT PAS énumérer de VkPhysicalDevice pour l'API native Vulkan vkEnumeratePhysicalDevices().

Si les implémentations d'appareils sont compatibles avec Vulkan 1.1, elles:

• [C-3-1] DOIT exposer la prise en charge des types de sémaphore et de handle externes SYNC_FD.
• [SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'extension VK_ANDROID_external_memory_android_hardware_buffer.

7.1.4.3 RenderScript

• [C-0-1] Les implémentations d'appareils DOIVENT prendre en charge Android RenderScript, comme indiqué dans la documentation du SDK Android.

7.1.4.4 Accélération graphique 2D

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle des graphismes 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue en utilisant un tag de fichier manifeste android:hardwareAccelerated ou des appels d'API directs.

Implémentations pour les appareils:

• [C-0-1] DOIT activer l'accélération matérielle par défaut et DOIT désactiver l'accélération matérielle si le développeur le demande en définissant android:hardwareAccelerated="false" ou en désactivant l'accélération matérielle directement via les API Android View.
• [C-0-2] DOIT présenter un comportement cohérent avec la documentation du SDK Android concernant l'accélération matérielle.

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES avec accélération matérielle en tant que cibles de rendu dans une hiérarchie d'UI.

Implémentations pour les appareils:

• [C-0-3] DOIT prendre en charge l'API TextureView et DOIT présenter un comportement cohérent avec l'implémentation Android en amont.

7.1.4.5 Écrans larges

Si des implémentations d'appareils sont compatibles avec les écrans larges via Configuration.isScreenWideColorGamut() , elles:

• [C-1-1] DOIT disposer d'un écran calibré pour les couleurs.
• [C-1-2] DOIT disposer d'un écran dont la gamme couvre entièrement la gamme de couleurs sRVB dans l'espace xyY CIE 1931.
• [C-1-3] DOIT disposer d'un écran dont la gamme présente une surface d'au moins 90% de l'espace DCI-P3 dans l'espace xyY de la CIE 1931.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.1 ou 3.2 et les signaler correctement.
• [C-1-5] DOIT faire la promotion des extensions EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3 et EGL_KHR_gl_colorspace_display_p3.
• [SR] SONT FORTEMENT RECOMMANDÉS de soutenir GL_EXT_sRGB.

À l'inverse, si les implémentations d'appareils ne sont pas compatibles avec les écrans larges, ils:

• [C-2-1] DEVRAIT couvrir 100% ou plus du sRVB dans l'espace xyY CIE 1931, bien que la gamme de couleurs de l'écran ne soit pas définie.

Mode de compatibilité des anciennes applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne dans un mode de taille d'écran "normale" (largeur 320 dp) au profit des anciennes applications non développées pour les anciennes versions d'Android qui sont antérieures à l'indépendance par rapport à la taille de l'écran.

Technologie d'écran

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches à l'écran. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android, sauf en cas d'autorisation expresse dans ce document.

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec les écrans capables d'afficher des graphiques en couleurs 16 bits.
• DEVRAIT prendre en charge les écrans compatibles avec des graphismes en couleurs 24 bits.
• [C-0-2] DOIT prendre en charge les écrans capables d'afficher des animations.
• [C-0-3] DOIT utiliser une technologie d'affichage dont le format de pixel (PAR) est compris entre 0,9 et 1,15. Autrement dit, le rapport hauteur/largeur des pixels DOIT être proche du carré (1,0) avec une tolérance de 10 ~ 15 %.

Écrans secondaires

Android prend en charge les écrans secondaires pour activer les fonctionnalités de partage multimédia et les API de développement permettant d'accéder aux écrans externes.

Si les appareils sont compatibles avec un écran externe via une connexion filaire, sans fil ou avec un écran supplémentaire intégré, ils:

• [C-1-1] DOIT implémenter le service système et l'API DisplayManager comme décrit dans la documentation du SDK Android.

7.2. Périphériques d'entrée

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un mécanisme de saisie, tel qu'un écran tactile ou une navigation non tactile, pour naviguer entre les éléments de l'interface utilisateur.

7.2.1. Clavier

Si les implémentations d'appareils prennent en charge les applications tierces de l'éditeur de mode de saisie (IME) :

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.software.input_methods.
• [C-1-2] DOIT implémenter intégralement Input Management Framework
• [C-1-3] DOIT disposer d'un clavier virtuel préinstallé.

Implémentations d'appareils: * [C-0-1] NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard (QWERTY ou 12 touches). * DEVRAIT inclure d'autres implémentations de clavier virtuel. * PEUT inclure un clavier physique.

7.2.2. Navigation non tactile

Android est compatible avec le pavé directionnel, le trackball et la molette comme mécanismes de navigation non tactile.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation.

Si les implémentations d'appareils ne proposent pas de navigation non tactile, elles:

• [C-1-1] DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils dépourvus d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour généralement accessibles via une interaction avec un bouton physique dédié ou une partie distincte de l'écran tactile sont essentielles au paradigme de navigation Android et, par conséquent, aux implémentations d'appareils:

• [C-0-1] DOIT fournir une affordance utilisateur pour lancer des applications installées dont l'activité a les valeurs <intent-filter> définies avec ACTION=MAIN et CATEGORY=LAUNCHER ou CATEGORY=LEANBACK_LAUNCHER pour les implémentations de téléviseurs. La fonction Accueil DOIT être le mécanisme de cette affordance utilisateur.
• DEVRAIT fournir des boutons pour les fonctions "Récents" et "Retour".

Si les fonctions "Accueil", "Récents" ou "Retour" sont fournies, elles:

• [C-1-1] DOIT être accessible en une seule action (appui, double-clic ou geste, par exemple) lorsque l'un de ces éléments est accessible.
• [C-1-2] DOIT indiquer clairement quelle action unique déclencherait chaque fonction. Il peut s'agir, par exemple, d'une icône visible imprimée sur le bouton, d'une icône de logiciel dans la partie de la barre de navigation de l'écran ou d'une démonstration guidée qui guide l'utilisateur pendant la configuration initiale.

Implémentations pour les appareils:

• Il est FORTEMENT RECOMMANDÉ de ne pas fournir de mécanisme d'entrée pour la fonction de menu, car elle a été abandonnée au profit de la barre d'action depuis Android 4.0.

Si les implémentations d'appareils intègrent la fonction Menu, celles-ci:

• [C-2-1] DOIT afficher le bouton à développer d'actions chaque fois que la fenêtre pop-up du menu à développer d'actions n'est pas vide et que la barre d'action est visible.
• [C-2-2] NE DOIT PAS modifier la position du pop-up de dépassement d'action affiché en sélectionnant le bouton à développer dans la barre d'action, mais PEUT afficher la fenêtre pop-up de dépassement d'action à une position modifiée à l'écran lorsqu'il est affiché en sélectionnant la fonction Menu.

Si les implémentations d'appareils ne proposent pas la fonction Menu, pour assurer la rétrocompatibilité, elles: * [C-3-1] DOIT mettre la fonction Menu à la disposition des applications lorsque la valeur de targetSdkVersion est inférieure à 10, que ce soit à l'aide d'un bouton physique, d'une touche logicielle ou de gestes. Cette fonction Menu doit être accessible, sauf si elle est masquée avec d'autres fonctions de navigation.

Si les implémentations d'appareils intègrent la fonction d'assistance, elles: * [C-4-1] DOIT rendre la fonction d'assistance accessible en une seule action (appui, double-clic ou geste, par exemple) lorsque d'autres touches de navigation sont accessibles. * [SR] FORTEMENT RECOMMANDÉ d'utiliser un appui prolongé sur la fonction HOME pour cette interaction désignée.

Si les implémentations d'appareils utilisent une partie distincte de l'écran pour afficher les touches de navigation, elles:

• [C-5-1] Les touches de navigation DOIVENT utiliser une partie distincte de l'écran, qui n'est pas accessible aux applications et NE DOIVENT PAS masquer la partie de l'écran accessible aux applications ni gêner leur fonctionnement.
• [C-5-2] DOIT mettre une partie de l'écran à la disposition des applications répondant aux exigences définies dans la section 7.1.1.
• [C-5-3] DOIT respecter les indicateurs définis par l'application via la méthode d'API View.setSystemUiVisibility(), de sorte que cette partie distincte de l'écran (la barre de navigation) soit correctement masquée, comme indiqué dans le SDK.

7.2.4. Saisie par écran tactile

Android est compatible avec divers systèmes de saisie de pointeur, tels que les écrans tactiles, les pavés tactiles et les faux dispositifs de saisie tactile. Les implémentations d'appareils à écran tactile sont associées à un écran de sorte que l'utilisateur ait l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système ne nécessite aucune affordance supplémentaire pour indiquer les objets manipulés.

Implémentations pour les appareils:

• DEVRAIT disposer d'un système de saisie de type pointeur (comme une souris ou tactile).
• DEVRAIT prendre en charge les pointeurs suivis de manière totalement indépendante.

Si les appareils sont équipés d'un écran tactile (tactile ou supérieur), les exigences suivantes s'appliquent:

• [C-1-1] DOIT indiquer TOUCHSCREEN_FINGER pour le champ d'API Configuration.touchscreen.
• [C-1-2] DOIT signaler les flags de fonctionnalité android.hardware.touchscreen et android.hardware.faketouch.

Si les implémentations d'appareils comprennent un écran tactile capable de suivre plusieurs pressions d'affilée, celles-ci:

• [C-2-1] DOIT indiquer les flags de fonctionnalité appropriés android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct et android.hardware.touchscreen.multitouch.jazzhand correspondant au type d'écran tactile spécifique de l'appareil.

Si les implémentations d'appareils n'incluent pas d'écran tactile (et s'appuient uniquement sur un pointeur) et répondent aux exigences concernant l'écran tactile artificiel de la section 7.2.5, les appareils suivants:

• [C-3-1] NE DOIT PAS signaler de flag de fonctionnalité commençant par android.hardware.touchscreen et DOIT signaler uniquement android.hardware.faketouch.

Saisie tactile simulée

L'interface tactile simulée fournit un système de saisie utilisateur qui se rapproche d'un sous-ensemble des fonctionnalités de l'écran tactile. Par exemple, une souris ou une télécommande qui dirige un curseur à l'écran se rapproche d'un toucher tactile, mais oblige l'utilisateur à pointer ou à sélectionner une option, puis à cliquer. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris gyroscopique, le gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante android.hardware.faketouch, qui correspond à un périphérique d'entrée haute fidélité non tactile (basé sur un pointeur), tel qu'une souris ou un pavé tactile, qui peut émuler de manière adéquate la saisie tactile (y compris la prise en charge des gestes de base). L'appareil indique que l'appareil est compatible avec un sous-ensemble émulé de fonctionnalités tactiles.

Si les implémentations d'appareils n'incluent pas d'écran tactile, mais incluent un autre système de saisie de pointeur qu'elles souhaitent proposer, elles:

• DEVRAIT déclarer la prise en charge du flag de fonctionnalité android.hardware.faketouch.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch, elles:

• [C-1-1] DOIT indiquer les positions X et Y absolues de l'écran de l'emplacement du pointeur et afficher un pointeur visuel à l'écran.
• [C-1-2] DOIT signaler l'événement tactile avec le code d'action spécifiant le changement d'état qui se produit sur le pointeur descendant ou remontant l'écran.
• [C-1-3] DOIT prendre en charge le pointeur vers le haut et le bas sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• [C-1-4] DOIT prendre en charge les pointeurs vers le bas, vers le haut, vers le bas, puis vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler le double appui sur un objet à l'écran.
• [C-1-5] DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un déplacement tactile.
• [C-1-6] DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de le pointer vers le haut, ce qui permet aux utilisateurs de faire glisser un objet sur l'écran.
• [C-1-7] DOIT indiquer TOUCHSCREEN_NOTOUCH pour le champ d'API Configuration.touchscreen.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.distinct, elles:

• [C-2-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-2-2] DOIT prendre en charge le suivi distinct d'au moins deux entrées de pointeur indépendantes.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.faketouch.multitouch.jazzhand, elles:

• [C-3-1] DOIT déclarer la prise en charge de android.hardware.faketouch.
• [C-3-2] DOIT prendre en charge un suivi distinct de 5 (suivi d'une main des doigts) ou plus d'entrées de pointeur de manière entièrement indépendante.

Compatibilité avec les manettes de jeu

Mappages de boutons

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

• [C-1-1] DOIT être équipé d'une manette ou d'un vaisseau avec une manette distincte dans la boîte, ce qui permettrait de saisir tous les événements listés dans les tableaux ci-dessous.
• [C-1-2] DOIT être capable de mapper les événements HID aux constantes Android view.InputEvent associées, comme indiqué dans les tableaux ci-dessous. L'implémentation Android en amont inclut l'implémentation de manettes de jeu qui répondent à cette exigence.

Bouton	Utilisation HID^2	Bouton Android
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0 x 09, 0 x 0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
O^1	0x09 0x0005	KEYCODE_BOUTON_Y (100)
Pavé directionnel vers le haut^1 Pavé directionnel descendant^1	0x01 0x0039^3	AXIS_HAT_Y^4
Pavé directionnel gauche1 Pavé directionnel droit^1	0x01 0x0039^3	AXIS_HAT_X^4
Bouton de l'épaule gauche^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite^1	0x09 0x0008	KEYCODE_BOUTON_R1 (103)
Clic gauche^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Effectuer un clic avec le stick droit^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Accueil^1	0x0c 0x0223	KEYCODE_HOME (3)
Retour^1	0x0c 0x0224	KEYCODE_BACK (4)

1 Événement clé

2 Les utilisations HID ci-dessus doivent être déclarées dans une manette de jeu CA (0x01 0x0005).

3 Cette utilisation doit avoir un minimum logique de 0, un maximum logique de 7, un minimum physique de 0, un maximum physique de 315, une unité en degrés et une taille de rapport de 4. La valeur logique est définie comme une rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et le bouton vers le haut que l'utilisateur appuie, tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et une pression sur les touches haut et gauche.

4 MotionEvent

Commandes analogiques^1	Utilisation HID	Bouton Android
Gâchette gauche	0x02, 0x00C5	AXIS_LTRIGGER
Déclencheur droit	0x02, 0x00C4	AXIS_RTRIGGER
Joystick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Joystick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. Télécommande

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.3.1.

7.3. Capteurs

Si les implémentations d'appareils incluent un type de capteur particulier associé à une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API, comme décrit dans la documentation du SDK Android et dans la documentation Android Open Source sur les capteurs.

Implémentations pour les appareils:

• [C-0-1] DOIT signaler avec précision la présence ou l'absence de capteurs conformément à la classe android.content.pm.PackageManager.
• [C-0-2] DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires.
• [C-0-3] DOIT se comporter de manière raisonnable pour toutes les autres API de capteur (par exemple, en renvoyant true ou false selon les cas, lorsque les applications tentent d'enregistrer des écouteurs, et non en les appelant lorsque les capteurs correspondants ne sont pas présents, etc.).

Si les implémentations d'appareils incluent un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, elles:

• [C-1-1] DOIT indiquer toutes les mesures de capteurs en utilisant les valeurs du système international d'unités (métriques) pertinentes pour chaque type de capteur, tel que défini dans la documentation du SDK Android.
• [C-1-2] DOIT transmettre les données de capteurs avec une latence maximale de 100 millisecondes + 2 * "sample_time" dans le cas d'un capteur diffusé en continu avec une latence minimale requise de 5 ms + 2 * sample_time lorsque le processeur de l'application est actif. Ce délai n'inclut pas les délais de filtrage.
• [C-1-3] DOIT indiquer le premier échantillon du capteur dans un délai de 400 millisecondes + 2 x échantillon_temps du capteur en cours d'activation. La justesse de cet échantillon peut être égale à 0.

• [SR] DEVRAIT signaler l'heure de l'événement en nanosecondes comme défini dans la documentation du SDK Android, qui représente l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano(). Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux futures versions de la plate-forme, qui pourraient devenir un composant OBLIGATOIRE. La durée de l'erreur de synchronisation DOIT être inférieure à 100 millisecondes.

• [C-1-4] Pour que toute API indiquée dans la documentation du SDK Android soit un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques qui DOIVENT présenter une gigue inférieure à 3 %. La gigue est définie comme l'écart type de la différence des valeurs d'horodatage signalées entre des événements consécutifs.

• [C-1-5] DOIT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer à l'état "suspendu" ou de sortir de l'état "suspendu".

• Lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie rapportée par chaque capteur.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et la documentation Android Open Source concernant les capteurs doivent faire autorité.

Certains types de capteurs sont composites, ce qui signifie qu'ils peuvent être dérivés des données fournies par un ou plusieurs autres capteurs. (par exemple, le capteur d'orientation et le capteur d'accélération linéaire).

Implémentations pour les appareils:

• DEVRAIT mettre en œuvre ces types de capteurs s'ils incluent des capteurs physiques préalables, comme décrit dans la section Types de capteurs.

Si les implémentations d'appareils incluent un capteur composite, celles-ci:

• [C-2-1] DOIT implémenter le capteur comme décrit dans la documentation Android Open Source sur les capteurs composites.

7.3.1. Accéléromètre

• Les implémentations d'appareils DOIVENT inclure un accéléromètre à 3 axes.

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

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER.
• [C-1-3] DOIT respecter le système de coordonnées du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT être capable de mesurer à partir de la chute libre jusqu'à quatre fois la gravité(4g) ou plus sur n'importe quel axe.
• [C-1-5] DOIT avoir une résolution d'au moins 12 bits.
• [C-1-6] DOIT avoir un écart type inférieur à 0,05 m/s^, où l'écart type doit être calculé par axe sur des échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• Les [SR] sont fortement recommandés pour implémenter le capteur composite TYPE_SIGNIFICANT_MOTION.
• Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED si l'accéléromètre en ligne peut être calibré en ligne.
• DEVRAIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER comme décrit dans le document du SDK Android.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.
• DEVRAIT avoir une résolution d'au moins 16 bits.
• DOIT être calibré en cours d'utilisation si les caractéristiques changent au cours du cycle de vie et sont compensées, et conservez les paramètres de compensation entre les redémarrages de l'appareil.
• DEVRAIT être compensé en température.
• DEVRAIT également implémenter le capteur TYPE_ACCELEROMETER_UNCALIBRATED.

Si les implémentations d'appareils incluent un accéléromètre à 3 axes et que l'un des capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER est implémenté:

• [C-2-1] La somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW.
• DEVRAIT être inférieure à 2 mW et à 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.

Si les appareils comprennent un accéléromètre à 3 axes et un gyroscope, ils:

• [C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• DEVRAIT implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.
• [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android nouveaux et existants.

Si les appareils comprennent un accéléromètre à 3 axes, un gyroscope et un magnétomètre, ils:

• [C-4-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

7.3.2. Magnétomètre

• Les implémentations d'appareils DOIVENT inclure un magnétomètre (boussole) à 3 axes.

Si les implémentations d'appareils incluent un magnétomètre à 3 axes, ils:

• [C-1-1] DOIT implémenter le capteur TYPE_MAGNETIC_FIELD.
• [C-1-2] DOIT pouvoir signaler des événements avec une fréquence d'au moins 10 Hz et DOIT rapporter des événements dont la fréquence est d'au moins 50 Hz.
• [C-1-3] DOIT respecter le système de coordonnées du capteur Android détaillé dans les API Android.
• [C-1-4] DOIT pouvoir mesurer entre -900 μT et +900 μT sur chaque axe avant la saturation.
• [C-1-5] DOIT avoir une valeur de décalage du fer dur inférieure à 700 μT et une valeur inférieure à 200 μT, en plaçant le magnétomètre éloigné des champs magnétiques dynamiques (induits par le courant) et statiques (induits par l'aimant).
• [C-1-6] DOIT avoir une résolution égale ou supérieure à 0,6 μT.
• [C-1-7] DOIT prendre en charge l'étalonnage et la compensation en ligne du biais du fer dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-8] DOIT appliquer la compensation du fer doux. L'étalonnage peut être effectué en cours d'utilisation ou pendant la production de l'appareil.
• [C-1-9] DOIT avoir un écart type, calculé par axe sur des échantillons collectés sur une période d'au moins 3 secondes au taux d'échantillonnage le plus rapide, ne dépassant pas 1,5 μT ; DOIT avoir un écart type inférieur à 0,5 μT.
• DEVRAIT implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED.
• [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED sur les appareils Android nouveaux et existants.

Si les appareils comprennent un magnétomètre à 3 axes, un accéléromètre et un gyroscope, ils:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils comprennent un magnétomètre à 3 axes (un accéléromètre), ils:

• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR.

Si les implémentations d'appareils comprennent un magnétomètre à 3 axes, un accéléromètre et un capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR, elles:

• [C-3-1] DOIT consommer moins de 10 mW.
• DEVRAIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode de traitement par lot à 10 Hz.

7.3.3. GPS

Implémentations pour les appareils:

• DEVRAIT inclure un récepteur GPS/GNSS.

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

• [C-1-1] DOIT prendre en charge les sorties de localisation à un taux d'au moins 1 Hz lorsqu'il est demandé via LocationManager#requestLocationUpdate.
• [C-1-2] DOIT être capable de déterminer la position en ciel ouvert (signaux forts, multi-chemins négligeables, HDOP < 2) en 10 secondes (délai rapide pour la première correction), lorsque la connexion Internet est d'au moins 0,5 Mbit/s. Cette exigence est généralement satisfaite par l'utilisation d'une certaine forme de technique GPS/GNSS assistée ou prévue pour minimiser le temps de verrouillage GPS/GNSS (les données d'assistance comprennent l'heure de référence, l'emplacement de référence et les éphémères du satellite/l'horloge).
  • [C-1-6] Une fois ce calcul de localisation effectué, les appareils DOIVENT déterminer leur position, en ciel ouvert, dans un délai de cinq secondes lorsque les demandes de localisation sont redémarrées, jusqu'à une heure après le calcul initial de la position, même si la demande suivante est effectuée sans connexion de données et/ou après un redémarrage.

• En ciel ouvert, après avoir déterminé la position, lorsque vous êtes à l'arrêt ou que vous vous déplacez avec un carré d'accélération inférieur à 1 mètre par seconde:

  • [C-1-3] DOIT pouvoir déterminer la position dans un rayon de 20 mètres et la vitesse dans un rayon de 0, 5 mètre par seconde, au moins 95% du temps.
  • [C-1-4] DOIT suivre et signaler simultanément via GnssStatus.Callback au moins huit satellites d'une même constellation.
  • DEVRAIT pouvoir suivre simultanément au moins 24 satellites de plusieurs constellations (par exemple, le GPS + au moins un satellite de Glonass, Beidou ou Galileo).
  • [C-1-5] DOIT indiquer la génération de la technologie GNSS via l'API de test "getGnssYearOfHardware".
  • [SR] Continuez à transmettre les données de localisation GPS/GNSS normales pendant un appel téléphonique d'urgence.
  • [SR] Transmet les mesures GNSS de toutes les constellations suivies (comme indiqué dans les messages GnssStatus), à l'exception de SBAS.
  • [SR] Rapport AGC et Fréquence de mesure GNSS.
  • [SR] Envoyez toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.
  • Il est FORTEMENT RECOMMANDÉ de respecter les exigences supplémentaires obligatoires pour les appareils déclarant les années "2016" ou "2017" via l'API de test LocationManager.getGnssYearOfHardware().

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et indiquent la capacité aux applications via le flag de fonctionnalité android.hardware.location.gps et que l'API de test LocationManager.getGnssYearOfHardware() indique "2016" ou une année plus récente, ils:

• [C-2-1] DOIT indiquer les mesures GNSS dès qu'elles sont trouvées, même si une position calculée à partir du GPS/GNSS n'est pas encore signalée.
• [C-2-2] DOIT indiquer les pseudo-plages et les taux de pseudo-plage GNSS, qui, en ciel ouvert après avoir déterminé la position, sont immobiles ou se déplacent avec un carré d'accélération inférieur à 0,2 mètre par seconde (au moins 95% du temps).

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et indiquent la capacité aux applications via le flag de fonctionnalité android.hardware.location.gps et que l'API de test LocationManager.getGnssYearOfHardware() indique "2017" ou une année plus récente, ils:

• [C-3-1] DOIT continuer à fournir les données de localisation GPS/GNSS normales pendant un appel téléphonique d'urgence.
• [C-3-2] DOIT indiquer les mesures GNSS de toutes les constellations suivies (telles que signalées dans les messages GnssStatus), à l'exception de SBAS.
• [C-3-3] DOIT indiquer le score AGC et la fréquence de mesure GNSS.
• [C-3-4] DOIT fournir toutes les estimations de précision (y compris la direction, la vitesse et la verticale) pour chaque position GPS/GNSS.

Si les implémentations d'appareils incluent un récepteur GPS/GNSS et indiquent la capacité aux applications via le flag de fonctionnalité android.hardware.location.gps et que l'API de test LocationManager.getGnssYearOfHardware() indique "2018" ou une année ultérieure, elles:

• [C-4-1] DOIT continuer à fournir des sorties GPS/GNSS normales aux applications lors d'un appel de session d'urgence initié par un réseau basé sur une station mobile (MS).
• [C-4-2] DOIT indiquer les positions et les mesures aux API du fournisseur de localisation GNSS.

7.3.4. Gyroscope

Implémentations pour les appareils:

• DEVRAIT inclure un gyroscope (capteur de changement angulaire).
• NE DOIT PAS inclure de gyroscope, sauf si un accéléromètre 3 axes est également inclus.

Si les implémentations d'appareils incluent un gyroscope:

• [C-1-1] DOIT pouvoir signaler des événements avec une fréquence d'au moins 50 Hz.
• [C-1-2] DOIT implémenter le capteur TYPE_GYROSCOPE et DOIT aussi implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED.
• [C-1-3] DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
• [C-1-4] DOIT avoir une résolution de 12 bits ou plus et DEVRAIT avoir une résolution de 16 bits ou plus.
• [C-1-5] DOIT être compensé en température.
• [C-1-6] DOIT être calibré et compensé en cours d'utilisation, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• [C-1-7] DOIT avoir une variance inférieure ou égale à 1e-7 rad^2 / s^2 par Hz (variance par Hz, ou rad^2 / s). La variance peut varier en fonction du taux d'échantillonnage, mais DOIT être contrainte par cette valeur. En d'autres termes, si vous mesurez la variance du gyroscope à un taux d'échantillonnage de 1 Hz, il DOIT ne pas être supérieur à 1e-7 rad^2/s^2.
• [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sur les appareils Android nouveaux et existants.
• [SR] Il est FORTEMENT RECOMMANDÉ d'indiquer une erreur d'étalonnage inférieure à 0,01 rad/s lorsque l'appareil est immobile à température ambiante.
• DEVRAIT enregistrer des événements dont la fréquence d'actualisation est d'au moins 200 Hz.

Si les appareils comprennent un gyroscope, un accéléromètre et un magnétomètre:

• [C-2-1] DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR.

Si les appareils sont équipés d'un gyroscope et d'un capteur d'accéléromètre:

• [C-3-1] DOIT implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION.
• [SR] Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android nouveaux et existants.
• DEVRAIT implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR.

Baromètre

• Les appareils DOIVENT inclure un baromètre (capteur de pression de l'air ambiant).

Si les implémentations d'appareils comprennent un baromètre, celles-ci:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• [C-1-2] DOIT pouvoir diffuser des événements avec une fréquence de 5 Hz ou plus.
• [C-1-3] DOIT être compensé en température.
• [SR] FORTEMENT RECOMMANDÉ de pouvoir indiquer des mesures de pression comprises entre 300 hPa et 1 100 hPa.
• DEVRAIT avoir une précision absolue de 1 hPa.
• DEVRAIT avoir une précision relative de 0,12 hPa sur une plage de 20 hPa (équivalant à une précision d'environ 1 m sur une variation d'environ 200 m au niveau de la mer).

7.3.6. Thermomètre

Appareils utilisés: * PEUT inclure un thermomètre ambiant (capteur de température). * PEUT, mais NE DEVRAIT PAS inclure de capteur de température pour processeur.

Si les appareils sont équipés d'un thermomètre ambiant (capteur de température), ils:

• [C-1-1] DOIT être défini comme SENSOR_TYPE_AMBIENT_TEMPERATURE et DOIT mesurer la température ambiante (de la pièce/l'habitacle du véhicule) à partir de laquelle l'utilisateur interagit avec l'appareil, en degrés Celsius.
• [C-1-2] DOIT être défini comme SENSOR_TYPE_TEMPERATURE.
• [C-1-3] DOIT mesurer la température du processeur de l'appareil.
• [C-1-4] NE DOIT PAS mesurer d'autres températures.

Notez que le type de capteur SENSOR_TYPE_TEMPERATURE a été abandonné dans Android 4.0.

7.3.7. Photomètre

• Les implémentations d'appareils PEUVENT inclure un photomètre (capteur de luminosité ambiante).

7.3.8. Capteur de proximité

• Les implémentations d'appareils PEUVENT inclure un capteur de proximité.

Si les implémentations d'appareils incluent un capteur de proximité, ils:

• [C-1-1] DOIT mesurer la proximité d'un objet dans la même direction que l'écran. Autrement dit, le capteur de proximité DOIT être orienté pour détecter les objets proches de l'écran, car l'objectif principal de ce type de capteur est de détecter un téléphone utilisé par l'utilisateur. Si les implémentations d'appareils incluent un capteur de proximité avec une autre orientation, celui-ci NE DOIT PAS être accessible via cette API.
• [C-1-2] DOIT avoir une précision d'au moins 1 bit.

7.3.9. Capteurs haute fidélité

Si les implémentations d'appareils incluent un ensemble de capteurs de meilleure qualité (tel que défini dans cette section) et les mettent à la disposition des applications tierces, elles:

• [C-1-1] DOIT identifier la capacité via l'indicateur de fonctionnalité android.hardware.sensor.hifi_sensors.

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

• [C-2-1] DOIT disposer d'un capteur TYPE_ACCELEROMETER qui:

  • L'intervalle de mesure DOIT être compris entre -8 g et +8 g, et entre -16 g et +16 g.
  • DOIT avoir une résolution de mesure d'au moins 2 048 LSB/g.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 400 μg/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 3 mW.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de 3 dB correspondant à au moins 80% de la fréquence de Nyquist et d'un spectre de bruit blanc dans cette bande passante.
  • DEVRAIT avoir une marche aléatoire d'accélération inférieure à 30 μg √Hz testée à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 1 mg/°C.
  • DOIT présenter une non-linéarité ≤ 0,5 % de la courbe la plus adaptée et une variation de la sensibilité par rapport à la température de ≤ 0,03%/C°.
  • DEVRAIT avoir une sensibilité transversale inférieure à 2,5 % et une variation de la sensibilité de l'axe transversal < 0,2% dans la plage de températures de fonctionnement de l'appareil.

• [C-2-2] DOIT avoir un TYPE_ACCELEROMETER_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_ACCELEROMETER.

• [C-2-3] DOIT disposer d'un capteur TYPE_GYROSCOPE qui:

  • DOIT avoir une plage de mesure comprise entre -1 000 et +1 000 dps.
  • DOIT avoir une résolution de mesure d'au moins 16 LSB/dps.
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 400 Hz ou plus ; DEVRAIT prendre en charge SensorDirectChannel RATE_VERY_FAST.
  • DOIT enregistrer un bruit de mesure inférieur à 0,014 °/s/√ Hz.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ de disposer d'une bande passante de 3 dB correspondant à au moins 80% de la fréquence de Nyquist et d'un spectre de bruit blanc dans cette bande passante.
  • DEVRAIT avoir un taux de marche aléatoire inférieur à 0,001 °/s √Hz testé à température ambiante.
  • DEVRAIT avoir un changement de biais par rapport à une température de ≤ +/- 0,05 °/ s / °C.
  • DEVRAIT avoir un changement de sensibilité par rapport à une température ≤ 0,02% / °C.
  • DEVRAIT présenter une non-linéarité de droite la plus adaptée de ≤ 0,2%.
  • DEVRAIT avoir une densité de bruit ≤ 0,007 °/s/√Hz.
  • L'erreur d'étalonnage DOIT être inférieure à 0,002 rad/s dans une plage de températures comprise entre 10 et 40 °C lorsque l'appareil est à l'arrêt.
  • La sensibilité g DOIT être inférieure à 0,1°/s/g.
  • DEVRAIT avoir une sensibilité transversale inférieure à 4,0 % et une variation de sensibilité transversale inférieure à 0,3% dans la plage de températures de fonctionnement de l'appareil.

• [C-2-4] DOIT comporter un TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que TYPE_GYROSCOPE.

• [C-2-5] DOIT disposer d'un capteur TYPE_GEOMAGNETIC_FIELD qui:

  • DOIT avoir une plage de mesure comprise entre -900 et +900 μT.
  • DOIT avoir une résolution de mesure d'au moins 5 LSB/uT.
  • DOIT avoir une fréquence de mesure minimale de 5 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus.
  • DOIT présenter un bruit de mesure inférieur à 0,5 uT.

• [C-2-6] DOIT comporter un TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que l'TYPE_GEOMAGNETIC_FIELD et en plus:

  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un spectre de bruit blanc de 1 Hz à au moins 10 Hz lorsque la fréquence de signalement est supérieure ou égale à 50 Hz.

• [C-2-7] DOIT disposer d'un capteur TYPE_PRESSURE qui:

  • La plage de mesure DOIT être comprise entre 300 et 1 100 hPa au minimum.
  • DOIT avoir une résolution de mesure d'au moins 80 LSB/hPa.
  • DOIT avoir une fréquence de mesure minimale de 1 Hz ou moins.
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus.
  • DOIT enregistrer un bruit de mesure inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 2 mW.
• [C-2-8] DOIT disposer d'un capteur TYPE_GAME_ROTATION_VECTOR qui :
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
• [C-2-9] DOIT disposer d'un capteur TYPE_SIGNIFICANT_MOTION qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-10] DOIT disposer d'un capteur TYPE_STEP_DETECTOR qui :
  • DOIT implémenter une forme non activée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur.
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
  • DOIT avoir une consommation d'énergie par lot inférieure ou égale à 4 mW.
• [C-2-11] DOIT disposer d'un capteur TYPE_STEP_COUNTER qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-12] DOIT disposer d'un capteur TILT_DETECTOR qui :
  • La consommation d'énergie DOIT être d'au moins 0,5 mW lorsque l'appareil est statique et de 1,5 mW lorsqu'il est en mouvement.
• [C-2-13] L'horodatage du même événement physique signalé par l'accéléromètre, le gyroscope et le magnétomètre DOIT se situer à moins de 2, 5 millisecondes l'un de l'autre. L'horodatage du même événement physique signalé par l'accéléromètre et le gyroscope DOIT se situer à 0,25 milliseconde l'un de l'autre.
• [C-2-14] DOIT disposer d'horodatages des événements du capteur du gyroscope sur la même base de temps que le sous-système de l'appareil photo, avec un écart d'une milliseconde près.
• [C-2-15] DOIT fournir des échantillons aux applications dans un délai de 5 millisecondes à compter du moment où les données sont disponibles sur l'un des capteurs physiques ci-dessus à l'application.
• [C-2-16] NE DOIT PAS avoir une consommation d'énergie supérieure à 0,5 mW lorsque l'appareil est statique et à 2 mW lorsque l'appareil est en mouvement lorsque l'une des combinaisons des capteurs suivants est activée :
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] PEUT disposer d'un capteur TYPE_PROXIMITY, mais s'il est présent, il DOIT disposer d'une capacité de mémoire tampon minimale de 100 événements de capteur.

Notez que l'ensemble des exigences de consommation d'énergie indiquées dans cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle inclut la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits connexes, système de traitement dédié des capteurs, etc.).

Si les implémentations d'appareils incluent la prise en charge directe des capteurs, celles-ci:

• [C-3-1] DOIT déclarer correctement la prise en charge des types de canaux directs et du taux de signalement direct via les API isDirectChannelTypeSupported et getHighestDirectReportRateLevel.
• [C-3-2] DOIT être compatible avec au moins l'un des deux types de canaux directs des capteurs pour tous les capteurs déclarant être compatibles avec le canal direct du capteur.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• DEVRAIT accepter les rapports d'événements via le canal direct du capteur pour le capteur principal (variante sans réveil) des types suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. Capteurs biométriques

Lecteurs d'empreinte digitale

Si les implémentations d'appareils comprennent un écran de verrouillage sécurisé:

• DEVRAIT inclure un lecteur d'empreinte digitale.

Si les implémentations d'appareils incluent un lecteur d'empreinte digitale et le rendent disponible pour des applications tierces:

• [C-1-1] DOIT déclarer la prise en charge de la fonctionnalité android.hardware.fingerprint.
• [C-1-2] DOIT implémenter intégralement l'API correspondante, comme décrit dans la documentation du SDK Android.
• [C-1-3] DOIT avoir un taux de faux acceptations inférieur ou égal à 0,002%.
• [SR] Il est FORTEMENT RECOMMANDÉ d'indiquer un taux d'acceptation par usurpation d'identité et par imposteur inférieur ou égal à 7%.
• [C-1-4] 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 spoofing et d'imposteurs sont supérieurs à 7%.
• [C-1-5] DOIT limiter le nombre de tentatives pendant au moins 30 secondes après cinq faux essais de validation par empreinte digitale.
• [C-1-6] DOIT disposer d'une implémentation de keystore intégrée au matériel et effectuer la mise en correspondance des empreintes digitales dans un environnement d'exécution sécurisé (TEE) ou sur une puce dotée d'un canal sécurisé vers le TEE.
• [C-1-7] DOIT faire en sorte que toutes les données d'empreintes digitales identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors du TEE, ou qu'une puce disposant d'un canal sécurisé vers le TEE, comme indiqué dans les consignes d'implémentation sur le site du projet Open Source Android.
• [C-1-8] DOIT empêcher l'ajout d'une empreinte digitale sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer un identifiant existant ou d'ajouter un nouvel identifiant d'appareil (code/schéma/mot de passe) sécurisé par TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour le faire.
• [C-1-9] NE DOIT PAS permettre aux applications tierces de faire la distinction entre différentes empreintes digitales.
• [C-1-10] DOIT respecter l'indicateur DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• [C-1-11] DOIT, lors d'une mise à niveau à partir d'une version antérieure à Android 6.0, migrer de manière sécurisée les données relatives aux empreintes digitales afin de répondre aux exigences ci-dessus ou les supprimer.
• [C-1-12] DOIT supprimer complètement toutes les données permettant d'identifier les empreintes digitales d'un utilisateur lorsque son compte est supprimé (y compris en cas de rétablissement de la configuration d'usine).
• [C-1-13] NE DOIT pas permettre au processeur d'application d'accéder de manière non chiffrée aux données permettant d'identifier les empreintes digitales ni aux données qui en sont dérivées (telles que les représentations vectorielles continues).
• [SR] Il est FORTEMENT RECOMMANDÉ d'avoir un taux de faux rejets inférieur à 10%, tel que mesuré sur l'appareil.
• [SR] Il est FORTEMENT RECOMMANDÉ d'avoir une latence inférieure à une seconde, mesurée entre l'appui sur le lecteur d'empreinte digitale et le déverrouillage de l'écran, pour un doigt enregistré.
• DEVRAIT utiliser l'icône d'empreinte Android fournie dans le projet Android Open Source.

7.3.10.2. Autres capteurs biométriques

Si les implémentations d'appareils incluent un ou plusieurs capteurs biométriques non basés sur les empreintes digitales et les mettent à la disposition d'applications tierces:

• [C-1-1] DOIT avoir un taux de faux acceptations inférieur ou égal à 0,002%.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'indiquer un taux d'acceptation par usurpation d'identité et par imposteur inférieur ou égal à 7%.
• [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 spoofing et d'imposteurs sont supérieurs à 7%.
• [C-1-3] DOIT limiter le taux de tentatives pendant au moins 30 secondes après cinq faux essais de vérification biométrique, lorsqu'un faux essai doit présenter une qualité de capture adéquate (ACQUIRED_GOOD) qui ne correspond pas à une méthode biométrique enregistrée
• [C-1-4] DOIT disposer d'une implémentation de keystore intégré au matériel et effectuer la mise en correspondance biométrique dans un TEE ou sur une puce dotée d'un canal sécurisé vers le TEE.
• [C-1-5] DOIT faire en sorte que toutes les données identifiables soient chiffrées et authentifiées de manière cryptographique de sorte qu'elles ne puissent pas être acquises, lues ou modifiées en dehors du TEE, ou d'une puce dotée d'un canal sécurisé vers le TEE, comme indiqué dans les consignes d'implémentation sur le site du projet Open Source Android.
• [C-1-6] DOIT empêcher l'ajout de nouvelles données biométriques sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer des identifiants existants ou d'ajouter de nouveaux identifiants d'appareil (code/schéma/mot de passe) sécurisés par TEE. L'implémentation du projet Android Open Source fournit le mécanisme dans le framework pour le faire.
• [C-1-7] NE DOIT PAS permettre aux applications tierces de faire la distinction entre les enregistrements biométriques.
• [C-1-8] DOIT respecter l'indicateur individuel de cette biométrie (par exemple, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE ou DevicePolicymanager.KEYGUARD_DISABLE_IRIS).
• [C-1-9] DOIT supprimer complètement toutes les données biométriques permettant d'identifier l'utilisateur en cas de suppression de son compte (y compris en cas de rétablissement de la configuration d'usine).
• [C-1-10] NE DOIT PAS permettre au processeur d'application d'accéder de manière non chiffrée à des données biométriques permettant d'identifier l'utilisateur ni à des données qui en sont dérivées (telles que les représentations vectorielles continues) en dehors du contexte du TEE.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir un taux de faux refus inférieur à 10%, tel que mesuré sur l'appareil.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée entre le moment où les données biométriques sont détectées et le déverrouillage de l'écran, pour chaque empreinte biométrique enregistrée.

7.3.11. Capteurs Android Automotive uniquement

Les capteurs propres à l'automobile sont définis dans le android.car.CarSensorManager API.

Engrenage actuel

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.5.1.

7.3.11.2. Mode Jour/Nuit

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.5.1.

Statut en voiture

Cette exigence a été abandonnée.

7.3.11.4. Vitesse de rotation

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.5.1.

7.3.11.5. Frein à main

Pour connaître les exigences spécifiques à chaque appareil, consultez la section 2.5.1.

7.3.12. Capteur de postures

Implémentations pour les appareils:

• PEUT prendre en charge les capteurs de position avec 6 degrés de liberté.

Si les implémentations d'appareils prennent en charge les capteurs de position à 6 degrés de liberté, ils:

• [C-1-1] DOIT implémenter et signaler le capteur TYPE_POSE_6DOF.
• [C-1-2] DOIT être plus précis que le vecteur de rotation seul.

7.4. Connectivité des données

7.4.1. Téléphonie

Le terme "Téléphonie" utilisé par les API Android et ce document fait spécifiquement référence au matériel permettant de passer des appels vocaux et d'envoyer des SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent être ou non commutés de paquets, ils sont destinés aux besoins d'Android et sont considérés comme étant indépendants de toute connectivité de données pouvant être implémentée à l'aide du même réseau. En d'autres termes, la fonctionnalité de téléphonie et les API Android se réfèrent spécifiquement aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir des SMS ne sont pas considérées comme des appareils de téléphonie, qu'elles utilisent ou non un réseau mobile pour la connectivité des données.

• Android PEUT être utilisé sur des appareils qui n'incluent pas de matériel téléphonique. Autrement dit, Android est compatible avec les appareils autres que les téléphones.

Si les implémentations d'appareils incluent la téléphonie GSM ou CDMA, ils:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.telephony et d'autres sous-indicateurs de fonctionnalité en fonction de la technologie concernée.
• [C-1-2] DOIT mettre en œuvre la compatibilité totale de l'API avec cette technologie.

Si les implémentations d'appareils n'incluent pas de matériel de téléphonie:

• [C-2-1] DOIT implémenter les API complètes en tant que no-ops.

Compatibilité avec le blocage des numéros

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

• [C-1-1] DOIT inclure une fonctionnalité de blocage de numéros
• [C-1-2] DOIT implémenter intégralement BlockedNumberContract et l'API correspondante, comme décrit dans la documentation du SDK.
• [C-1-3] DOIT bloquer tous les appels et messages provenant d'un numéro de téléphone figurant dans "BlockedNumberProvider" sans aucune interaction avec les applications. Seule exception : le blocage des numéros est temporairement levé, comme décrit dans la documentation du SDK.
• [C-1-4] NE DOIT PAS écrire dans le fournisseur de journaux d'appels de la plate-forme pour un appel bloqué.
• [C-1-5] NE DOIT PAS écrire au fournisseur de téléphonie pour un message bloqué.
• [C-1-6] DOIT implémenter une interface utilisateur de gestion des numéros bloqués, qui est ouverte avec l'intent renvoyé par la méthode TelecomManager.createManageBlockedNumbersIntent().
• [C-1-7] NE DOIT PAS permettre aux utilisateurs secondaires d'afficher ni de modifier les numéros bloqués sur l'appareil, car la plate-forme Android suppose que l'utilisateur principal a le contrôle total des services de téléphonie (une seule instance) sur l'appareil. Toutes les interfaces utilisateur liées au blocage DOIVENT être masquées pour les utilisateurs secondaires, et la liste des utilisateurs bloqués DOIT quand même être respectées.
• DEVRAIT transférer les numéros bloqués vers le fournisseur lorsqu'un appareil passera à Android 7.0.

API Telecom

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

• [C-1-1] DOIT prendre en charge les API ConnectionService décrites dans le SDK.
• [C-1-2] DOIT afficher un nouvel appel entrant et fournir une affordance à l'utilisateur pour accepter ou rejeter l'appel entrant lorsqu'il est en cours d'appel effectué par une application tierce qui n'est pas compatible avec la fonctionnalité de mise en attente spécifiée via CAPABILITY_SUPPORT_HOLD.

• [C-SR] SONT FORTEMENT RECOMMANDÉS d'informer l'utilisateur que l'appel en cours sera interrompu.

  L'implémentation d'AOSP répond à ces exigences par une notification prioritaire qui indique à l'utilisateur que le fait de répondre à un appel entrant entraînera l'interruption de l'autre appel.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de précharger l'application de téléphonie par défaut, qui affiche une entrée du journal d'appels et le nom d'une application tierce dans son journal d'appels lorsque l'application tierce définit la touche "Extras" EXTRA_LOG_SELF_MANAGED_CALLS sur son PhoneAccount sur true.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de gérer les événements KEYCODE_MEDIA_PLAY_PAUSE et KEYCODE_HEADSETHOOK du casque audio pour les API android.telecom, comme indiqué ci-dessous :
  • Appelez Connection.onDisconnect() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel en cours.
  • Appelez Connection.onAnswer() lorsqu'un appui court sur l'événement de touche est détecté pendant un appel entrant.
  • Appelez Connection.onReject() lorsqu'un appui prolongé sur l'événement de touche est détecté pendant un appel entrant.
  • Activer/Désactiver le son de CallAudioState.

7.4.2. IEEE 802.11 (Wi-Fi)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge d'une ou plusieurs formes de la norme 802.11.

Si les implémentations d'appareils sont compatibles avec la norme 802.11 et exposent la fonctionnalité à une application tierce, celles-ci:

• [C-1-1] DOIT implémenter l'API Android correspondante.
• [C-1-2] DOIT signaler le flag de fonctionnalité matérielle android.hardware.wifi.
• [C-1-3] DOIT implémenter l'API de multidiffusion comme décrit dans la documentation du SDK.
• [C-1-4] DOIT prendre en charge le multicast DNS (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à aucun moment de l'opération, y compris dans les cas suivants :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même lorsqu'elles sont en veille.
• [C-1-5] NE DOIT PAS traiter l'appel de méthode d'API WifiManager.enableNetwork() comme une indication suffisante pour changer le Network actuellement actif utilisé par défaut pour le trafic de l'application et renvoyé par les méthodes d'API ConnectivityManager telles que getActiveNetwork et registerDefaultNetworkCallback. En d'autres termes, ils ne peuvent désactiver l'accès Internet fourni par tout autre fournisseur de réseau (données mobiles, par exemple) que s'ils valident que le réseau Wi-Fi fournit l'accès à Internet.
• [C-SR] Sont FORTEMENT RECOMMANDÉS, lorsque la méthode API ConnectivityManager.reportNetworkConnectivity() est appelée, de réévaluer l'accès à Internet sur le Network. Une fois que l'évaluation détermine que le Network actuel ne fournit plus d'accès à Internet, passez à un autre réseau disponible (par exemple, les données mobiles) qui fournit un accès à Internet.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de randomiser l'adresse MAC source et le nombre de trames des demandes de vérification, une fois au début de chaque analyse, lorsque la STA est déconnectée.
  • Chaque groupe de trames de demande de vérification comprenant une analyse doit utiliser une adresse MAC cohérente (NE DEVRAIT PAS randomiser l'adresse MAC au milieu de l'analyse).
  • Le numéro de séquence des requêtes de vérification doit itérer normalement (de manière séquentielle) entre les demandes de vérification d'une analyse.
  • Le numéro de séquence de la demande de vérification doit être aléatoire entre la dernière demande de vérification d'une analyse et la première demande de vérification de l'analyse suivante.
• [C-SR] SONT FORTEMENT RECOMMANDÉS, lorsque la STA est déconnectée, pour n'autoriser que les éléments suivants dans les trames de requête de vérification :
  • Ensemble de paramètres SSID (0)
  • Ensemble de paramètres DS (3)

Si les implémentations d'appareils sont compatibles avec le Wi-Fi et l'utilisent pour rechercher la position, ils:

• [C-2-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via la méthode API WifiManager.isScanAlwaysAvailable.

Wi-Fi Direct

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge du Wi-Fi Direct (Wi-Fi peer-to-peer).

Si les appareils sont compatibles avec le Wi-Fi Direct, ils:

• [C-1-1] DOIT implémenter l'API Android correspondante comme décrit dans la documentation du SDK.
• [C-1-2] DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• [C-1-3] DOIT être compatible avec le fonctionnement Wi-Fi standard.
• [C-1-4] DOIT être compatible avec les opérations Wi-Fi et Wi-Fi Direct simultanément.

7.4.2.2. Configuration du lien direct par tunneling en Wi-Fi

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la configuration TDLS (Wi-Fi Tunneled Direct Link Setup), comme décrit dans la documentation du SDK Android.

Si les implémentations d'appareils sont compatibles avec le TDLS et que TDLS est activé par l'API WiFiManager, ils:

• [C-1-1] DOIT déclarer la prise en charge du TDLS via WifiManager.isTdlsSupported.
• DEVRAIT utiliser le TDLS uniquement lorsque cela est possible ET bénéfique.
• DEVRAIT utiliser une heuristique et NE PAS utiliser le TDLS lorsque ses performances pourraient être pires que de passer par le point d'accès Wi-Fi.

Wi-Fi Aware

Implémentations pour les appareils:

• DEVRAIT inclure la compatibilité avec Wi-Fi Aware.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Aware et exposent la fonctionnalité à des applications tierces, celles-ci:

• [C-1-1] DOIT implémenter les API WifiAwareManager comme décrit dans la documentation du SDK.
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.aware.
• [C-1-3] DOIT prendre en charge les opérations Wi-Fi et Wi-Fi Aware simultanément.
• [C-1-4] DOIT attribuer de manière aléatoire l'adresse de l'interface de gestion Wi-Fi Aware à des intervalles ne dépassant pas 30 minutes et chaque fois que Wi-Fi Aware est activé.

Si les implémentations d'appareils incluent la prise en charge du service Wi-Fi Aware et de la localisation via le Wi-Fi, comme décrit dans la section 7.4.2.5, et que ces fonctionnalités sont exposées à des applications tierces, les mesures suivantes seront prises:

• [C-2-1] DOIT implémenter les API de découverte avec détection de la position: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm et onServiceDiscoveredWithinRange.

7.4.2.4. Passpoint Wi-Fi

Implémentations pour les appareils:

• DEVRAIT prendre en charge Wi-Fi Passpoint.

Si les implémentations d'appareils sont compatibles avec Wi-Fi Passpoint, elles:

• [C-1-1] DOIT implémenter les API WifiManager liées à Passpoint, comme décrit dans la documentation du SDK.
• [C-1-2] DOIT être compatible avec la norme IEEE 802.11u, spécifiquement liée à la découverte et à la sélection de réseaux, comme le service publicitaire générique (GAS) et le protocole de requête réseau d'accès (ANQP).

À l'inverse, si les implémentations d'appareils n'incluent pas la prise en charge du point d'accès Wi-Fi:

• [C-2-1] L'implémentation des API WifiManager liées à Passpoint DOIT générer une UnsupportedOperationException.

Emplacement du Wi-Fi (délai aller-retour Wi-Fi - DAR)

Implémentations pour les appareils:

• DEVRAIT inclure la prise en charge de la localisation Wi-Fi.

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

• [C-1-1] DOIT implémenter les API WifiRttManager comme décrit dans la documentation du SDK.
• [C-1-2] DOIT déclarer le flag de fonctionnalité android.hardware.wifi.rtt.
• [C-1-3] DOIT attribuer de manière aléatoire l'adresse MAC source pour chaque rafale de DAR exécuté, tandis que l'interface Wi-Fi sur laquelle le DAR s'exécute n'est pas associée à un point d'accès.

7.4.3. Bluetooth

Si les appareils sont compatibles avec le profil audio Bluetooth, ils:

• DEVRAIT prendre en charge les codecs audio avancés et les codecs audio Bluetooth (par exemple, LDAC).

Si les implémentations d'appareils sont compatibles avec les protocoles HFP, A2DP et AVRCP:

• DEVRAIT prendre en charge au moins cinq appareils connectés au total.

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

• [C-1-1] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension.

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation.

Si les implémentations d'appareils prennent en charge les technologies Bluetooth et Bluetooth à basse consommation:

• [C-2-1] DOIT déclarer les fonctionnalités pertinentes de la plate-forme (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de la plate-forme.
• DEVRAIT implémenter les profils Bluetooth appropriés, tels que A2DP, AVRCP, OBEX, HFP, etc., en fonction de l'appareil.

Si les implémentations d'appareils sont compatibles avec la technologie Bluetooth à basse consommation, elles:

• [C-3-1] DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• [C-3-2] DOIT activer les API Bluetooth basées sur un profil d'attribut générique, comme décrit dans la documentation du SDK et dans le fichier android.bluetooth.
• [C-3-3] DOIT indiquer la valeur correcte pour BluetoothAdapter.isOffloadedFilteringSupported() pour indiquer si la logique de filtrage des classes d'API ScanFilter est mise en œuvre.
• [C-3-4] DOIT indiquer la valeur correcte pour BluetoothAdapter.isMultipleAdvertisementSupported() pour indiquer si la publicité à basse consommation est acceptée.
• DEVRAIT accepter le déchargement de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter.
• DEVRAIT permettre le déchargement de la recherche par lot sur le chipset Bluetooth.

• DEVRAIT prendre en charge les annonces multiples comportant au moins 4 emplacements.

• [SR] FORTEMENT RECOMMANDÉ d'implémenter un délai avant expiration de l'adresse privée pouvant être résolue (RPA) de 15 minutes maximum et de faire tourner l'adresse une fois le délai expiré afin de protéger la confidentialité des utilisateurs.

Si les implémentations d'appareils prennent en charge la technologie Bluetooth LE et l'utilisent pour la détection de la position, celles-ci:

• [C-4-1] DOIT fournir une affordance utilisateur pour activer/désactiver la valeur lue via le BluetoothAdapter.isBleScanAlwaysAvailable() de l'API système.

7.4.4. Communication en champ proche

Implémentations pour les appareils:

• DEVRAIT inclure un émetteur-récepteur et le matériel associé pour la technologie NFC (communication en champ proche).
• [C-0-1] DOIT implémenter les API android.nfc.NdefMessage et android.nfc.NdefRecord même si elles n'incluent pas la compatibilité NFC ou si elles ne déclarent pas la fonctionnalité android.hardware.nfc, car les classes représentent un format de représentation de données indépendant du protocole.

Si les implémentations d'appareils incluent du matériel NFC et prévoient de le rendre disponible pour les applications tierces:

• [C-1-1] DOIT signaler la caractéristique android.hardware.nfc à l'aide de la méthode android.content.pm.PackageManager.hasSystemFeature().
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes:
• [C-1-2] DOIT être capable d'agir en tant que lecteur/rédacteur sur le forum NFC (tel que défini par la spécification technique du forum NFC NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • ISO Dep (ISO 14443-4)
  • Types de tags du forum NFC 1, 2, 3, 4, 5 (définis par le forum NFC)

• [SR] VIVEMENT RECOMMANDÉ de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Remarque : bien que les normes NFC soient indiquées comme étant FORTEMENT RECOMMANDÉES, il est prévu qu'elles soient remplacées par une OBLIGATION dans la définition de compatibilité d'une prochaine version. Ces normes sont facultatives dans cette version, mais seront obligatoires dans les futures versions. Les appareils nouveaux et existants qui exécutent cette version d'Android sont vivement encouragés à respecter ces exigences dès maintenant afin de pouvoir effectuer la mise à niveau vers les futures versions de la plate-forme.

• [C-1-3] DOIT être capable de transmettre et de recevoir des données via les normes et protocoles peer-to-peer suivants:

  • ISO 18092
  • LLCP 1.2 (défini par le forum NFC)
  • SDP 1.0 (défini par le NFC Forum)
  • Protocole push NDEF
  • SNEP 1.0 (défini par le NFC Forum)
• [C-1-4] DOIT inclure la compatibilité avec Android Beam et DOIT activer Android Beam par défaut.
• [C-1-5] DOIT pouvoir envoyer et recevoir des messages à l'aide d'Android Beam lorsqu'Android Beam est activé ou qu'un autre mode NFC P2p propriétaire est activé.
• [C-1-6] DOIT mettre en œuvre le serveur SNEP par défaut. Les messages NDEF valides reçus par le serveur SNEP par défaut DOIVENT être distribués aux applications utilisant l'intent android.nfc.ACTION_NDEF_DISCOVERED. La désactivation d'Android Beam dans les paramètres NE DOIT PAS désactiver la distribution des messages NDEF entrants.
• [C-1-7] DOIT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC.
• [C-1-8] DOIT mettre en œuvre le serveur NPP. Les messages reçus par le serveur NPP DOIVENT être traités de la même manière que le serveur SNEP par défaut.
• [C-1-9] DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsqu'Android Beam est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT tenter d'envoyer un e-mail à un serveur NPP.
• [C-1-10] DOIT autoriser les activités de premier plan à définir le message NDEF P2P sortant à l'aide de android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback et android.nfc.NfcAdapter.enableForegroundNdefPush.
• DEVRAIT utiliser un geste ou confirmer à l'écran, par exemple "Appuyer pour partager", avant d'envoyer des messages NDEF P2P sortants.
• [C-1-11] DOIT être compatible avec le transfert de la connexion NFC vers le Bluetooth lorsque l'appareil est compatible avec le profil Bluetooth Object Push.
• [C-1-12] DOIT prendre en charge le transfert de connexion vers le Bluetooth lors de l'utilisation de android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications "Transfert de connexion version 1.2" et "Bluetooth Secure Simple Pairing Using NFC version 1.0" du forum NFC. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger la demande de transfert/sélectionner des enregistrements via NFC, et elle DOIT utiliser le profil push d'objet Bluetooth pour le transfert de données Bluetooth réel. Pour d'anciennes raisons (pour rester compatible avec les appareils Android 4.1), l'implémentation DEVRAIT toujours accepter les requêtes SNEP GET pour échanger la demande de transfert/sélectionner des enregistrements via NFC. Cependant, une implémentation elle-même NE DOIT PAS envoyer de requêtes SNEP GET pour effectuer le transfert de connexion.
• [C-1-13] DOIT interroger toutes les technologies compatibles en mode découverte NFC.
• DOIT être en mode de détection NFC lorsque l'appareil est activé, avec l'écran actif et l'écran de verrouillage déverrouillé.
• DOIT être capable de lire le code-barres et l'URL (s'ils sont encodés) des produits code-barres NFC Thinfilm.

Notez que les liens accessibles au public ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum mentionnées ci-dessus.

Android est compatible avec le mode HCE (émulation de carte hôte NFC).

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE (pour NfcA et/ou NfcB) et prennent en charge le routage des ID d'application (AID), elles:

• [C-2-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hce.
• [C-2-2] DOIT être compatible avec les API NFC HCE, telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent un chipset de contrôleur NFC compatible avec la technologie HCE pour NfcF et implémentent cette fonctionnalité pour des applications tierces:

• [C-3-1] DOIT indiquer la constante de caractéristique android.hardware.nfc.hcef.
• [C-3-2] DOIT implémenter les API d'émulation de cartes NFC telles que définies dans le SDK Android.

Si les implémentations d'appareils incluent une compatibilité NFC générale comme décrit dans cette section et sont compatibles avec les technologies MIFARE (MIFARE Classic, MIFARE Ultralight, NDEF sur MIFARE Classic) dans le rôle de lecteur/rédacteur, elles:

• [C-4-1] DOIT implémenter les API Android correspondantes, comme indiqué dans le SDK Android.
• [C-4-2] DOIT signaler la caractéristique com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature(). Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas comme une constante dans la classe android.content.pm.PackageManager.

7.4.5. Capacité réseau minimale

Implémentations pour les appareils:

• [C-0-1] DOIT inclure la compatibilité avec une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT être compatibles avec au moins une norme de données capable d'atteindre 200 Kbit/s ou plus. Exemples de technologies répondant à cette exigence : EDGE, HSPA, EV-DO, 802.11g, Ethernet et Bluetooth PAN.
• DEVRAIT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi), lorsqu'une norme de réseau physique (comme Ethernet) est la connexion de données principale.
• PEUT mettre en œuvre plusieurs formes de connectivité de données.
• [C-0-2] DOIT inclure une pile réseau IPv6 et accepter la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6.
• [C-0-3] DOIT activer IPv6 par défaut.
• DOIT s'assurer que la communication IPv6 est aussi fiable que l'IPv4, par exemple :
  • [C-0-4] DOIT maintenir la connectivité IPv6 en mode Sommeil.
  • [C-0-5] La limitation du débit NE DOIT PAS entraîner la perte de la connectivité IPv6 de l'appareil sur tout réseau compatible IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.
• [C-0-6] DOIT fournir aux applications tierces une connectivité IPv6 directe au réseau lorsqu'elles sont connectées à un réseau IPv6, sans aucune forme de traduction d'adresse ou de port effectuée localement sur l'appareil. Les API gérées telles que Socket#getLocalAddress ou Socket#getLocalPort) et les API NDK comme getsockname() ou IPV6_PKTINFO DOIVENT renvoyer l'adresse IP et le port réellement utilisés pour envoyer et recevoir des paquets sur le réseau.

Le niveau requis de compatibilité IPv6 dépend du type de réseau, comme indiqué dans les exigences suivantes.

Si les appareils sont compatibles avec le Wi-Fi, ils:

• [C-1-1] DOIT être compatible avec la double pile et le fonctionnement IPv6 uniquement sur le Wi-Fi.

Si les implémentations d'appareils sont compatibles avec Ethernet, ils:

• [C-2-1] DOIT être compatible avec le fonctionnement double pile sur Ethernet.

Si les appareils sont compatibles avec les données mobiles, ils:

• DEVRAIT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur le réseau mobile.

Si les implémentations d'appareils sont compatibles avec plusieurs types de réseaux (par exemple, le Wi-Fi et les données mobiles), elles:

• [C-3-1] DOIT respecter simultanément les exigences ci-dessus sur chaque réseau lorsque l'appareil est connecté simultanément à plusieurs types de réseaux.

7.4.6. Paramètres de synchronisation

Implémentations pour les appareils:

• [C-0-1] DOIT activer le paramètre de synchronisation automatique du maître pour que la méthode getMasterSyncAutomatically() renvoie la valeur "true".

7.4.7. Économiseur de données

Si les implémentations d'appareils incluent une connexion limitée, voici les types de connexions:

• [SR] FORTEMENT RECOMMANDÉ de fournir le mode Économiseur de données.

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

• [C-1-1] DOIT prendre en charge toutes les API de la classe ConnectivityManager, comme décrit dans la documentation du SDK.
• [C-1-2] DOIT fournir dans les paramètres une interface utilisateur qui gère l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, permettant aux utilisateurs d'ajouter des applications à la liste d'autorisation ou d'en supprimer.

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

• [C-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.
• [C-2-3] DOIT avoir une activité qui gère l'intent Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS, mais PEUT l'implémenter en tant que no-op.

7.4.8. Éléments sécurisés

Si les implémentations d'appareils prennent en charge les éléments sécurisés compatibles avec l'API Open Mobile et les rendent disponibles pour les applications tierces:

• [C-1-1] DOIT énumérer les lecteurs de composants sécurisés disponibles lorsque la méthode android.se.omapi.SEService.getReaders() est appelée.

7.5. Appareils photo

Si les implémentations d'appareils incluent au moins une caméra:

• [C-1-1] DOIT déclarer le flag de fonctionnalité android.hardware.camera.any.
• [C-1-2] DOIT être possible pour qu'une application puisse allouer simultanément trois bitmaps RGBA_8888 correspondant à la taille des images produites par le capteur photo ayant la plus grande résolution de l'appareil, alors que l'appareil photo est ouvert pour effectuer un aperçu de base tout en effectuant une capture.

7.5.1. Caméra arrière

Une caméra arrière est une caméra située sur le côté de l'appareil, en face de l'écran. Autrement dit, elle immortalise les scènes de l'autre côté de l'appareil, comme un appareil photo traditionnel.

Implémentations pour les appareils:

• DEVRAIT inclure une caméra arrière.

Si les implémentations d'appareils incluent au moins une caméra arrière:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera et android.hardware.camera.any.
• [C-1-2] DOIT avoir une résolution d'au moins 2 mégapixels.
• DOIT intégrer un autofocus matériel ou logiciel dans le pilote de l'appareil photo (transparent pour le logiciel d'application).
• PEUVENT comporter du matériel à mise au point fixe ou EDOF (profondeur de champ étendue).
• PEUT inclure un flash.

Si la caméra dispose d'un flash:

• [C-2-1] La lampe du flash NE DOIT PAS être allumée lorsqu'une instance android.hardware.Camera.PreviewCallback a été enregistrée sur une surface d'aperçu de l'appareil photo, sauf si l'application a explicitement activé le flash en activant les attributs FLASH_MODE_AUTO ou FLASH_MODE_ON d'un objet Camera.Parameters. Notez que cette contrainte ne s'applique pas à l'application de caméra système intégrée à l'appareil, mais uniquement aux applications tierces utilisant Camera.PreviewCallback.

7.5.2. Caméra frontale

Une caméra frontale est une caméra située du même côté de l'appareil que l'écran ; c'est-à-dire une caméra généralement utilisée pour filmer l'utilisateur, par exemple pour la visioconférence et des applications similaires.

Implémentations pour les appareils:

• PEUT inclure une caméra frontale.

Si les implémentations d'appareils incluent au moins une caméra avant:

• [C-1-1] DOIT signaler les indicateurs de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• [C-1-2] DOIT avoir une résolution VGA d'au moins (640 x 480 pixels).
• [C-1-3] NE DOIT PAS utiliser une caméra frontale par défaut pour l'API Camera et NE DOIT PAS configurer l'API pour traiter une caméra frontale comme caméra arrière par défaut, même s'il s'agit de la seule caméra de l'appareil.
• [C-1-4] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application lorsque celle-ci a explicitement demandé la rotation de l'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation(). À l'inverse, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil lorsque l'application actuelle ne demande pas explicitement la rotation de l'écran de l'appareil photo via un appel à la méthode android.hardware.Camera.setDisplayOrientation().
• [C-1-5] NE DOIT PAS mettre en miroir les flux d'image fixe ou vidéo finaux qui sont renvoyés aux rappels de l'application ou qui ont été validés dans le stockage multimédia.
• [C-1-6] DOIT mettre en miroir l'image affichée par la vue post-vue de la même manière que le flux d'image d'aperçu de l'appareil photo.
• PEUT inclure des fonctionnalités (autofocus, flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.

Si les implémentations d'appareils peuvent être pivotées par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur):

• [C-2-1] L'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.

7.5.3. Caméra externe

Implémentations pour les appareils:

• PEUT inclure la prise en charge d'une caméra externe qui n'est pas toujours connectée.

Si les implémentations d'appareils prennent en charge une caméra externe, celles-ci:

• [C-1-1] DOIT déclarer les indicateurs de fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any.
• [C-1-2] DOIT être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure) si la caméra externe se connecte via le port hôte USB.
• [C-1-3] DOIT réussir les tests CTS de la caméra lorsqu'une caméra externe physique est connectée. Pour en savoir plus sur le test CTS de la caméra, consultez source.android.com.
• DEVRAIT accepter les compressions vidéo telles que MJPEG pour permettre le transfert de flux d'image non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment).
• PEUT prendre en charge plusieurs appareils photo.
• PEUT prendre en charge l'encodage vidéo basé sur la caméra.

Si l'encodage vidéo basé sur la caméra est compatible:

• [C-2-1] Un flux simultané non encodé / MJPEG (QVGA ou résolution supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API permettant d'accéder à l'appareil photo. La nouvelle API android.hardware.camera2 offre des commandes de niveau inférieur à l'application, y compris des flux de rafale et de streaming sans copie efficaces, ainsi que des commandes par image pour l'exposition, le gain, la balance des blancs, la conversion des couleurs, la suppression du bruit, l'amélioration de la netteté, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0, mais il devrait toujours être disponible pour les applications. Les implémentations d'appareils Android DOIVENT assurer la compatibilité continue de l'API, comme décrit dans cette section et dans le SDK Android.

Toutes les fonctionnalités communes entre la classe obsolète android.hardware.Camera et le package android.hardware.camera2 plus récent DOIVENT présenter des performances et une qualité équivalentes dans les deux API. Par exemple, avec des paramètres équivalents, la vitesse et la précision de l'autofocus doivent être identiques, et la qualité des images capturées doit être identique. Il n'est pas nécessaire que les caractéristiques qui dépendent de la sémantique différente des deux API aient une vitesse ou une qualité identiques, mais DOIVENT être aussi proches que possible.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées aux appareils photo, pour toutes les caméras disponibles. Implémentations pour les appareils:

• [C-0-1] DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application lorsqu'une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int).
• [C-0-2] DOIT être également au format d'encodage NV21 lorsqu'une application enregistre une instance android.hardware.Camera.PreviewCallback, que le système appelle la méthode onPreviewFrame() et que le format d'aperçu est YCbCr_420_SP (les données de l'octet [] sont transmises à onPreviewFrame(). Autrement dit, NV21 DOIT être la valeur par défaut.
• [C-0-3] DOIT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo des caméras avant et arrière pour android.hardware.Camera. (L'encodeur vidéo matériel et l'appareil photo peuvent utiliser n'importe quel format de pixel natif, mais la mise en œuvre de l'appareil DOIT être compatible avec la conversion au format YV12.)
• [C-0-4] DOIT prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en tant que sorties via l'API android.media.ImageReader pour les appareils android.hardware.camera2 qui annoncent la capacité REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE dans android.request.availableCapabilities.
• [C-0-5] DOIT toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android, que l'appareil intègre un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo sans autofocus DOIVENT appeler toutes les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela ne concerne pas un appareil photo sans mise au point automatique). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels de l'API doivent toujours être "faussés" comme décrit dans la description.
• [C-0-6] DOIT reconnaître et respecter chaque nom de paramètre défini en tant que constante dans la classe android.hardware.Camera.Parameters. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître des constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() autres que celles documentées en tant que constantes sur android.hardware.Camera.Parameters. Autrement dit, les implémentations d'appareils DOIVENT prendre en charge tous les paramètres standards de l'appareil photo si le matériel le permet, et NE DOIVENT PAS être compatibles avec les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils qui prennent en charge la capture d'image à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR.
• [C-0-7] DOIT indiquer le niveau d'assistance approprié pour la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android, et signaler les indicateurs de fonctionnalité du framework appropriés.
• [C-0-8] DOIT également déclarer ses capacités de caméra individuelles android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés. DOIT définir ce drapeau si l'une des caméras associées est compatible avec cette fonctionnalité.
• [C-0-9] DOIT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de cette image est ajoutée au Media Store.
• [C-0-10] DOIT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par la caméra et que l'entrée de l'image a été ajoutée au Media Store.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge un appareil photo logique listant la capacité CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, pour les appareils dotés de plusieurs caméras orientées dans la même direction, soit chaque caméra physique orientée dans cette direction, à condition que le type d'appareil photo physique soit pris en charge par le framework et que CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL pour les caméras physiques soit LIMITED, FULL ou LEVEL_3.

7.5.5. Orientation de l'appareil photo

Si les appareils sont équipés d'une caméra avant ou arrière, la ou les caméras suivantes :

• [C-1-1] DOIT être orienté de sorte que la dimension longue de l'appareil photo s'aligne sur la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cette règle s'applique quelle que soit l'orientation naturelle de l'appareil. Autrement dit, elle s'applique aux appareils principaux en mode paysage ainsi qu'aux appareils en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimaux

Implémentations pour les appareils:

• [C-0-1] DOIT inclure un Gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données. Il DOIT être capable de télécharger des fichiers individuels d'une taille minimale de 100 Mo vers l'emplacement "cache" par défaut.

7.6.2. Stockage partagé des applications

Implémentations pour les appareils:

• [C-0-1] DOIT proposer un espace de stockage partagé par les applications, souvent appelé "stockage externe partagé", "stockage partagé d'application" ou via le chemin Linux "/sdcard" sur lequel il est installé.
• [C-0-2] DOIT être configuré avec un espace de stockage partagé installé par défaut, c'est-à-dire "prêt à l'emploi", qu'il soit implémenté sur un composant de stockage interne ou sur un support de stockage amovible (emplacement de carte Secure Digital, par exemple).
• [C-0-3] DOIT installer le stockage partagé de l'application directement sur le chemin Linux sdcard ou inclure un lien symbolique Linux entre sdcard et le point d'installation réel.
• [C-0-4] DOIT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur cet espace de stockage partagé, comme indiqué dans le SDK. Le stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.

Les implémentations d'appareils PEUVENT répondre aux exigences ci-dessus si elles remplissent l'une des conditions suivantes:

• Stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte SD (Secure Digital).
• Une partie de la mémoire de stockage interne (non amovible) mise en œuvre dans le projet Android Open Source (AOSP).

Si les implémentations d'appareils utilisent un espace de stockage amovible pour répondre aux exigences ci-dessus, celles-ci:

• [C-1-1] DOIT implémenter une interface utilisateur toast ou pop-up avertissant l'utilisateur lorsqu'aucun support de stockage n'est inséré dans l'emplacement.
• [C-1-2] DOIT inclure un support de stockage au format FAT (une carte SD, par exemple) ou montrer sur la boîte et tout autre support disponible au moment de l'achat que ce support de stockage doit être acheté séparément.

Si les implémentations d'appareils utilisent une partie de l'espace de stockage non amovible pour répondre aux exigences ci-dessus, elles:

• DEVRAIT utiliser l'implémentation AOSP du stockage partagé de l'application interne.
• PEUT partager l'espace de stockage avec les données privées de l'application.

Si les configurations d'appareils incluent plusieurs chemins d'espace de stockage partagé (par exemple, un emplacement pour carte SD et une mémoire de stockage interne partagée), les mesures suivantes sont prises:

• [C-2-1] DOIT autoriser uniquement les applications Android préinstallées et privilégiées disposant de l'autorisation WRITE_EXTERNAL_STORAGE pour écrire dans la mémoire de stockage externe secondaire, sauf en cas d'écriture dans leurs répertoires spécifiques au package ou dans le URI renvoyé en déclenchant l'intent ACTION_OPEN_DOCUMENT_TREE.

Si les appareils disposent d'un port USB compatible avec le mode périphérique USB, ils:

• [C-3-1] DOIT fournir un mécanisme permettant d'accéder aux données de l'espace de stockage partagé de l'application à partir d'un ordinateur hôte.
• DEVRAIT exposer le contenu des deux chemins de stockage de manière transparente via le service d'analyse multimédia d'Android et android.provider.MediaStore.
• PEUT utiliser la mémoire de stockage de masse USB, mais DOIT utiliser le protocole Media Transfer Protocol pour répondre à cette exigence.

Si les appareils disposent d'un port USB avec mode périphérique USB et compatible avec le protocole Media Transfer Protocol, ils:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer.
• DEVRAIT signaler une classe de périphérique USB de 0x00.
• DEVRAIT indiquer le nom d'interface USB « MTP ».

7.6.3. Stockage adoptable

Si l'appareil est censé être mobile par nature, contrairement à un téléviseur, les implémentations d'appareils sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car toute déconnexion accidentelle peut entraîner une perte/corruption de données.

Si le port du périphérique de stockage amovible se trouve dans un emplacement stable à long terme, comme le compartiment à piles ou un autre couvercle de protection, les configurations d'appareil sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable.

7.7. USB

Si les appareils disposent d'un port USB, ils:

• DEVRAIT prendre en charge le mode périphérique USB et le mode hôte USB.

7.7.1. Mode périphérique USB

Si les implémentations d'appareils comprennent un port USB compatible avec le mode périphérique:

• [C-1-1] Le port DOIT être connecté à un hôte USB doté d'un port USB standard de type A ou de type C.
• [C-1-2] DOIT indiquer la valeur correcte de iSerialNumber dans le descripteur de périphérique USB standard via android.os.Build.SERIAL.
• [C-1-3] DOIT détecter les chargeurs de 1,5 A et 3 A conformément à la norme de résistance de type C, et DOIT détecter les changements dans l'annonce si ceux-ci sont compatibles avec un câble USB Type-C.
• [SR] Le port DOIT utiliser un facteur de forme micro-B, micro-AB ou USB de type C. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• [SR] Le port DOIT se trouver en bas de l'appareil (en fonction de l'orientation naturelle) ou activer la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), de sorte que l'écran s'affiche correctement lorsque l'appareil est orienté avec le port situé en bas. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir être mis à niveau vers les futures versions de la plate-forme.
• [SR] DEVRAIT mettre en œuvre la prise en charge d'un courant de 1,5 A pendant le bip et le trafic du haut-parleur, comme indiqué dans la version 1.2 des spécifications de recharge de batterie USB. Il est VIVEMENT RECOMMANDÉ de répondre à ces exigences sur les appareils Android nouveaux et existants, afin de pouvoir passer aux versions futures de la plate-forme.
• [SR] FORTEMENT RECOMMANDÉ de ne pas prendre en charge les méthodes de recharge propriétaires qui modifient la tension Vbus au-delà des niveaux par défaut, ou qui modifient les rôles du récepteur ou de la source, cela peut entraîner des problèmes d'interopérabilité avec les chargeurs ou les appareils compatibles avec les modes USB Power Delivery standards. Bien que cela soit considéré comme "VENTEMENT RECOMMANDÉ", dans les futures versions d'Android, nous pourrions EXÉCUTER tous les appareils de type C pour assurer une interopérabilité totale avec les chargeurs standards de type C.
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge Power Delivery pour les données et le changement de rôle d'alimentation lorsqu'ils prennent en charge les modes USB Type-C et hôte USB.
• DEVRAIT prendre en charge l'alimentation électrique pour la recharge haute tension et la prise en charge d'autres modes tels que l'affichage.
• DEVRAIT implémenter l'API Android Open Accessory (AOA) et sa spécification comme indiqué dans la documentation du SDK Android.

Si les implémentations d'appareils incluent un port USB et implémentent la spécification AOA, ils:

• [C-2-1] DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory.
• [C-2-2] La classe de stockage de masse USB DOIT inclure la chaîne "android" à la fin de la chaîne iInterface de la description de l'interface de la mémoire de stockage de masse USB.

7.7.2. Mode hôte USB

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

• [C-1-1] DOIT implémenter l'API hôte USB Android comme indiqué dans le SDK Android et DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.host.
• [C-1-2] DOIT implémenter la prise en charge de la connexion de périphériques USB standards. En d'autres termes, ils DOIVENT :
  • Disposer d'un port de type C intégré à l'appareil ou expédier vos produits avec un ou plusieurs câbles permettant d'adapter un port propriétaire de l'appareil à un port USB Type-C standard (appareil USB Type-C)
  • disposer d'un appareil de type A ou l'expédier avec un ou plusieurs câbles adaptant un port propriétaire de l'appareil à un port USB de type A standard ;
  • disposer d'un port micro-AB intégré, qui DOIT être livré avec un câble adapté à un port standard de type A ;
• [C-1-3] NE DOIT PAS être livré avec un adaptateur convertissant un port USB de type A ou micro-AB dans un port de type C (réceptacle).
• [SR] FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB comme indiqué dans la documentation du SDK Android.
• DOIT prendre en charge la recharge du périphérique USB connecté en mode hôte, indiquer un courant source d'au moins 1,5 A, comme indiqué dans la section sur les paramètres de terminaison de la révision 1.2 des spécifications du câble et du connecteur USB Type-C pour les connecteurs USB Type-C, ou utiliser une plage actuelle de sortie du port de recharge en aval(CDP) comme indiqué dans les spécifications de recharge de la batterie USB, révision AB 1.2 pour les connecteurs USB Type-C.
• DEVRAIT implémenter et prendre en charge les normes USB Type-C.

Si les implémentations d'appareils incluent un port USB compatible avec le mode hôte et la classe audio USB, ils:

• [C-2-1] DOIT être compatible avec la classe USB HID.
• [C-2-2] DOIT prendre en charge la détection et la mise en correspondance des champs de données HID suivants, spécifiés dans les tables d'utilisation USB HID et la requête d'utilisation des commandes vocales avec les constantes KeyEvent, comme indiqué ci-dessous :
  • ID d'utilisation (0x0CD) de la page d'utilisation (0xC): KEYCODE_MEDIA_PLAY_PAUSE
  • ID d'utilisation (0x0E9) de la page d'utilisation (0xC): KEYCODE_VOLUME_UP
  • ID d'utilisation de la page d'utilisation (0xC) (0x0EA): KEYCODE_VOLUME_DOWN
  • ID d'utilisation (0x0CF) de la page d'utilisation (0xC): KEYCODE_VOICE_ASSIST

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et le framework d'accès au stockage (SAF), elles:

• [C-3-1] DOIT reconnaître tous les appareils MTP (Media Transfer Protocol) connectés à distance et rendre leur contenu accessible via les intents ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT et ACTION_CREATE_DOCUMENT. .

Si les implémentations d'appareils comprennent un port USB compatible avec le mode hôte et l'USB Type-C, ceux-ci:

• [C-4-1] DOIT implémenter la fonctionnalité Port double rôle définie par la spécification USB Type-C (section 4.5.1.3.3).
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge DisplayPort, DEVRAIT prendre en charge les tarifs de données USB SuperSpeed, et il est VIVEMENT RECOMMANDÉ de prendre en charge Power Delivery pour le transfert de données et de rôle de l'alimentation.
• [SR] FORTEMENT RECOMMANDÉ DE NE PAS prendre en charge le mode accessoire de l'adaptateur audio, comme décrit dans l'annexe A de la révision 1.2 des spécifications relatives au câble et au connecteur USB Type-C.
• DEVRAIT implémenter le modèle try.* le plus adapté au facteur de forme de l'appareil. Par exemple, un appareil portable DEVRAIT implémenter le modèle try.SNK.

7.8. Son

Micro

Si les implémentations d'appareils incluent un micro, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.microphone.
• [C-1-2] DOIT respecter les exigences concernant l'enregistrement audio décrites dans la section 5.4.
• [C-1-3] DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• [SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge l'enregistrement par ultrasons proches, comme décrit dans la section 7.8.3.

Si l'intégration d'un appareil n'inclut pas de micro:

• [C-2-1] NE DOIT PAS signaler la constante de caractéristique android.hardware.microphone.
• [C-2-2] DOIT implémenter l'API d'enregistrement audio au moins comme no-ops, conformément à la section 7.

Sortie audio

Si les appareils incluent un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio, comme un connecteur audio 3,5 mm à 4 conducteurs ou un port en mode hôte USB utilisant la classe audio USB, ils:

• [C-1-1] DOIT indiquer la constante de caractéristique android.hardware.audio.output.
• [C-1-2] DOIT respecter les exigences relatives à la lecture audio décrites dans la section 5.5.
• [C-1-3] DOIT respecter les exigences de latence audio décrites dans la section 5.6.
• [SR] FORTEMENT RECOMMANDÉ de prendre en charge la lecture par ultrasons, comme décrit dans la section 7.8.3.

Si les appareils ne comprennent pas de haut-parleur ni de port de sortie audio:

• [C-2-1] NE DOIT PAS signaler la fonctionnalité android.hardware.audio.output.
• [C-2-2] DOIT implémenter les API liées à la sortie audio au moins comme no-ops.

Dans cette section, un "port de sortie" est une interface physique, telle qu'un connecteur audio 3,5 mm, un port HDMI ou un port en mode hôte USB avec classe audio USB. La prise en charge de sorties audio sur des protocoles basés sur la radio, tels que le Bluetooth, le Wi-Fi ou les réseaux mobiles, ne signifie pas qu'un "port de sortie" est inclus.

Ports audio analogiques

Pour être compatibles avec les casques audio et autres accessoires audio utilisant la prise audio 3, 5 mm dans l'écosystème Android, les implémentations d'appareils qui incluent un ou plusieurs ports audio analogiques:

• [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure au moins un des ports audio, un connecteur audio de 3,5 mm à 4 conducteurs.

Si les appareils sont équipés d'un connecteur audio 3, 5 mm à quatre conducteurs:

• [C-1-1] DOIT être compatible avec la lecture audio sur des casques stéréo et stéréo dotés d'un micro.
• [C-1-2] DOIT prendre en charge les prises audio TRRS dans l'ordre de broche CTIA.
• [C-1-3] DOIT prendre en charge la détection et la mise en correspondance des codes de clavier pour les trois plages suivantes d'impédance équivalente entre le micro et les conducteurs de terre sur la fiche audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohm: KEYCODE_VOLUME_UP
  • 360-680 ohm: KEYCODE_VOLUME_DOWN
• [C-1-4] DOIT déclencher ACTION_HEADSET_PLUG au moment d'insérer la fiche, mais seulement lorsque tous les contacts de la fiche touchent les segments correspondants sur le connecteur.
• [C-1-5] DOIT être capable de générer au moins 150 mV ± 10% de la tension de sortie sur une impédance de haut-parleur de 32 ohms.
• [C-1-6] DOIT avoir une tension de biais du micro comprise entre 1,8 V et 2,9 V.
• [C-1-7] DOIT détecter et mapper le code de clavier pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la fiche audio :
  • 110-180 ohm:KEYCODE_VOICE_ASSIST
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge les prises audio avec l'ordre de broche OMTP.
• [C-SR] sont FORTEMENT RECOMMANDÉS de prendre en charge les enregistrements audio à partir d'un casque stéréo doté d'un micro.

Si les implémentations d'appareils disposent d'un connecteur audio 3,5 mm à 4 conducteurs, sont compatibles avec un micro et diffusent l'android.intent.action.HEADSET_PLUG avec la valeur de micro supplémentaire définie sur 1, les appareils:

• [C-2-1] DOIT prendre en charge la détection du micro sur l'accessoire audio branché.

7.8.3. Presque ultra-sons

Le son proche par ultrasons correspond à la bande 18,5 kHz à 20 kHz.

Implémentations pour les appareils:

• DOIT indiquer correctement la prise en charge de la fonctionnalité audio proche ultrasons via l'API AudioManager.getProperty, comme suit:

Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", les sources audio VOICE_RECOGNITION et UNPROCESSED DOIVENT respecter les exigences suivantes:

• [C-1-1] La réponse de puissance moyenne du micro dans la bande de 18,5 kHz à 20 kHz DOIT être inférieure de 15 dB à la réponse à 2 kHz.
• [C-1-2] Le rapport signal/bruit non pondéré du microphone entre 18,5 kHz et 20 kHz pour un ton de 19 kHz à -26 dBFS DOIT ne pas être inférieur à 50 dB.

Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est "true" (vrai) :

• [C-2-1] La réponse moyenne du haut-parleur sur la plage de 18,5 kHz à 20 kHz DOIT être inférieure ou égale à 40 dB en dessous de la réponse à 2 kHz.

7.9. Réalité virtuelle

Android inclut des API et des installations permettant de créer des applications de "réalité virtuelle" (RV), y compris des expériences RV mobiles de haute qualité. Les implémentations d'appareils DOIVENT implémenter ces API et ces comportements correctement, comme indiqué dans cette section.

7.9.1. Mode Réalité virtuelle

Android prend en charge le mode RV, une fonctionnalité qui gère le rendu stéréoscopique des notifications et désactive les composants d'interface utilisateur du système monoculaire lorsqu'une application de RV est axée sur l'utilisateur.

7.9.2. Mode Réalité virtuelle - Hautes performances

Si les implémentations d'appareils sont compatibles avec le mode RV, ils:

• [C-1-1] DOIT comporter au moins deux cœurs physiques.
• [C-1-2] DOIT déclarer la fonctionnalité android.hardware.vr.high_performance.
• [C-1-3] DOIT prendre en charge le mode Performances soutenues.
• [C-1-4] DOIT être compatible avec OpenGL ES 3.2.
• [C-1-5] DOIT accepter android.hardware.vulkan.level 0.
• DEVRAIT prendre en charge android.hardware.vulkan.level 1 ou version ultérieure.
• [C-1-6] DOIT 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_OVR_multiview_multisampled_render_to_texture et GL_EXT_protected_textures, et exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter GL_EXT_external_buffer et GL_EXT_EGL_image_array, et d'exposer les extensions dans la liste des extensions GL disponibles.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge Vulkan 1.1.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'implémenter VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing et VK_KHR_shared_presentable_image, et de les exposer dans la liste des extensions Vulkan disponibles.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'exposer au moins une famille de files d'attente Vulkan dans laquelle flags contient à la fois VK_QUEUE_GRAPHICS_BIT et VK_QUEUE_COMPUTE_BIT, et queueCount est au moins égal à 2.
• [C-1-7] Le processeur graphique et l'écran DOIVENT être capables de synchroniser l'accès au tampon d'affichage partagé de sorte que le rendu alterné des contenus de réalité virtuelle à 60 images par seconde avec deux contextes de rendu s'affiche sans artefact de déchirure visible.
• [C-1-9] DOIT implémenter la prise en charge des options AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA et AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT, comme décrit dans le NDK.
• [C-1-10] DOIT implémenter la prise en charge des AHardwareBuffer avec n'importe quelle combinaison des indicateurs d'utilisation AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT pour au moins les formats suivants: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] Sont FORTEMENT RECOMMANDÉS pour prendre en charge l'allocation de AHardwareBuffer avec plusieurs couches et indicateurs et formats spécifiés dans C-1-10.
• [C-1-11] DOIT prendre en charge le décodage H.264 d'au moins 3 840 x 2 160 à 30 FPS, compressé à une moyenne de 40 Mbit/s (équivalent à 4 instances de 1 920 x 1 080 à 30 FPS-10 Mbit/s ou 2 instances de 1 920 x 6 Mbit/s à 1 920 x 10 Mbit/s).
• [C-1-12] DOIT être compatible avec les formats HEVC et VP9, DOIT être capable de décoder au moins 1 920 x 1 080 à 30 FPS compressés à une moyenne de 10 Mbit/s et DOIT être capable de décoder 3 840 x 2 160 à 30 FPS et 20 Mbit/s d'instances 0 FPS à 0 Mbit/s (équivalent de 0 Mbit/s à 0 Mbit/s).
• [C-1-13] DOIT prendre en charge l'API HardwarePropertiesManager.getDeviceTemperatures et renvoyer des valeurs de température cutanée précises.
• [C-1-14] DOIT disposer d'un écran intégré et sa résolution DOIT être au moins de 1 920 x 1 080.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser une résolution d'écran d'au moins 2 560 x 1 440 pixels.
• [C-1-15] L'écran DOIT mettre à jour une fréquence d'au moins 60 Hz en mode RV.
• [C-1-17] L'écran DOIT prendre en charge un mode à faible persistance avec une persistance inférieure ou égale à 5 millisecondes, la persistance étant définie comme la durée pendant laquelle un pixel émet de la lumière.
• [C-1-18] DOIT être compatible avec les technologies Bluetooth 4.2 et Bluetooth LE Data Length Extension section 7.4.3.
• [C-1-19] DOIT accepter et signaler correctement le type de canal direct pour tous les types de capteurs par défaut suivants :
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] Il est FORTEMENT RECOMMANDÉ de prendre en charge le type de canal direct TYPE_HARDWARE_BUFFER pour tous les types de canaux directs listés ci-dessus.
• [C-1-21] DOIT respecter les exigences liées au gyroscope, à l'accéléromètre et au magnétomètre pour la région android.hardware.hifi_sensors, comme indiqué dans la section 7.3.9.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser la fonctionnalité android.hardware.sensor.hifi_sensors.
• [C-1-22] DOIT avoir une latence du mouvement de bout en bout et des photons ne dépassant pas 28 millisecondes.
• [C-SR] Il est FORTEMENT RECOMMANDÉ que la latence du mouvement de bout en bout et du photon ne dépasse pas 20 millisecondes.
• [C-1-23] DOIT avoir un ratio de première image, c'est-à-dire le ratio entre la luminosité des pixels sur la première image après une transition du noir au blanc et la luminosité des pixels blancs à l'état stable (au moins 85 %).
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'utiliser un ratio de première image d'au moins 90%.
• PEUT fournir un cœur exclusif à l'application de premier plan et prendre en charge l'API Process.getExclusiveCores pour renvoyer le nombre de cœurs de processeur exclusifs à l'application de premier plan.

Si un cœur exclusif est pris en charge, le noyau:

• [C-2-1] NE DOIT PAS autoriser l'exécution d'autres processus de l'espace utilisateur sur celui-ci (à l'exception des pilotes de périphériques utilisés par l'application), mais PEUVENT permettre à certains processus du noyau de s'exécuter si nécessaire.

8. Performances et puissance

Certains critères minimaux de performances et de puissance sont essentiels à l'expérience utilisateur et ont un impact sur les hypothèses de base que les développeurs auraient lorsqu'ils développent une application.

8.1. Cohérence de l'expérience utilisateur

Une interface utilisateur fluide peut être proposée à l'utilisateur final si certaines conditions minimales sont requises pour garantir une fréquence d'images et des temps de réponse cohérents dans les applications et les jeux. Les implémentations d'appareils, selon le type d'appareil, PEUVENT comporter des exigences mesurables en termes de latence de l'interface utilisateur et de changement de tâche, comme décrit dans la section 2.

8.2. Performances d'accès aux E/S de fichiers

Fournir une référence commune pour des performances d'accès aux fichiers cohérentes dans le stockage de données privé de l'application (partition /data) permet aux développeurs d'applications de définir des attentes qui faciliteront la conception de leur logiciel. Les implémentations d'appareils, selon leur type, PEUVENT être soumises à certaines exigences décrites dans la section 2 concernant les opérations de lecture et d'écriture suivantes:

• Performances d'écriture séquentielle. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec un tampon d'écriture de 10 Mo.
• Performances d'écriture aléatoire. Mesure effectuée par l'écriture d'un fichier de 256 Mo avec un tampon d'écriture de 4 Ko.
• Performances de lecture séquentielle. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo avec un tampon d'écriture de 10 Mo.
• Performances de lecture aléatoire. Mesure effectuée à partir de la lecture d'un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 Ko.

8.3. Modes d'économie d'énergie

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

• [C-1-1] NE DOIT PAS déroger à l'implémentation AOSP pour les algorithmes de déclenchement, de maintenance et de wakeup, ni pour l'utilisation des paramètres système globaux des modes d'économie d'énergie App Standby et Sommeil.
• [C-1-2] NE DOIT PAS déroger à l'implémentation AOSP concernant l'utilisation de paramètres globaux pour la gestion de la limitation des tâches, des alarmes et du réseau pour les applications de chaque bucket en mode Mise en veille des applications.
• [C-1-3] NE DOIT PAS dévier de l'implémentation AOSP pour le nombre de buckets de mise en veille des applications utilisés pour la mise en veille des applications.
• [C-1-4] DOIT implémenter les buckets de mise en veille des applications et la fonctionnalité Sommeil comme décrit dans la section Gestion de l'alimentation.
• [C-1-5] DOIT renvoyer true pour PowerManager.isPowerSaveMode() lorsque l'appareil est en mode Économie d'énergie.
• [C-SR] SONT FORTEMENT RECOMMANDÉS de permettre à l'utilisateur d'activer et de désactiver l'économiseur de batterie.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de fournir une affordance à l'utilisateur pour afficher toutes les applications exemptées des modes Économie d'énergie et Mise en veille des applications.

En plus des modes d'économie d'énergie, les implémentations d'appareils Android PEUVENT implémenter l'un ou l'ensemble des quatre états de veille définis par l'ACPI (Advanced Configuration and Power Interface).

Si les implémentations d'appareils implémentent les états d'alimentation S4 tels que définis par l'ACPI, elles:

• [C-1-1] NE DOIT entrer dans cet état qu'après que l'utilisateur a effectué une action explicite pour désactiver l'appareil (par exemple, en fermant un capot qui fait partie physiquement de l'appareil, ou en éteignant un véhicule ou une télévision) et avant que l'utilisateur ne réactive l'appareil (par exemple, en ouvrant le capot ou en rallumant le véhicule ou la télévision).

Si les implémentations d'appareils implémentent les états d'alimentation S3 tels que définis par l'ACPI, elles:

• [C-2-1] DOIT respecter le code C-1-1 ci-dessus, ou DOIT passer à l'état S3 uniquement lorsque les applications tierces n'ont pas besoin des ressources système (par exemple, l'écran ou le processeur).

  À l'inverse, vous DEVEZ quitter l'état S3 lorsque les applications tierces ont besoin des ressources système, comme décrit dans le présent SDK.

  Par exemple, bien que les applications tierces demandent de maintenir l'écran allumé via FLAG_KEEP_SCREEN_ON ou de maintenir le processeur fonctionnant via PARTIAL_WAKE_LOCK, l'appareil NE DOIT PAS passer à l'état S3, sauf si, comme décrit dans C-1-1, l'utilisateur a pris des mesures explicites pour mettre l'appareil dans un état inactif. À l'inverse, lorsqu'une tâche implémentée par des applications tierces via JobScheduler est déclenchée ou lorsque Firebase Cloud Messaging est distribué à des applications tierces, l'appareil DOIT quitter l'état S3, sauf si l'utilisateur l'a désactivé. Ces exemples ne sont pas exhaustifs. AOSP implémente de nombreux signaux de wakeup qui déclenchent un wakeup à partir de cet état.

8.4. Comptabilisation de la consommation d'énergie

Avec une comptabilisation et des rapports plus précis sur la consommation d'énergie, le développeur de l'application bénéficie à la fois des incitations et des outils nécessaires pour optimiser le modèle de consommation d'énergie de l'application.

Implémentations pour les appareils:

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

8.5. Performances constantes

Les performances peuvent fluctuer considérablement pour les applications de longue durée très performantes, soit à cause des autres applications s'exécutant en arrière-plan, soit à cause de la limitation du processeur due aux limites de température. Android inclut des interfaces de programmation. Ainsi, lorsque l'appareil est compatible, l'application de premier plan peut demander au système d'optimiser l'allocation des ressources pour faire face à ces fluctuations.

Implémentations pour les appareils:

• [C-0-1] DOIT indiquer précisément la prise en charge du mode Performances soutenues via la méthode API PowerManager.isSustainedPerformanceModeSupported().

• DEVRAIT prendre en charge le mode Performances soutenues.

Si les implémentations d'appareils sont compatibles avec le mode Performances soutenues, elles:

• [C-1-1] DOIT fournir à l'application de premier plan un niveau de performances constant pendant au moins 30 minutes, lorsque l'application le demande.
• [C-1-2] DOIT respecter l'API Window.setSustainedPerformanceMode() et les autres API associées.

Si les implémentations d'appareils incluent au moins deux cœurs de processeur:

• DEVRAIT fournir au moins un cœur exclusif pouvant être réservé par l'application de premier plan supérieure.

Si les implémentations d'appareils permettent de réserver un cœur exclusif à l'application de premier plan, elles:

• [C-2-1] DOIT indiquer à l'aide de la méthode d'API Process.getExclusiveCores() les numéros d'identification des cœurs exclusifs qui peuvent être réservés par l'application de premier plan supérieure.
• [C-2-2] NE DOIT PAS autoriser les processus d'espace utilisateur, à l'exception des pilotes de périphériques utilisés par l'application, de s'exécuter sur les cœurs exclusifs. Cependant, certains processus du noyau PEUVENT s'exécuter si nécessaire.

Si les implémentations d'appareils ne sont pas compatibles avec un cœur exclusif, celles-ci:

• [C-3-1] DOIT renvoyer une liste vide via la méthode API Process.getExclusiveCores().

9. Compatibilité des modèles de sécurité

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API de la documentation pour les développeurs Android.

• [C-0-2] DOIT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers ou d'autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android. Plus précisément, ils DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK ; aucune autorisation ne peut être omise, modifiée ni ignorée.

• PEUT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne figurent pas dans l'espace de noms android.\*.

• [C-0-2] Les autorisations dont l'protectionLevel est PROTECTION_FLAG_PRIVILEGED NE DOIT être accordée qu'aux applications préinstallées dans le ou les chemins privilégiés de l'image système et dans le sous-ensemble d'autorisations explicitement ajoutées à la liste d'autorisation pour chaque application. L'implémentation AOSP répond à cette exigence en lisant et en honorant les autorisations de la liste d'autorisation pour chaque application à partir des fichiers du chemin etc/permissions/ et en utilisant le chemin system/priv-app comme chemin privilégié.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec une targetSdkVersion supérieure à 22 les demandent au moment de l'exécution.

Implémentations pour les appareils:

• [C-0-3] DOIT afficher une interface dédiée permettant à l'utilisateur de décider s'il doit accorder les autorisations d'exécution demandées et fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• [C-0-4] DOIT comporter une seule et unique implémentation des deux interfaces utilisateur.
• [C-0-5] NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf dans les cas suivants :
  • Le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise.
  • Les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut.
• [C-0-6] DOIT accorder l'autorisation android.permission.RECOVER_KEYSTORE uniquement aux applications système qui enregistrent un agent de récupération correctement sécurisé. Un agent de récupération correctement sécurisé est défini comme un agent logiciel sur l'appareil qui se synchronise avec un espace de stockage distant hors appareil. Il est équipé d'un matériel sécurisé dont la protection est équivalente ou supérieure à celle décrite dans le service Google Cloud Key Vault pour empêcher les attaques par force brute sur le facteur de connaissance de l'écran de verrouillage.

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

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

Si les implémentations d'appareils visent à interdire à certaines applications, y compris celles préinstallées, d'accéder aux statistiques d'utilisation:

• [C-1-1] DOIT toujours avoir une activité qui gère le modèle d'intent android.settings.ACTION_USAGE_ACCESS_SETTINGS, mais DOIT l'implémenter en tant qu'opération no-op, c'est-à-dire avoir le même comportement que lorsque l'accès de l'utilisateur est refusé.

9.2. UID et isolation de processus

Implémentations pour les appareils:

• [C-0-1] DOIT être compatible avec le modèle de bac à sable des applications Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct.
• [C-0-2] DOIT prendre en charge l'exécution de plusieurs applications avec le même ID utilisateur Linux, à condition que les applications soient correctement signées et construites, comme indiqué dans la documentation de référence sur la sécurité et les autorisations.

9.3. Autorisations du système de fichiers

Implémentations pour les appareils:

• [C-0-1] DOIT prendre en charge le modèle d'autorisations d'accès aux fichiers Android défini dans la documentation de référence sur la sécurité et les autorisations.

9.4. Autres environnements d'exécution

Les implémentations d'appareils DOIVENT maintenir la cohérence du modèle de sécurité et d'autorisation Android, même si elles incluent des environnements d'exécution qui exécutent des applications à l'aide d'un logiciel ou d'une technologie autres que le format exécutable Dalvik ou du code natif. Autrement dit :

• [C-0-1] Les environnements d'exécution alternatifs DOIVENT être des applications Android et respecter le modèle de sécurité Android standard, tel que décrit ailleurs dans la section 9.

• [C-0-2] Les environnements d'exécution alternatifs NE DOIVENT PAS être autorisés à accéder aux ressources protégées par des autorisations non demandées dans le fichier AndroidManifest.xml de l'environnement d'exécution via le mécanisme <uses-permission>.

• [C-0-3] Les environnements d'exécution alternatifs NE DOIVENT PAS permettre aux applications d'utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

• [C-0-4] Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android, et les applications installées qui utilisent un autre environnement d'exécution NE DOIVENT PAS réutiliser le bac à sable d'une autre application installée sur l'appareil, sauf via les mécanismes Android standards de partage de l'ID utilisateur et de certificat de signature.

• [C-0-5] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec les bacs à sable correspondant à d'autres applications Android, ni leur accorder ou obtenir l'accès.

• [C-0-6] Les environnements d'exécution alternatifs NE DOIVENT PAS être lancés avec d'autres applications, ni accordés, ni accordés à d'autres applications.

• [C-0-7] Lorsque les fichiers .apk des environnements d'exécution alternatifs sont inclus dans l'image système des implémentations d'appareils, ils DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses dans les implémentations d'appareils.

• [C-0-8] Lors de l'installation d'applications, les environnements d'exécution alternatifs DOIVENT obtenir le consentement de l'utilisateur pour les autorisations Android utilisées par l'application.

• [C-0-9] Lorsqu'une application doit utiliser une ressource d'appareil pour laquelle il existe une autorisation Android correspondante (telle que l'appareil photo, le GPS, etc.), l'environnement d'exécution alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource.

• [C-0-10] Lorsque l'environnement d'exécution n'enregistre pas les capacités des applications de cette manière, il DOIT répertorier toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

• D'autres environnements d'exécution DOIVENT installer des applications via PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).

• Les environnements d'exécution alternatifs PEUVENT fournir un seul bac à sable Android partagé par toutes les applications qui les utilisent.

9.5. Compatibilité multi-utilisateur

Android permet de gérer plusieurs utilisateurs et d'isoler complètement les utilisateurs.

• Les implémentations sur les appareils PEUVENT, mais NE DOIVENT PAS activer le mode multi-utilisateur s'ils utilisent des supports amovibles comme stockage externe principal.

Si les implémentations d'appareils incluent plusieurs utilisateurs:

• [C-1-1] DOIT respecter les exigences suivantes liées à la compatibilité multi-utilisateur.
• [C-1-2] DOIT, pour chaque utilisateur, implémenter un modèle de sécurité cohérent avec le modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API.
• [C-1-3] DOIT disposer d'un répertoire de stockage d'application partagé séparé et isolé (également appelé /sdcard) pour chaque instance d'utilisateur.
• [C-1-4] DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées pour celui-ci ne peuvent pas répertorier, lire ou écrire dans les fichiers appartenant à un autre utilisateur, même si les données des deux utilisateurs sont stockées sur le même volume ou système de fichiers.
• [C-1-5] DOIT chiffrer le contenu de la carte SD lorsque le mode multi-utilisateur est activé à l'aide d'une clé stockée uniquement sur un support non amovible accessible uniquement au système si les implémentations d'appareils utilisent des supports amovibles pour les API de stockage externe. Étant donné que le contenu multimédia deviendra ainsi illisible pour un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour permettre aux PC hôtes d'accéder aux données de l'utilisateur actuel.

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

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

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

• [C-3-1] NE DOIT PAS être compatible avec les profils à accès limité, mais DOIT s'aligner sur la mise en œuvre AOSP des contrôles permettant d'autoriser ou non d'autres utilisateurs à accéder aux appels vocaux et aux SMS.

9.6. Avertissement relatif aux SMS premium

Android permet d'avertir les utilisateurs de la réception d'un SMS premium. Les SMS premium sont des SMS envoyés à un service enregistré auprès d'un opérateur et susceptibles d'entraîner des frais pour l'utilisateur.

Si des implémentations d'appareils déclarent prendre en charge android.hardware.telephony, elles:

• [C-1-1] DOIT avertir les utilisateurs avant d'envoyer un SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité

Les implémentations d'appareils DOIVENT garantir la conformité avec les fonctionnalités de sécurité du noyau et de la plate-forme, comme décrit ci-dessous.

Le bac à sable Android inclut des fonctionnalités qui utilisent le système de contrôle des accès obligatoire (MAC) Security-Enhanced Linux (SELinux), le système de bac à sable seccomp et d'autres fonctionnalités de sécurité dans le noyau Linux. Implémentations pour les appareils:

• [C-0-1] DOIT maintenir la compatibilité avec les applications existantes, même lorsque SELinux ou toute autre fonctionnalité de sécurité sont implémentés en deçà de l'infrastructure Android.
• [C-0-2] NE DOIT PAS disposer d'une interface utilisateur visible lorsqu'une violation de sécurité est détectée et bloquée avec succès par la fonctionnalité de sécurité implémentée sous le framework Android, mais PEUT disposer d'une interface utilisateur visible en cas de non-respect de la sécurité débloqué, entraînant ainsi un exploit réussi.
• [C-0-3] NE DOIT PAS rendre SELinux ou toute autre fonctionnalité de sécurité implémentée en dessous du framework Android configurable pour l'utilisateur ou le développeur d'applications.
• [C-0-4] NE DOIT PAS permettre à une application pouvant affecter une autre application via une API (telle qu'une API Device Administration) de configurer une règle rompant la compatibilité.
• [C-0-5] DOIT diviser le framework multimédia en plusieurs processus afin qu'il soit possible d'accorder un accès plus restreint pour chaque processus, comme décrit sur le site du projet Android Open Source.
• [C-0-6] DOIT mettre en œuvre un mécanisme de bac à sable pour l'application du noyau permettant de filtrer les appels système à l'aide d'une règle configurable à partir de programmes multithread. Le projet Open Source Android en amont répond à cette exigence en activant seccomp-BPF avec la synchronisation des groupes de threads (TSYNC), comme décrit dans la section "Configuration du noyau" sur source.android.com.

Les fonctionnalités d'intégrité du noyau et d'auto-protection font partie intégrante de la sécurité Android. Implémentations pour les appareils:

• [C-0-7] DOIT implémenter des protections contre le dépassement de tampon de la pile du noyau (par exemple, CONFIG_CC_STACKPROTECTOR_STRONG).
• [C-0-8] DOIT mettre en œuvre des protections strictes de la mémoire du noyau où le code exécutable est en lecture seule, les données en lecture seule ne sont pas exécutables ni en écriture, et les données accessibles en écriture ne sont pas exécutables (par exemple, CONFIG_DEBUG_RODATA ou CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] DOIT implémenter une vérification des limites de taille d'objet statique et dynamique des copies entre l'espace utilisateur et l'espace noyau (par exemple, CONFIG_HARDENED_USERCOPY) sur les appareils livrés à l'origine avec le niveau d'API 28 ou supérieur.
• [C-0-10] NE DOIT PAS exécuter la mémoire de l'espace utilisateur lors de l'exécution en mode noyau (par exemple, avec le PXN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur des appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-11] NE DOIT PAS lire ni écrire de mémoire de l'espace utilisateur dans le noyau en dehors des API d'accès à la copie utilisateur normales (par exemple, le PAN matériel, ou émulé via CONFIG_CPU_SW_DOMAIN_PAN ou CONFIG_ARM64_SW_TTBR0_PAN) sur les appareils livrés avec le niveau d'API 28 ou supérieur.
• [C-0-12] DOIT implémenter l'isolation des tables de pages du noyau sur tous les appareils livrés à l'origine avec un niveau d'API 28 ou supérieur (par exemple, CONFIG_PAGE_TABLE_ISOLATION ou `CONFIG_UNMAP_KERNEL_AT_EL0).
• [SR] FORTEMENT RECOMMANDÉ de conserver les données du noyau qui ne sont écrites que lors de l'initialisation et qui sont marquées en lecture seule après l'initialisation (par exemple, __ro_after_init).
• [SR] FORTEMENT RECOMMANDÉ de randomiser la disposition du code et de la mémoire du noyau, et d'éviter toute exposition qui pourrait compromettre la randomisation (par exemple, CONFIG_RANDOMIZE_BASE avec l'entropie du bootloader via /chosen/kaslr-seed Device Tree node ou EFI_RNG_PROTOCOL).

Si les implémentations d'appareils utilisent un noyau Linux, elles:

• [C-1-1] DOIT implémenter SELinux.
• [C-1-2] DOIT définir SELinux sur le mode d'application global.
• [C-1-3] DOIT configurer tous les domaines en mode "Enforcing". Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/fournisseur.
• [C-1-4] NE DOIT PAS modifier, omettre ni remplacer les règles "Neverallow" présentes dans le dossier "system/sepolicy" fourni dans le projet Android Open Source (AOSP) en amont. De plus, la règle DOIT se compiler avec toutes les règles "Neverallow" présentes, à la fois pour les domaines AOSP SELinux et pour les domaines spécifiques à l'appareil ou au fournisseur.
• [C-1-5] DOIT exécuter des applications tierces ciblant le niveau d'API 28 ou supérieur dans des bacs à sable SELinux par application, avec des restrictions SELinux par application sur le répertoire de données privé de chaque application.
• DEVRAIT conserver la règle SELinux par défaut fournie dans le dossier system/sepolicy du projet Android Open Source en amont et n'ajouter à cette règle que pour leur propre configuration spécifique à l'appareil.

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

Si les implémentations d'appareils utilisent un noyau autre que Linux:

• [C-2-1] DOIT utiliser un système de contrôle des accès obligatoire équivalent à SELinux.

Android contient plusieurs fonctionnalités de défense en profondeur qui font partie intégrante de la sécurité des appareils.

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de ne pas désactiver l'intégrité du flux de contrôle (CFI) ni la suppression du dépassement d'entiers (IntSan) sur les composants pour lesquels elle est activée.
• [C-SR] Il est FORTEMENT RECOMMANDÉ d'activer CFI et IntSan pour tout composant supplémentaire de l'espace utilisateur sensible à la sécurité, comme expliqué dans CFI et IntSan.

9.8. Confidentialité

9.8.1. Historique d'utilisation

Android stocke l'historique des choix de l'utilisateur et gère cet historique via UsageStatsManager.

Implémentations pour les appareils:

• [C-0-1] DOIT conserver une durée de conservation raisonnable de cet historique utilisateur.
• [SR] Il est FORTEMENT RECOMMANDÉ de conserver la période de conservation de 14 jours telle qu'elle est configurée par défaut dans l'implémentation d'AOSP.

Android stocke les événements système à l'aide des identifiants StatsLog et gère cet historique via StatsManager et l'API système IncidentManager.

Implémentations pour les appareils:

• [C-0-2] DOIT inclure uniquement les champs marqués d'un DEST_AUTOMATIC dans le rapport d'incident créé par la classe IncidentManager de l'API System.
• [C-0-3] NE DOIT PAS utiliser les identifiants d'événements système pour enregistrer d'autres événements que ceux décrits dans les documents du SDK StatsLog. Si d'autres événements système sont consignés, ils PEUVENT utiliser un identifiant atomique différent compris entre 100 000 et 200 000.

9.8.2. Enregistrement…

Implémentations pour les appareils:

• [C-0-1] NE DOIT PAS précharger ni distribuer de composants logiciels prêts à l'emploi qui envoient des informations privées de l'utilisateur (par exemple, les frappes au clavier ou le texte affiché à l'écran) hors de l'appareil sans l'autorisation de l'utilisateur ou sans lui envoyer de notifications claires en cours.

Si les implémentations d'appareils incluent une fonctionnalité dans le système qui capture le contenu affiché à l'écran et/ou enregistre le flux audio lu sur l'appareil, elles:

• [C-1-1] DOIT recevoir une notification permanente à l'utilisateur chaque fois que cette fonctionnalité est activée et qu'elle capture ou enregistre activement des vidéos.

Si les implémentations d'appareils incluent un composant prêt à l'emploi, capable d'enregistrer le son ambiant pour déduire des informations utiles sur le contexte de l'utilisateur:

• [C-2-1] NE DOIT PAS stocker dans un espace de stockage persistant sur l'appareil ni transmettre hors de l'appareil le contenu audio brut enregistré ou tout autre format pouvant être reconverti en contenu audio d'origine ou en télécopie, sauf avec le consentement explicite de l'utilisateur.

9.8.3. Connectivité

Si les appareils disposent d'un port USB compatible avec le mode périphérique USB, ils:

• [C-1-1] DOIT présenter une interface utilisateur demandant l'autorisation de l'utilisateur avant d'autoriser l'accès au contenu de la mémoire de stockage partagée via le port USB.

9.8.4. Trafic réseau

Implémentations pour les appareils:

• [C-0-1] DOIT préinstaller pour le magasin de l'autorité de certification approuvé par le système les mêmes certificats racine que ceux fournis en amont dans le projet Android Open Source en amont.
• [C-0-2] DOIT être livré avec un magasin d'autorités de certification racine d'utilisateur vide.
• [C-0-3] DOIT afficher un avertissement indiquant à l'utilisateur que le trafic réseau peut être surveillé, lorsqu'une autorité de certification racine est ajoutée.

Si le trafic de l'appareil est acheminé via un VPN, les implémentations d'appareils:

• [C-1-1] DOIT afficher un avertissement à l'utilisateur indiquant :
  • Ce trafic réseau peut être surveillé.
  • Ce trafic réseau est acheminé via l'application VPN spécifique qui fournit le VPN.

Si les implémentations d'appareils disposent d'un mécanisme, activé automatiquement par défaut, qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN (par exemple, le préchargement d'un service VPN avec android.permission.CONTROL_VPN accordé), elles:

• [C-2-1] DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme, sauf si le VPN est activé par le responsable du contrôle des règles relatives aux appareils via DevicePolicyManager.setAlwaysOnVpnPackage(). Dans ce cas , l'utilisateur n'a pas besoin de fournir un consentement distinct, mais il DOIT seulement être notifié.

Si les implémentations d'appareils implémentent une affordance utilisateur pour activer la fonction "VPN permanent" d'une application VPN tierce, elles:

• [C-3-1] DOIT désactiver cette affordance utilisateur pour les applications qui n'acceptent pas le service VPN permanent dans le fichier AndroidManifest.xml en définissant l'attribut SERVICE_META_DATA_SUPPORTS_ALWAYS_ON sur false.

9.9. Chiffrement du stockage des données

Si les performances de chiffrement AES (Advanced Encryption Standard), mesurées à l'aide de la technologie AES la plus performante disponible sur l'appareil (par exemple, les extensions de chiffrement ARM), sont supérieures à 50 Mio/s, les implémentations d'appareil:

• [C-1-1] DOIT prendre en charge le chiffrement du stockage des données privées de l'application (partition /data), ainsi que la partition de stockage partagé de l'application (partition /sdcard) s'il s'agit d'une partie permanente et non amovible de l'appareil, à l'exception des implémentations d'appareils qui sont généralement partagées (par exemple, la télévision).
• [C-1-2] DOIT activer le chiffrement du stockage des données par défaut au moment de la configuration initiale de l'utilisateur, sauf pour les implémentations d'appareils qui sont généralement partagées (par exemple, un téléviseur).

[Si les performances de chiffrement AES sont inférieures ou égales à 50 Mio/s, les implémentations d'appareils PEUVENT utiliser Adiantum-XChaCha12-AES au lieu de la forme AES indiquée dans l'un des éléments suivants: AES-256-XTS dans Section 9.9.2 [C-1-5]; AES-256 in CBS-CTS.

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 requises par le biais d'une mise à jour logicielle système, elles PEUVENT être exemptées des exigences ci-dessus.

Implémentations pour les appareils:

• DEVRAIT respecter les exigences de chiffrement du stockage des données ci-dessus en implémentant le chiffrement basé sur les fichiers (FBE).

9.9.1. Démarrage direct

Implémentations pour les appareils:

• [C-0-1] DOIT implémenter les API en mode Démarrage direct, même si elles ne sont pas compatibles avec le chiffrement du stockage.

• [C-0-2] Les intents ACTION_LOCKED_BOOT_COMPLETED et ACTION_USER_UNLOCKED DOIVENT toujours être diffusés pour signaler aux applications compatibles avec le démarrage direct que des emplacements de stockage chiffrés sur les appareils (DE) et CE (identifiants chiffrés) sont disponibles pour l'utilisateur.

9.9.2. Chiffrement basé sur les fichiers

Si les implémentations d'appareils sont compatibles avec FBE, ils:

• [C-1-1] DOIT démarrer sans demander d'identifiants à l'utilisateur et autoriser les applications compatibles avec le démarrage direct à accéder à l'espace de stockage DE (Device Encrypted) une fois le message ACTION_LOCKED_BOOT_COMPLETED diffusé.
• [C-1-2] DOIT autoriser l'accès à l'espace de stockage CE (Identifiants chiffrés) uniquement après que l'utilisateur a déverrouillé l'appareil en fournissant ses identifiants (par exemple, code secret, code, schéma ou empreinte) et que le message ACTION_USER_UNLOCKED est diffusé.
• [C-1-3] NE DOIT PAS proposer de méthode pour déverrouiller le stockage protégé par des certificats CE sans les identifiants fournis par l'utilisateur ni une clé de séquestre enregistrée.
• [C-1-4] DOIT être compatible avec le démarrage validé et s'assurer que les clés DE sont liées de manière cryptographique à la racine de confiance matérielle de l'appareil.
• [C-1-5] DOIT prendre en charge le chiffrement du contenu des fichiers à l'aide de l'algorithme AES-256-XTS. AES-256-XTS fait référence à la norme Advanced Encryption Standard avec une longueur de clé de 256 bits et fonctionne en mode XTS. La longueur totale de la clé XTS est de 512 bits.

• [C-1-6] DOIT prendre en charge le chiffrement des noms de fichiers à l'aide de l'algorithme AES-256 en mode CBC-CTS.

• Clés protégeant les espaces de stockage CE et DE:

• [C-1-7] DOIT être lié de manière cryptographique à un keystore intégré au matériel.

• [C-1-8] Les clés CE DOIVENT être liées aux identifiants de l'écran de verrouillage d'un utilisateur.
• [C-1-9] Les clés CE DOIVENT être liées à un code secret par défaut lorsque l'utilisateur n'a pas spécifié d'identifiants d'écran de verrouillage.

• [C-1-10] DOIT être unique et distinct, c'est-à-dire que la clé CE ou DE d'un utilisateur ne correspond pas aux clés CE ou DE d'un autre utilisateur.

• [C-1-11] DOIT utiliser par défaut les algorithmes de chiffrement, les longueurs de clé et les modes obligatoires.

• [C-SR] Il est FORTEMENT RECOMMANDÉ de chiffrer les métadonnées du système de fichiers, telles que la taille des fichiers, la propriété, les modes et les attributs étendus (xattrs), avec une clé cryptographiquement liée à la racine matérielle de confiance de l'appareil.

• DEVRAIT faire en sorte que les applis essentielles préinstallées (par exemple, Alarme, Téléphone, Messenger) prennent en charge le démarrage direct.

• PEUT prendre en charge d'autres algorithmes de chiffrement, longueurs de clés et modes de chiffrement du contenu et des noms de fichiers.

Le projet Android Open Source en amont fournit une implémentation à privilégier pour cette fonctionnalité, basée sur la fonctionnalité de chiffrement ext4 du noyau Linux.

9.9.3. Chiffrement complet du disque

Si les implémentations d'appareils sont compatibles avec le chiffrement complet du disque:

• [C-1-1] DOIT utiliser l'algorithme AES dans un mode conçu pour le stockage (XTS ou CBC-ESSIV, par exemple) et avec une clé de chiffrement d'une longueur de 128 bits ou plus.
• [C-1-2] DOIT utiliser un code secret par défaut pour encapsuler la clé de chiffrement et NE DOIT PAS écrire la clé de chiffrement dans l'espace de stockage sans avoir été chiffrée.
• [C-1-3] DOIT chiffrer la clé de chiffrement par défaut avec AES, sauf si l'utilisateur désactive explicitement cette fonctionnalité, sauf lorsqu'elle est en cours d'utilisation active, avec les identifiants de l'écran de verrouillage étirés à l'aide d'un algorithme d'étirement lent (par exemple, PBKDF2 ou scrypt).
• [C-1-4] L'algorithme d'étirement de mot de passe par défaut ci-dessus DOIT être lié de manière cryptographique à ce keystore lorsque l'utilisateur n'a pas spécifié d'identifiants d'écran de verrouillage ou a désactivé l'utilisation du code secret pour le chiffrement et que l'appareil fournit un keystore intégré au matériel.
• [C-1-5] NE DOIT PAS envoyer de clé de chiffrement depuis l'appareil (même si elle est encapsulée avec le code secret de l'utilisateur et/ou la clé associée au matériel).

Le projet Open Source Android en amont fournit une implémentation privilégiée de cette fonctionnalité, basée sur la fonctionnalité de noyau Linux dm-crypt.

9.10. Intégrité de l'appareil

Les exigences suivantes assurent la transparence de l'état de l'intégrité de l'appareil. Implémentations pour les appareils:

• [C-0-1] DOIT indiquer correctement, à l'aide de la méthode PersistentDataBlockManager.getFlashLockState() de l'API système, si l'état du bootloader permet de flasher l'image système. L'état FLASH_LOCK_UNKNOWN est réservé aux implémentations d'appareils qui effectuent une mise à niveau à partir d'une version antérieure d'Android où cette nouvelle méthode d'API système n'existait pas.

• [C-0-2] DOIT être compatible avec le démarrage validé pour assurer l'intégrité de l'appareil.

Si des implémentations d'appareils sont déjà lancées sans être compatibles avec le démarrage validé sur une version antérieure d'Android et qu'il n'est pas possible d'ajouter la prise en charge de cette fonctionnalité avec une mise à jour logicielle système, elles PEUVENT être exemptées de cette exigence.

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si les implémentations d'appareils sont compatibles avec la fonctionnalité, ils:

• [C-1-1] DOIT déclarer l'indicateur de fonctionnalité de la plate-forme android.software.verified_boot.
• [C-1-2] DOIT effectuer une vérification sur chaque séquence de démarrage.
• [C-1-3] DOIT commencer la validation à partir d'une clé matérielle immuable qui est la racine de confiance et aller jusqu'à la partition système.
• [C-1-4] DOIT mettre en œuvre chaque étape de vérification pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code lors de l'étape suivante.
• [C-1-5] DOIT utiliser des algorithmes de vérification aussi performants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clés publiques (RSA-2048).
• [C-1-6] NE DOIT PAS autoriser le démarrage en cas d'échec de la vérification du système, sauf si l'utilisateur consent à tenter quand même de démarrer. Dans ce cas, les données des blocs de stockage non validés NE DOIVENT pas être utilisées.
• [C-1-7] NE DOIT PAS autoriser la modification des partitions validées sur l'appareil, sauf si l'utilisateur a explicitement déverrouillé le bootloader.
• [C-SR] Si l'appareil comporte plusieurs puces discrètes (par exemple, un processeur radio ou un processeur d'image spécialisé), le processus de démarrage de chacune d'elles est VIVEMENT RECOMMANDÉ pour vérifier chaque étape au démarrage.
• [C-1-8] DOIT utiliser un espace de stockage inviolable pour indiquer si le bootloader est déverrouillé. Ce type de stockage signifie que le bootloader peut détecter si le stockage a été altéré depuis Android.
• [C-1-9] DOIT envoyer une invite à l'utilisateur lorsque vous utilisez l'appareil et exiger une confirmation physique avant d'autoriser la transition du mode verrouillé bootloader au mode déverrouillé du chargeur de démarrage.
• [C-1-10] DOIT implémenter une protection contre le rollback pour les partitions utilisées par Android (ex. : démarrage, partitions système) et utiliser un système de stockage inviolable pour stocker les métadonnées servant à déterminer la version minimale autorisée du système d'exploitation.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier tous les fichiers APK d'application privilégiés avec une chaîne de confiance racine dans /system, qui est protégée par le démarrage validé.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de vérifier tous les artefacts exécutables chargés par une application privilégiée en dehors de son fichier APK (comme le code chargé dynamiquement ou le code compilé) avant de les exécuter, ou de ne pas les exécuter du tout.
• DEVRAIT mettre en œuvre une protection contre le rollback pour tout composant doté d'un micrologiciel persistant (modem, appareil photo, par exemple) et utiliser un système de stockage avec système d'inviolabilité pour stocker les métadonnées utilisées pour déterminer la version minimale autorisée.

Si les implémentations d'appareils sont déjà lancées sans prendre en charge les versions C-1-8 à C-1-10 sur une version antérieure d'Android et qu'une mise à jour logicielle système ne permet pas de répondre à ces exigences, elles PEUVENT être exemptées.

Le projet Open Source Android en amont offre une implémentation privilégiée de cette fonctionnalité dans le dépôt external/avb/, qui peut être intégré au bootloader utilisé pour charger Android.

Implémentations pour les appareils:

• [C-R] Il est RECOMMANDÉ de prendre en charge l'API Android Protected Confirmation.

Si les implémentations d'appareils sont compatibles avec l'API Android Protected Confirmation:

• [C-3-1] DOIT signaler true pour l'API ConfirmationPrompt.isSupported().
• [C-3-2] DOIT s'assurer que le matériel sécurisé prend le contrôle total de l'écran, de sorte que l'OS Android ne peut pas le bloquer sans le détecter.
• [C-3-3] DOIT s'assurer que le matériel sécurisé prend le contrôle total de l'écran tactile.

9.11. Clés et identifiants

Le système Android Keystore permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations de chiffrement via l'API KeyChain ou l'API Keystore. Implémentations pour les appareils:

• [C-0-1] DOIT autoriser l'importation ou la génération d'au moins 8 192 clés.
• [C-0-2] L'authentification de l'écran de verrouillage DOIT limiter le nombre de tentatives et DOIT comporter un algorithme d'intervalle exponentiel entre les tentatives. Au-delà de 150 tentatives infructueuses, le délai DOIT être d'au moins 24 heures par tentative.
• NE DEVRAIT pas limiter le nombre de clés pouvant être générées

Lorsque l'implémentation de l'appareil est compatible avec l'utilisation d'un écran de verrouillage sécurisé:

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

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

9.11.1. Écran de verrouillage sécurisé

L’implémentation d’AOSP suit un modèle d’authentification à plusieurs niveaux dans lequel une authentification principale basée sur une usine de connaissances peut reposer soit sur une biométrie secondaire forte, soit sur des modalités tertiaires plus faibles.

Implémentations pour les appareils:

• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir une seule des méthodes suivantes comme méthode d'authentification principale :
  • Un code PIN numérique
  • Un mot de passe alphanumérique
  • Schéma de balayage sur une grille contenant exactement 3 x 3 points

Notez que les méthodes d'authentification ci-dessus sont désignées comme les principales méthodes d'authentification recommandées dans ce document.

Si les implémentations d'appareils ajoutent ou modifient les principales méthodes d'authentification recommandées et utilisent une nouvelle méthode d'authentification comme moyen sécurisé de verrouiller l'écran, la nouvelle méthode d'authentification:

• [C-2-1] DOIT être la méthode d'authentification de l'utilisateur décrite dans la section Exiger l'authentification de l'utilisateur pour l'utilisation des clés.
• [C-2-2] DOIT déverrouiller toutes les clés qu'une application de développement tierce doit utiliser lorsque l'utilisateur déverrouille l'écran de verrouillage sécurisé. Par exemple, toutes les clés DOIVENT être disponibles pour une application de développement tierce via les API pertinentes, telles que createConfirmDeviceCredentialIntent et setUserAuthenticationRequired.

Si les implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage (à condition qu'elles soient basées sur un secret connu) et utilisent une nouvelle méthode d'authentification à considérer comme un moyen sécurisé de verrouiller l'écran:

• [C-3-1] L'entropie de la longueur d'entrées la plus courte DOIT être supérieure à 10 bits.
• [C-3-2] L'entropie maximale de toutes les entrées possibles DOIT être supérieure à 18 bits.
• [C-3-3] La nouvelle méthode d'authentification NE DOIT PAS remplacer aucune des méthodes d'authentification principales recommandées (code, schéma, mot de passe) implémentées et fournies dans l'AOSP.
• [C-3-4] La nouvelle méthode d'authentification DOIT être désactivée lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_SOMETHING.

Si les implémentations d'appareils ajoutent ou modifient les principales méthodes d'authentification recommandées pour déverrouiller l'écran de verrouillage et utilisent une nouvelle méthode d'authentification basée sur la biométrie à traiter comme un moyen sécurisé de verrouiller l'écran, la nouvelle méthode:

• [C-4-1] DOIT respecter toutes les exigences décrites dans la section 7.3.10.2.
• [C-4-2] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui est basée sur un secret connu.
• [C-4-3] DOIT être désactivé et n'autoriser l'authentification principale recommandée pour déverrouiller l'écran que lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle de protection en appelant la méthode DevicePolicyManager.setKeyguardDisabledFeatures() , avec l'un des indicateurs biométriques associés (par exemple, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE ou KEYGUARD_DISABLE_IRIS).
• [C-4-4] DOIT inviter l'utilisateur à effectuer l'authentification principale recommandée (code, schéma, mot de passe, etc.) au moins une fois toutes les 72 heures.
• [C-4-5] DOIT avoir un taux de faux taux d'acceptation égal ou supérieur à celui requis pour un lecteur d'empreinte digitale, tel que décrit dans la section 7.3.10. Il DOIT être désactivé et n'autoriser l'authentification principale recommandée pour déverrouiller l'écran que lorsque l'application de contrôle des règles relatives aux appareils (DPC) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-SR] Il est FORTEMENT RECOMMANDÉ de définir des taux d'acceptation de spoofing et d'imposteurs égaux ou supérieurs à ceux requis pour un lecteur d'empreinte digitale, comme décrit dans la section 7.3.10.
• [C-4-6] DOIT disposer d'un pipeline de traitement sécurisé, de sorte qu'un piratage du système d'exploitation ou du noyau ne permette pas l'injection directe de données pour s'authentifier à tort en tant qu'utilisateur.
• [C-4-7] DOIT être associé à une action de confirmation explicite (appuyer sur un bouton, par exemple) pour autoriser l'accès aux clés du keystore si l'application définit true pour KeyGenParameterSpec.Built.setUserAuthenticationRequired() et que la biométrie est passive (par exemple, le visage ou l'iris, alors qu'aucun signal explicite d'intention n'est disponible).
• [C-SR] Il est FORTEMENT RECOMMANDÉ de sécuriser l'action de confirmation pour la biométrie passive afin qu'un système d'exploitation ou un noyau ne puisse pas en usurper l'identité. Par exemple, cela signifie que l'action de confirmation basée sur un bouton physique est acheminée via une broche GPIO (entrée uniquement) d'un élément sécurisé (SE) qui ne peut être pilotée que par une pression sur un bouton physique.

Si les méthodes d'authentification biométrique ne répondent pas aux taux d'acceptation de spoofing et d'imposteurs décrits dans la section 7.3.10:

• [C-5-1] Les méthodes DOIVENT être désactivées si l'application DPC (Device Policy Controller) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_BIOMETRIC_WEAK.
• [C-5-2] L'utilisateur DOIT être invité à procéder à l'authentification principale recommandée (par code, schéma ou mot de passe, par exemple) après un délai d'inactivité de quatre heures. Le délai d'inactivité est réinitialisé dès que les identifiants de l'appareil sont confirmés.
• [C-5-3] Les méthodes NE DOIVENT PAS être traitées comme un écran de verrouillage sécurisé et DOIVENT respecter les exigences commençant par C-8 dans la présente section ci-dessous.

Si des implémentations d'appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage et qu'une nouvelle méthode d'authentification est basée sur un jeton physique ou sur l'emplacement:

• [C-6-1] Ils DOIVENT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées, qui repose sur un secret connu et remplit les conditions requises pour être considéré comme un écran de verrouillage sécurisé.
• [C-6-2] La nouvelle méthode DOIT être désactivée et n'autoriser que l'une des méthodes d'authentification principales recommandées pour déverrouiller l'écran lorsque l'application DPC (Device Policy Controller) a défini la règle avec la méthode DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) ou la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
• [C-6-3] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principales recommandées (par code, schéma ou mot de passe, par exemple) au moins une fois toutes les 72 heures.
• [C-6-4] La nouvelle méthode NE DOIT PAS être traitée comme un écran de verrouillage sécurisé et DOIT respecter les contraintes indiquées dans C-8 ci-dessous.

Si les implémentations d'appareils disposent d'un écran de verrouillage sécurisé et incluent un ou plusieurs agents de confiance qui implémentent l'API système TrustAgentService, ils:

• [C-7-1] DOIT avoir une indication claire dans le menu des paramètres et sur l'écran de verrouillage lorsque le verrouillage de l'appareil est différé ou qu'il peut être déverrouillé par un ou plusieurs agents de confiance. Par exemple, AOSP répond à cette exigence en affichant une description textuelle pour les paramètres "Verrouiller automatiquement" et "Verrouillage instantané" dans le menu des paramètres, ainsi qu'une icône permettant de vous distinguer sur l'écran de verrouillage.
• [C-7-2] DOIT respecter et implémenter intégralement toutes les API d'agent de confiance dans la classe DevicePolicyManager, comme la constante KEYGUARD_DISABLE_TRUST_AGENTS.
• [C-7-3] NE DOIT PAS implémenter entièrement la fonction TrustAgentService.addEscrowToken() sur un appareil utilisé comme appareil personnel principal (par exemple, portable), mais PEUT-ÊTRE l'implémenter complètement sur des implémentations d'appareils généralement partagées (par exemple, Android Television ou Android Automotive).
• [C-7-4] DOIT chiffrer tous les jetons stockés ajoutés par TrustAgentService.addEscrowToken().
• [C-7-5] NE DOIT PAS stocker la clé de chiffrement sur le même appareil que celui où elle est utilisée. Par exemple, une clé stockée sur un téléphone peut déverrouiller un compte utilisateur sur un téléviseur.
• [C-7-6] DOIT informer l'utilisateur des implications en termes de sécurité avant d'autoriser le jeton de séquestre à déchiffrer le stockage de données.
• [C-7-7] DOIT disposer d'un mécanisme de secours pour utiliser l'une des méthodes d'authentification principales recommandées.
• [C-7-8] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma ou mot de passe) au moins une fois toutes les 72 heures.
• [C-7-9] L'utilisateur DOIT être invité à utiliser l'une des méthodes d'authentification principale recommandées (par exemple, code, schéma ou mot de passe) après un délai d'inactivité de quatre heures. Le délai d'inactivité est réinitialisé dès que les identifiants de l'appareil sont confirmés.
• [C-7-10] NE DOIT PAS être traité comme un écran de verrouillage sécurisé et DOIT respecter les contraintes indiquées dans le document C-8 ci-dessous.

Si les appareils ajoutent ou modifient des méthodes d'authentification pour déverrouiller l'écran de verrouillage qui n'est pas un écran de verrouillage sécurisé, comme décrit ci-dessus, et utilisent une nouvelle méthode d'authentification pour déverrouiller le verrouillage du clavier:

• [C-8-1] La nouvelle méthode DOIT être désactivée lorsque l'application DPC (Device Policy Controller) a défini la règle de qualité du mot de passe via la méthode DevicePolicyManager.setPasswordQuality() avec une constante de qualité plus restrictive que PASSWORD_QUALITY_UNSPECIFIED.
• [C-8-2] Il NE DOIT PAS réinitialiser les délais d'expiration du mot de passe définis par DevicePolicyManager.setPasswordExpirationTimeout().
• [C-8-3] Ils NE DOIVENT PAS authentifier l'accès aux keystores lorsque l'application définit true pour KeyGenParameterSpec.Builder.setUserAuthenticationRequired().

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.

Implémentations pour les appareils:

• [C-SR] SONT FORTEMENT RECOMMANDÉS de prendre en charge StrongBox.

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

• [C-1-1] DOIT déclarer FEATURE_STRONGBOX_KEYSTORE.

• [C-1-2] DOIT fournir du matériel sécurisé dédié pour sauvegarder le keystore et sécuriser l'authentification des utilisateurs.

• [C-1-3] DOIT disposer d'un processeur distinct qui ne partage aucun cache, ni aucune mémoire vive (DRAM), coprocesseur ou autre ressource principale avec le processeur d'application (PA).

• [C-1-4] DOIT s'assurer que les périphériques partagés avec le point d'accès ne peuvent en aucun cas modifier le traitement de StrongBox, ni obtenir d'informations à partir de celui-ci. Le point d'accès PEUT désactiver ou bloquer l'accès à StrongBox.

• [C-1-5] DOIT disposer d'une horloge interne avec une précision raisonnable (+-10%) et immunisée contre la manipulation par le point d'accès.

• [C-1-6] DOIT disposer d'un véritable générateur de nombres aléatoires produisant une sortie imprévisible et distribuée de manière uniforme.

• Les [C-1-7] DOIVENT disposer d'une résistance à la falsification, y compris à la pénétration physique et aux glitchs.

• [C-1-8] DOIT disposer d'une résistance du canal latéral, y compris la résistance aux fuites d'informations via les canaux latéraux de puissance, de temporisation, de rayonnement électromagnétique et de rayonnement thermique.

• [C-1-9] DOIT disposer d'un stockage sécurisé qui garantit la confidentialité, l'intégrité, l'authenticité, la cohérence et l'actualisation des contenus. L'espace de stockage NE DOIT PAS être lu ni modifié, sauf dans les cas autorisés par les API StrongBox.

• Pour valider la conformité avec les normes [C-1-3] à [C-1-9], les implémentations d'appareils:

  • [C-1-10] DOIT inclure le matériel certifié conforme au profil de protection IC sécurisé BSI-CC-PP-0084-2014 ou évalué par un laboratoire d'essais accrédité au niveau national qui procède à une évaluation des failles à fort potentiel d'attaque selon la norme commune d'application du potentiel d'attaque des cartes à puce.
  • [C-1-11] DOIT inclure le micrologiciel qui est évalué par un laboratoire d'essais accrédité au niveau national qui procède à une évaluation des failles à fort potentiel d'attaque, conformément à la norme commune d'application du potentiel d'attaque aux cartes à puce.
  • [C-SR] Il est FORTEMENT RECOMMANDÉ d'inclure le matériel évalué à l'aide d'une cible de sécurité, niveau d'évaluation (EAL) 5, complété par AVA_VAN.5. La certification EAL 5 deviendra probablement une exigence dans une prochaine version.

• Les [C-SR] sont FORTEMENT RECOMMANDÉS pour offrir une résistance aux attaques internes (IAR), ce qui signifie qu'un initié ayant accès aux clés de signature de micrologiciel ne peut pas produire de micrologiciel entraînant la fuite de secrets par la StrongBox, le contournement des exigences de sécurité fonctionnelles ou l'accès à des données utilisateur sensibles. La méthode recommandée pour implémenter l'IAR consiste à autoriser les mises à jour du micrologiciel uniquement lorsque le mot de passe de l'utilisateur principal est fourni via le HAL IAuthSecret.

9.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 générées par l'utilisateur. Autrement dit, toutes les données, à l'exception des suivantes :
  • Image système
  • Tous les fichiers de système d'exploitation requis par l'image système
• [C-0-3] DOIT supprimer les données conformément aux normes sectorielles pertinentes, telles que NIST SP800-88.
• [C-0-4] DOIT déclencher le processus de rétablissement de la configuration d'usine ci-dessus lorsque l'API DevicePolicyManager.wipeData() est appelée par l'application de contrôle des règles relatives aux appareils de l'utilisateur principal.
• PEUT fournir une option d'effacement rapide des données qui n'effectue qu'une effacement logique des données.

9.13. Mode de démarrage sécurisé

Android propose le mode Démarrage sécurisé, qui permet aux utilisateurs de démarrer dans un mode où seules les applications système préinstallées sont autorisées à s'exécuter et toutes les applications tierces sont désactivées. Ce mode, appelé "mode de démarrage sécurisé", permet à l'utilisateur de désinstaller les applications tierces potentiellement dangereuses.

Les implémentations d'appareils sont les suivantes:

• [SR] FORTEMENT RECOMMANDÉ d'implémenter le mode de démarrage sécurisé.

Si les implémentations d'appareils implémentent le mode de démarrage sécurisé, elles:

• [C-1-1] DOIT fournir à l'utilisateur une option permettant d'activer le mode Démarrage sécurisé de manière ininterrompue par rapport aux applications tierces installées sur l'appareil, sauf si l'application tierce est un outil de contrôle des règles relatives aux appareils et a défini l'indicateur UserManager.DISALLOW_SAFE_BOOT sur "true".

• [C-1-2] DOIT permettre à l'utilisateur de désinstaller des applications tierces en mode sans échec.

• DEVRAIT donner à l'utilisateur la possibilité d'activer le mode Démarrage sécurisé à partir du menu de démarrage à l'aide d'un workflow différent de celui d'un démarrage normal.

9.14. Isolation des systèmes de véhicule automobile

Les appareils Android Automotive doivent échanger des données avec des sous-systèmes critiques du véhicule en utilisant le HAL du véhicule pour envoyer et recevoir des messages sur des réseaux de véhicules tels que le bus CAN.

L'échange de données peut être sécurisé en implémentant des fonctionnalités de sécurité sous les couches du framework Android afin d'empêcher toute interaction malveillante ou involontaire avec ces sous-systèmes.

9.15. Abonnements

Les "forfaits" désignent les détails du contrat de facturation fournis par un opérateur mobile via SubscriptionManager.setSubscriptionPlans().

Toutes les implémentations d'appareils:

• [C-0-1] DOIT renvoyer les abonnements à l'application de l'opérateur mobile qui les a initialement fournis.
• [C-0-2] NE DOIT PAS sauvegarder ni importer de forfaits d'abonnement à distance.
• [C-0-3] DOIT autoriser uniquement les forçages, tels que SubscriptionManager.setSubscriptionOverrideCongested(), à partir de l'application de l'opérateur mobile proposant actuellement des abonnements valides.

10. Tests de compatibilité logicielle

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section. Notez toutefois qu'aucun package de test logiciel n'est complet. C'est pourquoi les responsables de la mise en œuvre d'appareils sont VIVEMENT RECOMMANDÉS d'apporter le moins de modifications possible à la référence et à l'implémentation préférée d'Android disponible dans le projet Android Open Source. Cela réduira le risque d'introduire des bugs qui créent des incompatibilités nécessitant des préparations et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Implémentations pour les appareils:

• [C-0-1] DOIT réussir la suite de test de compatibilité Android (CTS) disponible dans le projet Open Source Android, en utilisant le logiciel d'expédition final installé sur l'appareil.

• [C-0-2] DOIT garantir la compatibilité en cas d'ambiguïté dans CTS et pour toute réimplémentation de parties du code source de référence.

La CTS est conçue pour être exécutée sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. Les versions de la CTS seront indépendantes de cette définition de compatibilité, et plusieurs révisions de la CTS pourront être publiées pour Android 9.

Implémentations pour les appareils:

• [C-0-3] DOIT réussir la dernière version CTS disponible au moment où le logiciel de l'appareil est terminé.

• DEVRAIT utiliser autant que possible l'implémentation de référence dans l'arborescence Android Open Source.

10.2. Vérificateur CTS

L'outil de vérification CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester des fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et d'un capteur.

Implémentations pour les appareils:

• [C-0-1] DOIT exécuter correctement tous les cas applicables dans l'outil de vérification CTS.

L'outil de vérification CTS effectue des tests pour de nombreux types de matériel, y compris certains matériels facultatifs.

Implémentations pour les appareils:

• [C-0-2] DOIT réussir tous les tests de l'accéléromètre dont il dispose. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de l'accéléromètre dans l'outil de vérification CTS.

Les scénarios de test des fonctionnalités indiquées comme facultatives dans ce document de définition de compatibilité PEUVENT être ignorés ou omis.

• [C-0-2] Chaque appareil et chaque build DOIVENT exécuter correctement l'outil de vérification CTS, comme indiqué ci-dessus. Cependant, étant donné que de nombreux builds sont très similaires, les développeurs d'appareils ne sont pas censés exécuter explicitement le vérificateur CTS sur les builds qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui diffèrent d'une implémentation ayant réussi le vérificateur CTS uniquement par l'ensemble des paramètres régionaux inclus, des éléments de branding, etc. PEUVENT omettre le test CTS Verifier.

11. Logiciels à mettre à jour

• [C-0-1] Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer des mises à niveau "en direct", c'est-à-dire qu'un redémarrage de l'appareil PEUT être nécessaire. Vous pouvez utiliser n'importe quelle méthode, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

  • Téléchargements "Over The Air (OTA)" avec mise à jour hors connexion via un redémarrage
  • Mises à jour "partagées" via USB à partir d'un PC hôte.
  • Mises à jour "hors connexion" par un redémarrage et la mise à jour à partir d'un fichier stocké sur un espace de stockage amovible.

• [C-0-2] Le mécanisme de mise à jour utilisé DOIT prendre en charge les mises à jour sans effacer les données utilisateur. Autrement dit, le mécanisme de mise à jour DOIT préserver les données privées et les données partagées de l'application. Notez que le logiciel Android en amont inclut un mécanisme de mise à jour qui répond à cette exigence.

Si les implémentations de l'appareil incluent la prise en charge d'une connexion de données illimitées comme un profil 802.11 ou un profil PAN Bluetooth (Personal Area Network), les conditions suivantes doivent être réunies:

• [C-1-1] DOIT prendre en charge les téléchargements OTA avec une mise à jour hors connexion via un redémarrage.

Pour les implémentations d'appareils lancées avec Android 6.0 ou version ultérieure, le mécanisme de mise à jour DEVRAIT permettre de vérifier que l'image système est identique au résultat attendu après une OTA. L'implémentation OTA basée sur des blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

De plus, les implémentations d'appareils DOIVENT être compatibles avec les mises à jour du système A/B. L'AOSP implémente cette fonctionnalité à l'aide de la commande de démarrage HAL.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais pendant la durée de vie raisonnable du produit, déterminée en consultation avec l'équipe de compatibilité Android pour affecter la compatibilité des applications tierces:

• [C-2-1] L'équipe chargée de la mise en œuvre de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme qui vient d'être décrit.

Android inclut des fonctionnalités qui permettent à l'application Propriétaire de l'appareil (le cas échéant) de contrôler l'installation des mises à jour du système. Si le sous-système de mise à jour du système pour les appareils signale android.software.device_admin, les actions suivantes sont effectuées:

• [C-3-1] DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy.

12. Journal des modifications du document

Pour obtenir un résumé des modifications apportées à la définition de compatibilité dans cette version:

• Journal des modifications du document

Pour obtenir un résumé des modifications apportées à des sections spécifiques:

1. Introduction
2. Types d'appareils
3. Logiciel
4. Package d'application
5. Multimédia
6. Options et outils pour les développeurs
7. Compatibilité matérielle
8. Performances et puissance
9. Modèle de sécurité
10. Test de compatibilité logicielle
11. Logiciel pouvant être mis à jour
12. Journal des modifications du document
13. Nous contacter

12.1. Conseils d'affichage du journal des modifications

Les modifications sont marquées comme suit:

• CDD
  Modifications importantes apportées aux exigences de compatibilité.

• Docs
  Modifications esthétiques ou liées à la compilation.

Pour un affichage optimal, ajoutez les paramètres d'URL pretty=full et no-merges aux URL de votre journal de modifications.

13. Nous contacter

Vous pouvez rejoindre le forum sur la compatibilité Android pour demander des éclaircissements ou signaler des problèmes qui, selon vous, ne sont pas couverts par le document.