1. Introduction

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

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

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

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

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

De nombreuses ressources listées dans la section 14 sont dérivées directement ou indirectement du SDK Android et seront fonctionnellement identiques aux informations de la documentation de ce SDK. Dans le cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les références incluses dans la section 14 sont considérés comme faisant partie de cette définition de la compatibilité.

2. Types d'appareils

Bien que le projet Android Open Source ait été utilisé pour implémenter différents types et facteurs de forme d'appareils, de nombreux aspects de l'architecture et des exigences de compatibilité ont été optimisés pour les appareils portables. À partir d'Android 5.0, le projet Android Open Source vise à prendre en charge une plus grande variété de types d'appareils, comme décrit dans cette section.

Appareil Android portable désigne une implémentation d'appareil Android qui est généralement utilisée en le tenant dans la main, comme les lecteurs MP3, les téléphones et les tablettes. Implémentations d'appareils Android portables:

• DOIT être équipé d'un écran tactile intégré.
• DOIT disposer d'une source d'alimentation permettant la mobilité, comme une batterie.

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

• DOIT comporter un écran intégré OU inclure un port de sortie vidéo, tel que VGA, HDMI ou un port sans fil pour l'affichage.
• DOIT déclarer les fonctionnalités android.software.leanback et android.hardware.type.television [Ressources, 3].

Un appareil Android Watch désigne une implémentation d'appareil Android destinée à être portée sur le corps, peut-être au poignet, et:

• DOIT avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
• DOIT déclarer la fonctionnalité android.hardware.type.watch.
• DOIT prendre en charge uiMode = UI_MODE_TYPE_WATCH [Resources, 4].

L'implémentation d'Android Automotive désigne un tableau de bord de véhicule exécutant Android comme système d'exploitation pour une partie ou la totalité du système et/ou des fonctionnalités d'infodivertissement. Implémentations Android Automotive:

• DOIT déclarer la fonctionnalité android.hardware.type.automotive.
• DOIT prendre en charge uiMode = UI_MODE_TYPE_CAR [Resources, 5].

Toutes les implémentations d'appareils Android qui ne correspondent à aucun des types d'appareils ci-dessus DOIVENT respecter toutes les exigences de ce document pour être compatibles avec Android 6.0, sauf si l'exigence est explicitement décrite comme ne s'appliquant qu'à un type d'appareil Android spécifique ci-dessus.

2.1 Configurations de l'appareil

Voici un récapitulatif des principales différences de configuration matérielle par type d'appareil. (Les cellules vides indiquent "POURRA"). Toutes les configurations ne sont pas couvertes dans ce tableau. Pour en savoir plus, consultez les sections matérielles concernées.

Catégorie	Fonctionnalité	Section	Caméra à la main	Télévision	Regarder	Automobile	Autre
Entrée	Pavé directionnel	7.2.2. Navigation sans contact		OBLIGATOIRE
	Écran tactile	7.2.4. Saisie tactile	OBLIGATOIRE		OBLIGATOIRE		DOIT
	Micro	7.8.1. Micro	OBLIGATOIRE	DOIT	OBLIGATOIRE	OBLIGATOIRE	DOIT
Capteurs	Accéléromètre	7.3.1 Accéléromètre	DOIT		DOIT		DOIT
	GPS	7.3.3. GPS	DOIT			DOIT
Connectivité	Wi-Fi	7.4.2. IEEE 802.11	DOIT	OBLIGATOIRE		DOIT	DOIT
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	DOIT	DOIT			DOIT
	Bluetooth	7.4.3. Bluetooth	DOIT	OBLIGATOIRE	OBLIGATOIRE	OBLIGATOIRE	DOIT
	Bluetooth à basse consommation	7.4.3. Bluetooth	DOIT	OBLIGATOIRE	DOIT	DOIT	DOIT
	Mode périphérique/hôte USB	7.7. USB	DOIT			DOIT	DOIT
Sortie	Ports de sortie audio et/ou de haut-parleur	7.8.2. Sortie audio	OBLIGATOIRE	OBLIGATOIRE		OBLIGATOIRE	OBLIGATOIRE

3. Logiciel

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

L'environnement d'exécution de bytecode Dalvik géré est le principal moyen de transport des applications Android. L'API Android est l'ensemble d'interfaces de la plate-forme Android exposées aux applications exécutées dans l'environnement d'exécution géré. Les implémentations d'appareils DOIVENT fournir des implémentations complètes, y compris tous les comportements documentés, de toute API documentée exposée par le SDK Android [Ressources, 6] ou de toute API décorée avec le repère "@SystemApi" dans le code source Android en amont.

Les implémentations d'appareils NE DOIVENT PAS omettre d'API gérées, modifier les interfaces ou les signatures d'API, s'écarter du comportement documenté ni inclure de no-ops, sauf dans les cas spécifiquement autorisés par cette définition de compatibilité.

Cette définition de compatibilité permet d'omettre certains types de matériel pour lesquels Android inclut des API par les implémentations d'appareils. Dans ce cas, les API DOIVENT toujours être présentes et se comporter de manière raisonnable. Pour connaître les exigences spécifiques à ce scénario, consultez la section 7.

3.2. Compatibilité des API avec une compatibilité douce

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

3.2.1. Autorisations

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

3.2.2. Paramètres de compilation

Les API Android incluent un certain nombre de constantes dans la classe android.os.Build [Ressources, 8] qui sont destinées à décrire l'appareil actuel. Pour fournir des valeurs cohérentes et pertinentes dans les implémentations d'appareils, le tableau ci-dessous inclut des restrictions supplémentaires sur les formats de ces valeurs auxquelles les implémentations d'appareils DOIVENT se conformer.

Paramètre	Détails
VERSION.RELEASE	Version du système Android actuellement en cours d'exécution, au format lisible. Ce champ DOIT contenir l'une des valeurs de chaîne définies dans [Ressources, 9].
VERSION.SDK	Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 6.0, ce champ DOIT avoir la valeur entière 23.
VERSION.SDK_INT	Version du système Android actuellement en cours d'exécution, dans un format accessible au code d'application tiers. Pour Android 6.0, ce champ DOIT avoir la valeur entière 23.
VERSION.INCREMENTAL	Valeur choisie par l'implémentateur de l'appareil pour désigner la version spécifique du système Android en cours d'exécution, au format lisible par l'homme. Cette valeur NE DOIT PAS être réutilisée pour les différents builds mis à la disposition des utilisateurs finaux. L'utilisation typique de ce champ consiste à indiquer le numéro de build ou l'identifiant de modification de contrôle source utilisé pour générer le build. Aucune exigence n'est imposée 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'implémentateur de l'appareil pour identifier le matériel interne spécifique utilisé par l'appareil, au format lisible par l'homme. Ce champ peut être utilisé pour indiquer la révision spécifique de la carte alimentant l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
MARQUE	Valeur reflétant le nom de la marque associé à l'appareil tel que connu des utilisateurs finaux. DOIT être au format lisible par l'homme et DOIT représenter le fabricant de l'appareil ou la marque de l'entreprise sous laquelle l'appareil est commercialisé. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
SUPPORTED_ABIS	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_32_BIT_ABIS	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
SUPPORTED_64_BIT_ABIS	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI	Nom de l'ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
CPU_ABI2	Nom du deuxième ensemble d'instructions (type de processeur + convention ABI) du code natif. Voir la section 3.3. Compatibilité avec les API natives.
APPAREIL	Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code identifiant la configuration des fonctionnalités matérielles et la conception industrielle de l'appareil. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
FINGERPRINT	Chaîne qui identifie de manière unique ce build. Il DOIT être raisonnablement lisible par l'humain. Il DOIT respecter ce modèle: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) Exemple : acme/myproduct/     mydevice:6.0/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 contiennent des caractères d'espace, ils DOIVENT être remplacés dans l'empreinte de compilation par un autre caractère, tel que le trait de soulignement ("_"). La valeur de ce champ DOIT être encodable en ASCII 7 bits.
MATÉRIEL	Nom du matériel (à partir de la ligne de commande du kernel ou de /proc). Il DOIT être raisonnablement lisible par l'humain. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
ORGANISATEUR	Chaîne qui identifie de manière unique l'hôte sur lequel le build a été créé, au format lisible par l'homme. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
ID	Identifiant choisi par l'implémentateur de l'appareil pour faire référence à une version spécifique, au format lisible par l'utilisateur. Ce champ peut être identique à android.os.Build.VERSION.INCREMENTAL, mais DOIT être une valeur suffisamment significative pour que les utilisateurs finaux puissent distinguer les builds logiciels. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9._-]+$".
FABRICANT	Nom commercial du fabricant d'équipement d'origine (OEM) du produit. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
MODÈLE	Valeur choisie par l'implémentateur de l'appareil contenant le nom de l'appareil tel que connu par l'utilisateur final. Il DOIT s'agir du même nom que celui sous lequel l'appareil est commercialisé et vendu aux utilisateurs finaux. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
PRODUIT	Valeur choisie par l'implémentateur de l'appareil contenant le nom de développement ou le nom de code du produit spécifique (code SKU) qui DOIT être unique au sein de la même marque. DOIT être lisible par l'humain, mais n'est pas nécessairement destiné à être vu par les utilisateurs finaux. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^[a-zA-Z0-9_-]+$".
SERIAL	Un numéro de série matériel, qui DOIT être disponible et unique pour tous les appareils ayant le même MODÈLE et le même FABRICANT. La valeur de ce champ DOIT être encodable en ASCII 7 bits et correspondre à l'expression régulière "^([a-zA-Z0-9]{6,20})$".
TAGS	Liste de tags choisis par l'implémentateur de l'appareil, séparés par une virgule, qui permet de distinguer davantage le build. Ce champ DOIT contenir l'une des valeurs correspondant aux trois configurations de signature de la plate-forme Android standards: release-keys, dev-keys et test-keys.
DURÉE	Valeur représentant le code temporel de la compilation.
MACH	Valeur choisie par l'implémentateur de l'appareil spécifiant la configuration d'exécution du build. Ce champ DOIT avoir l'une des valeurs correspondant aux trois configurations d'exécution Android typiques: user, userdebug ou eng.
UTILISATEUR	Nom ou ID utilisateur de l'utilisateur (ou de l'utilisateur automatique) qui a généré le build. Aucune exigence n'est imposée concernant le format spécifique de ce champ, sauf qu'il NE DOIT PAS être nul ni la chaîne vide ("").
SECURITY_PATCH	Valeur indiquant le niveau du correctif de sécurité d'un build. Il DOIT indiquer que le build inclut tous les correctifs de sécurité publiés dans le bulletin de sécurité public Android désigné. Elle doit être au format [AAAA-MM-JJ] et correspondre à l'une des chaînes de niveau de correctif de sécurité Android des bulletins de sécurité publics, par exemple "2015-11-01".
BASE_OS	Valeur représentant le paramètre FINGERPRINT de la version qui est par ailleurs identique à cette version, à l'exception des correctifs fournis dans le bulletin de sécurité public Android. Il DOIT indiquer la valeur correcte. S'il n'existe pas de build de ce type, indiquez une chaîne vide ("").

3.2.3. Compatibilité des intents

Les implémentations d'appareils DOIVENT respecter le système d'intent à liaison lâche d'Android, comme décrit dans les sections ci-dessous. Par "honoré", on entend que l'implémentateur de l'appareil DOIT fournir une activité ou un service Android qui spécifie un filtre d'intent correspondant qui se lie et implémente un comportement correct pour chaque modèle d'intent spécifié.

3.2.3.1. 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 inclut une liste d'applications considérées comme des applications Android de base, qui implémente plusieurs modèles d'intent pour effectuer des actions courantes. Les applications principales d'Android sont les suivantes:

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

Les implémentations d'appareils DOIVENT inclure les applications Android de base, le cas échéant, mais DOIVENT inclure un composant implémentant les mêmes modèles d'intent définis par tous les composants d'activité ou de service "publics" de ces applications Android de base. Notez que les composants Activity ou Service sont considérés comme "publics" lorsque l'attribut android:exported est absent ou a la valeur "true".

3.2.3.2. Résolution des intents

Étant donné qu'Android est une plate-forme extensible, les implémentations d'appareils DOIVENT permettre à chaque modèle d'intent référencé dans la section 3.2.3.1 d'être remplacé par des applications tierces. L'implémentation Open Source Android en amont permet cela par défaut. Les implémentateurs d'appareils NE DOIVENT PAS associer des droits spéciaux à l'utilisation de ces modèles d'intent par les applications système, ni empêcher les applications tierces de se lier à ces modèles et de les contrôler. Cette interdiction inclut spécifiquement, mais sans s'y limiter, la désactivation de l'interface utilisateur "Chooser" qui permet à l'utilisateur de choisir parmi plusieurs applications qui gèrent toutes le même modèle d'intent.

Les implémentations d'appareils DOIVENT fournir une interface utilisateur permettant aux utilisateurs de modifier l'activité par défaut pour les intents.

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

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

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

3.2.3.3. Espaces de noms d'intent

Les implémentations d'appareils NE DOIVENT PAS inclure de composant Android qui respecte les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans l'espace de noms android.* ou com.android.*. Les implémentateurs d'appareils NE DOIVENT PAS inclure de composants Android qui respectent les nouveaux modèles d'intent ou d'intent de diffusion à l'aide d'une ACTION, d'une CATEGORIE ou d'une autre chaîne de clé dans un espace de package appartenant à une autre organisation. Les implémentateurs d'appareils NE DOIVENT PAS modifier ni étendre les modèles d'intent utilisés par les applications principales listé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 semblable à celle spécifiée pour les classes de langage Java dans la section 3.6.

3.2.3.4. Intents de diffusion

Les applications tierces s'appuient sur la plate-forme pour diffuser certains intents afin de les informer des modifications apportées à l'environnement matériel ou logiciel. Les appareils compatibles avec Android DOIVENT diffuser les intents de diffusion publique en réponse aux événements système appropriés. Les intents de diffusion sont décrits dans la documentation du SDK.

3.2.3.5. Paramètres de l'application par défaut

Android inclut des paramètres qui permettent aux utilisateurs de sélectionner facilement leurs applications par défaut, par exemple pour l'écran d'accueil ou les SMS. Lorsque cela est approprié, les implémentations d'appareils DOIVENT fournir un menu de paramètres similaire et être compatibles avec le modèle de filtre d'intent et les méthodes d'API décrites dans la documentation du SDK, comme indiqué ci-dessous.

Implémentations de l'appareil:

• DOIT respecter l'intent android.settings.HOME_SETTINGS pour afficher un menu de paramètres d'application par défaut pour l'écran d'accueil, si l'implémentation de l'appareil signale android.software.home_screen [Ressources, 10]
• DOIT fournir un menu de paramètres qui appelle l'intent android.provider.Telephony.ACTION_CHANGE_DEFAULT pour afficher une boîte de dialogue permettant de modifier l'application de SMS par défaut, si l'implémentation de l'appareil signale android.hardware.telephony [Ressources, 11]
• DOIT respecter l'intent android.settings.NFC_PAYMENT_SETTINGS pour afficher un menu de paramètres d'application par défaut pour le paiement sans contact, si l'implémentation de l'appareil signale android.hardware.nfc.hce [Ressources, 10]

3.3. Compatibilité avec les API natives

3.3.1. Interfaces binaires d'application

Le bytecode Dalvik géré peut appeler le code natif fourni dans le fichier .apk de l'application en tant que fichier .so ELF compilé pour l'architecture matérielle de l'appareil appropriée. Étant donné que le code natif est fortement dépendant de la technologie de processeur sous-jacente, Android définit un certain nombre d'interfaces binaires d'application (ABI) dans le NDK Android. Les implémentations d'appareils DOIVENT être compatibles avec une ou plusieurs ABI définies et DOIVENT implémenter la compatibilité avec le NDK Android, comme indiqué ci-dessous.

Si une implémentation d'appareil prend en charge une ABI Android, elle:

• DOIT inclure la prise en charge du code exécuté dans l'environnement géré pour appeler le code natif, à l'aide de la sémantique standard de l'interface Java Native Interface (JNI)
• DOIT être compatible avec la source (c'est-à-dire avec l'en-tête) et avec le binaire (pour l'ABI) avec chaque bibliothèque requise de la liste ci-dessous
• DOIT prendre en charge l'ABI 32 bits équivalent si une ABI 64 bits est prise en charge
• DOIT indiquer avec précision l'interface binaire d'application (ABI) native prise en charge par l'appareil, via les paramètres android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS et android.os.Build.SUPPORTED_64_BIT_ABIS, chacun étant une liste d'ABI séparés par une virgule, de la plus à la moins préférée
• DOIT indiquer, via les paramètres ci-dessus, uniquement les ABI documentées et décrites dans la dernière version de la documentation de gestion des ABI du NDK Android [Ressources, 12], et DOIT prendre en charge l'extension Advanced SIMD (également appelée NEON) [Ressources, 13].
• DOIT être compilé à l'aide du code source et des fichiers d'en-tête disponibles dans le projet Open Source Android en amont

Les API de code natif suivantes DOIVENT être disponibles pour les applications qui incluent du code natif:

• libc (bibliothèque C)
• libm (bibliothèque mathématique)
• Compatibilité minimale avec C++
• Interface JNI
• liblog (journalisation Android)
• libz (compression zlib)
• libdl (lecteur de liens dynamique)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (gestion des surfaces OpenGL natives)
• libjnigraphics.so
• libOpenSLES.so (compatibilité audio OpenSL ES 1.0.1)
• libOpenMAXAL.so (compatibilité avec OpenMAX AL 1.0.1)
• libandroid.so (prise en charge des activités Android natives)
• libmediandk.so (compatibilité avec les API multimédias natives)
• Prise en charge d'OpenGL, comme décrit ci-dessous

Notez que les futures versions du NDK Android peuvent prendre en charge des ABI supplémentaires. Si une implémentation d'appareil n'est pas compatible avec une ABI prédéfinie existante, elle NE DOIT PAS signaler la prise en charge d'une quelconque ABI.

Notez que les implémentations d'appareils DOIVENT inclure libGLESv3.so et DOIVENT créer un lien symbolique (lien symbolique) vers libGLESv2.so. À son tour, DOIT exporter tous les symboles de fonction OpenGL ES 3.1 et Android Extension Pack [Resources, 14] tels que définis dans la version du NDK android-21. Bien que tous les symboles doivent être présents, seules les fonctions correspondantes pour les versions et les extensions OpenGL ES réellement compatibles avec l'appareil doivent être entièrement implémentées.

Les implémentations d'appareils, si elles incluent une bibliothèque native portant le nom libvulkan.so, DOIVENT exporter des symboles de fonction et fournir une implémentation de l'API Vulkan 1.0 et des extensions VK_KHR_surface, VK_KHR_swapchain et VK_KHR_android_surface telles que définies par le groupe Khronos et qui réussissent les tests de conformité Khronos.

La compatibilité du code natif est difficile. Pour cette raison, il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils d'utiliser les implémentations des bibliothèques listées ci-dessus à partir du projet Open Source Android en amont.

3.3.2. Compatibilité du code natif ARM 32 bits

L'architecture ARMv8 abandonne plusieurs opérations de processeur, y compris certaines opérations utilisées dans le code natif existant. Sur les appareils ARM 64 bits, les opérations obsolètes suivantes DOIVENT rester disponibles pour le code ARM natif 32 bits, soit via la prise en charge du processeur natif, soit via l'émulation logicielle:

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

Les anciennes versions du NDK Android utilisaient /proc/cpuinfo pour découvrir les fonctionnalités du processeur à partir du code natif ARM 32 bits. Pour la compatibilité avec les applications créées à l'aide de ce NDK, les appareils DOIVENT inclure les lignes suivantes dans /proc/cpuinfo lorsqu'elles sont lues par des applications ARM 32 bits:

• "Fonctionnalités: ", suivi d'une liste des fonctionnalités de processeur ARMv7 facultatives compatibles avec l'appareil
• "Architecture de processeur: ", suivi d'un entier décrivant l'architecture ARM la plus élevée prise en charge par l'appareil (par exemple, "8" pour les appareils ARMv8)

Ces exigences ne s'appliquent que lorsque /proc/cpuinfo est lu par des applications ARM 32 bits. Les appareils NE DOIVENT PAS modifier /proc/cpuinfo lorsqu'ils sont lus par des applications ARM 64 bits ou non-ARM.

3.4. Compatibilité Web

3.4.1. Compatibilité avec WebView

La fonctionnalité de plate-forme android.software.webview DOIT être signalée sur tout appareil qui fournit une implémentation complète de l'API android.webkit.WebView et NE DOIT PAS être signalée sur les appareils sans implémentation complète de l'API. L'implémentation Open Source d'Android utilise le code du projet Chromium pour implémenter android.webkit.WebView [Ressources, 15]. Étant donné qu'il n'est pas possible de développer une suite de tests complète pour un système de rendu Web, les implémentateurs d'appareils DOIVENT utiliser le build en amont spécifique de Chromium dans l'implémentation de WebView. Plus spécifiquement :

• Les implémentations android.webkit.WebView de l'appareil DOIVENT être basées sur le build Chromium du projet Android Open Source Project en amont pour Android 6.0. Cette version inclut un ensemble spécifique de fonctionnalités et de correctifs de sécurité pour WebView [Ressources, 16].
• La chaîne d'agent utilisateur signalée par la WebView DOIT respecter le format suivant:

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

  • La valeur de la chaîne $(VERSION) DOIT être identique à celle d'android.os.Build.VERSION.RELEASE.
  • La valeur de la chaîne $(MODEL) DOIT être identique à celle d'android.os.Build.MODEL.
  • La valeur de la chaîne $(BUILD) DOIT être identique à celle d'android.os.Build.ID.
  • La valeur de la chaîne $(CHROMIUM_VER) DOIT correspondre à la version de Chromium dans le projet Open Source Android en amont.
  • Les implémentations d'appareils PEUVENT omettre "Mobile" dans la chaîne user-agent.

Le composant WebView DOIT prendre en charge autant de fonctionnalités HTML5 que possible et, s'il le fait, DOIT se conformer à la spécification HTML5 [Ressources, 17].

3.4.2. Compatibilité avec les navigateurs

Le navigateur autonome PEUT être basé sur une technologie de navigateur autre que WebKit. Toutefois, même si une autre application de navigateur est utilisée, le composant android.webkit.WebView fourni aux applications tierces DOIT être basé sur WebKit, comme décrit dans la section 3.4.1.

Les implémentations peuvent fournir une chaîne user-agent personnalisée dans l'application de navigateur autonome.

L'application de navigateur autonome (qu'elle soit basée sur l'application de navigateur WebKit en amont ou sur un remplacement tiers) DOIT prendre en charge autant que possible HTML5 [Ressources, 17]. Au minimum, les implémentations d'appareils DOIVENT prendre en charge chacune de ces API associées à HTML5:

• cache de l'application/opération hors connexion [Ressources, 18]
• la balise <video> [Ressources, 19]
• géolocalisation [Resources, 20]

De plus, les implémentations d'appareils DOIVENT être compatibles avec l'API Webstorage HTML5/W3C [Ressources, 21] et DEVRAIENT être compatibles avec l'API IndexedDB HTML5/W3C [Ressources, 22]. Notez que, à mesure que les organismes de normalisation du développement Web passent à IndexedDB plutôt qu'à Webstorage, IndexedDB devrait devenir un composant obligatoire dans une prochaine version d'Android.

3.5. Compatibilité du comportement des API

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

• Les appareils NE DOIVENT PAS modifier le comportement ni la sémantique d'un intent standard.
• Les appareils NE DOIVENT PAS modifier le cycle de vie ou la sémantique du cycle de vie d'un type particulier de composant système (tel que Service, Activity, ContentProvider, etc.).
• Les appareils NE DOIVENT PAS modifier la sémantique d'une autorisation standard.

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

3.6. Espaces de noms d'API

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

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

Les modifications interdites incluent les suivantes :

• Les implémentations d'appareils NE DOIVENT PAS modifier les API exposées publiquement sur la plate-forme Android en modifiant les signatures de méthode ou de classe, ni en supprimant des classes ou des champs de classe.
• Les implémentateurs d'appareils PEUVENT modifier l'implémentation sous-jacente des API, mais de telles modifications NE DOIVENT PAS avoir d'incidence sur le comportement indiqué et la signature en langage Java de toute API exposée publiquement.
• Les implémentateurs d'appareils NE DOIVENT PAS ajouter d'éléments exposés publiquement (tels que des classes ou des interfaces, ou des champs ou des méthodes à des classes ou interfaces existantes) aux API ci-dessus.

Un "élément exposé publiquement" est tout élément qui n'est pas décoré avec le repère "@hide" tel qu'il est utilisé dans le code source Android en amont. En d'autres termes, les implémentateurs d'appareils NE DOIVENT PAS exposer de nouvelles API ni modifier les API existantes dans les espaces de noms indiqués ci-dessus. Les implémentateurs d'appareils PEUVENT apporter des modifications internes uniquement, mais ces modifications NE DOIVENT PAS être annoncées ni exposées aux développeurs.

Les implémentateurs d'appareils PEUVENT ajouter des API personnalisées, mais ces API NE DOIVENT PAS se trouver dans un espace de noms appartenant à une autre organisation ou faisant référence à une autre organisation. Par exemple, les implémentateurs d'appareils NE DOIVENT PAS ajouter d'API à l'espace de noms com.google.* ou à un espace de noms similaire: seul Google peut le faire. De même, Google NE DOIT PAS ajouter d'API aux espaces de noms d'autres entreprises. De plus, si une implémentation d'appareil inclut des API personnalisées en dehors du namespace Android standard, ces API DOIVENT être empaquetées dans une bibliothèque partagée Android afin que seules les applications qui les utilisent explicitement (via le mécanisme <uses-librarygt;) soient affectées par l'augmentation de l'utilisation de la mémoire de ces API.

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

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

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

Les implémentations d'appareils DOIVENT prendre en charge le format Dalvik Executable (DEX) complet, ainsi que la spécification et la sémantique du bytecode Dalvik [Ressources, 23]. Les implémentateurs d'appareils DOIVENT utiliser ART, l'implémentation en amont de référence du format d'exécutable Dalvik et le système de gestion des paquets de l'implémentation de référence.

Les implémentations d'appareils DOIVENT configurer les environnements d'exécution Dalvik pour allouer de la mémoire conformément à la plate-forme Android en amont et comme indiqué dans le tableau suivant. (Consultez la section 7.1.1 pour connaître les définitions de la taille et de la densité de l'écran.)

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

Mise en page de l'écran	Densité d'écran	Mémoire minimale de l'application
Montre Android	120 PPP (ldpi)	32 Mo
	160 ppp (mdpi)
	213 ppp (tvdpi)
	240 ppp (hdpi)	36 Mo
	280 ppp (280 dpi)
	320 ppp (xhdpi)	48 Mo
	360 dpi (360 dpi)
	400 ppp (400 dpi)	56 Mo
	420 ppp (420dpi)	64 Mo
	480 dpi (xxhdpi)	88 Mo
	560 ppp (560dpi)	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 dpi)
	320 ppp (xhdpi)	80 Mo
	360 dpi (360 dpi)
	400 ppp (400 dpi)	96 Mo
	420 ppp (420dpi)	112 Mo
	480 dpi (xxhdpi)	128 Mo
	560 ppp (560dpi)	192 Mo
	640 ppp (xxxhdpi)	256 Mo
grande	120 PPP (ldpi)	32 Mo
	160 ppp (mdpi)	48 Mo
	213 ppp (tvdpi)	80 Mo
	240 ppp (hdpi)
	280 ppp (280 dpi)	96 Mo
	320 ppp (xhdpi)	128 Mo
	360 dpi (360 dpi)	160 Mo
	400 ppp (400 dpi)	192 Mo
	420 ppp (420dpi)	228 Mo
	480 dpi (xxhdpi)	256 Mo
	560 ppp (560dpi)	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 dpi)	144 Mo
	320 ppp (xhdpi)	192 Mo
	360 dpi (360 dpi)	240 Mo
	400 ppp (400 dpi)	288 Mo
	420 ppp (420dpi)	336 Mo
	480 dpi (xxhdpi)	384 Mo
	560 ppp (560dpi)	576 Mo
	640 ppp (xxxhdpi)	768 Mo

