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) [