3.8. Compatibilité de l'interface utilisateur

3.8.1. Lanceur (écran d'accueil)

Android inclut une application de lanceur (écran d'accueil) et prend en charge les applications tierces pour remplacer le lanceur de l'appareil (écran d'accueil). Les implémentations d'appareils qui permettent aux applications tierces de remplacer l'écran d'accueil de l'appareil DOIVENT déclarer la fonctionnalité de plate-forme android.software.home_screen.

3.8.2. Widgets

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un "AppWidget" à l'utilisateur final [Resources, 24], une fonctionnalité qui est FORTEMENT RECOMMANDÉE pour les implémentations d'appareils portables. Les implémentations d'appareils compatibles avec l'intégration de widgets sur l'écran d'accueil DOIVENT respecter les exigences suivantes et déclarer la prise en charge de la fonctionnalité de plate-forme android.software.app_widgets.

• Les lanceurs d'appareils DOIVENT inclure la prise en charge intégrée des AppWidgets et exposer les affordances de l'interface utilisateur pour ajouter, configurer, afficher et supprimer des AppWidgets directement dans le lanceur.
• Les implémentations d'appareils DOIVENT être capables d'afficher des widgets de 4 x 4 pixels dans la taille de grille standard. Pour en savoir plus, consultez les consignes de conception des widgets d'application dans la documentation du SDK Android [Ressources, 24].
• Les implémentations d'appareils qui prennent en charge l'écran de verrouillage PEUVENT prendre en charge les widgets d'application sur l'écran de verrouillage.

3.8.3. Notifications

Android inclut des API qui permettent aux développeurs d'avertir les utilisateurs d'événements notables [Ressources, 25], à l'aide des fonctionnalités matérielles et logicielles de l'appareil.

Certaines API permettent aux applications d'envoyer des notifications ou d'attirer l'attention à l'aide de matériel, en particulier du son, de la vibration et de la lumière. Les implémentations d'appareils DOIVENT prendre en charge les notifications qui utilisent des fonctionnalités matérielles, comme décrit dans la documentation du SDK et dans la mesure du possible avec le matériel d'implémentation de l'appareil. Par exemple, si une implémentation d'appareil inclut un vibreur, elle DOIT implémenter correctement les API de vibration. Si une implémentation d'appareil ne dispose pas de matériel, les API correspondantes DOIVENT être implémentées en tant que no-ops. Ce comportement est décrit plus en détail dans la section 7.

En outre, l'implémentation DOIT afficher correctement toutes les ressources (icônes, fichiers d'animation, etc.) fournies dans les API [Resources, 26] ou dans le guide de style des icônes de la barre d'état/système [Resources, 27], qui, dans le cas d'un appareil Android TV, inclut la possibilité de ne pas afficher les notifications. Les implémentateurs d'appareils PEUVENT proposer une expérience utilisateur alternative pour les notifications que celle fournie par l'implémentation Open Source Android de référence. Toutefois, ces systèmes de notification alternatifs DOIVENT prendre en charge les ressources de notification existantes, comme indiqué ci-dessus.

Android est compatible avec diverses notifications, par exemple:

• Notifications enrichies Vues interactives pour les notifications en cours.
• Notifications prioritaires. Les vues interactives peuvent être ignorées ou traitées par les utilisateurs sans qu'ils quittent l'application en cours.
• Notifications de l'écran de verrouillage Notifications affichées sur un écran de verrouillage avec un contrôle précis de la visibilité.

Lorsque ces notifications sont rendues visibles, les implémentations d'appareils Android DOIVENT exécuter correctement les notifications Rich et Heads-up, et inclure le titre/nom, l'icône et le texte, comme indiqué dans les API Android [Ressources, 28].

Android inclut des API Notification Listener Service qui permettent aux applications (une fois activées explicitement par l'utilisateur) de recevoir une copie de toutes les notifications au fur et à mesure de leur publication ou de leur mise à jour. Les implémentations d'appareils DOIVENT envoyer correctement et rapidement l'intégralité des notifications à tous ces services d'écouteur installés et activés par l'utilisateur, y compris toutes les métadonnées associées à l'objet Notification.

3.8.4. Recherche

Android inclut des API [Ressources, 29] qui permettent aux développeurs d'intégrer la recherche dans leurs applications et d'exposer les données de leur application dans la recherche système globale. De manière générale, cette fonctionnalité consiste en une interface utilisateur unique, au niveau du système, qui permet aux utilisateurs de saisir des requêtes, d'afficher des suggestions à mesure qu'ils saisissent du texte et d'afficher des résultats. Les API Android permettent aux développeurs de réutiliser cette interface pour fournir une recherche dans leurs propres applications et de fournir des résultats à l'interface utilisateur de recherche globale commune.

Les implémentations d'appareils Android DOIVENT inclure une recherche globale, une interface utilisateur de recherche unique, partagée et à l'échelle du système, capable de proposer des suggestions en temps réel en réponse à l'entrée utilisateur. Les implémentations d'appareils DOIVENT implémenter les API qui permettent aux développeurs de réutiliser cette interface utilisateur pour fournir une recherche dans leurs propres applications. Les implémentations d'appareils qui implémentent l'interface de recherche globale DOIVENT implémenter les API qui permettent aux applications tierces d'ajouter des suggestions au champ de recherche lorsqu'il est exécuté en mode recherche globale. Si aucune application tierce n'est installée pour utiliser cette fonctionnalité, le comportement par défaut DOIT être d'afficher les résultats et les suggestions du moteur de recherche Web.

Les implémentations d'appareils Android DOIVENT implémenter un assistant sur l'appareil pour gérer l'action d'assistance [Ressources, 30].

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 [Resources, 31]. Les implémentations d'appareils compatibles avec l'action d'assistance DOIVENT indiquer clairement à l'utilisateur final quand le contexte est partagé en affichant une lumière blanche autour des bords de l'écran. Pour assurer une visibilité claire à l'utilisateur final, l'indication DOIT respecter ou dépasser la durée et la luminosité de l'implémentation du projet Open Source Android.

3.8.5. Notifications toast

Les applications peuvent utiliser l'API "Toast" pour afficher des chaînes courtes non modales à l'utilisateur final, qui disparaissent après un court laps de temps [Resources, 32]. Les implémentations d'appareils DOIVENT afficher les toasts des applications aux utilisateurs finaux de manière très visible.

3.8.6. Thèmes

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

Android inclut une famille de thèmes "Holo" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème Holo tel que défini par le SDK Android [Resources, 33]. Les implémentations d'appareils NE DOIVENT PAS modifier les attributs du thème Holo exposés aux applications [Resources, 34].

Android inclut une famille de thèmes "Material" sous la forme d'un ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent adapter l'apparence du thème de conception à la grande variété de types d'appareils Android. Les implémentations d'appareils DOIVENT prendre en charge la famille de thèmes "Material" et NE DOIVENT PAS modifier les attributs du thème Material ni les éléments exposés aux applications [Ressources, 35].

Android inclut également une famille de thèmes "Par défaut de l'appareil" en tant qu'ensemble de styles définis que les développeurs d'applications peuvent utiliser s'ils souhaitent reproduire l'apparence du thème de l'appareil tel que défini par l'implémentateur de l'appareil. Les implémentations de l'appareil PEUVENT modifier les attributs de thème par défaut de l'appareil exposés aux applications [Resources, 34].

Android est compatible avec un thème de variante avec des barres système transparentes, ce qui permet aux développeurs d'applications de remplir la zone derrière la barre d'état et de navigation avec le contenu de leur application. Pour offrir une expérience de développement cohérente dans cette configuration, il est important que le style des icônes de la barre d'état soit conservé dans les différentes implémentations d'appareils. Par conséquent, les implémentations d'appareils Android DOIVENT utiliser le blanc pour les icônes d'état du système (telles que l'intensité du signal et le niveau de la batterie) et les notifications émises par le système, sauf si l'icône indique un état problématique ou qu'une application demande une barre d'état claire à l'aide de l'indicateur SYSTEM_UI_FLAG_LIGHT_STATUS_BAR. Lorsqu'une application demande une barre d'état claire, les implémentations d'appareils Android DOIVENT changer la couleur des icônes d'état du système en noir [Resources, 34].

3.8.7. Fonds d'écran animés

Android définit un type de composant, ainsi qu'une API et un cycle de vie correspondants, qui permettent aux applications d'exposer un ou plusieurs "fonds d'écran animés" à l'utilisateur final [Resources, 36]. Les fonds d'écran animés sont des animations, des motifs ou des images similaires avec des fonctionnalité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 exécuter tous les fonds d'écran animés, sans aucune limitation de fonctionnalité, à une fréquence d'images raisonnable et sans effet négatif sur d'autres applications. Si des limites matérielles provoquent le plantage et/ou le dysfonctionnement des fonds d'écran et/ou des applications, ou qu'elles consomment une puissance de processeur ou de batterie excessive, ou qu'elles s'exécutent à des fréquences d'images inacceptablement faibles, le matériel est considéré comme incapable d'exécuter un fond d'écran animé. Par exemple, certains fonds d'écran animés peuvent utiliser un contexte OpenGL 2.0 ou 3.x pour afficher leur contenu. Le fond d'écran animé ne s'exécute pas de manière fiable sur du matériel qui n'est pas compatible avec plusieurs contextes OpenGL, car l'utilisation d'un contexte OpenGL par le fond d'écran animé peut entrer en conflit avec d'autres applications qui utilisent également un contexte OpenGL.

Les implémentations d'appareils capables d'exécuter des fonds d'écran animés de manière fiable, comme décrit ci-dessus, DOIVENT implémenter des fonds d'écran animés et, lorsqu'elles sont implémentées, DOIVENT signaler l'indicateur de fonctionnalité de la plate-forme android.software.live_wallpaper.

3.8.8. Changement d'activité

Le code source Android en amont inclut l'écran d'aperçu [Resources, 37], une interface utilisateur au niveau du système permettant de changer de tâche et d'afficher les activités et tâches récemment consultées à l'aide d'une image miniature de l'état graphique de l'application au moment où l'utilisateur a quitté l'application pour la dernière fois. Les implémentations d'appareils incluant la touche de navigation de la fonction "Récents", comme indiqué dans la section 7.2.3, PEUVENT modifier l'interface, mais DOIVENT respecter les exigences suivantes:

• DOIT afficher les éléments récents affiliés en tant que groupe qui se déplace ensemble.
• DOIT prendre en charge au moins six activités affichées.
• DOIT afficher au moins le titre de quatre activités à la fois.
• DOIT afficher la couleur de surbrillance, l'icône et le titre de l'écran dans les éléments récents.
• DOIT implémenter le comportement d'épinglage d'écran [Ressources, 38] et fournir à l'utilisateur un menu de paramètres pour activer/désactiver la fonctionnalité.
• DOIT afficher une affordance de fermeture ("x"), mais PEUT retarder cette action jusqu'à ce que l'utilisateur interagisse avec les écrans.

Il est vivement recommandé d'utiliser l'interface utilisateur Android en amont (ou une interface basée sur des miniatures similaire) pour l'écran d'aperçu des implémentations d'appareils.

3.8.9. Gestion des entrées

Android est compatible avec la gestion des entrées et les éditeurs de méthodes d'entrée tiers [Ressources, 39]. Les implémentations d'appareils qui permettent aux utilisateurs d'utiliser des méthodes de saisie tierces sur l'appareil DOIVENT déclarer la fonctionnalité de plate-forme android.software.input_methods et prendre en charge les API IME, comme défini dans la documentation du SDK Android.

Les implémentations d'appareils qui déclarent la fonctionnalité android.software.input_methods DOIVENT fournir un mécanisme accessible à l'utilisateur pour ajouter et configurer des méthodes de saisie tierces. Les implémentations d'appareils DOIVENT afficher l'interface des paramètres en réponse à l'intent android.settings.INPUT_METHOD_SETTINGS.

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

L'API Client de télécommande est obsolète à partir d'Android 5.0 au profit du modèle de notification multimédia, qui permet aux applications multimédias de s'intégrer aux commandes de lecture affichées sur l'écran de verrouillage [Ressources, 40] en tant que notifications de l'écran de verrouillage. Les implémentations d'appareils DOIVENT afficher correctement le modèle de notification multimédia dans les notifications de l'écran de verrouillage décrites dans la section 3.8.3.

3.8.11. Rêves

Android est compatible avec les écrans de veille interactifs appelés "Dreams" [Resources, 41]. Dreams permet aux utilisateurs d'interagir avec des applications lorsqu'un appareil connecté à une source d'alimentation est inactif ou posé sur un socle. Les appareils Android Watch PEUVENT implémenter Dreams, mais les autres types d'implémentations d'appareils DOIVENT prendre en charge Dreams et fournir une option de paramètres permettant aux utilisateurs de configurer Dreams en réponse à l'intent android.settings.DREAM_SETTINGS.

3.8.12. Position

Lorsqu'un appareil dispose d'un capteur matériel (par exemple, un GPS) capable de fournir les coordonnées de localisation, les modes de localisation DOIVENT s'afficher dans le menu "Position" des paramètres [Ressources, 42].

3.8.13. Unicode et police

Android est compatible avec les caractères emoji en couleur. Lorsque les implémentations d'appareils Android incluent un IME, les appareils DOIVENT fournir à l'utilisateur une méthode de saisie pour les caractères emoji définis dans Unicode 6.1 [Ressources, 43]. Tous les appareils doivent être capables d'afficher ces caractères emoji sous forme de glyphes en couleur.

Android est compatible avec la police Roboto 2 avec différentes épaisseurs (sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light), qui DOIVENT toutes être incluses pour les langues disponibles sur l'appareil et la couverture complète de l'Unicode 7.0 pour le latin, le grec et le cyrillique, y compris les plages Latin Extended A, B, C et D, ainsi que tous les glyphes du bloc des symboles de devise de l'Unicode 7.0.

3.9. Gestion de l'appareil

Android inclut des fonctionnalités qui permettent aux applications axées sur la sécurité d'effectuer des fonctions d'administration d'appareils au niveau du système, telles que l'application de règles de mot de passe ou l'effacement à distance, via l'API Android Device Administration [Resources, 44]. Les implémentations d'appareils DOIVENT fournir une implémentation de la classe DevicePolicyManager [Resources, 45]. Les implémentations d'appareils qui incluent la prise en charge des écrans de verrouillage basés sur un CODE (numérique) ou un MOT DE PASSE (alphanumérique) DOIVENT prendre en charge l'ensemble des stratégies d'administration des appareils définies dans la documentation du SDK Android [Ressources, 44] et signaler la fonctionnalité de plate-forme android.software.device_admin.

3.9.1 Préparation de l'appareil

3.9.1.1 Provisionnement du propriétaire de l'appareil

Si une implémentation d'appareil déclare la fonctionnalité android.software.device_admin, le flux de configuration prêt à l'emploi DOIT permettre d'enregistrer une application de contrôle des règles relatives aux appareils (DPC) en tant qu'application du propriétaire de l'appareil [ Ressources, 46]. Les implémentations d'appareils PEUVENT comporter une application préinstallée qui effectue des fonctions d'administration de l'appareil, mais cette application NE DOIT PAS être définie comme l'application du propriétaire de l'appareil sans le consentement explicite ou l'action de l'utilisateur ou de l'administrateur de l'appareil.

L'expérience utilisateur du processus de provisionnement du propriétaire de l'appareil (flux lancé par android.app.action.PROVISION_MANAGED_DEVICE [ Ressources, 47]) DOIT être conforme à l'implémentation AOSP.

Si l'implémentation de l'appareil signale android.hardware.nfc, le NFC doit être activé, même lors du flux de configuration prêt à l'emploi, afin de permettre le provisionnement NFC des propriétaires d'appareils [Resources, 48].

3.9.1.2 Provisionnement de profils gérés

Si une implémentation d'appareil déclare android.software.managed_users, il DOIT être possible d'inscrire une application de contrôle des règles relatives aux appareils (DPC) en tant que propriétaire d'un nouveau profil géré. [ Ressources, 49]

L'expérience utilisateur du processus de provisionnement de profil géré (flux lancé par android.app.action.PROVISION_MANAGED_PROFILE [ Ressources, 50]) DOIT être conforme à l'implémentation AOSP.

3.9.2 Prise en charge des profils gérés

Les appareils compatibles avec les profils gérés sont les suivants:

• Déclarer android.software.device_admin (voir la section 3.9 Administration des appareils)
• ne sont pas des appareils avec peu de RAM (voir la section 7.6.1) ;
• Allouer de l'espace de stockage interne (non amovible) en tant qu'espace de stockage partagé (voir la section 7.6.2)

Les appareils compatibles avec les profils gérés DOIVENT:

• Déclarez le flag de fonctionnalité de plate-forme android.software.managed_users.
• Prise en charge des profils gérés via les API android.app.admin.DevicePolicyManager
• Autoriser la création d'un seul profil géré [Ressources, 50]
• Utilisez un badge d'icône (similaire au badge de travail en amont d'AOSP) pour représenter les applications et widgets gérés, ainsi que d'autres éléments d'interface utilisateur avec badge, tels que "Récents" et "Notifications".
• Affichez une icône de notification (similaire au badge professionnel en amont d'AOSP) pour indiquer quand l'utilisateur se trouve dans une application de profil géré.
• Affichez un toast indiquant que l'utilisateur se trouve dans le profil géré si et quand l'appareil se réveille (ACTION_USER_PRESENT) et que l'application de premier plan se trouve dans le profil géré.
• Si un profil géré existe, affichez 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, si cette fonctionnalité est activée par le contrôleur de stratégie d'appareil.
• Si un profil géré existe, exposez les affordances utilisateur suivantes pour l'utilisateur principal et le profil géré :
  • Comptabilisation distincte de la batterie, de la position, de la consommation de données mobiles et de l'espace de stockage pour l'utilisateur principal et le profil géré.
  • Gestion indépendante des applications VPN installées dans l'utilisateur principal ou le profil géré.
  • Gestion indépendante des applications installées dans le profil utilisateur principal ou géré.
  • Gestion indépendante des comptes dans le profil utilisateur principal ou géré.
• Assurez-vous que le numéroteur par défaut peut rechercher les informations de l'appelant à partir du profil géré (le cas échéant) et de celles du profil principal, si le contrôleur de stratégie d'appareil le permet.
• DOIT s'assurer qu'il répond à toutes les exigences de sécurité applicables à un appareil avec plusieurs utilisateurs activés (voir la section 9.5), même si le profil géré n'est pas comptabilisé comme un autre utilisateur en plus de l'utilisateur principal.

3.10. Accessibilité

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

Les implémentations d'appareils doivent respecter les exigences suivantes:

• Les implémentations Android Automotive DOIVENT fournir une implémentation du framework d'accessibilité Android conforme à l'implémentation Android par défaut.
• Les implémentations d'appareils (Android Auto exclu) DOIVENT fournir une implémentation du framework d'accessibilité Android conforme à l'implémentation Android par défaut.
• Les implémentations d'appareils (Android Automotive exclu) DOIVENT prendre en charge les implémentations de services d'accessibilité tiers via les API android.accessibilityservice [Ressources, 52].
• Les implémentations d'appareils (Android Automotive exclu) DOIVENT générer des AccessibilityEvents et les transmettre à toutes les implémentations d'AccessibilityService enregistrées de manière cohérente avec l'implémentation Android par défaut.
• Les implémentations d'appareils (appareils Android Auto et Android Watch sans sortie audio exclue) DOIVENT fournir un mécanisme accessible à l'utilisateur pour activer et désactiver les services d'accessibilité, et DOIVENT afficher cette interface en réponse à l'intent android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS.

En outre, les implémentations d'appareil DOIVENT fournir une implémentation d'un service d'accessibilité sur l'appareil et DOIVENT fournir un mécanisme permettant aux utilisateurs d'activer le service d'accessibilité lors de la configuration de l'appareil. Une implémentation Open Source d'un service d'accessibilité est disponible dans le projet Eyes Free [Ressources, 53].

3.11. Synthèse vocale

Android inclut des API qui permettent aux applications d'utiliser les services de synthèse vocale (TTS) et aux fournisseurs de services de fournir des implémentations de services de synthèse vocale [Ressources, 54]. Les implémentations d'appareils signalant la fonctionnalité android.hardware.audio.output DOIVENT respecter ces exigences liées au framework TTS Android.

Implémentations Android Automotive:

• DOIT être compatible avec les API du framework TTS Android.
• Peut prendre en charge l'installation de moteurs de synthèse vocale tiers. Si cette fonctionnalité est prise en charge, les partenaires DOIVENT fournir une interface accessible à l'utilisateur qui lui permet de sélectionner un moteur TTS à utiliser au niveau du système.

Toutes les autres implémentations d'appareils:

• DOIT être compatible avec les API du framework TTS Android et DOIT inclure un moteur TTS compatible avec les langues disponibles sur l'appareil. Notez que le logiciel Open Source Android en amont inclut une implémentation de moteur TTS complète.
• DOIT prendre en charge l'installation de moteurs TTS tiers
• DOIT fournir une interface accessible aux utilisateurs qui leur permet de sélectionner un moteur TTS à utiliser au niveau du système

3.12. TV Input Framework

Le framework d'entrée Android TV (TIF) simplifie la diffusion de contenu en direct sur les appareils Android TV. TIF fournit une API standard pour créer des modules d'entrée qui contrôlent les appareils Android TV. Les implémentations d'appareils Android TV DOIVENT prendre en charge le TV Input Framework [Ressources, 55].

Les implémentations d'appareils compatibles avec le TIF DOIVENT déclarer la fonctionnalité de plate-forme android.software.live_tv.

3.12.1. Application TV

Toute implémentation d'appareil qui déclare la prise en charge de la télévision en direct DOIT disposer d'une application TV installée (application TV). Le projet Android Open Source fournit une implémentation de l'application TV.

L'application TV par défaut doit permettre d'accéder aux chaînes à partir des entrées installées et des entrées tierces. Notez que les entrées installées englobent toutes les entrées fournies par défaut, qu'elles soient basées sur des fichiers TIF ou non.

L'application TV DOIT fournir des fonctionnalités permettant d'installer et d'utiliser des chaînes de télévision [Ressources, 56] et doit respecter les exigences suivantes:

• Les implémentations d'appareils DOIVENT permettre l'installation et la gestion d'entrées tierces basées sur le TIF (entrées tierces) [Ressources, 57].
• Les implémentations d'appareils PEUVENT fournir une séparation visuelle entre les entrées préinstallées basées sur le TIF (entrées installées) [Ressources, 58] et les entrées tierces.
• Les implémentations de l'appareil NE DOIVENT PAS afficher les entrées tierces à plus d'une action de navigation de l'application TV (c'est-à-dire développer une liste d'entrées tierces à partir de l'application TV).

3.12.1.1. Guide des programmes électroniques

Les implémentations d'appareils Android TV DOIVENT afficher une superposition informative et interactive, qui DOIT inclure un guide électronique des programmes (EPG) généré à partir des valeurs des champs TvContract.Programs [Resources, 59]. L'EPG doit répondre aux exigences suivantes:

• L'EPG DOIT afficher les informations de toutes les entrées installées et des entrées tierces.
• L'EPG peut fournir une séparation visuelle entre les entrées installées et les entrées tierces.
• Il est vivement recommandé que l'EPG affiche les entrées installées et les entrées tierces avec une importance égale. L'EPG NE DOIT PAS afficher les entrées tierces à plus d'une action de navigation des entrées installées sur l'EPG.
• Lors du changement de chaîne, les implémentations d'appareils DOIVENT afficher les données EPG du programme en cours de lecture.

3.12.1.2. Navigation

Les dispositifs d'entrée de l'appareil Android TV (télécommande, application de télécommande ou manette de jeu) DOIVENT permettre de naviguer vers toutes les sections de l'écran pouvant être actionnées via le pavé directionnel. Le pavé directionnel vers le haut et vers le bas DOIT être utilisé pour changer de chaîne de télévision en direct lorsqu'aucune section ne peut être actionnée à l'écran.

L'application TV DOIT transmettre les événements clés aux entrées HDMI via le CEC.

3.12.1.3. Association d'applications à une entrée TV

Les implémentations d'appareils Android TV DOIVENT prendre en charge l'association d'applications d'entrée TV, ce qui permet à toutes les entrées de fournir des liens d'activité entre l'activité en cours et une autre activité (par exemple, un lien entre une programmation en direct et un contenu associé) [Ressources, 60]. L'application TV doit afficher l'association de l'application d'entrée TV lorsqu'elle est fournie.

4. Compatibilité du packaging d'applications

Les implémentations d'appareils DOIVENT installer et exécuter les fichiers ".apk" Android tels que générés par l'outil "aapt" inclus dans le SDK Android officiel [Ressources, 61].

Les implémentations d'appareils NE DOIVENT PAS étendre les formats de fichier .apk [Ressources, 62], Android Manifest [Ressources, 49], bytecode Dalvik [Ressources, 23] ou bytecode RenderScript de manière à empêcher l'installation et l'exécution correctes de ces fichiers sur d'autres appareils compatibles.

5. Compatibilité multimédia

5.1. Codecs multimédias

Les implémentations d'appareils DOIVENT prendre en charge les principaux formats multimédias spécifiés dans la documentation du SDK Android [Ressources, 64], sauf dans les cas explicitement autorisés dans ce document. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge les formats multimédias, les encodeurs, les décodeurs, les types de fichiers et les formats de conteneur définis dans les tableaux ci-dessous et signalés via MediaCodecList [Resources, 65]. Les implémentations d'appareils DOIVENT également être en mesure de décoder tous les profils signalés dans CamcorderProfile [Ressources, 66] et DOIVENT être en mesure de décoder tous les formats qu'ils peuvent encoder. Tous ces codecs sont fournis en tant qu'implémentations logicielles dans l'implémentation Android préférée du Projet Android Open Source.

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

5.1.1. Codecs audio

Format/Codec	Encodeur	Décodeur	Détails	Types de fichiers/Formats de conteneurs compatibles
Profil MPEG-4 AAC (AAC LC)	OBLIGATOIRE1	REQUIRED	Compatibilité avec les contenus mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 8 à 48 kHz.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) AAC brut ADTS (.aac, décodage sous Android 3.1 et versions ultérieures, encodage sous Android 4.0 et versions ultérieures, ADIF non pris en charge) MPEG-TS (.ts, non accessible, Android 3.0 ou version ultérieure)
Profil MPEG-4 HE AAC (AAC+)	OBLIGATOIRE1 (Android 4.1 ou version ultérieure)	REQUIRED	Compatibilité avec le contenu mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 16 à 48 kHz.
Profil MPEG-4 HE AACv2 (AAC+ amélioré)		REQUIRED	Compatibilité avec le contenu mono/stéréo/5.0/5.12 avec des taux d'échantillonnage standards de 16 à 48 kHz.
AAC ELD (AAC à faible latence amélioré)	OBLIGATOIRE1 (Android 4.1 et versions ultérieures)	OBLIGATOIRE (Android 4.1 ou version ultérieure)	Compatibilité avec le contenu mono/stéréo avec des taux d'échantillonnage standards de 16 à 48 kHz.
AMR-NB	OBLIGATOIRE3	OBLIGATOIRE3	4,75 à 12,2 kbit/s échantillonnés à 8 kHz	3GPP (.3gp)
AMR-WB	OBLIGATOIRE3	OBLIGATOIRE3	9 débits de 6,60 kbit/s à 23,85 kbit/s échantillonnés à 16 kHz
FLAC		OBLIGATOIRE (Android 3.1 et versions ultérieures)	Mono/Stéréo (pas de multicanaux) Taux d'échantillonnage jusqu'à 48 kHz (mais jusqu'à 44,1 kHz RECOMMANDÉ sur les appareils avec sortie 44,1 kHz, car le convertisseur 48 kHz vers 44,1 kHz n'inclut pas de filtre passe-bas). 16 bits RECOMMANDÉ ; aucun tramage appliqué pour les 24 bits.	FLAC (.flac) uniquement
MP3		REQUIRED	Mono/Stéréo 8-320 kbit/s constant (CBR) ou débit variable (VBR)	MP3 (.mp3)
MIDI		REQUIRED	Types MIDI 0 et 1 Versions 1 et 2 de DLS XMF et Mobile XMF. Compatibilité avec les formats de sonnerie RTTTL/RTX, OTA et iMelody	Types 0 et 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		REQUIRED		Ogg (.ogg) Matroska (.mkv, Android 4.0 et versions ultérieures)
PCM/WAVE	OBLIGATOIRE4 (Android 4.1 ou version ultérieure)	REQUIRED	PCM linéaire 16 bits (débits jusqu'à la limite du matériel). Les appareils DOIVENT prendre en charge les taux d'échantillonnage pour l'enregistrement PCM brut aux fréquences de 8 000, 11 025, 16 000 et 44 100 Hz.	WAVE (.wav)
Opus		OBLIGATOIRE (Android 5.0 ou version ultérieure)		Matroska (.mkv)

1 Obligatoire pour les implémentations d'appareils qui définissent android.hardware.microphone, mais facultatif pour les implémentations d'appareils Android Watch.

2 Seul le downmix du contenu 5.0/5.1 est obligatoire. L'enregistrement ou le rendu de plus de deux canaux est facultatif.

3 Obligatoire pour les implémentations d'appareils Android portables.

4 Obligatoire pour les implémentations d'appareils qui définissent android.hardware.microphone, y compris les implémentations d'appareils Android Watch.

5.1.2. Codecs d'image

Format/Codec	Encodeur	Décodeur	Détails	Types de fichiers/Formats de conteneurs compatibles
JPEG	REQUIRED	REQUIRED	Base+progressive	JPEG (.jpg)
GIF		REQUIRED		GIF (.gif)
PNG	REQUIRED	REQUIRED		PNG (.png)
BMP		REQUIRED		BMP (.bmp)
WebP	REQUIRED	REQUIRED		WebP (.webp)

5.1.3. Codecs vidéo

Format/Codec	Encodeur	Décodeur	Détails	Types de fichiers/Formats de conteneurs compatibles
H.263	OBLIGATOIRE1	OBLIGATOIRE2		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	OBLIGATOIRE2	OBLIGATOIRE2	Pour en savoir plus, consultez les sections 5.2 et 5.3.	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, audio AAC uniquement, non accessible par recherche, Android 3.0 ou version ultérieure)
H.265 HEVC		OBLIGATOIRE5	Pour en savoir plus, consultez la section 5.3.	MPEG-4 (.mp4)
MPEG-2		FORTEMENT RECOMMANDÉ6	Main Profile	MPEG2-TS
MPEG-4 SP		OBLIGATOIRE2		3GPP (.3gp)
VP83	OBLIGATOIRE2 (Android 4.3 ou version ultérieure)	OBLIGATOIRE2 (Android 2.3.3 ou version ultérieure)	Pour en savoir plus, consultez les sections 5.2 et 5.3.	WebM (.webm) [Ressources, 67 Matroska (.mkv, Android 4.0 et versions ultérieures)4
VP9		OBLIGATOIRE2 (Android 4.4 ou version ultérieure)	Pour en savoir plus, consultez la section 5.3.	WebM (.webm) [Ressources, 67] Matroska (.mkv, Android 4.0 et versions ultérieures)4

1 Obligatoire pour les implémentations d'appareils qui incluent du matériel d'appareil photo et définissent android.hardware.camera ou android.hardware.camera.front.

2 Obligatoire pour les implémentations d'appareils, à l'exception des appareils Android Watch.

3 Pour une qualité acceptable des services de streaming vidéo Web et de visioconférence, les implémentations d'appareils DOIVENT utiliser un codec VP8 matériel conforme aux exigences de [Ressources, 68].

4 Les implémentations d'appareils DOIVENT prendre en charge l'écriture de fichiers Matroska WebM.

5 VITEMENT RECOMMANDÉ pour Android Auto, facultatif pour Android Watch et obligatoire pour tous les autres types d'appareils.

6 Ne s'applique qu'aux implémentations d'appareils Android TV.

5.2. Encodage vidéo

Les implémentations d'appareils Android avec des encodeurs H.263 DOIVENT être compatibles avec le niveau de profil de référence 45.

Les implémentations d'appareils Android compatibles avec le codec H.264 DOIVENT prendre en charge le niveau 3 du profil de référence et les profils d'encodage vidéo SD (Standard Definition) suivants. Elles DOIVENT également prendre en charge le niveau 4 du profil principal et les profils d'encodage vidéo HD (High Definition) suivants. Il est vivement recommandé d'encoder des vidéos HD 1080p à 30 FPS sur les appareils Android TV.

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

1 Si le matériel est compatible, mais FORTEMENT RECOMMANDÉ pour les appareils Android TV.

Les implémentations d'appareils Android compatibles avec le codec VP8 DOIVENT prendre en charge les profils d'encodage vidéo SD et DOIVENT prendre en charge les profils d'encodage vidéo HD (haute définition) suivants.

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

1 Si le matériel est compatible.

5.3. Décodage vidéo

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

Les implémentations d'appareils Android avec des décodeurs H.263 DOIVENT être compatibles avec le niveau de profil de référence 30.

Les implémentations d'appareils Android avec des décodeurs MPEG-4 DOIVENT prendre en charge le profil simple de niveau 3.

Les implémentations d'appareils Android avec des décodeurs H.264 DOIVENT être compatibles avec le profil principal de niveau 3.1 et les profils de décodage vidéo SD suivants, et DEVRAIENT être compatibles avec les profils de décodage HD. Les appareils Android TV DOIVENT être compatibles avec le profil High Profile de niveau 4.2 et le profil de décodage HD 1080p.

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

1 OBLIGATOIRE lorsque la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo.

2 OBLIGATOIRE pour les implémentations d'appareils Android TV.

Les implémentations d'appareils Android compatibles avec le codec VP8, comme décrit dans la section 5.1.3, DOIVENT prendre en charge les profils de décodage SD suivants et DOIVENT prendre en charge les profils de décodage HD. Les appareils Android TV DOIVENT être compatibles avec le profil de décodage HD 1080p.

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

1 OBLIGATOIRE lorsque la hauteur indiquée par la méthode Display.getSupportedModes() est égale ou supérieure à la résolution vidéo.

2 OBLIGATOIRE pour les implémentations d'appareils Android TV.

Les implémentations d'appareils Android, lorsqu'elles prennent en charge le codec VP9 comme décrit dans la section 5.1.3, DOIVENT prendre en charge les profils de décodage vidéo SD suivants et DOIVENT prendre en charge les profils de décodage HD. Il est vivement recommandé que les appareils Android TV soient compatibles avec le profil de décodage HD 1080p et DOIVENT être compatibles avec le profil de décodage UHD. Lorsque le profil de décodage vidéo UHD est pris en charge, il DOIT prendre en charge la profondeur de couleur 8 bits et DEVRAIT prendre en charge le profil 2 du VP9 (10 bits).

	SD (basse qualité)	SD (haute qualité)	HD 720p1	HD 1080p2	UHD2
Résolution vidéo	320 x 180 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	60 FPS	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	5 Mbit/s	20 Mbit/s

1 Obligatoire pour les implémentations d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.

2 FORTEMENT RECOMMANDÉ pour les implémentations d'appareils Android TV existantes lorsqu'elles sont compatibles avec le matériel.

Les implémentations d'appareils Android, lorsqu'elles prennent en charge le codec H.265 comme décrit dans la section 5.1.3, DOIVENT prendre en charge le niveau principal du profil principal de niveau 3 et les profils de décodage vidéo SD suivants, et DOIVENT prendre en charge les profils de décodage HD. Il est vivement recommandé que les appareils Android TV soient compatibles avec le profil de décodage UHD et le profil de décodage HD 1080p. Si le profil de décodage HD 1080p est pris en charge, il DOIT prendre en charge le niveau 4.1 du profil principal. Si le décodage UHD est pris en charge, il DOIT prendre en charge le profil de niveau principal 5 Main10.

	SD (basse qualité)	SD (haute qualité)	HD 720p1	HD 1080p2	UHD2
Résolution vidéo	352 x 288 px	640 x 360 px	1 280 x 720 px	1 920 x 1 080 px	3 840 x 2 160 px
Fréquence d'images de la vidéo	30 ips	30 ips	30 ips	60 FPS2	60 FPS
Débit vidéo	600 Kbits/s	1,6 Mbit/s	4 Mbit/s	10 Mbit/s	20 Mbit/s

1 Obligatoire pour les implémentations d'appareils Android TV, mais uniquement pour les autres types d'appareils si le matériel est compatible.

2 FORTEMENT RECOMMANDÉ pour les implémentations d'appareils Android TV existantes lorsqu'elles sont compatibles avec le matériel.

5.4. Enregistrement audio

Bien que certaines des exigences décrites dans cette section soient indiquées comme "DEVOIR" depuis Android 4.3, la définition de la compatibilité pour une future version prévoit de les remplacer par "DEVOIR". Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux respectent ces exigences, qui sont indiquées comme "DOIT". Sinon, ils ne pourront pas être compatibles avec Android lors de la mise à niveau vers la future version.

5.4.1. Capture audio RAW

Les implémentations d'appareils qui déclarent android.hardware.microphone DOIVENT permettre la capture de contenu audio brut avec les caractéristiques suivantes:

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

La capture pour les taux d'échantillonnage ci-dessus DOIT être effectuée sans suréchantillonnage, et tout sous-échantillonnage DOIT inclure un filtre anticrénelage approprié.

Les implémentations d'appareils qui déclarent android.hardware.microphone DOIVENT permettre la capture de contenu audio brut avec les caractéristiques suivantes:

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

Si la capture pour les taux d'échantillonnage ci-dessus est prise en charge, la capture DOIT être effectuée sans mise à l'échelle à un format supérieur à 16 000:22 050 ou 44 100:48 000. Tout suréchantillonnage ou sous-échantillonnage DOIT inclure un filtre anticrénelage approprié.

5.4.2. Enregistrer pour la reconnaissance vocale

En plus des spécifications d'enregistrement ci-dessus, lorsqu'une application a commencé à enregistrer un flux audio à l'aide de la source audio android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION:

• L'appareil DOIT présenter des caractéristiques d'amplitude par rapport à la fréquence à peu près plates: plus précisément, ±3 dB, de 100 Hz à 4 000 Hz.
• La sensibilité d'entrée audio DOIT être définie de sorte qu'une source de niveau de puissance acoustique (SPL) de 90 dB à 1 000 Hz génère une valeur efficace de 2 500 pour les échantillons 16 bits.
• Les niveaux d'amplitude PCM DOIVENT suivre de manière linéaire les variations de SPL d'entrée sur une plage d'au moins 30 dB, allant de -18 dB à +12 dB par rapport à 90 dB SPL au niveau du micro.
• La distorsion harmonique totale DOIT être inférieure à 1% pour 1 kHz à un niveau d'entrée de 90 dB SPL au niveau du micro.
• Le traitement de réduction du bruit, le cas échéant, DOIT être désactivé.
• Le contrôle de gain automatique, le cas échéant, DOIT être désactivé

Si la plate-forme est compatible avec les technologies de suppression du bruit optimisées pour la reconnaissance vocale, l'effet DOIT être contrôlable à partir de l'API android.media.audiofx.NoiseSuppressor. De plus, le champ UUID du descripteur d'effet du suppresseur de bruit DOIT identifier de manière unique chaque implémentation de la technologie de suppression du bruit.

5.4.3. Capture pour le redirignement de la lecture

La classe android.media.MediaRecorder.AudioSource inclut la source audio REMOTE_SUBMIX. Les appareils qui déclarent android.hardware.audio.output DOIVENT implémenter correctement la source audio REMOTE_SUBMIX afin que, lorsqu'une application utilise l'API android.media.AudioRecord pour enregistrer à partir de cette source audio, elle puisse capturer un mix de tous les flux audio, à l'exception des suivants:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. Lecture audio

Les implémentations d'appareils qui déclarent android.hardware.audio.output DOIVENT respecter les exigences de cette section.

5.5.1. Lecture audio brute

L'appareil DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:

• Format: PCM linéaire, 16 bits
• Taux d'échantillonnage: 8 000, 11 025, 16 000, 22 050, 32 000 et 44 100
• Canaux: mono, stéréo

L'appareil DOIT permettre la lecture de contenu audio brut avec les caractéristiques suivantes:

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

5.5.2. Effets audio

Android fournit une API pour les effets audio pour les implémentations d'appareils [Ressources, 69]. Implémentations d'appareils qui déclarent la fonctionnalité android.hardware.audio.output:

• DOIT prendre en charge les implémentations EFFECT_TYPE_EQUALIZER et EFFECT_TYPE_LOUDNESS_ENHANCER contrôlables via les sous-classes AudioEffect Equalizer et LoudnessEnhancer.
• DOIT être compatible avec l'implémentation de l'API Visualizer, contrôlable via la classe Visualizer.
• DOIT prendre en charge les implémentations EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB et EFFECT_TYPE_VIRTUALIZER, qui peuvent être contrôlées via les sous-classes AudioEffect BassBoost, EnvironmentalReverb, PresetReverb et Virtualizer.

5.5.3. Volume de sortie audio

Les implémentations d'appareils Android TV DOIVENT prendre en charge le volume principal du système et l'atténuation du volume de sortie audio numérique sur les sorties compatibles, à l'exception de la sortie de passthrough audio compressé (où aucun décodage audio n'est effectué sur l'appareil).

5.6. Latence audio

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

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

• latence de sortie ; Intervalle entre le moment où une application écrit un frame de données encodées en PCM et le moment où le son correspondant peut être entendu par un écouteur externe ou observé par un transducteur.
• Latence de sortie à froid La latence de sortie pour le premier frame, lorsque le système de sortie audio était inactif et éteint avant la requête.
• latence de sortie continue. La latence de sortie pour les frames suivants, une fois que l'appareil lit de l'audio.
• latence d'entrée ; Intervalle entre le moment où un son externe est présenté à l'appareil et le moment où une application lit le frame correspondant de données codées PCM.
• Latence d'entrée à froid Somme du temps d'entrée perdu et de la latence d'entrée pour le premier frame, lorsque le système d'entrée audio était inactif et éteint avant la requête.
• latence d'entrée continue ; Latence d'entrée pour les images suivantes lorsque l'appareil capture l'audio.
• jitter de sortie à froid. Variance entre les mesures distinctes des valeurs de latence de sortie à froid.
• jitter d'entrée à froid. Variance entre les mesures distinctes des valeurs de latence d'entrée à froid.
• latence aller-retour continue ; Somme de la latence d'entrée continue, de la latence de sortie continue et d'une période de tampon. Le terme de période de tampon permet de définir le temps de traitement de l'application et de 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 PCM OpenSL ES Ensemble des API OpenSL ES liées au PCM dans le NDK Android. Consultez NDK_root/docs/opensles/index.html.

Il est vivement recommandé que les implémentations d'appareils qui déclarent android.hardware.audio.output répondent ou dépassent ces exigences de sortie audio:

• Latence de sortie à froid de 100 millisecondes ou moins
• une latence de sortie continue de 45 millisecondes ou moins
• réduire le jitter de sortie à froid ;

Si une implémentation d'appareil répond aux exigences de cette section après tout calibrage initial lors de l'utilisation de l'API de file d'attente de tampon PCM OpenSL ES, pour la latence de sortie continue et la latence de sortie à froid sur au moins un appareil de sortie audio compatible, il est FORTEMENT RECOMMANDÉ de signaler la prise en charge de l'audio à faible latence en signalant la fonctionnalité android.hardware.audio.low_latency via la classe android.content.pm.PackageManager [Resources, 70]. À l'inverse, si l'implémentation de l'appareil ne répond pas à ces exigences, elle NE DOIT PAS indiquer la prise en charge de l'audio à faible latence.

Il est vivement recommandé que les implémentations d'appareils incluant android.hardware.microphone répondent à ces exigences audio d'entrée:

• une latence d'entrée à froid de 100 millisecondes ou moins
• une latence d'entrée continue de 30 millisecondes ou moins ;
• une latence aller-retour continue de 50 millisecondes ou moins
• réduire le jitter d'entrée à froid ;

5.7. Protocoles de réseau

Les appareils DOIVENT prendre en charge les protocoles de réseau multimédia pour la lecture audio et vidéo, comme indiqué dans la documentation du SDK Android [Ressources, 64]. Plus précisément, les appareils DOIVENT être compatibles avec les protocoles réseau multimédias suivants:

• RTSP (RTP, SDP)
• Streaming progressif HTTP(S)
• Draft protocol for HTTP(S) Live Streaming, version 3 [Resources, 71]

5.8. Secure Media

Les implémentations d'appareils compatibles avec la sortie vidéo sécurisée et capables de prendre en charge les surfaces sécurisées DOIVENT déclarer la prise en charge de Display.FLAG_SECURE. Les implémentations d'appareils qui déclarent la prise en charge de Display.FLAG_SECURE, si elles sont compatibles avec un protocole d'affichage sans fil, DOIVENT sécuriser la liaison avec un mécanisme cryptographique puissant tel que HDCP 2.x ou version ultérieure pour les écrans sans fil Miracast. De même, si elles sont compatibles avec un écran externe filaire, les implémentations de l'appareil DOIVENT être compatibles avec HDCP 1.2 ou version ultérieure. Les implémentations d'appareils Android TV DOIVENT être compatibles avec HDCP 2.2 pour les appareils compatibles avec la résolution 4K et HDCP 1.4 ou version ultérieure pour les résolutions inférieures. L'implémentation Open Source d'Android en amont prend en charge les écrans sans fil (Miracast) et filaires (HDMI) qui répondent à cette exigence.

5.9. MIDI (Musical Instrument Digital Interface)

Si une implémentation d'appareil est compatible avec le transport logiciel MIDI inter-application (appareils MIDI virtuels) et qu'elle est compatible avec le MIDI sur tous les transports matériels compatibles avec le MIDI suivants pour lesquels elle fournit une connectivité générique non MIDI, il est FORTEMENT RECOMMANDÉ de signaler la prise en charge de la fonctionnalité android.software.midi via la classe android.content.pm.PackageManager [Resources, 70].

Les transports matériels compatibles avec le MIDI sont les suivants:

• Mode hôte USB (section 7.7 USB)
• Mode périphérique USB (section 7.7 USB)

À l'inverse, si l'implémentation de l'appareil fournit une connectivité générique autre que MIDI via un transport matériel compatible avec MIDI listé ci-dessus, mais qu'elle n'est pas compatible avec MIDI via ce transport matériel, elle NE DOIT PAS signaler la prise en charge de la fonctionnalité android.software.midi.

Le MIDI via Bluetooth LE agissant en tant que rôle central (section 7.4.3 Bluetooth) est en phase d'essai. Une implémentation d'appareil qui signale la fonctionnalité android.software.midi et qui fournit une connectivité générique autre que MIDI via Bluetooth LE DOIT prendre en charge le MIDI via Bluetooth LE.

5.10. Audio professionnel

Si une implémentation d'appareil répond à toutes les exigences suivantes, il est FORTEMENT RECOMMANDÉ de signaler la prise en charge de la fonctionnalité android.hardware.audio.pro via la classe android.content.pm.PackageManager [Resources, 70].

• L'implémentation de l'appareil DOIT indiquer la prise en charge de la fonctionnalité android.hardware.audio.low_latency.
• La latence audio aller-retour continue, comme défini dans la section 5.6 "Latence audio", DOIT être de 20 ms ou moins et DEVRAIT être de 10 ms ou moins sur au moins un chemin pris en charge.
• Si l'appareil inclut un connecteur audio 3,5 mm à quatre conducteurs, la latence audio aller-retour continue DOIT être de 20 millisecondes ou moins sur le chemin du connecteur audio, et DEVRAIT être de 10 millisecondes ou moins sur le chemin du connecteur audio.
• L'implémentation de l'appareil DOIT inclure un ou plusieurs ports USB compatibles avec le mode hôte USB et le mode périphérique USB.
• Le mode hôte USB DOIT implémenter la classe audio USB.
• Si l'appareil inclut un port HDMI, l'implémentation de l'appareil DOIT prendre en charge la sortie en stéréo et en huit canaux avec une profondeur de 20 bits ou 24 bits et 192 kHz, sans perte de profondeur de bits ni reéchantillonnage.
• L'implémentation de l'appareil DOIT indiquer la prise en charge de la fonctionnalité android.software.midi.
• Si l'appareil inclut un connecteur audio 3,5 mm à quatre conducteurs, il est FORTEMENT RECOMMANDÉ que l'implémentation de l'appareil respecte la section Spécifications de l'appareil mobile (connecteur) de la spécification du casque audio filaire (v1.1).

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

6.1. Outils pour les développeurs

Les implémentations d'appareils DOIVENT prendre en charge les outils de développement Android fournis dans le SDK Android. Les appareils Android compatibles DOIVENT être compatibles avec:

• Android Debug Bridge (adb) [Ressources, 72]

Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctions adb, comme indiqué dans le SDK Android, y compris dumpsys [Resources, 73]. Le daemon adb côté appareil DOIT être inactif par défaut, et un mécanisme accessible à l'utilisateur DOIT être disponible pour activer Android Debug Bridge. Si une implémentation d'appareil omet le mode périphérique USB, elle DOIT implémenter le pont de débogage Android via un réseau local (tel qu'Ethernet ou 802.11).

Android est compatible avec adb sécurisé. adb sécurisé active adb sur les hôtes authentifiés connus. Les implémentations d'appareils DOIVENT être compatibles avec adb sécurisé.

• Dalvik Debug Monitor Service (ddms) [Resources, 74]

Les implémentations d'appareils DOIVENT prendre en charge toutes les fonctionnalités ddms, comme indiqué dans le SDK Android. Comme ddms utilise adb, la prise en charge de ddms DOIT être inactive par défaut, mais DOIT être prise en charge chaque fois que l'utilisateur a activé Android Debug Bridge, comme indiqué ci-dessus.

• Singe [Ressources, 75]

Les implémentations d'appareils DOIVENT inclure le framework Monkey et le rendre disponible pour les applications.

• SysTrace [Resources, 76]

Les implémentations d'appareils DOIVENT prendre en charge l'outil Systrace, comme indiqué dans le SDK Android. Systrace doit être inactif par défaut, et un mécanisme accessible par l'utilisateur doit être disponible pour l'activer.

La plupart des systèmes Linux et des systèmes Apple Macintosh reconnaissent les appareils Android à l'aide des outils du SDK Android standard, sans assistance supplémentaire. Toutefois, les systèmes Microsoft Windows nécessitent généralement un pilote pour les nouveaux appareils Android. (Par exemple, les nouveaux ID de fournisseur et parfois les nouveaux ID d'appareil nécessitent des pilotes USB personnalisés pour les systèmes Windows.) Si une implémentation d'appareil n'est pas reconnue par l'outil adb fourni dans le SDK Android standard, les implémentateurs d'appareils DOIVENT fournir des pilotes Windows permettant aux développeurs de se connecter à l'appareil à l'aide du protocole adb. Ces pilotes DOIVENT être fournis pour Windows XP, Windows Vista, Windows 7, Windows 8 et Windows 10, en versions 32 bits et 64 bits.

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'appareil DOIVENT respecter l'intent android.settings.APPLICATION_DEVELOPMENT_SETTINGS pour afficher les paramètres liés au développement d'applications [Ressources, 77]. L'implémentation Android en amont masque le menu "Options pour les développeurs" par défaut et permet aux utilisateurs de lancer les options pour les développeurs après avoir appuyé sept fois sur l'élément de menu Settings > About Device > Build Number (Paramètres > À propos de l'appareil > Numéro de version). Les implémentations d'appareils DOIVENT offrir une expérience cohérente pour les options pour les développeurs. Plus précisément, les implémentations d'appareils DOIVENT masquer les options pour les développeurs par défaut et DOIVENT fournir un mécanisme permettant d'activer les options pour les développeurs qui est cohérent avec l'implémentation Android en amont.

7. Compatibilité matérielle

Si un appareil inclut un composant matériel particulier associé à une API pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android. Si une API du SDK interagit avec un composant matériel déclaré comme facultatif et que l'implémentation de l'appareil ne possède pas ce composant:

• Les définitions de classe complètes (telles que documentées par le SDK) pour les API de composant DOIVENT toujours être présentées.
• Les comportements de l'API DOIVENT être implémentés en tant que no-ops de manière raisonnable.
• Les méthodes d'API DOIVENT renvoyer des valeurs nulles lorsque la documentation du SDK l'autorise.
• Les méthodes d'API DOIVENT renvoyer des implémentations sans opération de classes pour lesquelles les valeurs nulles ne sont pas autorisées par la documentation du SDK.
• Les méthodes d'API NE DOIVENT PAS générer d'exceptions non documentées par la documentation du SDK.

L'API de téléphonie est un exemple typique de scénario où ces exigences s'appliquent: même sur les appareils autres que des téléphones, ces API doivent être implémentées comme des opérations sans opération raisonnables.

Les implémentations d'appareils DOIVENT signaler de manière cohérente des informations de configuration matérielle précises via les méthodes getSystemAvailableFeatures() et hasSystemFeature(String) de la classe android.content.pm.PackageManager pour la même empreinte de compilation. [Resources, 70]

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 s'assurer que les applications tierces fonctionnent correctement sur différentes configurations matérielles [Resources, 78]. Les appareils DOIVENT implémenter correctement ces API et ces comportements, comme indiqué dans cette section.

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

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

7.1.1. Configuration de l'écran

7.1.1.1. Taille d'écran

Le framework d'UI Android est compatible avec différentes tailles d'écran et permet aux applications de interroger la taille de l'écran de l'appareil (également appelée "mise en page de l'écran") via android.content.res.Configuration.screenLayout avec SCREENLAYOUT_SIZE_MASK. Les implémentations d'appareils DOIVENT indiquer la taille d'écran correcte, telle que définie dans la documentation du SDK Android [Resources, 78] et déterminée par la plate-forme Android en amont. Plus précisément, les implémentations d'appareils DOIVENT indiquer la taille d'écran correcte en fonction des dimensions d'écran logiques en pixels indépendants de la densité (dp) suivantes.

• Les appareils doivent avoir une taille d'écran d'au moins 426 dp x 320 dp ("petit"), sauf s'il s'agit d'une montre Android.
• Les appareils qui indiquent une taille d'écran "normale" DOIVENT avoir une taille d'écran d'au moins 480 dp x 320 dp.
• Les appareils qui indiquent une taille d'écran "grande" DOIVENT avoir une taille d'écran d'au moins 640 dp x 480 dp.
• Les appareils qui indiquent une taille d'écran "xlarge" DOIVENT avoir une taille d'écran d'au moins 960 dp x 720 dp.

De plus,

• Les appareils Android Watch DOIVENT avoir un écran dont la diagonale physique est comprise entre 1,1 et 2,5 pouces.
• Les autres types d'implémentations d'appareils Android, avec un écran physiquement intégré, DOIVENT avoir un écran d'au moins 6,35 cm de diagonale physique.

Les appareils NE DOIVENT PAS modifier la taille d'écran indiquée à tout moment.

Les applications peuvent indiquer les tailles d'écran qu'elles acceptent via l'attribut <supports-screens> dans le fichier AndroidManifest.xml. Les implémentations d'appareils DOIVENT respecter correctement la compatibilité déclarée des applications avec les écrans de petite, moyenne, grande et très grande taille, comme décrit dans la documentation du SDK Android.

7.1.1.2. Format d'écran

Le format de l'écran DOIT être compris entre 1,3333 (4:3) et 1,86 (environ 16:9), mais les appareils Android Watch PEUVENT avoir un format de 1,0 (1:1), car une telle implémentation d'appareil utilisera UI_MODE_TYPE_WATCH comme android.content.res.Configuration.uiMode.

7.1.1.3. Densité d'écran

Le framework d'UI Android définit un ensemble de densités logiques standards pour aider les développeurs d'applications à cibler les ressources d'application. Les implémentations d'appareils DOIVENT n'indiquer qu'une seule des densités logiques du framework Android suivantes via les API android.util.DisplayMetrics, et DOIVENT exécuter les applications à cette densité standard et NE DOIVENT PAS modifier la valeur à tout moment pour l'affichage par défaut.

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

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

7.1.2. Métriques sur le Réseau Display

Les implémentations d'appareils DOIVENT indiquer les valeurs correctes pour toutes les métriques d'affichage définies dans android.util.DisplayMetrics [Resources, 79] et DOIVENT indiquer les mêmes valeurs, que l'écran intégré ou externe soit utilisé comme écran par défaut.

7.1.3. Orientation de l'écran

Les appareils DOIVENT indiquer les orientations d'écran qu'ils prennent en charge (android.hardware.screen.portrait et/ou android.hardware.screen.landscape) et DOIVENT indiquer au moins une orientation compatible. Par exemple, un appareil doté d'un écran en mode paysage à orientation fixe, comme un téléviseur ou un ordinateur portable, DOIT uniquement signaler android.hardware.screen.landscape.

Les appareils qui signalent les deux orientations d'écran DOIVENT être compatibles avec l'orientation dynamique des applications en mode portrait ou paysage. Autrement dit, l'appareil doit respecter la demande de l'application pour une orientation d'écran spécifique. Les implémentations d'appareils PEUVENT sélectionner l'orientation portrait ou paysage par défaut.

Les appareils DOIVENT indiquer la valeur correcte pour l'orientation actuelle de l'appareil, chaque fois qu'ils sont interrogés via android.content.res.Configuration.orientation, android.view.Display.getOrientation() ou d'autres API.

Les appareils NE DOIVENT PAS modifier la taille ou la densité d'écran signalée lors du changement d'orientation.

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

Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 1.0 et 2.0, comme indiqué et détaillé dans la documentation du SDK Android. Les implémentations d'appareils DOIVENT être compatibles avec OpenGL ES 3.0 ou 3.1 sur les appareils compatibles. Les implémentations d'appareils DOIVENT également prendre en charge Android RenderScript, comme indiqué dans la documentation du SDK Android [Ressources, 80].

Les implémentations d'appareils DOIVENT également s'identifier correctement comme étant compatibles avec OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 ou OpenGL 3.1. Par exemple :

• Les API gérées (par exemple, via la méthode GLES10.getString()) DOIVENT signaler la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
• Les API OpenGL natives C/C++ (API disponibles pour les applications via libGLES_v1CM.so, libGLES_v2.so ou libEGL.so) DOIVENT signaler la prise en charge d'OpenGL ES 1.0 et d'OpenGL ES 2.0.
• Les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0 ou 3.1 DOIVENT prendre en charge les API gérées correspondantes et inclure la prise en charge des API C/C++ natives. Sur les implémentations d'appareils qui déclarent la prise en charge d'OpenGL ES 3.0 ou 3.1, libGLESv2.so DOIT exporter les symboles de fonction correspondants en plus des symboles de fonction OpenGL ES 2.0.

En plus d'OpenGL ES 3.1, Android fournit un pack d'extension avec des interfaces Java [Ressources, 81] et une prise en charge native des fonctionnalités graphiques avancées telles que la tessellation et le format de compression de texture ASTC. Les implémentations d'appareils Android PEUVENT prendre en charge ce pack d'extension et DOIVENT identifier la prise en charge via l'indicateur de fonctionnalité android.hardware.opengles.aep uniquement si elles sont entièrement implémentées.

De plus, les implémentations d'appareils PEUVENT implémenter toutes les extensions OpenGL ES souhaitées. Toutefois, les implémentations d'appareils DOIVENT signaler via les API natives et gérées OpenGL ES toutes les chaînes d'extension qu'elles prennent en charge, et inversement NE DOIVENT PAS signaler les chaînes d'extension qu'elles ne prennent pas en charge.

Notez qu'Android permet aux applications de spécifier facultativement qu'elles nécessitent des formats de compression de texture OpenGL spécifiques. Ces formats sont généralement propres au fournisseur. Android n'exige pas d'implémenter de format de compression de texture spécifique pour les implémentations d'appareils. Toutefois, ils DOIVENT signaler avec précision tous les formats de compression de texture qu'ils acceptent, via la méthode getString() de l'API OpenGL.

Android inclut un mécanisme permettant aux applications de déclarer qu'elles souhaitent activer l'accélération matérielle pour les graphiques 2D au niveau de l'application, de l'activité, de la fenêtre ou de la vue à l'aide d'une balise de fichier manifeste android:hardwareAccelerated ou d'appels d'API directs [Resources, 82].

Les implémentations d'appareils DOIVENT activer l'accélération matérielle par défaut et DOIVENT 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 View Android.

De plus, les implémentations d'appareils DOIVENT présenter un comportement conforme à la documentation du SDK Android sur l'accélération matérielle [Ressources, 82].

Android inclut un objet TextureView qui permet aux développeurs d'intégrer directement des textures OpenGL ES accélérées par matériel en tant que cibles de rendu dans une hiérarchie d'UI. Les implémentations d'appareils DOIVENT être compatibles avec l'API TextureView et DOIVENT présenter un comportement cohérent avec l'implémentation Android en amont.

Android est compatible avec EGL_ANDROID_RECORDABLE, un attribut EGLConfig qui indique si EGLConfig est compatible avec le rendu dans un ANativeWindow qui enregistre des images dans une vidéo. Les implémentations d'appareils DOIVENT prendre en charge l'extension EGL_ANDROID_RECORDABLE [Ressources, 83].

7.1.5. Ancien mode de compatibilité des applications

Android spécifie un "mode de compatibilité" dans lequel le framework fonctionne en mode équivalent à la taille d'écran "normale" (largeur de 320 dp) pour le bénéfice des anciennes applications qui n'ont pas été développées pour les anciennes versions d'Android antérieures à l'indépendance de la taille d'écran.

• Android Automotive n'est pas compatible avec l'ancien mode de compatibilité.
• Toutes les autres implémentations d'appareils DOIVENT prendre en charge le mode de compatibilité des anciennes applications tel qu'implémenté par le code Open Source Android en amont. Autrement dit, les implémentations d'appareils NE DOIVENT PAS modifier les déclencheurs ou les seuils à partir desquels le mode de compatibilité est activé, et NE DOIVENT PAS modifier le comportement du mode de compatibilité lui-même.

7.1.6. Technologie d'affichage

La plate-forme Android inclut des API qui permettent aux applications d'afficher des graphiques riches. Les appareils DOIVENT prendre en charge toutes ces API telles que définies par le SDK Android, sauf si cela est spécifiquement autorisé dans ce document.

• Les appareils DOIVENT être compatibles avec les écrans capables d'afficher des graphiques couleur 16 bits et DOIVENT être compatibles avec les écrans capables d'afficher des graphiques couleur 24 bits.
• Les appareils DOIVENT être compatibles avec les écrans capables d'afficher des animations.
• La technologie d'affichage utilisée doit avoir un format de pixel (PAR) compris entre 0,9 et 1,15. Autrement dit, le format de pixel DOIT être proche du carré (1,0) avec une tolérance de 10 à 15 %.

7.1.7. Écrans secondaires

Android est compatible avec l'écran secondaire pour activer les fonctionnalités de partage multimédia et les API pour les développeurs permettant d'accéder aux écrans externes. Si un appareil est compatible avec un écran externe via une connexion filaire, sans fil ou intégrée, l'implémentation de l'appareil DOIT implémenter l'API du gestionnaire d'affichage, comme décrit dans la documentation du SDK Android [Ressources, 84].

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

Les appareils DOIVENT être compatibles avec un écran tactile ou répondre aux exigences de la section 7.2.2 pour la navigation non tactile.

7.2.1. Clavier

Implémentations de l'appareil:

• DOIT inclure la prise en charge du framework de gestion des entrées (qui permet aux développeurs tiers de créer des éditeurs de mode de saisie, c'est-à-dire un clavier virtuel), comme indiqué sur http://developer.android.com.
• DOIT fournir au moins une implémentation de clavier virtuel (que le clavier physique soit présent ou non), à l'exception des appareils Android Watch, où la taille de l'écran rend moins raisonnable l'utilisation d'un clavier virtuel.
• PEUT inclure des implémentations de clavier virtuel supplémentaires.
• PEUT inclure un clavier physique.
• NE DOIT PAS inclure de clavier physique qui ne correspond pas à l'un des formats spécifiés dans android.content.res.Configuration.keyboard [Ressources, 85] (QWERTY ou 12 touches).

7.2.2. Navigation non tactile

Implémentations de l'appareil:

• PEUT omettre une option de navigation non tactile (trackball, pavé directionnel ou roue) si l'implémentation de l'appareil n'est pas un appareil Android TV.
• DOIT indiquer la valeur correcte pour android.content.res.Configuration.navigation [Resources, 85].
• DOIT fournir un mécanisme d'interface utilisateur alternatif raisonnable pour la sélection et la modification du texte, compatible avec les moteurs de gestion des entrées. L'implémentation Open Source d'Android en amont inclut un mécanisme de sélection adapté aux appareils qui ne disposent pas d'entrées de navigation non tactiles.

7.2.3. Touches de navigation

Les fonctions Accueil, Récents et Retour (mappées respectivement sur les événements de touche KEYCODE_HOME, KEYCODE_APP_SWITCH et KEYCODE_BACK) sont essentielles au paradigme de navigation Android. Par conséquent:

• Les implémentations d'appareils Android portables DOIVENT fournir les fonctions Accueil, Récents et Retour.
• Les implémentations d'appareils Android TV DOIVENT fournir les fonctions Accueil et Retour.
• Les implémentations d'appareils Android Watch DOIVENT proposer la fonction Accueil à l'utilisateur, ainsi que la fonction Retour, sauf lorsqu'elles sont en mode UI_MODE_TYPE_WATCH.
• Les implémentations Android Auto doivent fournir la fonction Accueil et peuvent fournir les fonctions Retour et Récents.
• Tous les autres types d'implémentations d'appareils DOIVENT fournir les fonctions "Accueil" et "Retour".

Ces fonctions PEUVENT être implémentées via des boutons physiques dédiés (tels que des boutons tactiles mécaniques ou capacitifs) ou à l'aide de touches logicielles dédiées sur une partie distincte de l'écran, des gestes, d'un écran tactile, etc. Android accepte les deux implémentations. Toutes ces fonctions DOIVENT être accessibles par une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsqu'elles sont visibles.

La fonction "Récents", le cas échéant, DOIT comporter un bouton ou une icône visible, sauf si elle est masquée avec d'autres fonctions de navigation en mode plein écran. Cela ne s'applique pas aux appareils qui passent d'anciennes versions d'Android et qui disposent de boutons physiques pour la navigation et pas de touche "Récents".

Les fonctions "Accueil" et "Retour", le cas échéant, DOIVENT chacune comporter un bouton ou une icône visible, sauf si elles sont masquées avec d'autres fonctions de navigation en mode plein écran ou lorsque l'attribut uiMode UI_MODE_TYPE_MASK est défini sur UI_MODE_TYPE_WATCH.

La fonction Menu est obsolète depuis Android 4.0 et a été remplacée par la barre d'action. Par conséquent, les nouvelles implémentations d'appareils livrées avec Android 6.0 ou version ultérieure NE DOIVENT PAS implémenter de bouton physique dédié pour la fonction Menu. Les implémentations d'appareils plus anciennes NE DOIVENT PAS implémenter de bouton physique dédié pour la fonction Menu. Toutefois, si le bouton Menu physique est implémenté et que l'appareil exécute des applications avec targetSdkVersion > 10, l'implémentation de l'appareil:

• DOIT afficher le bouton du menu à développer d'action dans la barre d'action lorsqu'il est visible et que le pop-up du menu à développer d'action qui en résulte n'est pas vide. Pour une implémentation d'appareil lancée avant Android 4.4, mais mise à niveau vers Android 6.0, cette option est RECOMMANDÉE.
• NE DOIT PAS modifier la position du pop-up à développer d'action affiché en sélectionnant le bouton à développer dans la barre d'action.
• PEUT afficher le pop-up de débordement d'action à une position modifiée à l'écran lorsqu'il s'affiche en sélectionnant le bouton de menu physique.

Pour assurer la rétrocompatibilité, les implémentations d'appareils DOIVENT mettre la fonction Menu à la disposition des applications lorsque la version targetSdkVersion est inférieure à 10, soit par un bouton physique, une touche logicielle ou des gestes. Cette fonction de menu doit être présentée, sauf si elle est masquée avec d'autres fonctions de navigation.

Les implémentations d'appareils Android compatibles avec l'action d'assistance [Ressources, 30] DOIVENT la rendre accessible avec une seule action (par exemple, appuyer, double-cliquer ou effectuer un geste) lorsque d'autres touches de navigation sont visibles. Il est FORTEMENT RECOMMANDÉ d'utiliser l'appui prolongé sur le bouton d'accueil ou la touche logicielle comme action unique.

Les implémentations d'appareils PEUVENT utiliser une partie distincte de l'écran pour afficher les touches de navigation. Si tel est le cas, elles DOIVENT respecter les exigences suivantes:

• Les touches de navigation de l'implémentation de l'appareil DOIVENT utiliser une partie distincte de l'écran, qui n'est pas disponible pour les applications, et NE DOIVENT PAS masquer ni interférer avec la partie de l'écran disponible pour les applications.
• Les implémentations d'appareils DOIVENT mettre à la disposition des applications une partie de l'écran qui répond aux exigences définies dans la section 7.1.1.
• Les implémentations d'appareils DOIVENT afficher les touches de navigation lorsque les applications ne spécifient pas de mode d'UI système ou spécifient SYSTEM_UI_FLAG_VISIBLE.
• Les implémentations d'appareils DOIVENT présenter les touches de navigation dans un mode "bas profil" discret (par exemple, atténué) lorsque les applications spécifient SYSTEM_UI_FLAG_LOW_PROFILE.
• Les implémentations d'appareils DOIVENT masquer les touches de navigation lorsque les applications spécifient SYSTEM_UI_FLAG_HIDE_NAVIGATION.

7.2.4. Saisie par écran tactile

Les implémentations d'appareils DOIVENT comporter un système d'entrée de pointeur (similaire à une souris ou à un écran tactile). Toutefois, si une implémentation d'appareil n'est pas compatible avec un système de saisie par pointeur, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.touchscreen ou android.hardware.faketouch. Implémentations d'appareils qui incluent un système de saisie par pointeur:

• DOIT prendre en charge les pointeurs entièrement suivis de manière indépendante, si le système d'entrée de l'appareil prend en charge plusieurs pointeurs.
• DOIT indiquer la valeur d'android.content.res.Configuration.touchscreen [Ressources, 85] correspondant au type d'écran tactile spécifique de l'appareil.

Android est compatible avec différents écrans tactiles, pavés tactiles et faux périphériques d'entrée tactile. Les implémentations d'appareils à écran tactile sont associées à un écran [Resources, 86] de sorte que l'utilisateur a l'impression de manipuler directement les éléments à l'écran. Étant donné que l'utilisateur touche directement l'écran, le système n'a pas besoin d'affordances supplémentaires pour indiquer les objets manipulés. À l'inverse, une interface tactile simulée fournit un système de saisie utilisateur qui s'approche d'un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande qui dirige un curseur à l'écran s'approche de la saisie tactile, mais nécessite que l'utilisateur pointe ou mette en surbrillance l'élément, puis clique dessus. De nombreux périphériques d'entrée tels que la souris, le pavé tactile, la souris sans fil à gyroscope, le pointeur à gyroscope, le joystick et le pavé tactile multipoint peuvent prendre en charge les interactions tactiles simulées. Android inclut la constante de fonctionnalité android.hardware.faketouch, qui correspond à un périphérique d'entrée non tactile (basé sur un pointeur) haute fidélité, tel qu'une souris ou un pavé tactile, qui peut émuler correctement la saisie tactile (y compris la prise en charge des gestes de base) et indique que l'appareil est compatible avec un sous-ensemble émulé des fonctionnalités de l'écran tactile. Les implémentations d'appareils qui déclarent la fonctionnalité de faux appui DOIVENT respecter les exigences de la section 7.2.5.

Les implémentations d'appareils DOIVENT signaler la fonctionnalité appropriée correspondant au type d'entrée utilisé. Les implémentations d'appareils qui incluent un écran tactile (à un seul contact ou mieux) DOIVENT signaler la constante de fonctionnalité de plate-forme android.hardware.touchscreen. Les implémentations d'appareils qui signalent la constante de fonctionnalité de plate-forme android.hardware.touchscreen DOIVENT également signaler la constante de fonctionnalité de plate-forme android.hardware.faketouch. Les implémentations d'appareils qui n'incluent pas d'écran tactile (et qui ne reposent que sur un dispositif de pointage) NE DOIVENT PAS signaler de fonctionnalité d'écran tactile et DOIVENT signaler uniquement android.hardware.faketouch s'ils répondent aux exigences de l'écran tactile simulé de la section 7.2.5.

7.2.5. Saisie tactile fictive

Implémentations d'appareils qui déclarent la prise en charge d'android.hardware.faketouch:

• DOIT indiquer les positions X et Y absolues de l'emplacement du pointeur à l'écran et afficher un pointeur visuel à l'écran [Resources, 87].
• DOIT signaler l'événement tactile avec le code d'action qui spécifie le changement d'état qui se produit lorsque le pointeur descend ou monte sur l'écran [Resources, 87].
• DOIT prendre en charge le pointeur vers le bas et vers le haut sur un objet à l'écran, ce qui permet aux utilisateurs d'émuler un appui sur un objet à l'écran.
• DOIT prendre en charge le pointeur vers le bas, le pointeur vers le haut, le pointeur vers le bas, puis le pointeur vers le haut au même endroit sur un objet à l'écran dans un délai donné, ce qui permet aux utilisateurs d'émuler un double appui sur un objet à l'écran [Resources, 87].
• DOIT prendre en charge le pointeur vers le bas sur un point arbitraire de l'écran, le déplacement du pointeur vers un autre point arbitraire de l'écran, suivi d'un pointeur vers le haut, ce qui permet aux utilisateurs d'émuler un glissement tactile.
• DOIT prendre en charge le pointeur vers le bas, puis permettre aux utilisateurs de déplacer rapidement l'objet vers une autre position à l'écran, puis de pointer vers le haut de l'écran, ce qui leur permet de lancer un objet à l'écran.

Les appareils qui déclarent être compatibles avec android.hardware.faketouch.multitouch.distinct DOIVENT respecter les exigences de faketouch ci-dessus et DOIVENT également prendre en charge le suivi distinct de deux ou plusieurs entrées de pointeur indépendantes.

7.2.6. Compatibilité avec les manettes de jeu

Les implémentations d'appareils Android TV DOIVENT prendre en charge les mappages de boutons pour les manettes de jeu, comme indiqué ci-dessous. L'implémentation Android en amont inclut une implémentation pour les contrôleurs de jeu qui répond à cette exigence.

7.2.6.1. Mappages des boutons

Les implémentations d'appareils Android TV DOIVENT prendre en charge les mappages de clés suivants:

Bouton	Utilisation de l'HID2	Bouton Android
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
Croix directionnelle vers le haut1 Croix directionnelle vers le bas1	0x01 0x00393	AXIS_HAT_Y4
Flèche vers la gauche du pavé directionnel 1 Flèche vers la droite du pavé directionnel1	0x01 0x00393	AXIS_HAT_X4
Bouton de l'épaule gauche1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
Bouton de l'épaule droite1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
Clic sur le stick gauche1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
Clic sur le stick droit1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Accueil1	0x0c 0x0223	KEYCODE_HOME (3)
Retour1	0x0c 0x0224	KEYCODE_BACK (4)

1 [Ressources, 88]

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

3 Cette utilisation doit avoir une valeur minimale logique de 0, une valeur maximale logique de 7, une valeur minimale physique de 0, une valeur maximale physique de 315, des unités en degrés et une taille de rapport de 4. La valeur logique est définie comme étant la rotation dans le sens des aiguilles d'une montre à partir de l'axe vertical. Par exemple, une valeur logique de 0 représente une absence de rotation et la pression sur le bouton "Haut", tandis qu'une valeur logique de 1 représente une rotation de 45 degrés et la pression sur les touches "Haut" et "Gauche".

4 [Resources, 87]

Commandes analogiques1	Utilisation des périphériques HID	Bouton Android
Gauche	0x02 0x00C5	AXIS_LTRIGGER
Gauche	0x02 0x00C4	AXIS_RTRIGGER
Stick gauche	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
Stick droit	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 [Resources, 87]

7.2.7. Télécommande

Les implémentations d'appareils Android TV DOIVENT fournir une télécommande pour permettre aux utilisateurs d'accéder à l'interface TV. La télécommande peut être une télécommande physique ou une télécommande logicielle accessible depuis un téléphone mobile ou une tablette. La télécommande DOIT répondre aux exigences définies ci-dessous.

• Affordance de recherche. Les implémentations d'appareils DOIVENT déclencher KEYCODE_SEARCH (ou KEYCODE_ASSIST si l'appareil est compatible avec un assistant) lorsque l'utilisateur appelle la recherche vocale sur la télécommande physique ou logicielle.
• Navigation Toutes les télécommandes Android TV DOIVENT inclure les boutons Retour, Accueil et Sélection, et prendre en charge les événements de la croix directionnelle [Ressources, 88].

7.3. Capteurs

Android inclut des API permettant d'accéder à différents types de capteurs. Les implémentations d'appareils peuvent généralement omettre ces capteurs, comme indiqué dans les sous-sections suivantes. Si un appareil inclut un type de capteur particulier qui dispose d'une API correspondante pour les développeurs tiers, l'implémentation de l'appareil DOIT implémenter cette API comme décrit dans la documentation du SDK Android et la documentation Open Source Android sur les capteurs [Ressources, 89]. Par exemple, les implémentations d'appareils:

• DOIT signaler avec précision la présence ou l'absence de capteurs conformément à la classe android.content.pm.PackageManager [Resources, 70].
• DOIT renvoyer une liste précise des capteurs compatibles via SensorManager.getSensorList() et des méthodes similaires.
• DOIT se comporter de manière raisonnable pour toutes les autres API de capteurs (par exemple, en renvoyant "true" ou "false" selon les cas lorsque les applications tentent d'enregistrer des écouteurs, en n'appelant pas les écouteurs de capteurs lorsque les capteurs correspondants ne sont pas présents, etc.).
• DOIT signaler toutes les mesures des capteurs à l'aide des valeurs du système international d'unités (métriques) appropriées pour chaque type de capteur, comme défini dans la documentation du SDK Android [Ressources, 90].
• DOIT indiquer l'heure de l'événement en nanosecondes, comme défini dans la documentation du SDK Android. Représente l'heure à laquelle l'événement s'est produit et synchronisé avec l'horloge SystemClock.elapsedRealtimeNano(). Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme, où ce composant pourrait devenir OBLIGATOIRE. L'erreur de synchronisation DOIT être inférieure à 100 millisecondes [Resources, 91].
• DOIT signaler les données du capteur avec une latence maximale de 100 millisecondes + 2 * sample_time pour le cas d'un capteur en streaming 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.
• DOIT signaler le premier échantillon du capteur dans les 400 millisecondes + 2 * sample_time de l'activation du capteur. Une précision de 0 est acceptable pour cet exemple.

La liste ci-dessus n'est pas exhaustive. Le comportement documenté du SDK Android et de la documentation Open Source Android sur les capteurs [Ressources, 89] doit être considéré comme faisant 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. (Exemples : capteur d'orientation et capteur d'accélération linéaire.) Les implémentations d'appareils DOIVENT implémenter ces types de capteurs lorsqu'ils incluent les capteurs physiques requis, comme décrit dans [Ressources, 92]. Si une implémentation d'appareil inclut un capteur composite, elle DOIT implémenter le capteur comme décrit dans la documentation Open Source Android sur les capteurs composites [Ressources, 92].

Certains capteurs Android sont compatibles avec un mode de déclenchement "continu", qui renvoie des données en continu [Resources, 93]. Pour toute API indiquée par la documentation du SDK Android comme étant un capteur continu, les implémentations d'appareils DOIVENT fournir en continu des échantillons de données périodiques dont le jitter DOIT être inférieur à 3%, où le jitter est défini comme l'écart type de la différence entre les valeurs de code temporel signalées entre les événements consécutifs.

Notez que les implémentations de l'appareil DOIVENT s'assurer que le flux d'événements du capteur NE DOIT PAS empêcher le processeur de l'appareil de passer en état de suspension ou de se réveiller d'un état de suspension.

Enfin, lorsque plusieurs capteurs sont activés, la consommation d'énergie NE DOIT PAS dépasser la somme de la consommation d'énergie indiquée par chaque capteur.

7.3.1. Accéléromètre

Les implémentations d'appareils DOIVENT inclure un accéléromètre à trois axes. Il est vivement recommandé d'inclure ce capteur dans les appareils Android portables et les montres Android. Si une implémentation d'appareil inclut un accéléromètre à trois axes, elle:

• DOIT implémenter et signaler le capteur TYPE_ACCELEROMETER [Resources, 94].
• DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz pour les appareils Android Watch, car ces appareils sont soumis à des contraintes d'alimentation plus strictes, et 100 Hz pour tous les autres types d'appareils.
• DOIT signaler les événements jusqu'à au moins 200 Hz.
• DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android [Ressources, 90].
• DOIT être capable de mesurer de la chute libre jusqu'à quatre fois la gravité (4 g) ou plus sur n'importe quel axe.
• Doit avoir une résolution d'au moins 12 bits et 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 compensées, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• DOIT être compensé en température.
• DOIT avoir une déviation standard ne dépassant pas 0,05 m/s^, où la déviation standard doit être calculée par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide.
• DOIT implémenter les capteurs composites TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR et TYPE_STEP_COUNTER, comme décrit dans le document du SDK Android. Il est FORTEMENT RECOMMANDÉ d'implémenter le capteur composite TYPE_SIGNIFICANT_MOTION sur les appareils Android existants et nouveaux. Si l'un de ces capteurs est implémenté, la somme de leur consommation d'énergie DOIT toujours être inférieure à 4 mW et DOIT être inférieure à 2 mW et 0,5 mW lorsque l'appareil est dans un état dynamique ou statique.
• Si un capteur de gyroscope est inclus, vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION, et DEVREZ implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR. Il est vivement recommandé d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android existants et nouveaux.
• DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR, si un capteur de gyroscope et un capteur de magnétomètre sont également inclus.

7.3.2. Magnétomètre

Les implémentations d'appareils DOIVENT inclure un magnétomètre (boussole) à trois axes. Si un appareil inclut un magnétomètre 3 axes, il:

• DOIT implémenter le capteur TYPE_MAGNETIC_FIELD et DOIT également implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED. Nous vous RECOMMANDONS vivement d'implémenter le capteur TYPE_MAGNETIC_FIELD_UNCALIBRATED sur les appareils Android existants et nouveaux.
• DOIT pouvoir générer des rapports sur les événements jusqu'à une fréquence d'au moins 10 Hz et DOIT générer des rapports sur les événements jusqu'à au moins 50 Hz.
• DOIT respecter le système de coordonnées des capteurs Android, comme indiqué dans les API Android [Ressources, 90].
• DOIT être capable de mesurer entre -900 µT et +900 µT sur chaque axe avant de saturer.
• DOIT avoir une valeur de décalage en fer dur inférieure à 700 µT et DEVRAIT avoir une valeur inférieure à 200 µT, en plaçant le magnétomètre loin des champs magnétiques dynamiques (induits par le courant) et statiques (induits par le magnétisme).
• DOIT avoir une résolution égale ou plus dense que 0,6 µT et DEVRAIT avoir une résolution égale ou plus dense que 0,2 µ.
• DOIT être compensé en température.
• DOIT prendre en charge la calibration et la compensation en ligne du biais de l'acier dur, et préserver les paramètres de compensation entre les redémarrages de l'appareil.
• La compensation du fer doux doit être appliquée. Le calibrage peut être effectué pendant l'utilisation ou lors de la production de l'appareil.
• L'écart type, calculé par axe sur les échantillons collectés sur une période d'au moins trois secondes au taux d'échantillonnage le plus rapide, DOIT être inférieur à 0,5 µT.
• DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR, si un capteur d'accéléromètre et un capteur de gyroscope sont également inclus.
• PEUT implémenter le capteur TYPE_GEOMAGNETIC_ROTATION_VECTOR si un capteur d'accéléromètre est également implémenté. Toutefois, s'il est implémenté, il DOIT consommer moins de 10 mW et DEVRAIT consommer moins de 3 mW lorsque le capteur est enregistré pour le mode par lot à 10 Hz.

7.3.3. GPS

Les implémentations d'appareils DOIVENT inclure un récepteur GPS. Si l'implémentation d'un appareil inclut un récepteur GPS, elle DOIT inclure une forme de technique "GPS assisté" pour réduire le temps de verrouillage du GPS.

7.3.4. Gyroscope

Les implémentations d'appareils DOIVENT inclure un gyroscope (capteur de changement angulaire). Les appareils NE DOIVENT PAS inclure de capteur de gyroscope, sauf si un accéléromètre à trois axes est également inclus. Si une implémentation d'appareil inclut un gyroscope:

• DOIT implémenter le capteur TYPE_GYROSCOPE et DOIT également implémenter le capteur TYPE_GYROSCOPE_UNCALIBRATED. Nous vous recommandons vivement d'implémenter le capteur SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sur les appareils Android existants et nouveaux.
• DOIT être capable de mesurer les changements d'orientation jusqu'à 1 000 degrés par seconde.
• DOIT pouvoir signaler des événements jusqu'à une fréquence d'au moins 50 Hz pour les appareils Android Watch, car ces appareils sont soumis à des contraintes d'alimentation plus strictes, et 100 Hz pour tous les autres types d'appareils.
• DOIT signaler les événements jusqu'à au moins 200 Hz.
• DOIT avoir une résolution de 12 bits ou plus et DEVRAIT avoir une résolution de 16 bits ou plus.
• DOIT être compensé en température.
• DOIVENT être calibrés et compensés lorsqu'ils sont utilisés, et conserver les paramètres de compensation entre les redémarrages de l'appareil.
• DOIT avoir une variance ne dépassant pas 1e-7 rad² / s² par Hz (variance par Hz, ou rad² / s). La variance peut varier avec le taux d'échantillonnage, mais doit être limitée par cette valeur. En d'autres termes, si vous mesurez la variance du gyro à un taux d'échantillonnage de 1 Hz, elle ne doit pas dépasser 1e-7 rad^2/s^2.
• DOIT implémenter un capteur composite TYPE_ROTATION_VECTOR, si un capteur d'accéléromètre et un capteur de magnétomètre sont également inclus.
• Si un capteur d'accéléromètre est inclus, vous DEVEZ implémenter les capteurs composites TYPE_GRAVITY et TYPE_LINEAR_ACCELERATION, et DEVREZ implémenter le capteur composite TYPE_GAME_ROTATION_VECTOR. Il est vivement recommandé d'implémenter le capteur TYPE_GAME_ROTATION_VECTOR sur les appareils Android existants et nouveaux.

7.3.5. Le baromètre

Les implémentations d'appareils DOIVENT inclure un baromètre (capteur de pression de l'air ambiant). Si une implémentation d'appareil inclut un baromètre, elle:

• DOIT implémenter et signaler le capteur TYPE_PRESSURE.
• DOIT pouvoir envoyer des événements à 5 Hz ou plus.
• DOIT avoir une précision adéquate pour permettre d'estimer l'altitude.
• DOIT être compensé en température.

7.3.6. Thermomètre

Les implémentations d'appareils PEUVENT inclure un thermomètre ambiant (capteur de température). S'il est présent, il DOIT être défini sur SENSOR_TYPE_AMBIENT_TEMPERATURE et DOIT mesurer la température ambiante (de la pièce) en degrés Celsius.

Les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS, inclure un capteur de température du processeur. S'il est présent, il DOIT être défini comme SENSOR_TYPE_TEMPERATURE, DOIT mesurer la température du processeur de l'appareil et NE DOIT PAS mesurer d'autre température. 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é. Les appareils pouvant passer un appel vocal et indiquant une valeur autre que PHONE_TYPE_NONE dans getPhoneType DOIVENT inclure un capteur de proximité. Si une implémentation d'appareil inclut un capteur de proximité, elle:

• 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 une implémentation d'appareil inclut un capteur de proximité avec une autre orientation, il NE DOIT PAS être accessible via cette API.
• Doit avoir une précision d'au moins 1 bit.

7.3.9. Capteurs haute fidélité

Les implémentations d'appareils compatibles avec un ensemble de capteurs de meilleure qualité pouvant répondre à toutes les exigences listées dans cette section DOIVENT identifier la compatibilité via le flag de fonctionnalité android.hardware.sensor.hifi_sensors.

Un appareil déclarant android.hardware.sensor.hifi_sensors DOIT prendre en charge tous les types de capteurs suivants qui répondent aux exigences de qualité ci-dessous:

• SENSOR_TYPE_ACCELEROMETER
  • DOIT avoir une plage de mesure d'au moins -8 g à +8 g
  • Doit avoir une résolution de mesure d'au moins 1 024 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 200 Hz ou plus
  • Le bruit de mesure doit être inférieur à 400 µG/√Hz.
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 3 000 événements de capteur
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 3 mW.
• SENSOR_TYPE_GYROSCOPE
  • DOIT avoir une plage de mesure d'au moins -1 000 et +1 000 dps
  • Doit avoir une résolution de mesure d'au moins 16 LSB/dps
  • DOIT avoir une fréquence de mesure minimale de 12,5 Hz ou moins
  • DOIT avoir une fréquence de mesure maximale de 200 Hz ou plus
  • Le bruit de mesure doit être inférieur à 0,014 °/s/√Hz.
• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED avec les mêmes exigences de qualité que SENSOR_TYPE_GYROSCOPE
• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • DOIT avoir une plage de mesure d'au moins -900 et +900 uT
  • Doit avoir une résolution de mesure d'au moins 5 LSB/uT
  • Doit avoir une fréquence de mesure minimale de 5 Hz ou moins
  • DOIT avoir une fréquence de mesure maximale de 50 Hz ou plus
  • Le bruit de mesure doit être inférieur à 0,5 uT.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED avec les mêmes exigences de qualité que SENSOR_TYPE_GEOMAGNETIC_FIELD et en plus :
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 600 événements de capteur
• SENSOR_TYPE_PRESSURE
  • DOIT avoir une plage de mesure d'au moins 300 à 1 100 hPa
  • Doit avoir une résolution de mesure d'au moins 80 LSB/hPa
  • Doit avoir une fréquence de mesure minimale de 1 Hz ou moins
  • DOIT avoir une fréquence de mesure maximale de 10 Hz ou plus
  • Le bruit de mesure doit être inférieur à 2 Pa/√Hz.
  • DOIT implémenter une forme de ce capteur sans réveil avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 2 mW.
• TYPE_GAME_ROTATION_VECTOR
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 300 événements de capteur.
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement
• SENSOR_TYPE_STEP_DETECTOR
  • DOIT implémenter une forme non réveillée de ce capteur avec une capacité de mise en mémoire tampon d'au moins 100 événements de capteur
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement
  • La consommation d'énergie de la mise en lot doit être inférieure ou égale à 4 mW.
• SENSOR_TYPE_STEP_COUNTER
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement
• SENSOR_TILT_DETECTOR
  • DOIT avoir une consommation d'énergie inférieure à 0,5 mW lorsque l'appareil est statique et à 1,5 mW lorsque l'appareil est en mouvement

De plus, un tel appareil DOIT répondre aux exigences suivantes concernant le sous-système de capteurs:

• L'horodatage de l'événement du même événement physique signalé par l'accéléromètre, le capteur gyroscopique et le magnétomètre DOIT être compris dans une plage de 2,5 millisecondes.
• Les codes temporels des événements du capteur du gyroscope DOIVENT être sur la même base temporelle que le sous-système de la caméra et présenter une erreur inférieure à 1 milliseconde.
• La latence de diffusion des échantillons vers le HAL DOIT être inférieure à cinq millisecondes à partir du moment où les données sont disponibles sur le matériel physique du capteur.
• La consommation d'énergie ne doit pas dépasser 0,5 mW lorsque l'appareil est statique et 2 mW lorsque l'appareil est en mouvement, lorsque l'une des combinaisons suivantes de capteurs est activée :
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

Notez que toutes les exigences de consommation d'énergie de cette section n'incluent pas la consommation d'énergie du processeur d'application. Elle comprend la puissance consommée par l'ensemble de la chaîne de capteurs (capteur, circuits de support, système de traitement de capteur dédié, etc.).

Les types de capteurs suivants PEUVENT également être compatibles avec une implémentation d'appareil déclarant android.hardware.sensor.hifi_sensors, mais si ces types de capteurs sont présents, ils DOIVENT respecter la capacité de mise en tampon minimale suivante:

• SENSOR_TYPE_PROXIMITY: 100 événements de capteur

7.3.10. Lecteur d'empreinte digitale

Les implémentations d'appareils avec un écran de verrouillage sécurisé DOIVENT inclure un lecteur d'empreinte digitale. Si une implémentation d'appareil inclut un lecteur d'empreinte digitale et dispose d'une API correspondante pour les développeurs tiers, elle:

• DOIT déclarer la prise en charge de la fonctionnalité android.hardware.fingerprint.
• DOIT implémenter entièrement l'API correspondante, comme décrit dans la documentation du SDK Android [Ressources, 95].
• DOIT avoir un taux de fausse acceptation inférieur à 0,002%.
• Il est vivement recommandé d'avoir un taux de faux rejet inférieur à 10%, mesuré sur l'appareil.
• Il est FORTEMENT RECOMMANDÉ de définir une latence inférieure à une seconde, mesurée à partir du moment où le capteur d'empreinte digitale est touché jusqu'au déverrouillage de l'écran, pour un doigt enregistré.
• DOIT limiter les tentatives pendant au moins 30 secondes après cinq tentatives incorrectes pour la validation de l'empreinte digitale.
• DOIT disposer d'une implémentation de keystore basée sur le matériel et effectuer la mise en correspondance des empreintes digitales dans un environnement d'exécution sécurisé (TEE) ou sur une puce avec un canal sécurisé vers le TEE.
• Toutes les données d'empreinte identifiables DOIVENT être chiffrées et authentifiées de manière cryptographique afin qu'elles ne puissent pas être acquises, lues ni modifiées en dehors de l'environnement d'exécution sécurisé (TEE), comme indiqué dans les consignes d'implémentation sur le site du projet Android Open Source [Ressources, 96].
• DOIT empêcher l'ajout d'une empreinte digitale sans d'abord établir une chaîne de confiance en demandant à l'utilisateur de confirmer les identifiants de l'appareil existants ou d'en ajouter de nouveaux (code/schéma/mot de passe) sécurisés par le TEE. L'implémentation du projet Open Source Android fournit le mécanisme dans le framework pour ce faire.
• NE DOIT PAS permettre aux applications tierces de distinguer les empreintes individuelles.
• DOIT respecter l'indicateur DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT.
• Lors de la mise à niveau à partir d'une version antérieure à Android 6.0, les données d'empreinte digitale doivent être migrées de manière sécurisée pour répondre aux exigences ci-dessus ou supprimées.
• DOIT utiliser l'icône d'empreinte digitale Android fournie dans le projet Android Open Source.

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 lié à la réalisation d'appels vocaux et à l'envoi de messages SMS via un réseau GSM ou CDMA. Bien que ces appels vocaux puissent ou non être commutés par paquets, ils sont considérés comme indépendants de toute connectivité de données pouvant être implémentée sur le même réseau. En d'autres termes, les fonctionnalités et les API de "téléphonie" Android font spécifiquement référence aux appels vocaux et aux SMS. Par exemple, les implémentations d'appareils qui ne peuvent pas passer d'appels ni envoyer/recevoir de messages SMS NE DOIVENT PAS signaler la fonctionnalité android.hardware.telephony ni aucune sous-fonctionnalité, que ce soit ou non via un réseau mobile pour la connectivité de données.

Android peut être utilisé sur des appareils qui n'incluent pas de matériel de téléphonie. Autrement dit, Android est compatible avec des appareils autres que des téléphones. Toutefois, si l'implémentation d'un appareil inclut la téléphonie GSM ou CDMA, elle DOIT prendre en charge entièrement l'API pour cette technologie. Les implémentations d'appareils qui n'incluent pas de matériel de téléphonie DOIVENT implémenter les API complètes en tant que no-ops.

7.4.2. IEEE 802.11 (Wi-Fi)

Les implémentations d'appareils Android TV DOIVENT être compatibles avec une ou plusieurs formes de 802.11 (b/g/a/n, etc.), et les autres types d'implémentation d'appareils Android DOIVENT être compatibles avec une ou plusieurs formes de 802.11. Si l'implémentation d'un appareil inclut la prise en charge de la norme 802.11 et expose la fonctionnalité à une application tierce, elle DOIT implémenter l'API Android correspondante et:

• DOIT signaler le commutateur de fonctionnalité matérielle android.hardware.wifi.
• DOIT implémenter l'API multicast comme décrit dans la documentation du SDK [Ressources, 97].
• DOIT prendre en charge le DNS multicast (mDNS) et NE DOIT PAS filtrer les paquets mDNS (224.0.0.251) à tout moment de l'opération, y compris :
  • Même lorsque l'écran n'est pas actif.
  • Pour les implémentations d'appareils Android TV, même en mode veille.

7.4.2.1. Wi-Fi Direct

Les implémentations d'appareils DOIVENT prendre en charge le Wi-Fi Direct (Wi-Fi peer-to-peer). Si une implémentation d'appareil inclut la prise en charge de Wi-Fi Direct, elle DOIT implémenter l'API Android correspondante, comme décrit dans la documentation du SDK [Ressources, 98]. Si l'implémentation d'un appareil est compatible avec Wi-Fi Direct, elle:

• DOIT signaler la fonctionnalité matérielle android.hardware.wifi.direct.
• DOIT être compatible avec le fonctionnement normal du Wi-Fi.
• DOIT prendre en charge le fonctionnement simultané du Wi-Fi et du Wi-Fi Direct.

7.4.2.2. Configuration du lien direct en tunnel Wi-Fi

Les implémentations d'appareils Android TV DOIVENT prendre en charge la configuration de liaison directe en tunnel Wi-Fi (TDLS), et les autres types d'implémentations d'appareils Android DOIVENT prendre en charge le TDLS Wi-Fi, comme décrit dans la documentation du SDK Android [Ressources, 99]. Si l'implémentation d'un appareil inclut la prise en charge de TDLS et que TDLS est activé par l'API WiFiManager, l'appareil:

• Vous DEVEZ utiliser TDLS uniquement lorsque c'est possible ET avantageux.
• DOIT avoir une heuristique et NE PAS utiliser TDLS lorsque ses performances peuvent être moins bonnes que celles du point d'accès Wi-Fi.

7.4.3. Bluetooth

Android est compatible avec le Bluetooth et le Bluetooth à basse consommation [Ressources, 100]. Les implémentations d'appareils qui incluent la prise en charge du Bluetooth et du Bluetooth à basse consommation DOIVENT déclarer les fonctionnalités de plate-forme pertinentes (android.hardware.bluetooth et android.hardware.bluetooth_le, respectivement) et implémenter les API de la plate-forme. Les implémentations d'appareils DOIVENT implémenter les profils Bluetooth pertinents tels que A2DP, AVCP, OBEX, etc., selon les besoins de l'appareil. Les implémentations d'appareils Android Television DOIVENT prendre en charge le Bluetooth et le Bluetooth LE.

Implémentations d'appareils prenant en charge le Bluetooth à basse consommation:

• DOIT déclarer la fonctionnalité matérielle android.hardware.bluetooth_le.
• DOIT activer les API Bluetooth basées sur le GATT (Generic Attribute Profile) comme décrit dans la documentation du SDK et dans [Resources, 100].
• Nous vous RECOMMANDONS vivement d'implémenter un délai avant expiration de l'adresse privée résoluble (RPA) de 15 minutes maximum et de faire tourner l'adresse à l'expiration pour protéger la confidentialité des utilisateurs.
• DOIT prendre en charge le transfert de la logique de filtrage vers le chipset Bluetooth lors de l'implémentation de l'API ScanFilter [Ressources, 101] et DOIT indiquer la valeur correcte de l'emplacement où la logique de filtrage est implémentée chaque fois qu'elle est interrogée via la méthode android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported().
• DOIT prendre en charge le transfert de la numérisation groupée vers le chipset Bluetooth, mais si ce n'est pas le cas, DOIT renvoyer la valeur "false" chaque fois qu'il est interrogé via la méthode android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported().
• DOIT prendre en charge la publicité multiple avec au moins quatre emplacements, mais si ce n'est pas le cas, DOIT renvoyer la valeur "false" chaque fois qu'il est interrogé via la méthode android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported().

7.4.4. Communication en champ proche

Les implémentations d'appareils DOIVENT inclure un émetteur-récepteur et du matériel associé pour la technologie NFC (communication en champ proche). Si une implémentation d'appareil inclut du matériel NFC et prévoit de le mettre à la disposition d'applications tierces, elle:

• DOIT signaler la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Resources, 70].
• DOIT être capable de lire et d'écrire des messages NDEF via les normes NFC suivantes :
  • DOIT être capable de fonctionner comme lecteur/enregistreur NFC Forum (tel que défini par la spécification technique NFC Forum NFCForum-TS-DigitalProtocol-1.0) via les normes NFC suivantes :
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • Types de tags NFC Forum 1, 2, 3 et 4 (définis par le forum NFC)
  • Il est fortement recommandé de pouvoir lire et écrire des messages NDEF ainsi que des données brutes via les normes NFC suivantes. Notez que, bien que les normes NFC ci-dessous soient indiquées comme FORTEMENT RECOMMANDÉES, la définition de la compatibilité d'une future version prévoit de les remplacer par OBLIGATOIRE. Ces normes sont facultatives dans cette version, mais elles seront obligatoires dans les versions ultérieures. Nous encourageons vivement les appareils existants et nouveaux exécutant cette version d'Android à répondre à ces exigences dès maintenant afin qu'ils puissent passer aux futures versions de la plate-forme.
    • NfcV (ISO 15693)
  • DOIT être en mesure de lire le code-barres et l'URL (si encodés) des produits avec code-barres NFC Thinfilm [Ressources, 102].
  • 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 NFC Forum)
    • SDP 1.0 (défini par le forum NFC)
    • NDEF Push Protocol [Resources, 103]
    • SNEP 1.0 (défini par le forum NFC)
  • DOIT inclure la prise en charge d'Android Beam [Resources, 104]:
    • DOIT implémenter le serveur par défaut SNEP. Les messages NDEF valides reçus par le serveur SNEP par défaut DOIVENT être distribués aux applications à l'aide de l'intent android.nfc.ACTION_NDEF_DISCOVERED. La désactivation d'Android Beam dans les paramètres NE DOIT PAS désactiver l'envoi du message NDEF entrant.
    • DOIT respecter l'intent android.settings.NFCSHARING_SETTINGS pour afficher les paramètres de partage NFC [Ressources, 105].
    • DOIT implémenter le serveur NPP. Les messages reçus par le serveur NPP DOIVENT être traités de la même manière que le serveur par défaut SNEP.
    • DOIT implémenter un client SNEP et tenter d'envoyer un NDEF P2P sortant au serveur SNEP par défaut lorsque Android Beam est activé. Si aucun serveur SNEP par défaut n'est trouvé, le client DOIT tenter d'envoyer un message à un serveur NPP.
    • DOIT autoriser les activités de premier plan à définir le message NDEF P2P sortant à l'aide d'android.nfc.NfcAdapter.setNdefPushMessage, d'android.nfc.NfcAdapter.setNdefPushMessageCallback et d'android.nfc.NfcAdapter.enableForegroundNdefPush.
    • DOIT utiliser un geste ou une confirmation à l'écran, comme "Appuyer pour transférer", avant d'envoyer des messages NDEF P2P sortants.
    • DOIT activer Android Beam par défaut et DOIT pouvoir envoyer et recevoir des données à l'aide d'Android Beam, même lorsqu'un autre mode P2P NFC propriétaire est activé.
    • DOIT prendre en charge le transfert de connexion NFC vers le Bluetooth lorsque l'appareil est compatible avec le profil Bluetooth Object Push. Les implémentations d'appareils DOIVENT prendre en charge le transfert de connexion vers le Bluetooth lorsque vous utilisez android.nfc.NfcAdapter.setBeamPushUris, en implémentant les spécifications "Connection Handover version 1.2" [Resources, 106] et "Bluetooth Secure Simple Pairing Using NFC version 1.0" [Resources, 107] du NFC Forum. Une telle implémentation DOIT implémenter le service LLCP de transfert avec le nom de service "urn:nfc:sn:handover" pour échanger les enregistrements de requête/sélection de transfert via NFC, et DOIT utiliser le profil Bluetooth Object Push Profile pour le transfert de données Bluetooth. Pour des raisons d'ancienneté (pour rester compatible avec les appareils Android 4.1), l'implémentation DOIT toujours accepter les requêtes GET SNEP pour échanger la requête de transfert/sélectionner des enregistrements via NFC. Toutefois, une implémentation elle-même NE DOIT PAS envoyer de requêtes GET SNEP pour effectuer la passation de connexion.
  • DOIT interroger toutes les technologies compatibles en mode découverte NFC.
  • DOIT être en mode découverte NFC lorsque l'appareil est actif, l'écran actif et l'écran de verrouillage déverrouillé.

(Notez que les liens publics ne sont pas disponibles pour les spécifications JIS, ISO et NFC Forum citées ci-dessus.)

Android est compatible avec le mode NFC Host Card Emulation (HCE). Si l'implémentation d'un appareil inclut un chipset de contrôleur NFC compatible avec la technologie HCE et le routage de l'ID d'application (AID), elle:

• DOIT signaler la constante de fonctionnalité android.hardware.nfc.hce.
• DOIT être compatible avec les API NFC HCE telles que définies dans le SDK Android [Ressources, 108].

De plus, les implémentations d'appareils PEUVENT inclure la prise en charge des lecteurs/lecteurs pour les technologies MIFARE suivantes.

• MIFARE Classic
• MIFARE Ultralight
• NDEF sur MIFARE Classic

Notez qu'Android inclut des API pour ces types MIFARE. Si une implémentation d'appareil est compatible avec MIFARE dans le rôle de lecteur/écrivain, elle:

• DOIT implémenter les API Android correspondantes, comme indiqué dans la documentation du SDK Android.
• DOIT signaler la fonctionnalité com.nxp.mifare à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Ressources, 70]. Notez qu'il ne s'agit pas d'une fonctionnalité Android standard et qu'elle n'apparaît donc pas en tant que constante dans la classe android.content.pm.PackageManager.
• NE DOIT PAS implémenter les API Android correspondantes ni signaler la fonctionnalité com.nxp.mifare, sauf s'il implémente également la prise en charge générale de la technologie NFC, comme décrit dans cette section.

Si une implémentation d'appareil n'inclut pas de matériel NFC, elle NE DOIT PAS déclarer la fonctionnalité android.hardware.nfc à partir de la méthode android.content.pm.PackageManager.hasSystemFeature() [Resources, 70] et DOIT implémenter l'API NFC Android comme une opération sans effet.

Comme les classes android.nfc.NdefMessage et android.nfc.NdefRecord représentent un format de représentation de données indépendant du protocole, les implémentations d'appareils DOIVENT implémenter ces API, même si elles n'incluent pas la compatibilité avec la technologie NFC ni ne déclarent la fonctionnalité android.hardware.nfc.

7.4.5. Capacité réseau minimale

Les implémentations d'appareils DOIVENT prendre en charge une ou plusieurs formes de mise en réseau de données. Plus précisément, les implémentations d'appareils DOIVENT prendre en charge au moins une norme de données capable de 200 kbit/s ou plus. EDGE, HSPA, EV-DO, 802.11g, Ethernet, PAN Bluetooth, etc. sont des exemples de technologies qui répondent à cette exigence.

Les implémentations d'appareils où une norme de réseau physique (telle qu'Ethernet) constitue la connexion de données principale DOIVENT également prendre en charge au moins une norme de données sans fil courante, telle que 802.11 (Wi-Fi).

Les appareils PEUVENT implémenter plusieurs formes de connectivité de données.

Les appareils DOIVENT inclure une pile réseau IPv6 et prendre en charge la communication IPv6 à l'aide des API gérées, telles que java.net.Socket et java.net.URLConnection, ainsi que des API natives, telles que les sockets AF_INET6. Le niveau de compatibilité IPv6 requis dépend du type de réseau, comme suit:

• Les appareils compatibles avec les réseaux Wi-Fi DOIVENT prendre en charge le fonctionnement à double pile et IPv6 uniquement sur Wi-Fi.
• Les appareils compatibles avec les réseaux Ethernet DOIVENT prendre en charge l'opération à double pile sur Ethernet.
• Les appareils compatibles avec les données mobiles DOIVENT prendre en charge le fonctionnement IPv6 (IPv6 uniquement et éventuellement double pile) sur les données mobiles.
• Lorsqu'un appareil est connecté simultanément à plusieurs réseaux (par exemple, Wi-Fi et données mobiles), il DOIT simultanément répondre à ces exigences sur chaque réseau auquel il est connecté.

IPv6 DOIT être activé par défaut.

Pour que la communication IPv6 soit aussi fiable qu'IPv4, les paquets IPv6 unicast envoyés à l'appareil NE DOIVENT PAS être abandonnés, même lorsque l'écran n'est pas actif. Les paquets IPv6 multicast redondants, tels que les annonces de routeur identiques répétées, PEUVENT être limités en débit au niveau du matériel ou du micrologiciel si cela est nécessaire pour économiser de l'énergie. Dans ce cas, la limitation de débit NE DOIT PAS entraîner la perte de connectivité IPv6 de l'appareil sur un réseau compatible avec IPv6 qui utilise des durées de vie RA d'au moins 180 secondes.

La connectivité IPv6 DOIT être maintenue en mode Doze.

7.4.6. Paramètres de synchronisation

La synchronisation automatique principale doit être activée par défaut dans les implémentations d'appareils afin que la méthode getMasterSyncAutomatically() renvoie "true" [Resources, 109].

7.5. Caméras

Les implémentations d'appareils DOIVENT inclure une caméra arrière et PEUVENT inclure une caméra avant. Une caméra arrière est une caméra située sur le côté de l'appareil, à l'opposé de l'écran. Autrement dit, elle capture des scènes à l'arrière de l'appareil, comme une caméra traditionnelle. Une caméra avant est une caméra située du même côté de l'appareil que l'écran. Autrement dit, il s'agit d'une caméra généralement utilisée pour prendre une photo de l'utilisateur, par exemple pour les visioconférences et les applications similaires.

Si une implémentation d'appareil inclut au moins une caméra, une application DOIT pouvoir allouer simultanément trois bitmaps égaux à la taille des images produites par le capteur d'appareil photo de la plus haute résolution de l'appareil.

7.5.1. Caméra arrière

Les implémentations d'appareils DOIVENT inclure une caméra arrière. Si l'implémentation d'un appareil inclut au moins une caméra arrière:

• DOIT signaler le commutateur de fonctionnalité android.hardware.camera et android.hardware.camera.any.
• Doit avoir une résolution d'au moins 2 mégapixels.
• Le pilote de l'appareil photo doit implémenter la mise au point automatique matérielle ou logicielle (transparente pour le logiciel d'application).
• POURRAIENT avoir un matériel à mise au point fixe ou à profondeur de champ étendue (EDOF, Extended Depth of Field).
• POURRA inclure un flash. Si l'appareil photo inclut un flash, la lampe de 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 d'appareil photo système intégrée de l'appareil, mais uniquement aux applications tierces qui utilisent Camera.PreviewCallback.

7.5.2. Caméra avant

Les implémentations d'appareils PEUVENT inclure une caméra avant. Si l'implémentation d'un appareil inclut au moins une caméra avant, elle:

• DOIT signaler le commutateur de fonctionnalité android.hardware.camera.any et android.hardware.camera.front.
• DOIT avoir une résolution d'au moins VGA (640 x 480 pixels).
• NE DOIT PAS utiliser une caméra avant par défaut pour l'API Camera. L'API Appareil photo d'Android est compatible avec les caméras avant. Les implémentations d'appareils NE DOIVENT PAS configurer l'API pour qu'elle traite une caméra avant comme la caméra arrière par défaut, même si elle est la seule caméra de l'appareil.
• POURRA inclure des fonctionnalités (comme le focus automatique, le flash, etc.) disponibles pour les caméras arrière, comme décrit dans la section 7.5.1.
• DOIT refléter horizontalement (c'est-à-dire en miroir) le flux affiché par une application dans un CameraPreview, comme suit :
  • Si l'implémentation de l'appareil peut être pivotée par l'utilisateur (par exemple, automatiquement via un accéléromètre ou manuellement via une entrée utilisateur), l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation actuelle de l'appareil.
  • Si l'application actuelle a explicitement demandé que l'écran de l'appareil photo soit pivoté via un appel à la méthode android.hardware.Camera.setDisplayOrientation()[Resources, 110], l'aperçu de l'appareil photo DOIT être mis en miroir horizontalement par rapport à l'orientation spécifiée par l'application.
  • Sinon, l'aperçu DOIT être mis en miroir le long de l'axe horizontal par défaut de l'appareil.
• DOIT refléter l'image affichée par le postview de la même manière que le flux d'images d'aperçu de l'appareil photo. Si l'implémentation de l'appareil n'est pas compatible avec la postview, cette exigence ne s'applique évidemment pas.
• NE DOIT PAS refléter les flux d'images fixes ou vidéo capturés renvoyés aux rappels d'application ou enregistrés dans le stockage multimédia.

7.5.3. Caméra externe

Les implémentations d'appareils avec le mode hôte USB PEUVENT inclure la compatibilité avec une caméra externe connectée au port USB. Si un appareil est compatible avec une caméra externe:

• DOIT déclarer la fonctionnalité de plate-forme android.hardware.camera.external et android.hardware camera.any.
• Doit être compatible avec la classe vidéo USB (UVC 1.0 ou version ultérieure).
• Peut être compatible avec plusieurs caméras.

La prise en charge de la compression vidéo (par exemple, MJPEG) est RECOMMANDÉE pour permettre le transfert de flux non encodés de haute qualité (c'est-à-dire des flux d'images bruts ou compressés indépendamment). L'encodage vidéo basé sur l'appareil photo peut être pris en charge. Si tel est le cas, un flux non encodé/ MJPEG simultané (résolution QVGA ou supérieure) DOIT être accessible à l'implémentation de l'appareil.

7.5.4. Comportement de l'API Camera

Android inclut deux packages d'API pour accéder à l'appareil photo. L'API android.hardware.camera2 la plus récente expose le contrôle de l'appareil photo de niveau inférieur à l'application, y compris des flux de streaming/rafale efficaces sans copie et des commandes par frame de l'exposition, du gain, des gains de balance des blancs, de la conversion des couleurs, du dénoyage, de l'accentuation, etc.

L'ancien package d'API, android.hardware.Camera, est marqué comme obsolète dans Android 5.0. Toutefois, comme il doit toujours être disponible pour que les applications puissent utiliser les implémentations d'appareils Android, vous devez assurer la prise en charge continue de l'API, comme décrit dans cette section et dans le SDK Android.

Les implémentations d'appareils DOIVENT implémenter les comportements suivants pour les API liées à la caméra, pour toutes les caméras disponibles:

• Si une application n'a jamais appelé android.hardware.Camera.Parameters.setPreviewFormat(int), l'appareil DOIT utiliser android.hardware.PixelFormat.YCbCr_420_SP pour les données d'aperçu fournies aux rappels d'application.
• Si une application enregistre une instance android.hardware.Camera.PreviewCallback et que le système appelle la méthode onPreviewFrame() lorsque le format d'aperçu est YCbCr_420_SP, les données du byte[] transmises à onPreviewFrame() doivent également être au format d'encodage NV21. Autrement dit, NV21 DOIT être la valeur par défaut.
• Pour android.hardware.Camera, les implémentations d'appareils DOIVENT prendre en charge le format YV12 (comme indiqué par la constante android.graphics.ImageFormat.YV12) pour les aperçus de l'appareil photo pour les caméras avant et arrière. (L'encodeur vidéo matériel et la caméra peuvent utiliser n'importe quel format de pixel natif, mais l'implémentation de l'appareil DOIT prendre en charge la conversion en YV12.)
• Pour android.hardware.camera2, les implémentations d'appareils doivent prendre en charge les formats android.hardware.ImageFormat.YUV_420_888 et android.hardware.ImageFormat.JPEG en sortie via l'API android.media.ImageReader.

Les implémentations d'appareils DOIVENT toujours implémenter l'API Camera complète incluse dans la documentation du SDK Android [Ressources, 111], que l'appareil inclue ou non un autofocus matériel ou d'autres fonctionnalités. Par exemple, les appareils photo qui ne disposent pas d'autofocus DOIVENT toujours appeler les instances android.hardware.Camera.AutoFocusCallback enregistrées (même si cela n'a aucune pertinence pour un appareil photo sans autofocus). Notez que cela s'applique aux caméras avant. Par exemple, même si la plupart des caméras avant ne sont pas compatibles avec la mise au point automatique, les rappels d'API doivent toujours être "faussés" comme décrit.

Les implémentations d'appareils DOIVENT reconnaître et respecter chaque nom de paramètre défini comme constante dans la classe android.hardware.Camera.Parameters, si le matériel sous-jacent est compatible avec la fonctionnalité. Si le matériel de l'appareil n'est pas compatible avec une fonctionnalité, l'API doit se comporter comme indiqué dans la documentation. À l'inverse, les implémentations d'appareils NE DOIVENT PAS respecter ni reconnaître les constantes de chaîne transmises à la méthode android.hardware.Camera.setParameters() 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 d'appareil photo standards si le matériel le permet et NE DOIVENT PAS prendre en charge les types de paramètres d'appareil photo personnalisés. Par exemple, les implémentations d'appareils compatibles avec la capture d'images à l'aide de techniques d'imagerie HDR (High Dynamic Range) DOIVENT prendre en charge le paramètre de l'appareil photo Camera.SCENE_MODE_HDR [Ressources, 112].

Étant donné que toutes les implémentations d'appareils ne peuvent pas prendre en charge toutes les fonctionnalités de l'API android.hardware.camera2, les implémentations d'appareils DOIVENT indiquer le niveau de prise en charge approprié avec la propriété android.info.supportedHardwareLevel, comme décrit dans le SDK Android [Resources, 113] et indiquer les indicateurs de fonctionnalité de framework appropriés [Resources, 114].

Les implémentations d'appareils DOIVENT également déclarer les fonctionnalités individuelles de la caméra d'android.hardware.camera2 via la propriété android.request.availableCapabilities et déclarer les indicateurs de fonctionnalité appropriés [Resources, 114]. Un appareil doit définir l'indicateur de fonctionnalité si l'un de ses appareils photo connectés est compatible avec la fonctionnalité.

Les implémentations d'appareils DOIVENT diffuser l'intent Camera.ACTION_NEW_PICTURE chaque fois qu'une nouvelle photo est prise par l'appareil photo et que l'entrée de la photo a été ajoutée au Media Store.

Les implémentations d'appareils DOIVENT diffuser l'intent Camera.ACTION_NEW_VIDEO chaque fois qu'une nouvelle vidéo est enregistrée par l'appareil photo et que l'entrée de l'image a été ajoutée au store multimédia.

7.5.5. Orientation de l'appareil photo

Les caméras avant et arrière, le cas échéant, DOIVENT être orientées de sorte à faire correspondre la dimension longue de la caméra à la dimension longue de l'écran. Autrement dit, lorsque l'appareil est tenu en mode paysage, les appareils photo DOIVENT capturer des images en mode paysage. Cela s'applique quelle que soit l'orientation naturelle de l'appareil, c'est-à-dire aux appareils en mode paysage et en mode portrait.

7.6. Mémoire et stockage

7.6.1. Mémoire et stockage minimums

La mémoire disponible pour le noyau et l'espace utilisateur dans les implémentations d'appareils DOIT être au moins égale ou supérieure aux valeurs minimales spécifiées dans le tableau suivant. (Pour connaître les définitions de la taille et de la densité de l'écran, consultez la section 7.1.1.)

Densité et taille de l'écran	Appareil 32 bits	Appareil 64 bits
Appareils Android Watch (en raison des écrans plus petits)	416 Mo	Non applicable
280 dpi ou moins sur les écrans de petite/moyenne taille mdpi ou moins sur les grands écrans ldpi ou moins sur les écrans très grands formats	424 Mo	704 Mo
xhdpi ou version ultérieure sur les écrans de petite/moyenne taille hdpi ou version ultérieure sur les grands écrans mdpi ou plus sur les écrans très grands	512 Mo	832 Mo
400 dpi ou plus sur les écrans de petite/moyenne taille xhdpi ou version ultérieure sur les grands écrans tvdpi ou version ultérieure sur les écrans très grands	896 Mo	1 280 Mo
560 dpi ou plus sur les écrans de petite/moyenne taille 400 dpi ou plus sur les grands écrans xhdpi ou version ultérieure sur les écrans très grands	1 344 Mo	1 824 Mo

Les valeurs de mémoire minimale DOIVENT s'ajouter à tout espace de mémoire déjà dédié à des composants matériels tels que la radio, la vidéo, etc. qui ne sont pas sous le contrôle du noyau.

Les implémentations d'appareils disposant de moins de 512 Mo de mémoire disponibles pour le noyau et l'espace utilisateur, sauf pour une montre Android, DOIVENT renvoyer la valeur "true" pour ActivityManager.isLowRamDevice().

Les appareils Android TV doivent disposer d'au moins 5 Go, et les autres implémentations d'appareils doivent disposer d'au moins 1,5 Go d'espace de stockage non volatile disponible pour les données privées de l'application. Autrement dit, la partition /data doit être d'au moins 5 Go pour les appareils Android TV et d'au moins 1,5 Go pour les autres implémentations d'appareils. Il est FORTEMENT RECOMMANDÉ que les implémentations d'appareils exécutant Android disposent d'au moins 3 Go d'espace de stockage non volatile pour les données privées de l'application afin qu'elles puissent passer aux futures versions de la plate-forme.

Les API Android incluent un gestionnaire de téléchargement que les applications PEUVENT utiliser pour télécharger des fichiers de données [Ressources, 115]. L'implémentation du Gestionnaire de téléchargement sur l'appareil DOIT être capable de télécharger des fichiers individuels d'au moins 100 Mo à l'emplacement par défaut du "cache".

7.6.2. Stockage partagé de l'application

Les implémentations d'appareils DOIVENT proposer un stockage partagé pour les applications, également souvent appelé "stockage externe partagé".

Les implémentations d'appareils DOIVENT être configurées avec un stockage partagé installé par défaut. Si le stockage partagé n'est pas installé sur le chemin d'accès Linux /sdcard, l'appareil DOIT inclure un lien symbolique Linux de /sdcard au point d'installation réel.

Les implémentations d'appareils PEUVENT comporter du matériel pour le stockage amovible accessible par l'utilisateur, tel qu'un emplacement pour carte Secure Digital (SD). Si ce créneau est utilisé pour répondre à l'exigence de stockage partagé, l'implémentation de l'appareil:

• DOIT implémenter une interface utilisateur de type "toast" ou pop-up avertissant l'utilisateur en l'absence de carte SD.
• DOIT inclure une carte SD au format FAT d'une capacité de 1 Go ou plus OU indiquer sur la boîte et sur tout autre matériel disponible au moment de l'achat que la carte SD doit être achetée séparément.
• DOIT installer la carte SD par défaut.

Les implémentations d'appareils PEUVENT également allouer de l'espace de stockage interne (non amovible) en tant qu'espace de stockage partagé pour les applications, comme indiqué dans le projet Android Open Source en amont. Les implémentations d'appareils DOIVENT utiliser cette configuration et cette implémentation logicielle. Si une implémentation d'appareil utilise un espace de stockage interne (non amovible) pour répondre aux exigences de stockage partagé, alors que cet espace de stockage PEUT partager l'espace avec les données privées de l'application, il DOIT avoir une taille d'au moins 1 Go et être installé sur /sdcard (ou /sdcard DOIT être un lien symbolique vers l'emplacement physique s'il est installé ailleurs).

Les implémentations d'appareils DOIVENT appliquer l'autorisation android.permission.WRITE_EXTERNAL_STORAGE sur cet espace de stockage partagé, comme indiqué dans la documentation. Sinon, l'espace de stockage partagé DOIT être accessible en écriture par toute application qui obtient cette autorisation.

Les implémentations d'appareils qui incluent plusieurs chemins d'espace de stockage partagé (comme un emplacement pour carte SD et un espace de stockage interne partagé) DOIVENT n'autoriser que les applications Android préinstallées et privilégiées disposant de l'autorisation WRITE_EXTERNAL_STORAGE à écrire sur l'espace de stockage externe secondaire, sauf lorsqu'elles écrivent dans leurs répertoires spécifiques au package ou dans le URI renvoyé en déclenchant l'intent ACTION_OPEN_DOCUMENT_TREE.

Toutefois, les implémentations d'appareils DOIVENT exposer le contenu des deux chemins de stockage de manière transparente via le service de numérisation multimédia d'Android et android.provider.MediaStore.

Quelle que soit la forme de stockage partagé utilisée, si l'implémentation de l'appareil comporte un port USB compatible avec le mode périphérique USB, elle DOIT fournir un mécanisme permettant d'accéder au contenu du stockage partagé à partir d'un ordinateur hôte. Les implémentations d'appareils PEUVENT utiliser le stockage de masse USB, mais DOIVENT utiliser le protocole de transfert multimédia pour répondre à cette exigence. Si l'implémentation de l'appareil est compatible avec le protocole Media Transfer, elle:

• DOIT être compatible avec l'hôte MTP Android de référence, Android File Transfer [Resources, 116].
• DOIT indiquer une classe d'appareil USB de 0x00.
• DOIT indiquer un nom d'interface USB de "MTP".

7.6.3. Stockage adoptable

Il est vivement recommandé d'implémenter un stockage adoptable si le port de l'appareil de stockage amovible se trouve dans un emplacement stable à long terme, tel que dans le compartiment de la batterie ou dans un autre boîtier de protection [Ressources, 117].

Les implémentations d'appareils tels qu'un téléviseur PEUVENT permettre l'adoption via des ports USB, car l'appareil est censé être statique et non mobile. Toutefois, pour les autres implémentations d'appareils de nature mobile, il est FORTEMENT RECOMMANDÉ d'implémenter le stockage adoptable dans un emplacement stable à long terme, car une déconnexion accidentelle peut entraîner une perte ou une corruption de données.

7.7. USB

Les implémentations d'appareils DOIVENT prendre en charge le mode périphérique USB et le mode hôte USB.

Si l'implémentation d'un appareil inclut un port USB compatible avec le mode périphérique:

• Le port DOIT être connectable à un hôte USB doté d'un port USB Type-A ou Type-C standard.
• Le port DOIT utiliser le facteur de forme USB micro-B, micro-AB ou Type-C. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• Le port DOIT se trouver en bas de l'appareil (selon l'orientation naturelle) ou permettre la rotation logicielle de l'écran pour toutes les applications (y compris l'écran d'accueil), afin que l'affichage s'affiche correctement lorsque l'appareil est orienté avec le port en bas. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
• Il DOIT implémenter l'API et la spécification Android Open Accessory (AOA) comme indiqué dans la documentation du SDK Android. S'il s'agit d'un appareil Android portable, il DOIT implémenter l'API AOA. Implémentations d'appareils implémentant la spécification AOA :
  • DOIT déclarer la prise en charge de la fonctionnalité matérielle android.hardware.usb.accessory [Ressources, 118].
  • DOIT prendre en charge l'établissement d'une communication basée sur le protocole AOA lors de la première connexion à une machine hôte USB qui sert d'accessoire, sans que l'utilisateur ait besoin de modifier le mode USB par défaut.
  • DOIT implémenter la classe audio USB comme indiqué dans la documentation du SDK Android [Ressources, 119].
  • De plus, 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 du stockage de masse USB.
• Il DOIT être compatible avec la consommation d'un courant de 1,5 A pendant le chirp HS et le trafic, comme spécifié dans la spécification de recharge de la batterie USB, version 1.2 [Ressources, 120]. Il est FORTEMENT RECOMMANDÉ que les appareils Android existants et nouveaux répondent à ces exigences afin qu'ils puissent passer aux futures versions de la plate-forme.
la norme de résistance Type-C.
• La valeur de iSerialNumber dans le descripteur d'appareil standard USB DOIT être égale à la valeur d'android.os.Build.SERIAL.

Si une implémentation d'appareil inclut un port USB compatible avec le mode hôte:

• DOIT utiliser un port USB Type-C si l'implémentation de l'appareil est compatible avec USB 3.1.
• PEUT utiliser un facteur de forme de port non standard, mais doit être fourni avec un ou plusieurs câbles permettant d'adapter le port à un port USB de type A ou C standard.
• PEUT utiliser un port USB micro-AB, mais doit être fourni avec un ou plusieurs câbles permettant d'adapter le port à un port USB type-A ou type-C standard.
• Il est FORTEMENT RECOMMANDÉ d'implémenter la classe audio USB, comme indiqué dans la documentation du SDK Android [Resources, 119].
• 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 [Ressources, 121].
• DOIT prendre en charge le chargement de l'appareil en mode hôte, en annonçant un courant de source d'au moins 1,5 A, comme indiqué dans la section "Paramètres de terminaison" de la spécification du câble et du connecteur USB Type-C, version 1.2 [] pour les connecteurs USB Type-C ou en utilisant la plage de courant de sortie du port en aval de recharge(CDP) comme indiqué dans la spécification de recharge de la batterie USB, version 1.2 [Ressources, 120] pour les connecteurs Micro-AB.

7.8. Audio

7.8.1. Micro

Les implémentations d'appareils PEUVENT omettre un micro. Toutefois, si une implémentation d'appareil omet un micro, elle NE DOIT PAS signaler la constante de fonctionnalité android.hardware.microphone et DOIT implémenter l'API d'enregistrement audio au moins en tant que no-ops, conformément à la section 7. À l'inverse, les implémentations d'appareils qui disposent d'un micro:

• DOIT indiquer la constante de la fonctionnalité android.hardware.microphone
• DOIVENT respecter les exigences concernant l'enregistrement audio de la section 5.4
• DOIT respecter les exigences de latence audio de la section 5.6
• FORTEMENT RECOMMANDÉ de prendre en charge l'enregistrement par ultrasons proche, comme décrit dans la section 7.8.3

7.8.2. Sortie audio

Implémentations d'appareils incluant un haut-parleur ou un port de sortie audio/multimédia pour un périphérique de sortie audio tel qu'un casque ou une enceinte externe:

• DOIT signaler la constante de fonctionnalité android.hardware.audio.output.
• DOIT respecter les exigences de lecture audio de la section 5.5.
• DOIT respecter les exigences de latence audio de la section 5.6.
• FORTEMENT RECOMMANDÉ de prendre en charge la lecture proche des ultrasons, comme décrit dans la section 7.8.3

À l'inverse, si l'implémentation d'un appareil n'inclut pas de haut-parleur ni de port de sortie audio, elle NE DOIT PAS signaler la fonctionnalité de sortie android.hardware.audio et DOIT implémenter les API liées à la sortie audio en tant que no-ops au moins.

L'implémentation de l'appareil Android Watch PEUT, mais NE DOIT PAS, avoir une sortie audio. En revanche, les autres types d'implémentations d'appareils Android DOIVENT avoir une sortie audio et déclarer android.hardware.audio.output.

7.8.2.1. Ports audio analogiques

Pour être compatible avec les casques et autres accessoires audio utilisant la prise audio 3,5 mm dans l'écosystème Android [Ressources, 122], si une implémentation d'appareil inclut un ou plusieurs ports audio analogiques, au moins l'un des ports audio DOIT être un connecteur audio 3,5 mm à quatre conducteurs. Si l'implémentation d'un appareil comporte une prise audio 3,5 mm à quatre conducteurs, elle:

• DOIT être compatible avec la lecture audio sur des casques stéréo et des casques stéréo avec micro, et DOIT être compatible avec l'enregistrement audio à partir de casques stéréo avec micro.
• DOIT être compatible avec les prises audio TRRS avec la disposition des broches CTIA et DOIT être compatible avec les prises audio avec la disposition des broches OMTP.
• DOIT prendre en charge la détection du micro sur l'accessoire audio branché, si l'implémentation de l'appareil est compatible avec un micro, et diffuser android.intent.action.HEADSET_PLUG avec la valeur supplémentaire micro définie sur 1.
• DOIT prendre en charge la détection et le mappage sur les codes de touche pour les trois plages d'impédance équivalente suivantes entre le micro et les conducteurs de terre sur la prise audio :
  • 70 ohms ou moins: KEYCODE_HEADSETHOOK
  • 210-290 ohms: KEYCODE_VOLUME_UP
  • 360-680 Ohm: KEYCODE_VOLUME_DOWN
• DOIT prendre en charge la détection et le mappage sur le code de touche pour la plage d'impédance équivalente suivante entre le micro et les conducteurs de terre sur la prise audio :
  • 110-180 Ohm : KEYCODE_VOICE_ASSIST
• DOIT déclencher ACTION_HEADSET_PLUG lors de l'insertion d'une prise, mais uniquement après que tous les contacts de la prise ont touché leurs segments correspondants sur la prise.
• DOIT être capable de piloter au moins 150 mV ± 10% de la tension de sortie sur une impédance d'enceinte de 32 ohms.
• La tension de polarisation du micro doit être comprise entre 1,8 V et 2,9 V.

7.8.3. Ultrasons proches

L'audio proche des ultrasons correspond à la bande de fréquences de 18,5 kHz à 20 kHz. Les implémentations d'appareils DOIVENT signaler correctement la prise en charge de la fonctionnalité audio à ultrasons via l'API AudioManager.getProperty comme suit:

• Si PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND est défini sur "true", alors :
  • La réponse moyenne de puissance du micro dans la bande de fréquences de 18,5 kHz à 20 kHz ne doit pas être inférieure de plus de 15 dB à la réponse à 2 kHz.
  • Le rapport signal/bruit (SNR) non pondéré du micro entre 18,5 kHz et 20 kHz pour un son de 19 kHz à -26 dBFS DOIT être d'au moins 50 dB.
• Si PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND est défini sur "true", la réponse moyenne du haut-parleur dans la plage de fréquences 18,5 kHz à 20 kHz DOIT être supérieure d'au moins 40 dB à la réponse à 2 kHz.

8. Performances et puissance

Certains critères de performances et d'alimentation minimaux sont essentiels à l'expérience utilisateur et ont une incidence sur les hypothèses de référence que les développeurs peuvent avoir lors du développement d'une application. Les appareils Android Watch DOIVENT et les autres types d'implémentations d'appareils DOIVENT respecter les critères suivants:

8.1. Cohérence de l'expérience utilisateur

Les implémentations d'appareils DOIVENT fournir une interface utilisateur fluide en assurant un taux de rafraîchissement et des temps de réponse cohérents pour les applications et les jeux. Les implémentations d'appareils DOIVENT répondre aux exigences suivantes:

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

8.2. Performances d'accès aux E/S de fichiers

Les implémentations d'appareils DOIVENT assurer la cohérence des performances d'accès aux fichiers de stockage interne pour les opérations de lecture et d'écriture.

• Écriture séquentielle. Les implémentations d'appareils DOIVENT garantir des performances d'écriture séquentielle d'au moins 5 Mo/s pour un fichier de 256 Mo utilisant un tampon d'écriture de 10 Mo.
• Écriture aléatoire Les implémentations d'appareils DOIVENT garantir des performances d'écriture aléatoire d'au moins 0,5 Mo/s pour un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 ko.
• Lecture séquentielle Les implémentations d'appareils DOIVENT garantir des performances de lecture séquentielle d'au moins 15 Mo/s pour un fichier de 256 Mo à l'aide d'un tampon d'écriture de 10 Mo.
• Lecture aléatoire Les implémentations d'appareils DOIVENT garantir des performances de lecture aléatoire d'au moins 3,5 Mo/s pour un fichier de 256 Mo à l'aide d'un tampon d'écriture de 4 ko.

8.3. Modes d'économie d'énergie

Toutes les applications exemptées du mode Veille des applications et/ou du mode Doze DOIVENT être visibles par l'utilisateur final. De plus, les algorithmes de déclenchement, de maintenance, de réveil et l'utilisation des paramètres système globaux de ces modes d'économie d'énergie DOIVENT respecter le projet Open Source Android.

8.4. Comptabilisation de la consommation d'énergie

Une comptabilisation et une création de rapports plus précises de la consommation d'énergie fournissent au développeur d'applications à la fois les incitations et les outils nécessaires pour optimiser le schéma d'utilisation de l'énergie de l'application. Par conséquent, les implémentations d'appareils:

• DOIT être en mesure de suivre la consommation d'énergie des composants matériels et d'attribuer cette consommation d'énergie à des applications spécifiques. Plus précisément, les implémentations :
  • DOIT fournir un profil d'alimentation par composant qui définit la valeur de consommation actuelle pour chaque composant matériel et l'épuisement approximatif de la batterie causé par les composants au fil du temps, comme indiqué sur le site du projet Android Open Source [Ressources, 123].
  • DOIT indiquer toutes les valeurs de consommation d'énergie en milliampères-heure (mAh)
  • DOIT être attribué au composant matériel lui-même si vous ne parvenez pas à attribuer la consommation d'énergie du composant matériel à une application.
  • 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 kernel uid_cputime.
• DOIT mettre cette consommation d'énergie à la disposition du développeur de l'application via la commande shell adb shell dumpsys batterystats [Resources, 124].
• DOIT respecter l'intent android.intent.action.POWER_USAGE_SUMMARY et afficher un menu de paramètres qui affiche cette consommation d'énergie [Ressources, 125].

9. Compatibilité des modèles de sécurité

Les implémentations d'appareils DOIVENT implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android, tel que défini dans le document de référence sur la sécurité et les autorisations des API [Ressources, 126] de la documentation pour les développeurs Android. Les implémentations d'appareils DOIVENT prendre en charge l'installation d'applications autosignées sans nécessiter d'autorisations/certificats supplémentaires de la part de tiers/autorités. Plus précisément, les appareils compatibles DOIVENT prendre en charge les mécanismes de sécurité décrits dans les sous-sections suivantes.

9.1. Autorisations

Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations Android tel que défini dans la documentation pour les développeurs Android [Ressources, 126]. Plus précisément, les implémentations DOIVENT appliquer chaque autorisation définie comme décrit dans la documentation du SDK. Aucune autorisation ne peut être omise, modifiée ou ignorée. Les implémentations PEUVENT ajouter des autorisations supplémentaires, à condition que les nouvelles chaînes d'ID d'autorisation ne se trouvent pas dans l'espace de noms android.*.

Les autorisations dont le niveau de protection est dangereux sont des autorisations d'exécution. Les applications avec targetSdkVersion > 22 les demandent au moment de l'exécution. Implémentations de l'appareil:

• DOIT afficher une interface dédiée permettant à l'utilisateur de décider d'accorder les autorisations d'exécution demandées et de fournir une interface permettant à l'utilisateur de gérer les autorisations d'exécution.
• Vous devez disposer d'une seule et unique implémentation des deux interfaces utilisateur.
• NE DOIT PAS accorder d'autorisations d'exécution aux applications préinstallées, sauf si :
  • le consentement de l'utilisateur peut être obtenu avant que l'application ne l'utilise ;
  • les autorisations d'exécution sont associées à un modèle d'intent pour lequel l'application préinstallée est définie comme gestionnaire par défaut ;

9.2. UID et isolation des processus

Les implémentations d'appareils DOIVENT prendre en charge le modèle de bac à sable d'application Android, dans lequel chaque application s'exécute en tant qu'UID unique de style Unix et dans un processus distinct. Les implémentations d'appareils DOIVENT 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 défini dans la référence sur la sécurité et les autorisations [Ressources, 126].

9.3. Autorisations du système de fichiers

Les implémentations d'appareils DOIVENT prendre en charge le modèle d'autorisations d'accès aux fichiers Android tel que défini dans la référence sur la sécurité et les autorisations [Ressources, 126].

9.4. Environnements d'exécution alternatifs

Les implémentations d'appareils PEUVENT inclure des environnements d'exécution qui exécutent des applications à l'aide d'un autre logiciel ou d'une autre technologie que le format exécutable Dalvik ou le code natif. Toutefois, ces environnements d'exécution alternatifs NE DOIVENT PAS compromettre le modèle de sécurité Android ni la sécurité des applications Android installées, comme décrit dans cette section.

Les environnements d'exécution alternatifs DOIVENT eux-mêmes être des applications Android et respecter le modèle de sécurité Android standard, comme décrit ailleurs dans la section 9.

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>.

Les environnements d'exécution alternatifs NE DOIVENT PAS autoriser les applications à utiliser des fonctionnalités protégées par des autorisations Android limitées aux applications système.

Les environnements d'exécution alternatifs DOIVENT respecter le modèle de bac à sable Android. Plus précisément, les environnements d'exécution alternatifs:

• DOIT installer les applications via le PackageManager dans des bacs à sable Android distincts (ID utilisateur Linux, etc.).
• PEUT fournir un seul bac à sable Android partagé par toutes les applications utilisant l'environnement d'exécution alternatif.
• et les applications installées à l'aide d'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 d'ID utilisateur partagé et de certificat de signature.
• NE DOIT PAS se lancer avec, accorder ni être autorisé à accéder aux bacs à sable correspondant à d'autres applications Android.
• NE DOIT PAS être lancée avec, être accordée ou accorder à d'autres applications des droits d'accès du super-utilisateur (root) ou de tout autre ID utilisateur.

Les fichiers .apk des environnements d'exécution alternatifs PEUVENT être inclus dans l'image système d'une implémentation d'appareil, mais DOIVENT être signés avec une clé distincte de celle utilisée pour signer les autres applications incluses avec l'implémentation de l'appareil.

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. Si une application doit utiliser une ressource d'appareil pour laquelle une autorisation Android correspondante est disponible (appareil photo, GPS, etc.), le runtime alternatif DOIT informer l'utilisateur que l'application pourra accéder à cette ressource. Si l'environnement d'exécution n'enregistre pas les fonctionnalités de l'application de cette manière, l'environnement d'exécution DOIT lister toutes les autorisations détenues par l'environnement d'exécution lui-même lors de l'installation d'une application utilisant cet environnement d'exécution.

9.5. Compatibilité multi-utilisateur

Android est compatible avec plusieurs utilisateurs et prend en charge l'isolation complète des utilisateurs [Resources, 127]. Les implémentations d'appareils PEUVENT permettre l'utilisation de plusieurs utilisateurs, mais lorsqu'elles sont activées, elles DOIVENT respecter les exigences suivantes liées à la prise en charge du mode multi-utilisateur [Ressources, 128]:

• Les implémentations d'appareils qui ne déclarent pas l'indicateur de fonctionnalité android.hardware.telephony DOIVENT prendre en charge les profils dont l'accès est limité, une fonctionnalité qui permet aux propriétaires d'appareils de gérer des utilisateurs supplémentaires et leurs fonctionnalités sur l'appareil. Avec les profils restreints, les propriétaires d'appareils peuvent rapidement configurer des environnements distincts pour les utilisateurs supplémentaires, et gérer des restrictions plus précises dans les applications disponibles dans ces environnements.
• À l'inverse, les implémentations d'appareils qui déclarent le flag de fonctionnalité android.hardware.telephony NE DOIVENT PAS prendre en charge les profils limités, mais DOIVENT s'aligner sur l'implémentation des commandes AOSP pour autoriser /désactiver l'accès d'autres utilisateurs aux appels vocaux et aux SMS.
• Les implémentations d'appareils DOIVENT, pour chaque utilisateur, implémenter un modèle de sécurité conforme au modèle de sécurité de la plate-forme Android tel que défini dans le document de référence sur la sécurité et les autorisations des API [Ressources, 126].
• Chaque instance utilisateur sur un appareil Android DOIT disposer de répertoires de stockage externes distincts et isolés. Les implémentations d'appareils PEUVENT stocker les données de plusieurs utilisateurs sur le même volume ou le même système de fichiers. Toutefois, l'implémentation de l'appareil DOIT s'assurer que les applications appartenant à un utilisateur donné et exécutées en son nom ne peuvent pas lister, lire ni écrire des données appartenant à un autre utilisateur. Notez que les supports amovibles, tels que les emplacements pour cartes SD, peuvent permettre à un utilisateur d'accéder aux données d'un autre utilisateur via un PC hôte. Pour cette raison, les implémentations d'appareils qui utilisent des supports amovibles pour les API de stockage externe principales DOIVENT chiffrer le contenu de la carte SD si la multi-utilisateur est activée à l'aide d'une clé stockée uniquement sur des supports non amovibles accessibles uniquement au système. Comme cela rend les supports multimédias illisibles par un PC hôte, les implémentations d'appareils devront passer à MTP ou à un système similaire pour fournir aux PC hôtes un accès aux données de l'utilisateur actuel. Par conséquent, les implémentations d'appareils PEUVENT, mais NE DOIVENT PAS activer la multi-utilisation si elles utilisent des supports amovibles [Ressources, 129] pour le stockage externe principal.

9.6. Avertissement concernant les SMS premium

Android permet d'avertir les utilisateurs de tout message SMS sortant surtaxé [Ressources, 130]. Les SMS premium sont des messages envoyés à un service enregistré auprès d'un opérateur qui peuvent entraîner des frais pour l'utilisateur. Les implémentations d'appareils qui déclarent la prise en charge d'android.hardware.telephony DOIVENT avertir les utilisateurs avant d'envoyer un message SMS à des numéros identifiés par des expressions régulières définies dans le fichier /data/misc/sms/codes.xml de l'appareil. Le projet Android Open Source en amont fournit une implémentation qui répond à cette exigence.

9.7. Fonctionnalités de sécurité du noyau

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) et d'autres fonctionnalités de sécurité du noyau Linux. SELinux ou toute autre fonctionnalité de sécurité implémentée sous le framework Android:

• DOIT assurer la compatibilité avec les applications existantes.
• NE DOIT PAS comporter d'interface utilisateur visible lorsqu'une violation de sécurité est détectée et bloquée, mais PEUT comporter une interface utilisateur visible lorsqu'une violation de sécurité non bloquée se produit, ce qui entraîne un exploit réussi.
• NE DOIT PAS être configurable par l'utilisateur ni par le développeur.

Si une API de configuration de règles est exposée à une application pouvant affecter une autre application (telle qu'une API d'administration d'appareils), elle NE DOIT PAS autoriser les configurations qui compromettent la compatibilité.

Les appareils DOIVENT implémenter SELinux ou, s'ils utilisent un noyau autre que Linux, un système de contrôle d'accès obligatoire équivalent. Les appareils doivent également respecter les exigences suivantes, qui sont satisfaites par l'implémentation de référence dans le projet Open Source Android en amont.

Implémentations de l'appareil:

• DOIT définir SELinux sur le mode d'application forcée global.
• Vous devez configurer tous les domaines en mode d'application. Aucun domaine en mode permissif n'est autorisé, y compris les domaines spécifiques à un appareil/vendeur.
• NE DOIT PAS modifier, omettre ni remplacer les règles neverallow présentes dans le dossier external/sepolicy fourni dans le projet Android Open Source (AOSP) en amont. La stratégie DOIT compiler avec toutes les règles neverallow présentes, à la fois pour les domaines SELinux AOSP et les domaines spécifiques à l'appareil/au fournisseur.

Les implémentations d'appareils DOIVENT conserver la stratégie SELinux par défaut fournie dans le dossier external/sepolicy du projet Open Source Android en amont et ne doivent ajouter à cette stratégie que pour leur propre configuration spécifique à l'appareil. Les implémentations d'appareils DOIVENT être compatibles avec le projet Android Open Source en amont.

9.8. Confidentialité

Si l'appareil implémente une fonctionnalité dans le système qui capture les contenus affichés à l'écran et/ou enregistre le flux audio diffusé sur l'appareil, il DOIT informer l'utilisateur en continu chaque fois que cette fonctionnalité est activée et qu'elle capture/enregistre activement.

Si une implémentation d'appareil comporte un mécanisme qui achemine le trafic de données réseau via un serveur proxy ou une passerelle VPN par défaut (par exemple, le préchargement d'un service VPN avec android.permission.CONTROL_VPN accordé), l'implémentation de l'appareil DOIT demander le consentement de l'utilisateur avant d'activer ce mécanisme.

Si une implémentation d'appareil comporte un port USB compatible avec le mode périphérique USB, elle DOIT présenter une interface utilisateur demandant le consentement de l'utilisateur avant d'autoriser l'accès au contenu du stockage partagé via le port USB.

9.9. Chiffrement complet de disque

Si l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé qui signale "true" pour KeyguardManager.isDeviceSecure() [Ressources, 131] et qu'il ne s'agit pas d'un appareil dont la mémoire est limitée, comme indiqué par la méthode ActivityManager.isLowRamDevice(), l'appareil DOIT prendre en charge le chiffrement de disque complet [Ressources, 132] 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.

Pour les implémentations d'appareils compatibles avec le chiffrement de disque complet et dont les performances de chiffrement AES (Advanced Encryption Standard) dépassent 50 Mo/s, le chiffrement de disque complet DOIT être activé par défaut au moment où l'utilisateur a terminé l'expérience de configuration prête à l'emploi. Si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android avec le chiffrement de disque complet désactivé par défaut, cet appareil ne peut pas répondre à l'exigence via une mise à jour du logiciel système et peut donc être exempté.

Le chiffrement DOIT utiliser AES avec une clé de 128 bits (ou plus) et un mode conçu pour le stockage (par exemple, AES-XTS, AES-CBC-ESSIV). La clé de chiffrement NE DOIT PAS être écrite sur le stockage à tout moment sans être chiffrée. Sauf lorsqu'elle est utilisée, la clé de chiffrement DOIT être chiffrée AES avec le code de verrouillage de l'écran étiré à l'aide d'un algorithme d'étirement lent (par exemple, PBKDF2 ou scrypt). Si l'utilisateur n'a pas spécifié de code secret pour l'écran de verrouillage ou a désactivé l'utilisation du code secret pour le chiffrement, le système DOIT utiliser un code secret par défaut pour encapsuler la clé de chiffrement. Si l'appareil fournit un keystore intégré au matériel, l'algorithme d'étirement de mot de passe DOIT être lié de manière cryptographique à ce keystore. La clé de chiffrement NE DOIT PAS être envoyée en dehors de l'appareil (même lorsqu'elle est encapsulée avec le code secret de l'utilisateur et/ou la clé liée au matériel). Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité dm-crypt du noyau Linux.

9.10. démarrage validé

Le démarrage validé est une fonctionnalité qui garantit l'intégrité du logiciel de l'appareil. Si une implémentation d'appareil est compatible avec cette fonctionnalité, elle DOIT:

• Déclarer l'indicateur de fonctionnalité de plate-forme android.software.verified_boot
• Effectuer une vérification à chaque séquence de démarrage
• Démarrer la validation à partir d'une clé matérielle immuable qui est la racine de confiance, et remonter jusqu'à la partition système
• Implémentez chaque étape de validation pour vérifier l'intégrité et l'authenticité de tous les octets de l'étape suivante avant d'exécuter le code de l'étape suivante.
• Utilisez des algorithmes de validation aussi puissants que les recommandations actuelles du NIST pour les algorithmes de hachage (SHA-256) et les tailles de clé publique (RSA-2048).

Le projet Android Open Source en amont fournit une implémentation privilégiée de cette fonctionnalité basée sur la fonctionnalité dm-verity du noyau Linux.

À partir d'Android 6.0, les implémentations d'appareils avec des performances de cryptographie AES (Advanced Encryption Standard) supérieures à 50 Mo/s DOIVENT prendre en charge le démarrage validé pour l'intégrité de l'appareil. Si une implémentation d'appareil est déjà lancée sans prendre en charge le démarrage validé sur une version antérieure d'Android, cet appareil ne peut pas prendre en charge cette fonctionnalité avec une mise à jour du logiciel système et est donc exempté de cette exigence.

9.11. Clés et identifiants

Le système Android Keystore [Ressources, 133] permet aux développeurs d'applications de stocker des clés cryptographiques dans un conteneur et de les utiliser dans des opérations cryptographiques via l'API KeyChain [Ressources, 134] ou l'API Keystore [Ressources, 135].

Toutes les implémentations d'appareils Android DOIVENT respecter les exigences suivantes:

• NE DOIT PAS limiter le nombre de clés pouvant être générées et DOIT au moins permettre d'importer plus de 8 192 clés.
• L'authentification de l'écran de verrouillage DOIT limiter le nombre d'essais et DOIT comporter un algorithme de délai avant expiration exponentiel, tel qu'implémenté dans le projet Open Source Android.
• Lorsque l'implémentation de l'appareil est compatible avec un écran de verrouillage sécurisé et dispose d'un matériel sécurisé tel qu'un composant sécurisé (SE) où un environnement d'exécution sécurisé (TEE) peut être implémenté, les éléments suivants sont disponibles :
  • Nous vous recommandons vivement de sauvegarder l'implémentation du keystore avec le matériel sécurisé. Le projet Open Source Android en amont fournit l'implémentation de la couche d'abstraction matérielle (HAL) Keymaster qui peut être utilisée pour répondre à cette exigence.
  • DOIT effectuer l'authentification de l'écran de verrouillage dans le matériel sécurisé si l'appareil dispose d'une implémentation de keystore intégrée au matériel et n'autoriser l'utilisation des clés liées à l'authentification que si l'authentification aboutit. Le projet Open Source Android en amont fournit la couche d'abstraction matérielle (HAL) Gatekeeper qui peut être utilisée pour répondre à cette exigence [Resources, 136].

Notez que, bien que les exigences ci-dessus liées au TEE soient indiquées comme FORTEMENT RECOMMANDÉES, la définition de la compatibilité pour la prochaine version de l'API prévoit de les remplacer par "EXIGÉ". Si une implémentation d'appareil est déjà lancée sur une version antérieure d'Android et qu'elle n'a pas implémenté de système d'exploitation approuvé sur le matériel sécurisé, il est possible qu'un tel appareil ne puisse pas répondre aux exigences via une mise à jour logicielle du système. Il est donc fortement recommandé d'implémenter un TEE.

9.12. Suppression des données

Les appareils DOIVENT fournir aux utilisateurs un mécanisme permettant d'effectuer un "rétablissement de la configuration d'usine" qui permet de supprimer de manière logique et physique toutes les données, à l'exception de l'image système et des données d'autres partitions pouvant être considérées comme faisant partie de l'image système. Cette méthode doit respecter les normes du secteur applicables à la suppression des données, telles que la norme NIST SP800-88. Cette méthode DOIT être utilisée pour l'implémentation de l'API wipeData() (qui fait partie de l'API Android Device Administration) décrite dans la section 3.9 Administration des appareils.

Les appareils peuvent fournir un effacement rapide des données qui effectue un effacement logique des données.

10. Tests de compatibilité des logiciels

Les implémentations d'appareils DOIVENT réussir tous les tests décrits dans cette section.

Toutefois, notez qu'aucun package de test logiciel n'est totalement complet. Pour cette raison, il est FORTEMENT RECOMMANDÉ aux implémentateurs d'appareils d'apporter le moins de modifications possible à l'implémentation de référence et privilégiée d'Android disponible dans le projet Android Open Source. Cela réduit le risque d'introduire des bugs qui créent des incompatibilités nécessitant des retouches et des mises à jour potentielles de l'appareil.

10.1. Compatibility Test Suite

Les implémentations d'appareils DOIVENT réussir les tests de compatibilité Android (CTS) [Ressources, 137] disponibles sur le projet Android Open Source, à l'aide du logiciel final fourni sur l'appareil. En outre, les implémentateurs d'appareils DOIVENT utiliser autant que possible l'implémentation de référence dans l'arborescence Open Source Android et DOIVENT assurer la compatibilité en cas d'ambiguïté dans le CTS et pour toute réimplémentation de parties du code source de référence.

Le CTS est conçu pour être exécuté sur un appareil réel. Comme tout logiciel, le CTS peut lui-même contenir des bugs. La version du CTS sera gérée indépendamment de cette définition de la compatibilité. Plusieurs révisions du CTS peuvent être publiées pour Android 6.0. Les implémentations d'appareils DOIVENT réussir les tests de la dernière version de CTS disponible au moment où le logiciel de l'appareil est finalisé.

10.2. Validateur CTS

Les implémentations d'appareils DOIVENT exécuter correctement tous les cas applicables dans le vérificateur CTS. Le vérificateur CTS est inclus dans la suite de tests de compatibilité. Il est destiné à être exécuté par un opérateur humain pour tester les fonctionnalités qui ne peuvent pas être testées par un système automatisé, comme le bon fonctionnement d'une caméra et de capteurs.

Le vérificateur CTS propose des tests pour de nombreux types de matériel, y compris certains matériels facultatifs. Les implémentations d'appareils DOIVENT réussir tous les tests du matériel dont elles disposent. Par exemple, si un appareil possède un accéléromètre, il DOIT exécuter correctement le scénario de test de l'accéléromètre dans le vérificateur CTS. Les cas de test des fonctionnalités indiquées comme facultatives par ce document de définition de la compatibilité PEUVENT être ignorés ou omis.

Chaque appareil et chaque build DOIVENT exécuter correctement le vérificateur CTS, comme indiqué ci-dessus. Toutefois, comme de nombreuses versions sont très similaires, les implémentateurs d'appareils ne sont pas tenus d'exécuter explicitement le vérificateur CTS sur des versions qui ne diffèrent que de manière triviale. Plus précisément, les implémentations d'appareils qui ne diffèrent d'une implémentation ayant réussi le vérificateur CTS que par l'ensemble des paramètres régionaux, de la marque, etc. PEUVENT omettre le test du vérificateur CTS.

11. Logiciels pouvant être mis à jour

Les implémentations d'appareils DOIVENT inclure un mécanisme permettant de remplacer l'intégralité du logiciel système. Le mécanisme n'a pas besoin d'effectuer de mises à niveau "en direct". Autrement dit, un redémarrage de l'appareil peut être nécessaire.

N'importe quelle méthode peut être utilisée, à condition qu'elle puisse remplacer l'intégralité du logiciel préinstallé sur l'appareil. Par exemple, l'une des approches suivantes répond à cette exigence:

• Téléchargements OTA (Over The Air) avec mise à jour hors connexion via le redémarrage
• Mises à jour en mode "partage de connexion" via USB à partir d'un PC hôte
• Mises à jour "hors connexion" via un redémarrage et une mise à jour à partir d'un fichier sur un stockage amovible

Toutefois, si l'implémentation de l'appareil prend en charge une connexion de données non limitée, telle que le profil 802.11 ou le profil Bluetooth PAN (Personal Area Network) :

• Les implémentations Android Automotive DOIVENT prendre en charge les téléchargements OTA avec mise à jour hors connexion via un redémarrage.
• Toutes les autres implémentations d'appareils DOIVENT prendre en charge les téléchargements OTA avec mise à jour hors connexion via le redémarrage.

Le mécanisme de mise à jour utilisé DOIT être compatible avec 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.

Pour les implémentations d'appareils lancées avec Android 6.0 ou version ultérieure, le mécanisme de mise à jour DOIT permettre de vérifier que l'image système est identique au résultat attendu après une mise à jour OTA. L'implémentation OTA basée sur les blocs dans le projet Android Open Source en amont, ajoutée depuis Android 5.1, répond à cette exigence.

Si une erreur est détectée dans l'implémentation d'un appareil après sa sortie, mais dans la durée de vie raisonnable du produit déterminée en consultation avec l'équipe de compatibilité Android, et qu'elle affecte la compatibilité des applications tierces, l'implémentateur de l'appareil DOIT corriger l'erreur via une mise à jour logicielle disponible qui peut être appliquée conformément au mécanisme décrit ci-dessus.

Android inclut des fonctionnalités qui permettent à l'application propriétaire de l'appareil (si elle est présente) de contrôler l'installation des mises à jour du système. Pour faciliter cette tâche, le sous-système de mise à jour du système pour les appareils qui signalent android.software.device_admin DOIT implémenter le comportement décrit dans la classe SystemUpdatePolicy [ Ressources, 138].

12. Journal des modifications du document

Le tableau suivant récapitule les modifications apportées à la définition de la compatibilité dans cette version.

Section	Résumé des modifications
Divers	Occurrences du terme "recommandé" remplacées par "RECOMMANDÉ"
2. Types d'appareils	Mise à jour pour les implémentations Android Automotive
3.2.2. Paramètres de compilation	Ajouts pour le numéro de série du matériel et le niveau du correctif de sécurité d'un build
3.2.3.2. Résolution des intents	La section "Forcer un intent" a été rebaptisée "Résolution d'intent", avec de nouvelles exigences concernant l'association d'applications par défaut faisant autorité.
3.3.1. Interfaces binaires d'application	Ajouts pour la prise en charge de l'ABI Android ; modification liée au nom de la bibliothèque Vulkan
3.4.1. Compatibilité avec WebView	Modification de la chaîne user-agent signalée par la WebView
3.7. Compatibilité avec l'environnement d'exécution	Modifications apportées au tableau d'allocation de mémoire
3.8.4. Recherche	Informations sur les exigences concernant l'Assistant
3.8.6. Thèmes	Ajout de l'obligation de prendre en charge les icônes système noires lorsque le drapeau SYSTEM_UI_FLAG_LIGHT_STATUS_BAR est demandé
3.8.8. Changement d'activité	Assouplissement des exigences concernant le nombre de titres dans la vue d'ensemble
3.8.10. Contrôle des contenus multimédias sur l'écran de verrouillage	Contrôle multimédia de l'écran de verrouillage pour en savoir plus sur la section 3.8.3.
3.9.1. Provisionnement de l'appareil	Contient de nouvelles sections pour le provisionnement du propriétaire de l'appareil et le provisionnement du profil géré
3.9.2. Assistance pour les profils gérés	Nouvelle section avec les exigences concernant la prise en charge de la fonctionnalité de profil géré par les appareils
3.12.1. Application TV	Ajout d'une section pour clarifier les exigences concernant les applications TV pour les appareils Android TV
3.12.1.1. Guide des programmes électroniques	Ajout d'une section pour clarifier les exigences concernant l'EPG pour les appareils Android TV
3.12.1.2. Navigation	Ajout d'une section pour clarifier les exigences de navigation dans les applications TV pour les appareils Android TV
3.12.1.3. Association d'applications à une entrée TV	Ajout d'une section pour clarifier les exigences concernant la prise en charge de l'association d'applications d'entrée TV pour les appareils Android TV
5.1. Codecs multimédias	Informations sur la prise en charge des formats multimédias principaux et du décodage.
5.1.3. Codecs vidéo	Modifications et ajouts concernant les téléviseurs Android
5.2. Encodage vidéo	Modifications pour les encodeurs
5.3. Décodage vidéo	Modifications apportées aux décodeurs, y compris concernant la compatibilité avec la résolution vidéo dynamique, le changement de fréquence d'images, etc.
5.4. Enregistrement audio	Ajouts liés à la capture audio
5.6. Latence audio	Mise à jour concernant les rapports sur la prise en charge de l'audio à faible latence
5.10. Audio professionnel	Mises à jour générales pour la prise en charge de l'audio professionnel, mises à jour des spécifications des appareils mobiles (connecteur), du mode hôte audio USB et autres mises à jour
5.9. MIDI (Musical Instrument Digital Interface)	Ajout d'une section sur la compatibilité facultative avec l'interface MIDI (Musical Instrument Digital Interface)
6.1. Outils pour les développeurs	Mise à jour des pilotes compatibles avec Windows 10
7.1.1.3. Densité d'écran	Mises à jour de la densité d'écran, par exemple en lien avec une montre Android
7.2.3. Touches de navigation	Mise à jour des exigences pour les implémentations d'appareils incluant l'action d'assistance
7.3. Capteurs (et sous-sections)	Nouvelles exigences pour certains types de capteurs
7.3.9. Capteurs haute fidélité	Nouvelle section avec les exigences concernant les appareils compatibles avec les capteurs haute fidélité
7.3.10. Lecteur d'empreinte digitale	Nouvelle section sur les exigences liées aux lecteurs d'empreinte digitale
7.4.2. IEEE 802.11 (Wi-Fi)	Informations sur la prise en charge du multicast DNS (mDNS)
7.4.3. Bluetooth	Ajout concernant l'adresse privée résoluble (RPA) pour le Bluetooth Low Energy (BLE)
7.4.4. Communication en champ proche	Ajouts aux exigences concernant la technologie NFC (communication en champ proche)
7.4.5. Capacité réseau minimale	Ajout de conditions requises pour la compatibilité avec IPv6
7.6.3. Stockage adoptable	Nouvelle section pour l'implémentation du stockage adoptable
7.7. USB	Exigences liées à la mise en œuvre de la spécification AOA
7.8.3. Ultrasons proches	Ajouts liés à l'enregistrement, à la lecture et à l'audio en ultrason	Assouplissement des exigences concernant le rapport signal/bruit du micro à ultrasons
8.3. Modes d'économie d'énergie	Nouvelle section contenant les exigences concernant les modes Mise en veille des applications et Sommeil
8.4. Comptabilisation de la consommation d'énergie	Nouvelle section contenant les exigences concernant le suivi de la consommation d'énergie des composants matériels et l'attribution de cette consommation à des applications spécifiques
9.1. Autorisations	Ajout aux conditions d'autorisation
9.7. Fonctionnalités de sécurité du noyau	Mises à jour de SE Linux
9.8. Confidentialité	Ajout concernant le consentement de l'utilisateur pour accéder au stockage partagé via un port USB
9.9. Chiffrement complet de disque	Exigences concernant le chiffrement de disque
9.10. démarrage validé	Exigence supplémentaire pour le démarrage validé
9.11. Clés et identifiants	Nouvelle section d'exigences concernant les clés et les identifiants
9.12. Suppression des données	Nouvelle section pour "Rétablir la configuration d'usine"
11. Logiciels pouvant être mis à jour	Exigence liée à la règle de mise à jour du système définie par le propriétaire de l'appareil

13. Nous contacter

Vous pouvez rejoindre le forum de compatibilité Android [Ressources, 139] et demander des précisions ou soulever les problèmes que vous pensez que le document ne couvre pas.

14. Ressources

1. Niveaux d'exigences de la norme IETF RFC 2119: http://www.ietf.org/rfc/rfc2119.txt

2. Projet Android Open Source: http://source.android.com/

3. Fonctionnalités Android Television: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Fonctionnalité Android Watch: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API Android UI_MODE_TYPE_CAR: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

6. Définitions et documentation des API: http://developer.android.com/reference/packages.html

7. Documentation de référence sur les autorisations Android: http://developer.android.com/reference/android/Manifest.permission.html

8. Documentation android.os.Build: http://developer.android.com/reference/android/os/Build.html

9. Chaînes de version autorisées pour Android 6.0: http://source.android.com/docs/compatibility/6.0/versions.html

10. Paramètres du développeur Android: http://developer.android.com/reference/android/provider/Settings.html

11. Fournisseur de téléphonie: http://developer.android.com/reference/android/provider/Telephony.html

12. Gestion des ABI Android NDK: https://developer.android.com/ndk/guides/abis.html

13. Architecture SIMD avancée: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

14. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

15. Classe android.webkit.WebView: http://developer.android.com/reference/android/webkit/WebView.html

16. Compatibilité avec WebView: http://www.chromium.org/

17. HTML5: http://html.spec.whatwg.org/multipage/

18. Fonctionnalités hors connexion HTML5: http://dev.w3.org/html5/spec/Overview.html#offline

19. Balise vidéo HTML5: http://dev.w3.org/html5/spec/Overview.html#video

20. API de géolocalisation HTML5/W3C: http://www.w3.org/TR/geolocation-API/

21. API Webstorage HTML5/W3C: http://www.w3.org/TR/webstorage/

22. API IndexedDB HTML5/W3C: http://www.w3.org/TR/IndexedDB/

23. Format Dalvik Executable et spécification du bytecode: disponible dans le code source Android, à l'adresse dalvik/docs

24. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

25. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

26. Ressources d'application: https://developer.android.com/guide/topics/resources/available-resources.html

27. Guide de style des icônes de la barre d'état: http://developer.android.com/design/style/iconography.html

28. Ressources sur les notifications: https://developer.android.com/design/patterns/notifications.html

29. Gestionnaire de recherche: http://developer.android.com/reference/android/app/SearchManager.html

30. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

31. API Android Assist: https://developer.android.com/reference/android/app/assist/package-summary.html

32. Toasts: http://developer.android.com/reference/android/widget/Toast.html

33. Thèmes: http://developer.android.com/guide/topics/ui/themes.html

34. Classe R.style: http://developer.android.com/reference/android/R.style.html

35. Material Design: http://developer.android.com/reference/android/R.style.html#Theme_Material

36. Fonds d'écran animés: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

37. Ressources sur l'écran "Vue d'ensemble" : http://developer.android.com/guide/components/recents.html

38. Épinglage d'écran: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

39. Modes de saisie: http://developer.android.com/guide/topics/text/creating-input-method.html

40. Notification multimédia: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

41. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

42. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

43. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

44. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

45. Documentation DevicePolicyManager: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

46. Application du propriétaire de l'appareil: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Flux de provisionnement du propriétaire d'appareil Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. Provisionnement du propriétaire de l'appareil via NFC: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Application propriétaire du profil Android:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Flux de provisionnement de profil géré Android: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

51. API Android Accessibility Service: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

52. API d'accessibilité Android: http://developer.android.com/reference/android/view/accessibility/package-summary.html

53. Projet Eyes Free: http://code.google.com/p/eyes-free

54. API Text-to-Speech: http://developer.android.com/reference/android/speech/tts/package-summary.html

55. Television Input Framework: /devices/tv/index.html

56. Chaînes de l'application TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. Entrées TV tierces: /devices/tv/index.html#third-party_input_example

58. Entrées TV: /devices/tv/index.html#tv_inputs

59. Champs de l'EPG des chaînes de télévision: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. Association d'applications d'entrée TV: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

61. Documentation de référence des outils (pour adb, aapt, ddms et systrace): http://developer.android.com/tools/help/index.html

62. Description du fichier APK Android: http://developer.android.com/guide/components/fundamentals.html

63. Fichiers manifestes: http://developer.android.com/guide/topics/manifest/manifest-intro.html

64. Formats multimédias Android: http://developer.android.com/guide/appendix/media-formats.html

65. API Android MediaCodecList: http://developer.android.com/reference/android/media/MediaCodecList.html

66. API Android CamcorderProfile: http://developer.android.com/reference/android/media/CamcorderProfile.html

67. Projet WebM: http://www.webmproject.org/

68. Exigences de codage matériel RTC: http://www.webmproject.org/hardware/rtc-coding-requirements/

69. API AudioEffect: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

70. Classe android.content.pm.PackageManager et liste des fonctionnalités matérielles Android: http://developer.android.com/reference/android/content/pm/PackageManager.html

71. Draft Protocol HTTP Live Streaming: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

72. ADB: http://developer.android.com/tools/help/adb.html

73. Dumpsys: /devices/input/diagnostics.html

74. DDMS: http://developer.android.com/tools/debugging/ddms.html

75. Outil de test du singe: http://developer.android.com/tools/help/monkey.html

76. Outil Systrace: http://developer.android.com/tools/help/systrace.html

77. Paramètres liés au développement d'applications Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

78. Compatibilité avec plusieurs écrans: http://developer.android.com/guide/practices/screens_support.html

79. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

80. RenderScript: http://developer.android.com/guide/topics/renderscript/

81. Pack d'extensions Android pour OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

82. Accélération matérielle: http://developer.android.com/guide/topics/graphics/hardware-accel.html

83. Extension EGL-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

84. Gestionnaire d'affichage: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

85. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

86. Configuration de la saisie tactile: http://source.android.com/docs/core/interaction/input/touch-devices

87. API Motion Event: http://developer.android.com/reference/android/view/MotionEvent.html

88. API Key Event: http://developer.android.com/reference/android/view/KeyEvent.html

89. Capteurs Open Source Android: http://source.android.com/docs/core/interaction/sensors

90. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

91. Événement de capteur avec code temporel: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

92. Capteurs composites Android Open Source: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. Mode de déclenchement continu: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. API Android Fingerprint: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. HAL d'empreinte digitale Android: /devices/tech/security/authentication/fingerprint-hal.html

97. API Wi-Fi Multicast: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

98. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

99. API WifiManager: http://developer.android.com/reference/android/net/wifi/WifiManager.html

100. API Bluetooth: http://developer.android.com/reference/android/bluetooth/package-summary.html

101. API Bluetooth ScanFilter: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

102. Code-barres NFC: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. Protocole NDEF Push: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

104. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

105. Paramètres de partage NFC Android: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

106. Transfert de connexion NFC: http://members.nfc-forum.org/specs/spec_list/#conn_handover

107. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

108. Émulation de carte basée sur l'hôte: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

109. Résolveur de contenu: http://developer.android.com/reference/android/content/ContentResolver.html

110. API d'orientation de l'appareil photo: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

111. Caméra: http://developer.android.com/reference/android/hardware/Camera.html

112. Caméra: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

113. Niveau matériel de l'appareil photo: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

114. Compatibilité avec les versions de l'appareil photo: http://source.android.com/docs/core/camera/versioning

115. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

116. Android File Transfer: http://www.android.com/filetransfer

117. Stockage extensible: http://source.android.com/docs/core/storage/adoptable

118. Accessoires Android Open: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

119. Audio USB Android: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

120. Spécification de recharge de la batterie USB, version 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

121. API USB Host: http://developer.android.com/guide/topics/connectivity/usb/host.html

122. Casque audio filaire: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

123. Composants du profil d'alimentation: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. Résumé de la consommation d'énergie: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

126. Documentation de référence sur la sécurité et les autorisations Android: http://developer.android.com/guide/topics/security/permissions.html

127. Documentation de référence sur UserManager: http://developer.android.com/reference/android/os/UserManager.html

128. Référence sur le stockage externe: http://source.android.com/docs/core/storage/traditional

129. API de stockage externe: http://developer.android.com/reference/android/os/Environment.html

130. Code court SMS: http://en.wikipedia.org/wiki/Short_code

131. Signalement de l'écran de verrouillage sécurisé: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

132. Chiffrement Open Source Android: http://source.android.com/docs/security/features/encryption

133. Système Android Keystore: https://developer.android.com/training/articles/keystore.html

134. API KeyChain: https://developer.android.com/reference/android/security/KeyChain.html

135. API Keystore: https://developer.android.com/reference/java/security/KeyStore.html

136. HAL Gatekeeper: http://source.android.com/docs/security/features/authentication/gatekeeper

137. Présentation du programme de compatibilité Android: http://source.android.com/docs/compatibility

138. Classe SystemUpdatePolicy: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

139. Forum sur la compatibilité Android: https://groups.google.com/forum/#!forum/android-compatibility

140. Gérer les liens d'application: https://developer.android.com/training/app-links/index.html

141. Google Digital Asset Links: https://developers.google.com/digital-asset-links

Bon nombre de ces ressources sont dérivées directement ou indirectement du SDK Android et sont fonctionnellement identiques aux informations de la documentation de ce SDK. Dans tous les cas où cette définition de la compatibilité ou la suite de tests de compatibilité ne sont pas conformes à la documentation du SDK, la documentation du SDK est considérée comme faisant autorité. Tous les détails techniques fournis dans les références ci-dessus sont considérés comme faisant partie de cette définition de compatibilité.